jmv_10.a-r_lgd.pdf

1194 North Mathilda AvenueSunnyvale, CA 94089USA408-745-2000www.juniper.net

Worldwide Education ServicesWorldwide Education Services

Junos MPLS and VPNs10.a

Detailed Lab Guide

Course Number: EDU-JUN-JMV

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.

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.

Junos MPLS and VPNs Detailed Lab Guide, Revision 10.a

Copyright © 2010 Juniper Networks, Inc. All rights reserved.

Printed in USA.

Revision History:

Revision 10.a—December 2010

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 10.3R1.9. 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.

Contents • iii

Contents

Lab 1: MPLS Fundamentals (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1Part 1: Configuring Network Interfaces and Baseline Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2Part 2: Configuring Customer Edge Router and Network Interfaces . . . . . . . . . . . . . . . . . . . . . . .1-11Part 3: Configuring a Static LSP Through the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-20

Lab 2: Label Distribution Protocols (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1Part 1: Configuring Customer Edge Router and Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 2-2Part 2: Configuring RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7Part 3: Configuring a Explicit Route Object (ERO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-12Part 4: Configuring LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-15Part 5: Changing the Default Route Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-18

Lab 3: CSPF (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Part 1: Creating the Baseline Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Part 2: Enabling the TED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5Part 3: Configuring RSVP-Signaled LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-11Part 4: Adding Administrative Groups to Core-Facing Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . .3-14Part 5: Configuring LSPs to Take Gold, Silver, and Bronze Paths Using CSPF . . . . . . . . . . . . . . .3-16

Lab 4: Traffic Protection (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1Part 1: Creating the Baseline Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Part 2: Redistributing Routes into BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6Part 3: Creating an LSP to the Remote PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7Part 4: Configuring a Secondary Path for Added Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10Part 5: Configuring Secondary Standby Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-15Part 6: Examining a Secondary/Secondary Protected LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-23Part 7: Examining a Fast-Reroute Protected LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-28Part 8: Examining Link and Node-Link Protected LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-32

Lab 5: Miscellaneous MPLS Features (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Part 1: Configuring the Baseline Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Part 2: Configuring a RSVP LSP to Install a Route in the inet.0 Table . . . . . . . . . . . . . . . . . . . . 5-7Part 3: Configuring MPLS Traffic Engineering to Install an inet.0 Route . . . . . . . . . . . . . . . . .5-10Part 4: Using Policy to Control LSP Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13Part 5: Using LSP Metric to Control LSP Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-21Part 6: Configuring Your Router to Not Decrement the TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-24Part 7: Configuring Your Router to Signal Explicit Null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-25Part 8: Configuring Your Router to Automatically Adjust the RSVP Reservation Based on Observed

Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-27Part 9: Using MPLS Ping to Verify LSP Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-28

Lab 6: VPN Baseline Configuration (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1Part 1: Creating the Baseline SP Network and Enabling PE for Layer 3 VPN Signaling . . . . . . . . . 6-2Part 2: Configuring the CE Router Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6

iv • Contents

Lab 7: Layer 3 VPN with Static and BGP Routing (Detailed) . . . . . . . . . . . . . . . . . . . . . . 7-1Part 1: Loading and Verifying the VPN Baseline Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-2Part 2: Establishing an RSVP Signaled LSP Between PE Routers . . . . . . . . . . . . . . . . . . . . . . . . . .7-4Part 3: Configuring the PE to CE Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-6Part 4: Configuring a Layer 3 VPN Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-7Part 5: Configuring Static Routing Between the PE and CE Routers . . . . . . . . . . . . . . . . . . . . . . . .7-9Part 6: Configuring BGP Routing Between the PE and CE Routers . . . . . . . . . . . . . . . . . . . . . . . 7-13

Lab 8: Route Reflection and Internet Access (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . 8-1Part 1: Loading and Verifying the VPN Baseline Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2Part 2: Configuring Your PE Router to Peer with the Route Reflector . . . . . . . . . . . . . . . . . . . . . . .8-4Part 3: Establishing LDP Signaled LSPs Between PE Routers and Router Reflector . . . . . . . . . . .8-6Part 4: Configuring Another CE Router Using a Virtual Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8Part 5: Configuring the PE to CE Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10Part 6: Configuring Two Layer 3 VPN Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12Part 7: Configuring BGP Routing Between the PE and CE Routers . . . . . . . . . . . . . . . . . . . . . . . 8-14Part 8: Implementing Route Target Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22Part 9: Configuring Internet Access Using a Non-VRF Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8-28

Lab 9: GRE Tunnel Integration (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1Part 1: Loading and Verifying the VPN Baseline Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2Part 2: Configuring the PE to CE Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4Part 3: Configuring a Layer 3 VPN Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5Part 4: Configuring OSPF Routing Between the PE and CE Routers . . . . . . . . . . . . . . . . . . . . . . . .9-6Part 5: Establishing a GRE Tunnel Between PE Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-11Part 6: Creating and Adding a Static Route to inet.3 . . . . . . . . . . . . .9-13Part 7: Redistributing BGP Routes into OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-17

Lab 10: BGP Layer 2 VPNs (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-1Part 1: Loading and Verifying the VPN Baseline Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2Part 2: Establishing a LDP Signaled LSP Between PE Routers . . . . . . . . . . . . . . . . . . . . . . . . . . 10-4Part 3: Configuring the PE to CE Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5Part 4: Configuring a BGP Layer 2 VPN Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7Part 5: Configuring Routing Protocols on the CE Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11

Lab 11: Circuit Cross Connect and LDP Layer 2 Circuits (Detailed) . . . . . . . . . . . . . . . .11-1Part 1: Loading and Verifying the VPN Baseline Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2Part 2: Establishing an RSVP-Signaled LSP Between PE Routers . . . . . . . . . . . . . . . . . . . . . . . . 11-4Part 3: Configuring the PE to CE Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5Part 4: Configuring a LDP Layer 2 Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7Part 5: Configuring Routing Protocols on the CE Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10Part 6: Configuring a CCC Connection Between PE Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12

Lab 12: Virtual Private LAN Service (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-1Part 1: Loading and Verifying the VPN Baseline Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2Part 2: Adjusting the Properties of the Virtual Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4Part 3: Configuring a Virtual Switch Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5Part 4: Enabling LDP Signaling in the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6Part 5: Configuring an LDP VPLS Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9Part 6: Using MSTP to Prevent a Layer 2 Loop in a VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15Part 7: Adding a Subinterface to the Virtual Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20Part 8: Configuring the Virtual Switch Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-21Part 9: Configuring a BGP VPLS with Redundant Links between CE and PE Routers . . . . . . . 12-23

Contents • v

Lab 13: Carrier-of-Carrier VPNs (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-1Part 1: Loading and Verifying the VPN Baseline Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . .13-2Part 2: Configuring the Subscriber CE Router Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-4Part 3: Enabling MPLS in the Provider Backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-5Part 4: Configuring a Layer 3 VPN on the Provider PE Routers . . . . . . . . . . . . . . . . . . . . . . . . . . .13-6Part 5: Configuring the Customer CE Logical System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-8Part 6: Configuring the Customer PE Logical System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-14Part 7: Placing IBGP Learned Routes in inet.3 . . . . . . . . . . . . . . 13-17Part 8: Configuring a BGP VPLS Between Customer PE Routers . . . . . . . . . . . . . . . . . . . . . . . . 13-21

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

vi • Contents

www.juniper.net Course Overview • v

Course Overview

This five-day course is designed to provide students with MPLS-based virtual private network (VPN) knowledge and configuration examples. The course includes an overview of MPLS concepts such as control and forwarding plane, RSVP Traffic Engineering, LDP, Layer 3 VPNs, next-generation multicast virtual private networks (MVPNs), BGP Layer 2 VPNs, LDP Layer 2 Circuits, and virtual private LAN service (VPLS). This course also covers Junos operating system-specific implementations of Layer 2 control instances and active interface for VPLS. This course is based on the Junos OS Release 10.3R1.9.

Through demonstrations and hands-on labs, students will gain experience in configuring and monitoring the Junos OS and in device operations.

Objectives

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

• Explain common terms relating to MPLS.

• Explain routers and the way they forward MPLS packets.

• Explain packet flow and handling through a label-switched path (LSP).

• Describe the configuration and verification of MPLS forwarding.

• Understand the information in the Label Information Base.

• Explain the two label distribution protocols used by the Junos OS.

• Configure and troubleshoot RSVP-signaled and LDP-signaled LSPs.

• Explain the constraints of both RSVP and LDP.

• Explain the path selection process of RSVP without the use of the Constrained Shortest Path First (CSPF) algorithm.

• Explain the Interior Gateway Protocol (IGP) extensions used to build the Traffic Engineering Database (TED).

• Describe the CSPF algorithm and its path selection process.

• Describe administrative groups and how they can be used to influence path selection.

• Describe the default traffic protection behavior of RSVP-Signaled LSPs.

• Explain the use of primary and secondary LSPs.

• Explain LSP priority and preemption.

• Describe the operation and configuration of fast reroute.

• Describe the operation and configuration of link and node protection.

• Describe the LSP optimization options.

• Explain the purpose of several miscellaneous MPLS features.

• Explain the definition of the term “Virtual Private Network”.

• Describe the differences between provider-provisioned and customer-provisioned VPNs.

• Describe the differences between Layer 2 VPNs and Layer 3 VPNs.

• Explain the features of provider-provisioned VPNs supported by the Junos OS.

• Explain the roles of Provider (P) routers, Provider Edge (PE) routers, and Customer Edge (CE) routers.

• Describe the VPN-IPv4 address formats.

• Describe the route distinguisher use and formats.

• Explain the RFC 4364 control flow.

vi • Course Overview www.juniper.net

• Create a routing instance, assign interfaces, create routes, and import and export routes within the routing instance using route distinguishers and route targets.

• Explain the purpose of BGP extended communities and how to configure and use these communities.

• Describe the steps necessary for proper operation of a PE to CE dynamic routing protocol.

• Configure a simple Layer 3 VPN using a dynamic CE-PE routing protocol.

• Describe the routing-instance switch.

• Explain the issues with the support of traffic originating on multiaccess VPN routing and forwarding table (VRF table) interfaces.

• Use operational commands to view Layer 3 VPN control exchanges.

• Use operational commands to display Layer 3 VPN VRF tables.

• Monitor and troubleshoot PE-CE routing protocols.

• Describe the four ways to improve Layer 3 VPN scaling.

• Describe the three methods for providing Layer 3 VPN customers with Internet access.

• Describe how the auto-export command and routing table groups can be used to support communications between sites attached to a common PE router.

• Describe the flow of control and data traffic in a hub-and-spoke topology.

• Describe the various Layer 3 VPN class-of-service (CoS) mechanisms supported by the Junos OS.

• Explain the Junos OS support for generic routing encapsulation (GRE) and IP Security (IPsec) tunnels in Layer 3 VPNs.

• Describe the flow of control traffic and data traffic in a next-generation MVPN.

• Describe the configuration steps for establishing a next-generation MVPN.

• Monitor and verify the operation of next-generation MVPNs.

• Describe the purpose and features of a BGP Layer 2 VPN.

• Describe the roles of a CE device, PE router, and P router in a BGP Layer 2 VPN.

• Explain the flow of control traffic and data traffic for a BGP Layer 2 VPN.

• Configure a BGP Layer 2 VPN and describe the benefits and requirements of over-provisioning.

• Monitor and troubleshoot a BGP Layer 2 VPN.

• Explain the BGP Layer 2 VPN scaling mechanisms and route reflection.

• Describe the Junos OS BGP Layer 2 VPN CoS support.

• Describe the flow of control and data traffic for an LDP Layer 2 circuit.

• Configure an LDP Layer 2 circuit.

• Monitor and troubleshoot an LDP Layer 2 circuit.

• Describe and configure circuit cross-connect (CCC) MPLS interface tunneling.

• Describe the difference between Layer 2 MPLS VPNs and VPLS.

• Explain the purpose of the PE device, the CE device, and the P device.

• Explain the provisioning of CE and PE routers.

• Describe the signaling process of VPLS.

• Describe the learning and forwarding process of VPLS.

• Describe the potential loops in a VPLS environment.

www.juniper.net Course Overview • vii

• Configure BGP and LDP VPLS.

• Troubleshoot VPLS.

• Describe the Junos OS support for carrier of carriers.

• Describe the Junos OS support for interprovider VPNs.

Intended Audience

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

Course Level

Junos MPLS and VPNs (JMV) is an advanced-level course.

Prerequisites

Students should have intermediate-level networking knowledge and an understanding of the Open Systems Interconnection (OSI) model and the TCP/IP protocol suite. Students should also have familiarity with the Protocol Independent Multicast—Sparse Mode (PIM-SM) protocol. Students should also attend the Introduction to the Junos Operating System (IJOS), Junos Routing Essentials (JRE), and Junos Service Provider Switching (JSPX) courses prior to attending this class.

viii • Course Agenda www.juniper.net

Course Agenda

Day 1

Chapter 1: Course Introduction

Chapter 2: MPLS Fundamentals

Lab 1: MPLS Fundamentals

Chapter 3: Label Distribution Protocols

Lab 2: Label Distribution Protocols

Chapter 4: Constrained Shortest Path First

Lab 3: CSPF

Day 2

Chapter 5: Traffic Protection and LSP Optimization

Lab 4: Traffic Protection

Chapter 6: Miscellaneous MPLS Features

Lab 5: Miscellaneous MPLS Features

Chapter 7: VPN Review

Chapter 8: Layer 3 VPNs

Lab 6: VPN Baseline Configuration

Day 3

Chapter 9: Basic Layer 3 VPN Configuration

Lab 7: Layer 3 VPN with Static and BGP Routing

Chapter 10: Troubleshooting Layer 3 VPNs

Chapter 11: Layer 3 VPN Scaling and Internet Access

Lab 8: Route Reflection and Internet Access

Chapter 12: Layer 3 VPNs—Advanced Topics

Lab 9: GRE Tunnel Integration

Day 4

Chapter 13: Multicast VPNs

Chapter 14: BGP Layer 2 VPNs

Lab 10: BGP Layer 2 VPNs

Chapter 15: Layer 2 VPN Scaling and COS

Chapter 16: LDP Layer 2 Circuits

Lab 11: Circuit Cross Connect and LDP Layer Circuits

Chapter 17: Virtual Private LAN Service

Day 5

Chapter 18: VPLS Configuration

Lab 12: Virtual Private LAN Service

Chapter 19: Interprovider VPNs

Lab 13: Carrier-of-Carrier VPNs (Detailed)

www.juniper.net Document Conventions • ix

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.

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.

Defined and Undefined Syntax Variables

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

Style Description Usage Example

Franklin Gothic Normal text. Most of what you read in the Lab Guide and Student Guide.

Courier New Console text:

• Screen captures

• Noncommand-related syntax

GUI text elements:

• Menu names

• Text field entry

commit complete

Exiting configuration mode

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


Normal CLI

Normal GUI

No distinguishing variant. 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.


CLI Variable

GUI Variable

Text where variable value is already assigned.

policy my-peers

Click my-peers in the dialog.

CLI Undefined

GUI Undefined

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

Type set policy policy-name.

ping 10.0.x.y

Select File > Save, and type filename in the Filename field.

x • Additional Information 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 Junos MPLS and VPNs Detailed Lab Guide was developed and tested using software Release 10.3R1.9. Previous and later versions of software might behave differently so you should always consult the documentation and release notes for the version of code you are running before reporting errors.

This document is written and maintained by the Juniper Networks Education Services development team. Please send questions and suggestions for improvement to [email protected].

Technical Publications

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

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

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

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

Juniper Networks Support

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

www.juniper.net MPLS Fundamentals (Detailed) • Lab 1–110.a.10.3R1.9

Lab 1MPLS Fundamentals (Detailed)

Overview

This lab demonstrates configuration and monitoring of multiprotocol label switched path (MPLS) static label switched path (LSP) features on devices running the Junos operating system. In this lab, you use the command-line interface (CLI) to configure and monitor network interfaces, Open Shortest Path First (OSPF), Border Gateway Protocol (BGP), Virtual Routers and static MPLS LSPs.

The lab is available in two formats: a high-level format designed to make you think through each step and a detailed format that offers step-by-step instructions complete with sample output from most commands.

By completing this lab, you will perform the following tasks:

• Configure and verify proper operation of network interfaces.

• Configure and verify OSPF, BGP, and a virtual router.

• Configure and monitor a MPLS static LSP.

Junos MPLS and VPNs

Lab 1–2 • MPLS Fundamentals (Detailed) www.juniper.net

Part 1: Configuring Network Interfaces and Baseline Protocols

In this lab part, you will be using the lab diagram titled “Lab 1: Part 1—Static LSPs (Infrastructure)”. You will configure network interfaces on your assigned device. You will then verify that the interfaces are operational and that the system adds the corresponding routing table entries for the configured interfaces. After verifying your interfaces, you will configure the router to participate in the OSPF area 0.0.0.0. Once you have completed this, you will set up a internal BGP (IBGP) peering with the remote team’s router.

Step 1.1

Ensure you know what device you are assigned. Check with your instructor if necessary. Change all the x values on the Lab 1 topologies to reflect the correct value. This will help avoid any confusion during the configuration steps throughout the lab.

Step 1.2

Consult the management network diagram, provided by your instructor, to determine your device’s management address.

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 mxA-1, which uses 10.210.15.1 as its management IP address. The actual management subnet varies between delivery environments.

Note

The instructor will tell you the nature of your access and will provide you with the necessary details to access your assigned device.

Junos MPLS and VPNs

www.juniper.net MPLS Fundamentals (Detailed) • Lab 1–3

Step 1.3

Access the CLI at your station using either the console, Telnet, or Secure Shell (SSH) as directed by your instructor. The following example shows simple Telnet access to mxA-1 using the Secure CRT program.

Step 1.4

Log in as user lab with the password supplied by your instructor.

mxA-1 (ttyp0)

login: labPassword:

--- JUNOS 10.3R1.9 built 2010-08-13 12:48:28 UTClab@mxA-1>

Step 1.5

Enter configuration mode and load the reset configuration file jmv-reset-RouterName and commit. For example: team mxA-1 would load configuration file jmv-reset-mxA-1.

lab@mxA-1> configure Entering configuration mode

[edit]lab@mxA-1# load override jmv-reset-mxA-1 load complete

[edit]lab@mxA-1# commit commit complete

Junos MPLS and VPNs


Step 1.6

Navigate to the [edit interfaces] hierarchy level.

[edit]lab@mxA-1# edit interfaces

[edit interfaces]lab@mxA-1#

Step 1.7

Refer to the network diagram and configure the interfaces for your assigned device. Use the virtual local area network (VLAN) ID as the logical unit value for the tagged interface. Use logical unit 0 for all other interfaces. Remember to configure the loopback interface!

[edit interfaces]lab@mxA-1# set ge-1/0/0 vlan-tagging

[edit interfaces]lab@mxA-1# set ge-1/0/0 unit 2xy vlan-id 2xy

[edit interfaces]lab@mxA-1# set ge-1/0/0 unit 2xy family inet address 172.22.2xy.1/24


[edit interfaces]lab@mxA-1# set ge-1/0/1 unit 2xy vlan-id 2xy

[edit interfaces]lab@mxA-1# set ge-1/0/1 unit 2xy family inet address 172.22.2xy.1/24

[edit interfaces]lab@mxA-1# set lo0 unit 0 family inet address 192.168.x.y/32

Step 1.8

Display the interface configuration and ensure that it matches the details outlined on the network diagram for this lab. When you are comfortable with the interface configuration, issue the commit-and-quit command to activate the configuration and return to operational mode.

[edit interfaces]lab@mxA-1# show ge-1/0/0 { vlan-tagging; unit 210 { vlan-id 210; family inet { address 172.22.210.1/24; } }}

Junos MPLS and VPNs


ge-1/0/1 { vlan-tagging; unit 211 { vlan-id 211; family inet { address 172.22.211.1/24; } }}fxp0 { description "MGMT INTERFACE - DO NOT DELETE"; unit 0 { family inet { address 10.210.15.1/27; } }}lo0 { unit 0 { family inet { address 192.168.1.1/32; } }}

[edit interfaces]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 1.9

Issue the show interfaces terse command to verify the current state of the recently configured interfaces.

lab@mxA-1> show interfaces terse Interface Admin Link Proto Local Remotege-1/0/0 up up ge-1/0/0.210 up up inet 172.22.210.1/24 multiservicege-1/0/0.32767 up up multiservicelc-1/0/0 up up lc-1/0/0.32769 up up vplsge-1/0/1 up up ge-1/0/1.211 up up inet 172.22.211.1/24 multiservicege-1/0/1.32767 up up multiservicege-1/0/2 up up ge-1/0/3 up up ge-1/0/4 up up ge-1/0/5 up up ge-1/0/6 up up ge-1/0/7 up up ge-1/0/8 up up

Junos MPLS and VPNs


ge-1/0/9 up up ge-1/1/0 up downlc-1/1/0 up up lc-1/1/0.32769 up up vplsge-1/1/1 up downge-1/1/2 up downge-1/1/3 up downge-1/1/4 up up ge-1/1/5 up up ge-1/1/6 up up ge-1/1/7 up up ge-1/1/8 up up ge-1/1/9 up up ge-1/2/0 up downlc-1/2/0 up up lc-1/2/0.32769 up up vplsge-1/2/1 up downge-1/2/2 up downge-1/2/3 up downge-1/2/4 up downge-1/2/5 up downge-1/2/6 up downge-1/2/7 up downge-1/2/8 up downge-1/2/9 up downge-1/3/0 up downlc-1/3/0 up up lc-1/3/0.32769 up up vplsge-1/3/1 up downge-1/3/2 up downge-1/3/3 up downge-1/3/4 up downge-1/3/5 up downge-1/3/6 up downge-1/3/7 up downge-1/3/8 up downge-1/3/9 up downcbp0 up up demux0 up up dsc up up em0 up up em0.0 up up inet 10.0.0.4/8 128.0.0.4/2 inet6 fe80::200:ff:fe00:4/64 fec0::a:0:0:4/64 tnp 0x4 em1 up up em1.0 up up inet 10.0.0.4/8 128.0.0.4/2 inet6 fe80::200:1ff:fe00:4/64 fec0::a:0:0:4/64 tnp 0x4 fxp0 up up fxp0.0 up up inet 10.210.15.1/27 gre up up

Junos MPLS and VPNs


ipip up up irb up up lo0 up up lo0.0 up up inet 192.168.1.1 --> 0/0lo0.16384 up up inet 127.0.0.1 --> 0/0lo0.16385 up up inet lsi up up mtun up up pimd up up pime up up pip0 up up pp0 up up tap up up

Question: What are the Admin and Link states for the recently configured interfaces?

Answer: The configured interfaces should all show Admin and Link states of up, as shown in the previous output. If the configured interfaces are in the down state, contact your instructor.

Step 1.10

Issue the show route command to view the current route entries.

lab@mxA-1> show route

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

10.210.13.0/27 *[Direct/0] 19:49:58 > via fxp0.010.210.15.1/32 *[Local/0] 19:49:58 Local via fxp0.0172.22.210.0/24 *[Direct/0] 00:27:19 > via ge-1/0/0.210172.22.210.1/32 *[Local/0] 00:27:19 Local via ge-1/0/0.210172.22.211.0/24 *[Direct/0] 00:27:19 > via ge-1/0/1.211172.22.211.1/32 *[Local/0] 00:27:19 Local via ge-1/0/1.211192.168.1.1/32 *[Direct/0] 00:27:19 > via lo0.0

Junos MPLS and VPNs


Question: Does the routing table display an entry for all local interface addresses and directly connected networks?

Answer: The answer should be yes. If necessary, you can refer back to the network diagram and compare it with the displayed route entries.

Question: Are any routes currently hidden?

Answer: You can possibly see hidden routes depending on the environment and how the delivery rack was prepared. In this example, no hidden routes are present as indicated in the summary line towards the top of the sample output.

Step 1.11

Enter in to configuration mode and navigate to the [edit protocols ospf] hierarchy level.


[edit]lab@mxA-1# edit protocols ospf

[edit protocols ospf]lab@mxA-1#

Step 1.12

Configure the core facing interfaces in area 0.0.0.0. Remember to add the loopback interface.

[edit protocols ospf]lab@mxA-1# set area 0 interface ge-1/0/0.2xy

[edit protocols ospf]lab@mxA-1# set area 0 interface ge-1/0/1.2xy

[edit protocols ospf]lab@mxA-1# set area 0 interface lo0

Step 1.13

Activate the configuration changes and exit to operational mode. Issue the show ospf neighbor command.

Junos MPLS and VPNs


[edit protocols ospf]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1> show ospf neighbor Address Interface State ID Pri Dead172.22.210.2 ge-1/0/0.210 Full 192.168.5.1 128 36172.22.211.2 ge-1/0/1.211 Full 192.168.5.2 128 37

Question: Which neighbor state is shown for the listed interfaces?

Answer: The neighbor state for the ge-1/0/0.2xy and ge-1/0/1.2xy interfaces should be Full, as shown in the previous sample output. If you do not see the Full state for both interfaces, check your configuration.

Step 1.14

Using the ping utility, verify reachability to remote students interfaces. Remember to verify the loopback address.

lab@mxA-1> ping 172.22.2xy.1 rapid count 10 PING 172.22.212.1 (172.22.212.1): 56 data bytes!!!!!!!!!!--- 172.22.212.1 ping statistics ---10 packets transmitted, 10 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.500/0.524/0.695/0.057 ms

lab@mxA-1> ping 172.22.2xy.1 rapid count 10 PING 172.22.213.1 (172.22.213.1): 56 data bytes!!!!!!!!!!--- 172.22.213.1 ping statistics ---10 packets transmitted, 10 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.500/0.520/0.669/0.050 ms

lab@mxA-1> ping 192.168.x.y rapid count 10 PING 192.168.1.2 (192.168.1.2): 56 data bytes!!!!!!!!!!--- 192.168.1.2 ping statistics ---10 packets transmitted, 10 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.472/0.523/0.696/0.060 ms

Note

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

Junos MPLS and VPNs


Question: Are the ping tests successful?

Answer: Yes, the ping tests should be successful at this time. If your tests are not successful, check with the remote student team or your instructor.

Step 1.15

Enter in to configuration mode and define the autonomous system number designated for your network. Refer to the network diagram as necessary.


[edit]lab@mxA-1# set routing-options autonomous-system 65512

Step 1.16

Navigate to the [edit protocols bgp] hierarchy level. Configure a BGP group named my-int-group that establishes an internal BGP peering session with the remote team’s router. Refer to the network diagram for this lab as necessary.

[edit]lab@mxA-1# edit protocols bgp

[edit protocols bgp]lab@mxA-1# set group my-int-group type internal

[edit protocols bgp]lab@mxA-1# set group my-int-group local-address 192.168.x.y

[edit protocols bgp]lab@mxA-1# set group my-int-group neighbor 192.168.x.y

[edit protocols bgp]lab@mxA-1# commitcommit complete

Step 1.17

Issue the run show bgp summary command to view the current BGP summary information for your device.

[edit protocols bgp]lab@mxA-1# run show bgp summary Groups: 1 Peers: 1 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...192.168.1.2 65512 3 3 0 8 1 0/0/0/0 0/0/0/0

Junos MPLS and VPNs


Question: How many BGP neighbors does your router currently list?

Answer: Your router should list the one IBGP peer you defined previously in this lab part. If you do not see the IBGP peer, check your configuration. If necessary, consult with the remote team and the instructor.

Question: Does your session show an Active state?

Answer: You should not see an Active state on this peering. If you see this, check your configuration and consult with the remote team and the instructor.

STOP Do not proceed until the remote team finishes Part 1.

Part 2: Configuring Customer Edge Router and Network Interfaces

In this lab part, you will reference the lab diagram titled “Lab 1: Parts 2-3—Static LSPs”. You will configure a virtual router instance on your router, representing the customer edge (CE) router. You will configure the interfaces and networks needed to establish a external BGP (EBGP) peering between the customer edge router and your provider edge (PE) router. You will first configure your virtual router and all interfaces for both routers. Second you will configure the EBGP peering session between the two routers. Next you will advertise your loopback address from your CE device to your PE router. You will share these routes with your IBGP peer.

Step 2.1

Refer to the lab diagram to ensure you navigate to the correct virtual router name. Navigate to the [edit routing-instances cex-y] hierarchy and configure the instance to behave as a virtual router. Configure the interfaces that should be members of the virtual router. Make sure you include a loopback interface.

[edit]lab@mxA-1# edit routing-instances cex-y

[edit routing-instances ce1-1]lab@mxA-1# set instance-type virtual-router

Junos MPLS and VPNs


[edit routing-instances ce1-1]lab@mxA-1# set interface ge-1/1/4

[edit routing-instances ce1-1]lab@mxA-1# set interface lo0.1

Step 2.2

Review the virtual router configuration up to this point by issuing the command show.

[edit routing-instances ce1-1]lab@mxA-1# show instance-type virtual-router;interface ge-1/1/4.0; ## 'ge-1/1/4.0' is not definedinterface lo0.1; ## 'lo0.1' is not defined

Question: Do you see any issues with the current configuration?

Answer: You should notice that the interfaces that have been added to the virtual router need to be defined in the main instance.

Step 2.3

Navigate to the [edit interfaces] hierarchy. Configure both physical interfaces required for the connection to the virtual router. Configure unit 1 under the loopback interface. Consult the network diagram for proper IP addressing. After verifying your configuration, commit and exit to operational mode to verify connectivity.

[edit routing-instances ce1-1]lab@mxA-1# top edit interfaces

[edit interfaces]lab@mxA-1# set ge-1/0/4 unit 0 family inet address 10.0.xy.1/24

[edit interfaces]lab@mxA-1# set ge-1/1/4 unit 0 family inet address 10.0.xy.2/24

[edit interfaces]lab@mxA-1# set lo0 unit 1 family inet address 192.168.1x.y/32


lab@mxA-1>

Junos MPLS and VPNs


Step 2.4

Verify connectivity from CE to PE router using the ping utility.

lab@mxA-1> ping 10.0.xy.1 routing-instance cex-y PING 10.0.10.1 (10.0.10.1): 56 data bytes64 bytes from 10.0.10.1: icmp_seq=0 ttl=64 time=0.800 ms64 bytes from 10.0.10.1: icmp_seq=1 ttl=64 time=0.379 ms64 bytes from 10.0.10.1: icmp_seq=2 ttl=64 time=0.432 ms64 bytes from 10.0.10.1: icmp_seq=3 ttl=64 time=0.403 ms64 bytes from 10.0.10.1: icmp_seq=4 ttl=64 time=0.406 ms^C--- 10.0.10.1 ping statistics ---5packets transmitted, 5packets received, 0% packet lossround-trip min/avg/max/stddev = 0.379/0.473/0.800/0.147 ms

Step 2.5

Return to configuration mode and configure the main instance (PE) to establish an EBGP peering session, named my-ext-group, to your virtual router (CE). Verify configuration looks correct before moving on. Please refer to Lab 1: Part 2 and 3 network diagram for appropriate peer autonomous system numbers.



[edit protocols bgp]lab@mxA-1# set group my-ext-group type external

[edit protocols bgp]lab@mxA-1# set group my-ext-group peer-as 65x0y

[edit protocols bgp]lab@mxA-1# set group my-ext-group neighbor 10.0.xy.2

[edit protocols bgp]lab@mxA-1# show group my-ext-group type external;peer-as 65101;neighbor 10.0.10.2;

Note

Use Ctrl + c to stop a continuous ping operation.

Junos MPLS and VPNs


Question: Do you have to configure the group type as external?

Answer: No, the default group type for bgp is external. However, it is good practice to specify the type to ensure other people reviewing the configuration can differentiate between internal and external groups.

Step 2.6

Navigate to the [edit routing-instances cex-y] hierarchy and configure the autonomous system for the virtual router (CE). Next configure the EBGP group named my-ext-group, on the CE router. Once you are satisfied with the configuration commit and exit to operational mode and verify the neighborship is established before moving on to the next step.

[edit protocols bgp]lab@mxA-1# top edit routing-instances cex-y

[edit routing-instances ce1-1]lab@mxA-1# set routing-options autonomous-system 65x0y

[edit routing-instances ce1-1]lab@mxA-1# edit protocols bgp

[edit routing-instances ce1-1 protocols bgp]lab@mxA-1# set group my-ext-group type external

[edit routing-instances ce1-1 protocols bgp]lab@mxA-1# set group my-ext-group peer-as 65512

[edit routing-instances ce1-1 protocols bgp]lab@mxA-1# set group my-ext-group neighbor 10.0.xy.1

[edit routing-instances ce1-1 protocols bgp]lab@mxA-1# commit and-quitcommit completeExiting configuration mode

lab@mxA-1> show bgp summary Groups: 3 Peers: 3 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...10.0.10.1 65512 3 3 0 0 12 Establ ce1-1.inet.0: 0/0/0/010.0.10.2 65101 2 3 0 0 12 0/0/0/0 0/0/0/0192.168.1.2 65512 242 241 0 8 1:47:21 0/0/0/0 0/0/0/0

Junos MPLS and VPNs


Question: Is your EBGP peering established between your PE and CE routers?

Answer: Yes, you should see two new peerings for the recently configured EBGP. One should display as a normal peering (PE instance) and the other peering from the virtual router (CE) should display as a routing instance peering, identified by InstanceName.inet.0, followed by the route information.

Question: Are you sending any routes from your CE router?

Answer: No, at this time there should not be any routes being sent from the CE router.

Step 2.7

After you have verified all peers are up, enter configuration mode and issue the save jmv-lab1-RouterName-baseline command to save the configuration for future labs in this course. Consult your lab diagram to ensure you save the configuration with the correct router name. For example: team mxA-1 would issue the command: save jmv-lab1-mxA-1-baseline

lab@mxA-1> configureEntering configuration mode

[edit]lab@mxA-1# save jmv-lab1-RouterName-baseline Wrote 89 lines of configuration to 'jmv-lab1-mxA-1-baseline'

Step 2.8

Navigate to the [edit policy-options] hierarchy and configure a policy named ce-export-loopback. Allow your CE loopback address to be exported. After creating the policy, navigate to the virtual router and apply this new policy as an export policy to your EBGP group. Commit and exit to operational mode after you are satisfied with your configuration.

[edit]lab@mxA-1# edit policy-options

[edit policy-options]lab@mxA-1# set policy-statement ce-export-loopback term 1 from protocol direct

[edit policy-options]lab@mxA-1# set policy-statement ce-export-loopback term 1 from route-filter 192.168.1x.y exact

Junos MPLS and VPNs


[edit policy-options]lab@mxA-1# set policy-statement ce-export-loopback term 1 then accept

[edit policy-options]lab@mxA-1# top edit routing-instances cex-y

[edit routing-instances ce1-1]lab@mxA-1# set protocols bgp group my-ext-group export ce-export-loopback

[edit routing-instances ce1-1]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 2.9

Verify that you are advertising the loopback address to your EBGP peer. Next verify you are advertising the EBGP route from your PE router to your IBGP peer.

lab@mxA-1> show route advertising-protocol bgp 10.0.xy.1

ce1-1.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 192.168.11.1/32 Self I

lab@mxA-1> show route advertising-protocol bgp 192.168.x.y

inet.0: 41 destinations, 41 routes (41 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 192.168.11.1/32 10.0.10.2 100 65101 I

Step 2.10

Verify that you are receiving the remote CE loopback from your IBGP neighbor. The total destination routes may differ in your outputs.

lab@mxA-1> show route receive-protocol bgp 192.168.x.y

inet.0: 42 destinations, 42 routes (41 active, 0 holddown, 1 hidden)

ce1-1.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

lab@mxA-1>

Note


Junos MPLS and VPNs


Question: Where is the route the remote peer is advertising to us?

Answer: It is being received but is stored as a hidden route, which indicates you might have a problem.

Step 2.11

Take an extensive look at the hidden route and determine why the route is hidden.

lab@mxA-1> show route 192.168.1x.y hidden extensive

inet.0: 42 destinations, 42 routes (41 active, 0 holddown, 1 hidden)192.168.11.2/32 (1 entry, 0 announced) BGP Preference: 170/-101 Next hop type: Unusable Next-hop reference count: 1 State: <Hidden Int Ext> Local AS: 65512 Peer AS: 65512 Age: 1:02:44 Task: BGP_65512.192.168.1.2+59586 AS path: 65102 I Accepted Localpref: 100 Router ID: 192.168.1.2 Indirect next hops: 1 Protocol next hop: 10.0.11.2 Indirect next hop: 0 -

Question: Why is the route hidden?

Answer: The route is hidden because the next hop is unusable. This is indicating we do not have a route to the protocol next hop and can not determine the physical next hop needed to install this route.

Junos MPLS and VPNs


Question: How do you fix this problem and get the route to be a usable route?

Answer: Because you do not know about the network that connects the remote PE router to the remote CE router, you must change the next hop advertised for that route. You must create a policy to change the next hop of the route before advertising the route to your peer. Then the remote team should be able to install and use the route you are advertising.

Step 2.12

Enter into configuration mode. Navigate to the [edit policy-options] hierarchy and create the policy named nhs. Configure this policy to take all bgp routes learned from your CE neighbor and change the next-hop to itself before advertising these routes to your remote IBGP peer. Apply this policy as an export policy to the BGP group my-int-group. After you are satisfied with your policy and configuration commit your changes and exit to operational mode.



[edit policy-options]lab@mxA-1# set policy-statement nhs term 1 from protocol bgp

[edit policy-options]lab@mxA-1# set policy-statement nhs term 1 then next-hop self

[edit policy-options]lab@mxA-1# set policy-statement nhs term 1 then accept

[edit policy-options]lab@mxA-1# top edit protocols bgp group my-int-group

[edit protocols bgp group my-int-group]lab@mxA-1# set export nhs

[edit protocols bgp group my-int-group]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Junos MPLS and VPNs


Step 2.13

Verify that the remote loopback address is now usable and installed in the routing table.




Question: Do you see the route now?

Answer: Yes, you should now see the route for the remote CE loopback. If you do not see this route please review your configuration and consult with the remote team to verify correct configuration. If necessary, please consult the instructor.

Step 2.14

Verify you are receiving and installing the route to the remote CE router in your virtual router.

lab@mxA-1> show route receive-protocol bgp 10.0.xy.1


ce1-1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 192.168.11.2/32 10.0.10.1 65512 65102 I

lab@mxA-1> show route table cex-y.inet.0

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

10.0.10.0/24 *[Direct/0] 03:29:45 > via ge-1/1/4.010.0.10.2/32 *[Local/0] 03:29:45 Local via ge-1/1/4.0192.168.11.1/32 *[Direct/0] 03:29:45 > via lo0.1

Note


Junos MPLS and VPNs


192.168.11.2/32 *[BGP/170] 00:08:57, localpref 100 AS path: 65512 65102 I > to 10.0.10.1 via ge-1/1/4.0

Question: Is the route present in your CE routing table?

Answer: Yes, you should now see the route in your routing instance table.


Part 3: Configuring a Static LSP Through the Core

In this lab part, you will reference the lab diagram titled “Lab 1: Parts 2-3—Static LSPs”. You will configure a static LSP that will be used for traffic that is destined to the network connected to the remote PE router. After configuring the LSP we will verify CE to CE router communication through the static LSP.

Step 3.1

Enter into configuration mode and navigate to the [edit interfaces] hierarchy. Configure the core facing interface to allow MPLS traffic.



[edit interfaces]lab@mxA-1# set ge-1/0/0 unit 2xy family mpls

Step 3.2

Navigate to [edit protocols mpls] hierarchy and add the interface all statement. As good practice please be sure to disable the management interface.

[edit interfaces]lab@mxA-1# top edit protocols mpls

[edit protocols mpls]lab@mxA-1# set interface all

[edit protocols mpls]lab@mxA-1# set interface fxp0 disable

Junos MPLS and VPNs


Step 3.3

Commit the configuration changes. Issue the command run show route table mpls.0 command to verify that the mpls table has been created.

[edit protocols mpls]lab@mxA-1# commit commit complete

[edit protocols mpls]lab@mxA-1# run show route table mpls.0

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

0 *[MPLS/0] 00:09:13, metric 1 Receive1 *[MPLS/0] 00:09:13, metric 1 Receive2 *[MPLS/0] 00:09:13, metric 1 Receive

Question: What are the routes that you see?

Answer: You should see the three labels that are automatically created. Packets received with these label values are sent to the Routing Engine for processing. Label 0 is the IPv4 explicit null label, Label 1 is the MPLS equivalent of the IP Router Alert label and Label 2 is the IPv6 explicit null label.

Step 3.4

Review the interfaces that are participating in MPLS to ensure we have the proper configuration by executing the run show mpls interface command.

[edit protocols mpls]lab@mxA-1# run show mpls interface Interface State Administrative groupsge-1/0/0.210 Up <none>

Question: What interface do you see?

Answer: You should see the interface you configured family mpls under. If you see something other than this interface, please review your configuration and contact your instructor.

Junos MPLS and VPNs


Step 3.5

Create a static LSP named my-static-lsp with the egress address of the remote PE loopback.

[edit protocols mpls]lab@mxA-1# set static-label-switched-path my-static-lsp ingress to 192.168.x.y

Step 3.6

Navigate to the [edit protocols mpls static-label-switched-path my-static-lsp ingress] hierarchy. Configure the next-hop for the LSP and assign the appropriate label to the LSP. Please consult the lab diagram titled “Lab 1: Parts 2-3—Static LSPs” for the path and label to be assigned. Review your configuration and after you are satisfied with the configuration, commit the changes and exit to operational mode.

[edit protocols mpls]lab@mxA-1# edit static-label-switched-path my-static-lsp ingress

[edit protocols mpls static-label-switched-path my-static-lsp ingress]lab@mxA-1# set next-hop 172.22.2xy.2

[edit protocols mpls static-label-switched-path my-static-lsp ingress]lab@mxA-1# set push 1000x0y

[edit protocols mpls static-label-switched-path my-static-lsp ingress]lab@mxA-1# show next-hop 172.22.210.2;to 192.168.1.2;push 1000101;

[edit protocols mpls static-label-switched-path my-static-lsp ingress]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 3.7

Issue the show mpls static-lsp ingress command to view the current status of the recently configured LSP.

lab@mxA-1> show mpls static-lsp ingress Ingress LSPs:LSPname To Statemy-static-lsp 192.168.1.2 UpTotal 1, displayed 1, Up 1, Down 0

Question: What is the state of the static LSP?

Answer: The state of the static LSP should be Up.

Junos MPLS and VPNs


Step 3.8

Review the route being used for the remote CE router’s loopback by issuing the show route 192.168.1x.y command.

lab@mxA-1> show route 192.168.1x.y


192.168.11.2/32 *[BGP/170] 02:23:46, localpref 100, from 192.168.1.2 AS path: 65102 I > to 172.22.210.2 via ge-1/0/0.210, Push 1000101



Question: How do you determine that the static LSP is going to be used when directing traffic to this destination?

Answer: Careful review of the route installed in the inet.0 table shows that there is a label value of 1000x0y that will be pushed into the packet. This indicates that the packet will be sent with a label into the MPLS LSP and will be forwarded by the next-hop router based on this label.

Step 3.9

Look at the traffic statistics for traffic traversing our new LSP. Execute the show mpls static-lsp statistics ingress command to view the statistics for the traffic the enters the LSP at this router.

lab@mxA-1> show mpls static-lsp statistics ingressIngress LSPs:LSPname To State Packets Bytesmy-static-lsp 192.168.1.2 Up 0 0Total 1, displayed 1, Up 1, Down 0

Step 3.10

Test the LSP by using the ping utility from the virtual router by executing the ping 192.168.1x.y source 192.168.1x.y count 10 rapid routing-instance cex-y command.

lab@mxA-1> ping 192.168.1x.y source 192.168.1x.y count 10 rapid routing-instance cex-yPING 192.168.11.2 (192.168.11.2): 56 data bytes

Junos MPLS and VPNs


!!!!!!!!!!--- 192.168.11.2 ping statistics ---10 packets transmitted, 10 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.554/0.577/0.687/0.037 ms

Step 3.11

Look at the LSP statistics to verify that the traffic traversed the LSP.

lab@mxA-1> show mpls static-lsp statistics ingress Ingress LSPs:LSPname To State Packets Bytesmy-static-lsp 192.168.1.2 Up 10 880Total 1, displayed 1, Up 1, Down 0

Question: How many packets do you see that traversed through the LSP?

Answer: You should see that 10 packets have traversed through the LSP. These are the 10 ping packets that were just sent to the remote CE. If the remote team in your pod has also completed this task you will see 20 ping packets.

STOP Tell your instructor that you have completed Lab 1.

www.juniper.net Label Distribution Protocols (Detailed) • Lab 2–110.a.10.3R1.9

Lab 2Label Distribution Protocols (Detailed)

Overview

This lab demonstrates configuration and monitoring of Resource Reservation Protocol (RSVP) and Label Distribution (LDP) signalled label switched path (LSP) features on routers running the Junos operating system. In this lab, you use the command-line interface (CLI) to configure and monitor network interfaces, Border Gateway Protocol (BGP), Virtual Routers, RSVP LSPs, and LDP LSPs.



• Configure and verify proper operation of network interfaces.

• Configure and verify BGP, and a virtual router.

• Configure and monitor a RSVP LSP.

• Modify RSVP LSP by explicitly defining path requirements.

• Configure and monitor a LDP LSP.

• Manipulate the default behavior of RSVP and LDP, depending on network requirements.

Junos MPLS and VPNs

Lab 2–2 • Label Distribution Protocols (Detailed) www.juniper.net

Part 1: Configuring Customer Edge Router and Network Interfaces

In this lab part, you will reference the lab diagram titled “Lab 2: Label Distribution Protocols”. You will configure the virtual router representing the customer edge (CE) router. You will configure the interfaces and networks needed to establish an external BGP (EBGP) peering between the customer edge router and your provider edge (PE) router. You will first configure your virtual router and all interfaces for both routers. Second, you will configure the EBGP peering session between the two routers. Next, you will advertise your loopback address from your CE device to your PE router. You will share these routes with your internal BGP (IBGP) peer.

Step 1.1

Enter into configuration mode and load the baseline configuration that you saved in Lab 1 by executing the load override jmv-lab1-RouterName-baseline command. Once the configuration has been loaded, commit the changes and exit to operational mode. Verify your Open Shortest Path First (OSPF) neighborships are up and operational.


[edit]lab@mxA-1# load override jmv-lab1-mxA-1-baseline load complete

[edit]lab@mxA-1# commit and-quit commit completeExiting configuration mode


Step 1.2

Verify connectivity from CE to PE router using the ping utility.

lab@mxA-1> ping 10.0.xy.1 routing-instance cex-y PING 10.0.10.1 (10.0.10.1): 56 data bytes64 bytes from 10.0.10.1: icmp_seq=0 ttl=64 time=0.800 ms64 bytes from 10.0.10.1: icmp_seq=1 ttl=64 time=0.379 ms64 bytes from 10.0.10.1: icmp_seq=2 ttl=64 time=0.432 ms64 bytes from 10.0.10.1: icmp_seq=3 ttl=64 time=0.403 ms64 bytes from 10.0.10.1: icmp_seq=4 ttl=64 time=0.406 ms^C--- 10.0.10.1 ping statistics ---5packets transmitted, 5packets received, 0% packet lossround-trip min/avg/max/stddev = 0.379/0.473/0.800/0.147 ms

Junos MPLS and VPNs

www.juniper.net Label Distribution Protocols (Detailed) • Lab 2–3

Step 1.3

Verify the BGP neighbor relationship is established before moving on to the next step.

lab@mxA-1> show bgp summary Groups: 3 Peers: 3 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...10.0.10.1 65512 3 3 0 0 12 Establ ce1-1.inet.0: 0/0/0/010.0.10.2 65101 2 3 0 0 12 0/0/0/0 0/0/0/0192.168.1.2 65512 242 241 0 8 1:47:21 0/0/0/0 0/0/0/0

Step 1.4

Enter back into configuration mode. Navigate to the [edit policy-options] hierarchy and configure a policy named vr-export-loopback. Allow your CE router loopback address to be accepted. After creating the policy, navigate to the virtual router and apply this new policy as an export policy to your EBGP group. Commit and exit to operational mode after you are satisfied with your configuration.



[edit policy-options]lab@mxA-1# set policy-statement vr-export-loopback term 1 from protocol direct

[edit policy-options]lab@mxA-1# set policy-statement vr-export-loopback term 1 from route-filter 192.168.1x.y exact

[edit policy-options]lab@mxA-1# set policy-statement vr-export-loopback term 1 then accept

[edit policy-options]lab@mxA-1# top edit routing-instances cex-y

[edit routing-instances ce1-1]lab@mxA-1# set protocols bgp group my-ext-group export vr-export-loopback


lab@mxA-1>

Junos MPLS and VPNs


Step 1.5

Verify that you are advertising the loopback address to your EBGP peer. Next, verify you are advertising the EBGP route from your PE router to your IBGP peer.


ce1-1.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 192.168.11.1/32 Self I



Step 1.6

Verify that you are receiving the remote CE router loopback from your IBGP neighbor.




lab@mxA-1>

Step 1.7

Take an extensive look at the hidden route and determine why the route is hidden.

lab@mxA-1> show route 192.168.1x.y hidden extensive

inet.0: 42 destinations, 42 routes (41 active, 0 holddown, 1 hidden)192.168.11.2/32 (1 entry, 0 announced) BGP Preference: 170/-101 Next hop type: Unusable Next-hop reference count: 1 State: <Hidden Int Ext> Local AS: 65512 Peer AS: 65512 Age: 1:02:44 Task: BGP_65512.192.168.1.2+59586 AS path: 65102 I Accepted Localpref: 100 Router ID: 192.168.1.2 Indirect next hops: 1 Protocol next hop: 10.0.11.2 Indirect next hop: 0 -

Note


Junos MPLS and VPNs


Question: Why is the route hidden?

Answer: The route is hidden because the next hop is unusable. This is indicating we do not have a route to the protocol next hop and cannot determine the physical next hop needed to install this route.

Question: How do we fix this problem and get the route to be a usable route?

Answer: Because we do not know about the network that connects the remote PE router to the remote CE router, we must change the next hop advertised for that route. We must create a policy to change the next hop of the route before advertising the route to our peer. Then the remote team should be able to install and use the route we are advertising.

Step 1.8

Enter into configuration mode. Navigate to the [edit policy-options] hierarchy and create the policy named nhs. Configure this policy to take all BGP routes learned from your CE neighbor and change the next hop to itself before advertising these routes to your remote IBGP peer. Apply this policy as an export policy to the BGP group my-int-group. After you are satisfied with your policy and configuration commit your changes and exit to operational mode.



[edit policy-options]lab@mxA-1# set policy-statement nhs term 1 from protocol bgp

[edit policy-options]lab@mxA-1# set policy-statement nhs term 1 then next-hop self

[edit policy-options]lab@mxA-1# set policy-statement nhs term 1 then accept

[edit policy-options]lab@mxA-1# top edit protocols bgp group my-int-group

[edit protocols bgp group my-int-group]lab@mxA-1# set export nhs

Junos MPLS and VPNs



lab@mxA-1>

Step 1.9

Verify that the remote loopback address is now usable and installed in the routing table.




Question: Do you see the route now?

Answer: Yes, you should now see the route for the remote CE loopback. If you do not see this route please review your configuration and consult with the remote team to verify correct configuration. If necessary, please consult the instructor.

Step 1.10

Verify you are receiving and installing the route to the remote CE router in your virtual router.



ce1-1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 192.168.11.2/32 10.0.10.1 65512 65102 I

lab@mxA-1> show route table cex-y.inet.0


Note


Junos MPLS and VPNs


10.0.10.0/24 *[Direct/0] 03:29:45 > via ge-1/1/4.010.0.10.2/32 *[Local/0] 03:29:45 Local via ge-1/1/4.0192.168.11.1/32 *[Direct/0] 03:29:45 > via lo0.1192.168.11.2/32 *[BGP/170] 00:08:57, localpref 100 AS path: 65512 65102 I > to 10.0.10.1 via ge-1/1/4.0

Question: Is the route present in your CE routing table?

Answer: Yes, you should now see the route in your routing instance table.


Part 2: Configuring RSVP

In this lab part, you will continue using the Lab 2 network diagram. You will configure a RSVP signaled LSP that will be used for traffic that is destined to the network connected to the remote PE router. After configuring the LSP we will verify CE to CE router communication through the RSVP LSP.

Step 2.1

Enter into configuration mode and navigate to the [edit interfaces] hierarchy. Configure the core facing interfaces to allow multiprotocol label switching (MPLS) traffic.





Junos MPLS and VPNs


Step 2.2

Navigate to [edit protocols mpls] hierarchy and add the interface all statement. As good practice please be sure to disable the management interface.

[edit interfaces]lab@mxA-1# top edit protocols mpls

[edit protocols mpls]lab@mxA-1# set interface all

[edit protocols mpls]lab@mxA-1# set interface fxp0 disable

Step 2.3

Commit the configuration changes and review the interfaces that are participating in MPLS to ensure we have the proper configuration by executing the run show mpls interface command.

[edit protocols mpls]lab@mxA-1# commit commit complete

[edit protocols mpls]lab@mxA-1# run show mpls interface Interface State Administrative groupsge-1/0/0.210 Up <none>ge-1/0/1.211 Up <none>

Step 2.4

Navigate to the [edit protocols rsvp] hierarchy. Add the appropriate core facing interfaces manually. Remember that you must specify the correct unit number when adding interfaces to any protocol configuration. The default Junos OS behavior is to assume unit 0 if no unit is specified. Review the configuration before committing to ensure the interfaces are correct.

[edit protocols mpls]lab@mxA-1# top edit protocols rsvp

[edit protocols rsvp]lab@mxA-1# set interface ge-1/0/0.2xy

[edit protocols rsvp]lab@mxA-1# set interface ge-1/0/1.2xy

[edit protocols rsvp]lab@mxA-1# show interface ge-1/0/0.210;interface ge-1/0/1.211;

[edit protocols rsvp]lab@mxA-1# commit commit complete

Junos MPLS and VPNs


Step 2.5

Add the configuration for creating the LSP. Navigate to the [edit protocols mpls] hierarchy. First, turn off constrained shortest path first (CSPF) by issuing the set no-cspf command. Next, create a label-switched-path named pey-to-pez-x. For example, if you are assigned router mxA-1, your peer router is mxA-2. The LSP should be named pe1-to-pe2-1. Your LSP should egress at your remote peer’s loopback address. Verify that the configuration looks correct. Commit and exit to operation mode when you are satisfied with the changes.

[edit protocols rsvp]lab@mxA-1# top edit protocols mpls

[edit protocols mpls]lab@mxA-1# set no-cspf

[edit protocols mpls]lab@mxA-1# set label-switched-path pey-to-pez-x to 192.168.x.y

[edit protocols mpls]lab@mxA-1# show no-cspf;label-switched-path pe1-to-pe2-1 { to 192.168.1.2;}interface all;interface fxp0.0 { disable;}

[edit protocols mpls]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Note

It is perfectly acceptable to use the interface all option when adding the interfaces into RSVP. For this lab, however, we ask that you explicitly identify the interfaces to demonstrate the importance of including the correct unit number when manually configuring particular interfaces.

Junos MPLS and VPNs


Step 2.6

Verify the status of your recently configured LSP reviewing the information displayed by issuing the show mpls lsp command.

lab@mxA-1> show mpls lsp Ingress LSP: 1 sessionsTo From State Rt P ActivePath LSPname192.168.1.2 192.168.1.1 Up 1 * pe1-to-pe2-1Total 1 displayed, Up 1, Down 0

Egress LSP: 1 sessionsTo From State Rt Style Labelin Labelout LSPname 192.168.1.1 192.168.1.2 Up 0 1 FF 3 - pe2-to-pe1-1Total 1 displayed, Up 1, Down 0

Transit LSP: 0 sessionsTotal 0 displayed, Up 0, Down 0

Question: How many LSPs are reflected in the output and what are the terminating points?

Answer: If the remote team has finished configuring their LSP, you should see two LSPs. The LSP you configured should be displayed under the Ingress section and the other should be displayed under the Egress section. If the remote team has not finished their configuration you will only see the entry under the Ingress section. The terminating points of both LSP should be the loopback address of the ingress and egress routers.

Question: Can you tell what path the LSP signaled over?

Answer: No, from the basic output you cannot determine the path the LSP is using. To see what path the LSP is using you must include the detail or extensive tag on the command you used.

Step 2.7

Review the ingress LSP in more detail by including the ingress and extensive options with the previous command.

lab@mxA-1> show mpls lsp ingress extensive Ingress LSP: 1 sessions

Junos MPLS and VPNs


192.168.1.2 From: 192.168.1.1, State: Up, ActiveRoute: 1, LSPname: pe1-to-pe2-1 ActivePath: (primary) LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.210.2 172.22.201.2 172.22.206.2 172.22.212.1 4 Jul 15 14:24:41.556 Selected as active path 3 Jul 15 14:24:41.553 Record Route: 172.22.210.2 172.22.201.2 172.22.206.2 172.22.212.1 2 Jul 15 14:24:41.552 Up 1 Jul 15 14:24:41.525 Originate Call Created: Thu Jul 15 14:24:41 2010Total 1 displayed, Up 1, Down 0

Question: Can you determine what routers in the network are being traversed by the LSP you configured?

Answer: Yes. By comparing the hop addresses captured by the record route object (RRO) and the Lab2 lab diagram you can determine the exact path the LSP is using.

Step 2.8

Verify traffic that is destined to the remote CE router’s loopback will use the LSP by issuing the show route 192.168.1x.y command.



192.168.11.2/32 *[BGP/170] 21:58:11, localpref 100, from 192.168.1.2 AS path: 65102 I > to 172.22.210.2 via ge-1/0/0.210, label-switched-path pe1-to-pe2-1



Junos MPLS and VPNs


Step 2.9

Verify the remote CE router’s loopback is reachable from your local CE router by sending five Internet Control Message Protocol (ICMP) packets. Verify these ICMP packets traversed the LSP by displaying the traffic statistics for the LSP.

lab@mxA-1> ping 192.168.1x.y source 192.168.1x.y routing-instance cex-y count 5 PING 192.168.11.2 (192.168.11.2): 56 data bytes64 bytes from 192.168.11.2: icmp_seq=0 ttl=59 time=0.710 ms64 bytes from 192.168.11.2: icmp_seq=1 ttl=59 time=0.670 ms64 bytes from 192.168.11.2: icmp_seq=2 ttl=59 time=0.624 ms64 bytes from 192.168.11.2: icmp_seq=3 ttl=59 time=0.680 ms64 bytes from 192.168.11.2: icmp_seq=4 ttl=59 time=0.659 ms

--- 192.168.11.2 ping statistics ---5 packets transmitted, 5 packets received, 0% packet lossround-trip min/avg/max/stddev = 0.624/0.669/0.710/0.028 ms

lab@mxA-1> show mpls lsp statistics ingress Ingress LSP: 1 sessionsTo From State Packets Bytes LSPname192.168.1.2 192.168.1.1 Up 5 440 lsp-to-mxA-2Total 1 displayed, Up 1, Down 0


Part 3: Configuring a Explicit Route Object (ERO)

In this lab part, you will continue using the “Lab 2: Label Distribution Protocols” lab diagram. You will create a path using both strict and loose path constraints. You will apply the path as the primary path to your existing LSP, forcing the LSP to signal along the specified path. You will decide which path the LSP will traverse. The only criteria for this task is that you must have at least one strict hop and one loose hop defined for the path. The example below is from the perspective of the pex- router. The path example will have a strict hop requirement of the p4 router and a loose hop requirement of the p3 router. This path was chosen for demonstration purposes only—you might choose to engineer your LSP path differently.

Step 3.1

Enter into configuration mode and edit to the [edit protocols mpls] hierarchy. Create a path named my-ER0 and configure the strict and loose hops you want the LSP path to signal along.


[edit]lab@mxA-1# edit protocols mpls

[edit protocols mpls]lab@mxA-1# set path my-ERO 172.22.2xy.2 strict

Junos MPLS and VPNs


[edit protocols mpls]lab@mxA-1# set path my-ERO 192.168.5.3 loose

[edit protocols mpls]lab@mxA-1# show no-cspf;label-switched-path pe1-to-pe2-1 { to 192.168.1.2;}path my-ERO { 172.22.211.2 strict; 192.168.5.3 loose;}interface all;interface fxp0.0 { disable;}

Step 3.2

Apply the ERO you just created as the primary path used by the LSP you configured in Part 2. If you do not remember what the LSP name was, you can use the question mark option to display the LSPs that are configured on the router. Review the configuration changes before committing and exiting to operational mode.

[edit protocols mpls]lab@mxA-1# set label-switched-path ? Possible completions: <path_name> Name of path

pe1-to-pe2-1 Name of path[edit protocols mpls]lab@mxA-1# set label-switched-path pey-to-pez-x primary my-ERO

[edit protocols mpls]lab@mxA-1# show no-cspf;label-switched-path pe1-to-pe2-1 { to 192.168.1.2; primary my-ERO;}path my-ERO { 172.22.211.2 strict; 192.168.5.3 loose;}interface all;interface fxp0.0 { disable;}


lab@mxA-1>

Junos MPLS and VPNs


Step 3.3

Verify the status of your LSP using the show mpls lsp ingress command.

lab@mxA-1> show mpls lsp ingress Ingress LSP: 1 sessionsTo From State Rt P ActivePath LSPname192.168.1.2 192.168.1.1 Up 1 * my-ERO pe1-to-pe2-1Total 1 displayed, Up 1, Down 0

Question: What is the state of your LSP?

Answer: If your configuration is correct, the state of the LSP will show Up. If it does not, please review your configuration and correct any issues. Please ask the instructor for assistance if needed.

Question: What is the active path being used?

Answer: You should see the path name you configured as the primary path (my-ERO) displayed under the ActivePath column.

Step 3.4

Review the output displayed from the show mpls lsp ingress detail command to verify the LSP is following the path you created.

lab@mxA-1> show mpls lsp ingress detail Ingress LSP: 1 sessions

192.168.1.2 From: 192.168.1.1, State: Up, ActiveRoute: 1, LSPname: pe1-to-pe2-1 ActivePath: my-ERO (primary) LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary my-ERO State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.211.2 172.22.202.1 172.22.201.2 172.22.206.2 172.22.212.1Total 1 displayed, Up 1, Down 0

Junos MPLS and VPNs


Question: Does the RRO reflect the path you specified?

Answer: The Record Route Object (RRO) should display the physical interfaces addresses along the path you specified.

Part 4: Configuring LDP

In this lab part, you will deactivate RSVP and add LDP to your network setup. Then you will verify that traffic will transit the network using the LDP LSP.

Step 4.1

Enter into configuration mode and deactivate RSVP. Commit the configuration change.


[edit]lab@mxA-1# deactivate protocols rsvp


Step 4.2

Navigate to the [edit protocols ldp] hierarchy and add the interface all statement. As good practice, remember to disable the management interface. After making the configuration changes commit and exit to operation mode for verification.

[edit]lab@mxA-1# edit protocols ldp

[edit protocols ldp]lab@mxA-1# set interface all

[edit protocols ldp]lab@mxA-1# set interface fxp0 disable

[edit protocols ldp]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Junos MPLS and VPNs


Step 4.3

Verify the proper interfaces are participating in LDP by issuing the command show ldp interface.

lab@mxA-1> show ldp interface Interface Label space ID Nbr count Next hellolo0.0 192.168.1.1:0 0 0ge-1/0/0.210 192.168.1.1:0 1 1ge-1/0/1.211 192.168.1.1:0 1 2

Question: Do you see the correct interfaces?

Answer: You should see entries for lo0, ge-1/0/0, and ge-1/0/1 with your proper unit number. If you see something other than the expected interfaces please review your configuration and if necessary request assistance from the instructor.

Step 4.4

Verify the status of the LSP by issuing the show ldp session command.

lab@mxA-1> show ldp session Address State Connection Hold time192.168.5.1 Operational Open 26192.168.5.4 Operational Open 26

Question: What is the status of the connection?

Answer: The connection should display as open for each session.

Step 4.5

Verify traffic that is destined to the remote CE router’s loopback will use the LSP by issuing the show route 192.168.1x.y command.



192.168.11.2/32 *[BGP/170] 2d 03:38:57, localpref 100, from 192.168.1.2 AS path: 65102 I > to 172.22.210.2 via ge-1/0/0.210, Push 300000 to 172.22.211.2 via ge-1/0/1.211, Push 300000


Junos MPLS and VPNs


192.168.11.2/32 *[BGP/170] 1d 06:13:15, localpref 100 AS path: 65512 65102 I > to 10.0.10.1 via ge-1/1/4.0

Step 4.6

Verify the remote CE router’s loopback is reachable from your local CE router by sending five ICMP packets. Verify these ICMP packets traversed the LSP by displaying the traffic statistics for the LSP.


lab@mxA-1> show ldp traffic-statistics FEC Type Packets Bytes Shared 192.168.1.2/32 Transit 0 0 No Ingress 5 440 No 192.168.3.1/32 Transit 0 0 No Ingress 0 0 No 192.168.3.2/32 Transit 0 0 No Ingress 0 0 No 192.168.5.1/32 Transit 0 0 No Ingress 0 0 No 192.168.5.2/32 Transit 0 0 No Ingress 0 0 No 192.168.5.3/32 Transit 0 0 No Ingress 0 0 No 192.168.5.4/32 Transit 0 0 No Ingress 0 0 No 192.168.5.5/32 Transit 0 0 No Ingress 0 0 No 192.168.5.6/32 Transit 0 0 No Ingress 0 0 No

Question: Was your ping test successful?

Answer: At this point, your pings should succeed. If your pings do not succeed, please review your configuration for possible issues and check with your peer group to ensure their LSPs are functional. Please request assistance from the instructor if needed.

STOP Do not proceed until the remote team finishes Part 4

Junos MPLS and VPNs


Part 5: Changing the Default Route Preference

In this lab part, your network will be running both RSVP and LDP to signal LSPs. All traffic destined for the remote CE router must use the LDP LSPs. You will use protocol preference to maniplate the LSP that is chosen as the next-hop.

Step 5.1

Enter into configuration mode and re-activate the RSVP protocol. Commit the configuration changes.


[edit]lab@mxA-1# activate protocols rsvp


Step 5.2

Review the routing table to determine what route is being used to carry traffic to the remote CE network. Please note that the route might not change right away. It can take a few moments to update the routing table.

[edit]lab@mxA-1# run show route 192.168.1x.y


192.168.11.2/32 *[BGP/170] 18:16:33, localpref 100, from 192.168.1.2 AS path: 65102 I > to 172.22.211.2 via ge-1/0/1.211, label-switched-path pe1-to-pe2-1



Question: What protocol is being used to carry the traffic to remote CE router?

Answer: If you look carefully you will notice that the next hop is via the RSVP-signalled LSP. This indicates that RSVP is the preferred route and will be used for traffic destined to the CE network.

Junos MPLS and VPNs


Question: What table can you look at to see the preference values of RSVP and LDP?

Answer: You should look at the inet.3 routing table.

Step 5.3

Review the routes being used in the routing table inet.3 by issuing the run show route table inet.3 192.168.x.y command.

[edit]lab@mxA-1# run show route table inet.3 192.168.x.y


192.168.1.2/32 *[RSVP/7/1] 18:31:22, metric 4 > to 172.22.211.2 via ge-1/0/1.211, label-switched-path pe1-to-pe2-1 [LDP/9] 00:14:48, metric 1 > to 172.22.210.2 via ge-1/0/0.210, Push 299904 to 172.22.211.2 via ge-1/0/1.211, Push 299904

Question: How can we make the LDP route more preferred than the RSVP route?

Answer: You can make LDP more preferred by lowering the preference of LDP or by raising the preference of RSVP.

Step 5.4

Lower the preference of the LDP protocol to be one lower than RSVP. You can accomplish this by issuing the set protocols ldp preference 6 command. After changing the protocol preference, commit your changes. After the commit has finished, review the 192.168.1x.y route and the inet.3 routing table to ensure LDP will be used for traffic to the CE network.

[edit]lab@mxA-1# set protocols ldp preference 6


[edit]lab@mxA-1# run show route 192.168.1x.y

Junos MPLS and VPNs



192.168.11.2/32 *[BGP/170] 19:04:24, localpref 100, from 192.168.1.2 AS path: 65102 I > to 172.22.210.2 via ge-1/0/0.210, Push 299904 to 172.22.211.2 via ge-1/0/1.211, Push 299904



[edit]lab@mxA-1# run show route table inet.3 192.168.x.y


192.168.1.2/32 *[LDP/6] 00:00:22, metric 1 > to 172.22.210.2 via ge-1/0/0.210, Push 299904 to 172.22.211.2 via ge-1/0/1.211, Push 299904 [RSVP/7/1] 00:00:29, metric 4 > to 172.22.211.2 via ge-1/0/1.211, label-switched-path pe1-to-pe2-1

Question: What protocol is now the more preferred protocol for traffic destined to the remote CE network?

Answer: The LDP protocol and routes should be more preferred now.


Note

It is perfectly acceptable in our situation to make all LDP routes more preferred than RSVP routes. However, this might not always be the case. You can increase the route preference on RSVP routes on each label-switched-path. This allows you to alter the preference on a more granular level than LDP.

www.juniper.net CSPF (Detailed) • Lab 3–110.a.10.3R1.9

Lab 3CSPF (Detailed)

Overview

In this lab, you create a baseline multiprotocol label switching (MPLS) network and then create label switched paths (LSPs) using administrative groups as a constraint for constrained shortest path first (CSPF).

The lab is available in two formats: a high-level format that is 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.


• Create a baseline network.

• Define three Resource Reservation Protocol (RSVP) signaled LSPs to the remote provider edge (PE) router.

• Create and assign administrative groups to interfaces and define an LSP using administrative groups as a routing constraint.

• Analyze the traffic engineering database (TED).

Junos MPLS and VPNs

Lab 3–2 • CSPF (Detailed) www.juniper.net

Part 1: Creating the Baseline Network

In this lab part, you will configure the baseline network for the lab. You will load the baseline configuration that was saved at the end of Lab 1 and then enable RSVP and MPLS on the core-facing interfaces. Please refer to the lab diagram titled “Lab 3: CSPF”.

Step 1.1

Enter configuration mode and load the baseline configuration for your PE router. The file should be saved in the /var/home/lab directory and is named jmv-lab1-RouterName-baseline. Commit the baseline configuration and exit to operational mode to verify connectivity.

lab@mxB-1> configure Entering configuration mode

[edit]lab@mxB-1# load override jmv-lab1-routername-baseline load complete

[edit]lab@mxB-1# commit and-quit commit completeExiting configuration mode

Step 1.2

Verify that your PE router has established Open Shortest Path First (OSPF) adjacencies with the neighboring P routers.

lab@mxB-1> show ospf neighbor Address Interface State ID Pri Dead172.22.220.2 ge-1/0/0.220 Full 192.168.5.1 128 37172.22.221.2 ge-1/0/1.221 Full 192.168.5.4 128 34

Question: Are the OSPF neighbors in a Full state?

Answer: The neighboring P routers should be in a Full state with your PE router. If they are not, doublecheck the interface and OSPF settings. If you need further assistance, consult with your instructor.

Step 1.3

Verify that your PE router has established a Border Gateway Protocol (BGP) neighbor relationship with the remote PE router.

lab@mxB-1> show bgp neighbor 192.168.x.y Peer: 192.168.2.2+64590 AS 65512 Local: 192.168.2.1+179 AS 65512 Type: Internal State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive

Junos MPLS and VPNs

www.juniper.net CSPF (Detailed) • Lab 3–3

Last Error: None Options: <Preference LocalAddress Refresh> Local Address: 192.168.2.1 Holdtime: 90 Preference: 170 Number of flaps: 1 Last flap event: RecvNotify Error: 'Cease' Sent: 0 Recv: 1 Peer ID: 192.168.2.2 Local ID: 192.168.2.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 65512) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 3 Sent 2 Checked 25 Input messages: Total 6983 Updates 8 Refreshes 0 Octets 132919 Output messages: Total 6988 Updates 8 Refreshes 0 Octets 133069 Output Queue[0]: 0

lab@mxB-1> show bgp summary Groups: 3 Peers: 3 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...10.0.20.1 65512 6913 6913 0 0 2d 4:10:00 Establ ce2-1.inet.0: 0/0/0/010.0.20.2 65201 6912 6913 0 0 2d 4:10:00 Establ inet.0: 0/0/0/0192.168.2.2 65512 6983 6988 0 1 2d 4:41:34 Establ

Junos MPLS and VPNs


Question: Is the neighbor relationship in the established state with the remote PE router?

Answer: The remote PE router should be in an established state with your PE router. If it is not, double check the interface and BGP settings. If you need further assistance, consult with your instructor.

Step 1.4

For an interface to support the forwarding of MPLS packets, you must enable the MPLS family on each interface. Enter configuration mode and navigate to the [edit interfaces] hierarchy. Enable family mpls on both of the core facing interfaces.


[edit]lab@mxB-1# edit interfaces

[edit interfaces]lab@mxB-1# set ge-1/0/0 unit 2xy family mpls


Step 1.5

Navigate to the [edit protocols] hierarchy and configure the MPLS protocol on the core-facing interfaces.

[edit interfaces]lab@mxB-1# top edit protocols

[edit protocols]lab@mxB-1# set mpls interface ge-1/0/0.2xy


Step 1.6

Configure the RSVP protocol on the core-facing interfaces. Commit your configuration and exit to operational mode.

[edit protocols]lab@mxB-1# set rsvp interface ge-1/0/0.2xy


[edit protocols]lab@mxB-1# commit and-quit

Junos MPLS and VPNs


commit completeExiting configuration mode

Step 1.7

Using show commands, verify that the MPLS and RSVP are configured correctly on the core-facing interfaces.

lab@mxB-1> show mpls interface Interface State Administrative groupsge-1/0/0.220 Up <none>ge-1/0/1.221 Up <none>

lab@mxB-1> show rsvp interface RSVP interface: 2 active Active Subscr- Static Available Reserved HighwaterInterface State resv iption BW BW BW markge-1/0/0.220Up 0 100% 1000Mbps 1000Mbps 0bps 0bps ge-1/0/1.221Up 0 100% 1000Mbps 1000Mbps 0bps 0bps

Part 2: Enabling the TED

By default, the Junos operating system does not support the flooding the Opaque LSAs used to build the TED. This feature must be enabled on every router in the OSPF network. In this lab part, you will enable the TED and verify its operation.

Step 2.1

View the OSPF database and determine what types of link state advertisements (LSAs) are currently being flooded in the network.

lab@mxB-1> show ospf database

OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 192.168.1.1 192.168.1.1 0x80000342 5 0x22 0xca63 60Router 192.168.1.3 192.168.1.3 0x80000120 7 0x22 0xc182 60Router *192.168.2.1 192.168.2.1 0x8000031d 3 0x22 0xce59 60Router 192.168.2.2 192.168.2.2 0x8000031d 7 0x22 0x69b3 60Router 192.168.5.1 192.168.5.1 0x80000300 4 0x22 0x1561 108Router 192.168.5.2 192.168.5.2 0x800002eb 6 0x22 0x93c9 72Router 192.168.5.3 192.168.5.3 0x800002f0 6 0x22 0x79e5 108Router 192.168.5.4 192.168.5.4 0x800002ff 4 0x22 0x540f 108Router 192.168.5.5 192.168.5.5 0x800002dc 5 0x22 0x9ec3 72Router 192.168.5.6 192.168.5.6 0x800002e3 6 0x22 0x9ec1 108Network 172.22.201.2 192.168.5.2 0x800002e3 6 0x22 0x5620 32Network 172.22.202.2 192.168.5.4 0x800002c1 4 0x22 0x97fb 32Network 172.22.203.2 192.168.5.5 0x800002d3 5 0x22 0x96e4 32Network 172.22.204.2 192.168.5.6 0x800002ba 6 0x22 0xcfc0 32Network 172.22.205.2 192.168.5.5 0x800002d3 5 0x22 0x6417 32Network 172.22.206.2 192.168.5.3 0x800002c1 6 0x22 0x751b 32Network 172.22.207.2 192.168.5.6 0x800002b9 6 0x22 0x94fb 32Network 172.22.210.2 192.168.5.1 0x800002bd 4 0x22 0x792 32Network 172.22.211.2 192.168.5.4 0x800002b1 4 0x22 0x207e 32Network 172.22.212.2 192.168.5.3 0x800002ae 6 0x22 0x336d 32Network 172.22.213.2 192.168.5.6 0x800002a7 6 0x22 0x425e 32

Junos MPLS and VPNs


Network 172.22.220.2 192.168.5.1 0x800002c6 4 0x22 0x93f1 32Network 172.22.221.2 192.168.5.4 0x800002be 4 0x22 0xa4e1 32Network 172.22.222.2 192.168.5.3 0x800002be 6 0x22 0xa3e2 32Network 172.22.223.2 192.168.5.6 0x800002b6 6 0x22 0xb4d2 32OpaqArea 1.0.0.1 192.168.1.1 0x8000031e 5 0x22 0x6dca 28OpaqArea 1.0.0.1 192.168.1.3 0x8000011e 7 0x22 0x7bba 28OpaqArea 1.0.0.1 192.168.5.1 0x800002d3 4 0x22 0xd6e 28OpaqArea 1.0.0.1 192.168.5.2 0x800002ea 6 0x22 0xe27f 28OpaqArea 1.0.0.1 192.168.5.3 0x800002c9 6 0x22 0x2958 28OpaqArea 1.0.0.1 192.168.5.4 0x800002c9 4 0x22 0x2d52 28OpaqArea 1.0.0.1 192.168.5.5 0x800002db 5 0x22 0xd5e 28OpaqArea 1.0.0.1 192.168.5.6 0x800002c2 6 0x22 0x433f 28OpaqArea 1.0.0.3 192.168.5.1 0x800002d3 4 0x22 0x6a1d 124OpaqArea 1.0.0.3 192.168.5.2 0x800002e9 5 0x22 0x5619 124OpaqArea 1.0.0.3 192.168.5.3 0x800002c8 6 0x22 0xd882 124OpaqArea 1.0.0.3 192.168.5.4 0x800002c9 4 0x22 0xb9c5 124OpaqArea 1.0.0.3 192.168.5.5 0x800002db 5 0x22 0xd29b 124OpaqArea 1.0.0.3 192.168.5.6 0x800002c2 6 0x22 0x760e 124OpaqArea 1.0.0.4 192.168.5.1 0x800002d1 4 0x22 0x93e6 124OpaqArea 1.0.0.4 192.168.5.2 0x800002e9 5 0x22 0xa0c2 124OpaqArea 1.0.0.4 192.168.5.3 0x800002c7 6 0x22 0x5a29 124OpaqArea 1.0.0.4 192.168.5.4 0x800002c8 4 0x22 0x6ef6 124OpaqArea 1.0.0.4 192.168.5.5 0x800002db 5 0x22 0xe288 124OpaqArea 1.0.0.4 192.168.5.6 0x800002c0 6 0x22 0xd690 124OpaqArea 1.0.0.5 192.168.5.1 0x800002cd 4 0x22 0x62f7 124OpaqArea 1.0.0.5 192.168.5.2 0x800002e9 5 0x22 0xf36e 124OpaqArea 1.0.0.5 192.168.5.3 0x800002c5 6 0x22 0x126d 124OpaqArea 1.0.0.5 192.168.5.4 0x800002c6 4 0x22 0xea96 124OpaqArea 1.0.0.5 192.168.5.5 0x800002da 5 0x22 0x1a52 124OpaqArea 1.0.0.5 192.168.5.6 0x800002be 6 0x22 0x2c56 124OpaqArea 1.0.0.6 192.168.5.1 0x800002b9 4 0x22 0x8af6 124OpaqArea 1.0.0.6 192.168.5.3 0x800002b0 6 0x22 0xf48f 124OpaqArea 1.0.0.6 192.168.5.4 0x800002b0 4 0x22 0x94fa 124OpaqArea 1.0.0.6 192.168.5.6 0x800002a9 6 0x22 0xfa95 124

Question: What types of LSAs are being flooded in the OSPF domain?

Answer: You should see Router, Network, and OpaqArea LSAs.

Junos MPLS and VPNs


Question: Is your router generating an OpaqArea LSA?

Answer: Looking at the Adv Rtr field, you should notice that your router is not generating the OpaqArea LSA. The provider routers have been configured to allow for the flooding of the OpaqArea LSA.

Step 2.2

View the TED and determine whether or not your router is using the OpaqArea LSA to build a TED.

lab@mxB-1> show ted database TED database: 0 ISIS nodes 0 INET nodes

lab@mxB-1>

Question: Does your router have a TED available for CSPF calculations?

Answer: No. Even though your router is receiving the OpaqArea LSAs which would normally be used to build the TED, your router is ignoring those LSAs.

Step 2.3

Enter configuration mode and navigate to the [edit protocols ospf] hierarchy and enable traffic-engineering so that your router will flood its own OpaqArea LSA and use these LSA types to build and use the TED for CSPF calculations. Commit your configuration and exit to operational mode to determine if your router is using the TED .


[edit]lab@mxB-1# edit protocols ospf

[edit protocols ospf]lab@mxB-1# set traffic-engineering

[edit protocols ospf]lab@mxB-1# commit and-quit commit complete

lab@mxB-1> show ospf database

Junos MPLS and VPNs


OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 192.168.1.1 192.168.1.1 0x80000342 282 0x22 0xca63 60Router 192.168.1.3 192.168.1.3 0x80000120 284 0x22 0xc182 60Router *192.168.2.1 192.168.2.1 0x8000031e 94 0x22 0xcc5a 60Router 192.168.2.2 192.168.2.2 0x8000031d 284 0x22 0x69b3 60Router 192.168.5.1 192.168.5.1 0x80000300 281 0x22 0x1561 108Router 192.168.5.2 192.168.5.2 0x800002eb 283 0x22 0x93c9 72Router 192.168.5.3 192.168.5.3 0x800002f0 283 0x22 0x79e5 108Router 192.168.5.4 192.168.5.4 0x800002ff 281 0x22 0x540f 108Router 192.168.5.5 192.168.5.5 0x800002dc 282 0x22 0x9ec3 72Router 192.168.5.6 192.168.5.6 0x800002e3 283 0x22 0x9ec1 108Network 172.22.201.2 192.168.5.2 0x800002e3 283 0x22 0x5620 32Network 172.22.202.2 192.168.5.4 0x800002c1 281 0x22 0x97fb 32Network 172.22.203.2 192.168.5.5 0x800002d3 282 0x22 0x96e4 32Network 172.22.204.2 192.168.5.6 0x800002ba 283 0x22 0xcfc0 32Network 172.22.205.2 192.168.5.5 0x800002d3 282 0x22 0x6417 32Network 172.22.206.2 192.168.5.3 0x800002c1 283 0x22 0x751b 32Network 172.22.207.2 192.168.5.6 0x800002b9 283 0x22 0x94fb 32Network 172.22.210.2 192.168.5.1 0x800002bd 281 0x22 0x792 32Network 172.22.211.2 192.168.5.4 0x800002b1 281 0x22 0x207e 32Network 172.22.212.2 192.168.5.3 0x800002ae 283 0x22 0x336d 32Network 172.22.213.2 192.168.5.6 0x800002a7 283 0x22 0x425e 32Network 172.22.220.2 192.168.5.1 0x800002c6 281 0x22 0x93f1 32Network 172.22.221.2 192.168.5.4 0x800002be 281 0x22 0xa4e1 32Network 172.22.222.2 192.168.5.3 0x800002be 283 0x22 0xa3e2 32Network 172.22.223.2 192.168.5.6 0x800002b6 283 0x22 0xb4d2 32OpaqArea 1.0.0.1 192.168.1.1 0x8000031e 282 0x22 0x6dca 28OpaqArea 1.0.0.1 192.168.1.3 0x8000011e 284 0x22 0x7bba 28OpaqArea*1.0.0.1 192.168.2.1 0x80000001 94 0x22 0xb2a3 28OpaqArea 1.0.0.1 192.168.5.1 0x800002d3 281 0x22 0xd6e 28OpaqArea 1.0.0.1 192.168.5.2 0x800002ea 283 0x22 0xe27f 28OpaqArea 1.0.0.1 192.168.5.3 0x800002c9 283 0x22 0x2958 28OpaqArea 1.0.0.1 192.168.5.4 0x800002c9 281 0x22 0x2d52 28OpaqArea 1.0.0.1 192.168.5.5 0x800002db 282 0x22 0xd5e 28OpaqArea 1.0.0.1 192.168.5.6 0x800002c2 283 0x22 0x433f 28OpaqArea*1.0.0.3 192.168.2.1 0x80000001 94 0x22 0x102b 124OpaqArea 1.0.0.3 192.168.5.1 0x800002d3 281 0x22 0x6a1d 124OpaqArea 1.0.0.3 192.168.5.2 0x800002e9 282 0x22 0x5619 124OpaqArea 1.0.0.3 192.168.5.3 0x800002c8 283 0x22 0xd882 124OpaqArea 1.0.0.3 192.168.5.4 0x800002c9 281 0x22 0xb9c5 124OpaqArea 1.0.0.3 192.168.5.5 0x800002db 282 0x22 0xd29b 124OpaqArea 1.0.0.3 192.168.5.6 0x800002c2 283 0x22 0x760e 124OpaqArea*1.0.0.4 192.168.2.1 0x80000001 94 0x22 0x38ff 124OpaqArea 1.0.0.4 192.168.5.1 0x800002d1 281 0x22 0x93e6 124OpaqArea 1.0.0.4 192.168.5.2 0x800002e9 282 0x22 0xa0c2 124OpaqArea 1.0.0.4 192.168.5.3 0x800002c7 283 0x22 0x5a29 124OpaqArea 1.0.0.4 192.168.5.4 0x800002c8 281 0x22 0x6ef6 124OpaqArea 1.0.0.4 192.168.5.5 0x800002db 282 0x22 0xe288 124OpaqArea 1.0.0.4 192.168.5.6 0x800002c0 283 0x22 0xd690 124OpaqArea 1.0.0.5 192.168.5.1 0x800002cd 281 0x22 0x62f7 124OpaqArea 1.0.0.5 192.168.5.2 0x800002e9 282 0x22 0xf36e 124OpaqArea 1.0.0.5 192.168.5.3 0x800002c5 283 0x22 0x126d 124OpaqArea 1.0.0.5 192.168.5.4 0x800002c6 281 0x22 0xea96 124

Junos MPLS and VPNs


OpaqArea 1.0.0.5 192.168.5.5 0x800002da 282 0x22 0x1a52 124OpaqArea 1.0.0.5 192.168.5.6 0x800002be 283 0x22 0x2c56 124OpaqArea 1.0.0.6 192.168.5.1 0x800002b9 281 0x22 0x8af6 124OpaqArea 1.0.0.6 192.168.5.3 0x800002b0 283 0x22 0xf48f 124OpaqArea 1.0.0.6 192.168.5.4 0x800002b0 281 0x22 0x94fa 124OpaqArea 1.0.0.6 192.168.5.6 0x800002a9 283 0x22 0xfa95 124

lab@mxB-1> show ted database TED database: 0 ISIS nodes 25 INET nodesID Type Age(s) LnkIn LnkOut Protocol172.22.201.2-1 Net 180 2 2 OSPF(0.0.0.0) To: 192.168.5.2, Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 To: 192.168.5.1, Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0ID Type Age(s) LnkIn LnkOut Protocol172.22.202.2-1 Net 180 2 2 OSPF(0.0.0.0) To: 192.168.5.1, Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 To: 192.168.5.4, Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0ID Type Age(s) LnkIn LnkOut Protocol172.22.203.2-1 Net 180 2 2 OSPF(0.0.0.0) To: 192.168.5.4, Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 To: 192.168.5.5, Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0ID Type Age(s) LnkIn LnkOut Protocol172.22.204.2-1 Net 180 2 2 OSPF(0.0.0.0) To: 192.168.5.5, Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 To: 192.168.5.6, Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0ID Type Age(s) LnkIn LnkOut Protocol172.22.205.2-1 Net 180 2 2 OSPF(0.0.0.0) To: 192.168.5.2, Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 To: 192.168.5.5, Local: 0.0.0.0, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0...

Question: Is your router generating an OpaqArea LSA?

Answer: Looking at the Adv Rtr field, you should notice that your router is now generating the OpaqArea LSAs.

Junos MPLS and VPNs


Question: Does your router have a TED available for CSPF calculations?

Answer: Yes. Your router has built it own local TED and can use the database for CSPF calculations.

Step 2.4

View the TED and determine the colors (administrative groups) that have been assigned to your PE router local interfaces.

lab@mxB-1> show ted database extensive 192.168.x.y TED database: 0 ISIS nodes 25 INET nodesNodeID: 192.168.2.1 Type: Rtr, Age: 664 secs, LinkIn: 2, LinkOut: 2 Protocol: OSPF(0.0.0.0) To: 172.22.220.2-1, Local: 172.22.220.1, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 Color: 0 <none> Metric: 1 Static BW: 1000Mbps Reservable BW: 1000Mbps Available BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps To: 172.22.221.2-1, Local: 172.22.221.1, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 Color: 0 <none> Metric: 1 Static BW: 1000Mbps Reservable BW: 1000Mbps Available BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps

Junos MPLS and VPNs


Question: Have any colors been assigned to your PE router’s core-facing interfaces?

Answer: No. The TED contains all of the details of the network that can be used by the CSPF algorithm. Currently, both of the core facing interfaces have not colors (administrative groups) assigned.


Part 3: Configuring RSVP-Signaled LSPs

In this lab part, you will configure gold, silver, and bronze RSVP-signaled LSPs.

Step 3.1

Enter configuration mode and navigate to the [edit protocols mpls] hierarchy. Configure an RSVP-signaled LSP named lsp-gold-pey-to-pez-x to the remote PE router’s loopback address. Ensure that this LSP traverses P2 as a loose hop.


[edit]lab@mxB-1# edit protocols mpls

[edit protocols mpls]lab@mxB-1# set path path-name 192.168.5.2 loose

[edit protocols mpls]lab@mxB-1# set label-switched-path lsp-gold-pey-to-pez-x to 192.168.x.y

[edit protocols mpls]lab@mxB-1# set label-switched-path lsp-gold-pey-to-pez-x primary path-name

Step 3.2

Configure an RSVP-signaled LSP named lsp-silver-pey-to-pez-x to the remote PE router’s loopback address. Ensure that this LSP traverses P2 as a loose hop.

[edit protocols mpls]lab@mxB-1# set label-switched-path lsp-silver-pey-to-pez-x to 192.168.x.y

[edit protocols mpls]lab@mxB-1# set label-switched-path lsp-silver-pey-to-pez-x primary path-name

Junos MPLS and VPNs


Step 3.3

Configure an RSVP-signaled LSP named lsp-bronze-pey-to-pez-x to the remote PE router’s loopback address. Ensure that this LSP traverses P2 as a loose hop. Commit your configuration and exit to operational mode.

[edit protocols mpls]lab@mxB-1# set label-switched-path lsp-bronze-pey-to-pez-x to 192.168.x.y

[edit protocols mpls]lab@mxB-1# set label-switched-path lsp-bronze-pey-to-pez-x primary path-name

[edit protocols mpls]lab@mxB-1# commit and-quit commit completeExiting configuration mode

Step 3.4

Verify that the new LSPs are up and are currently traversing P2.

lab@mxB-1> show rsvp session Ingress RSVP: 3 sessionsTo From State Rt Style Labelin Labelout LSPname 192.168.2.2 192.168.2.1 Up 0 1 FF - 308672 lsp-bronze-pe1-to-pe2-2192.168.2.2 192.168.2.1 Up 0 1 FF - 308688 lsp-gold-pe1-to-pe2-2192.168.2.2 192.168.2.1 Up 0 1 FF - 308704 lsp-silver-pe1-to-pe2-2Total 3 displayed, Up 3, Down 0

Egress RSVP: 0 sessionsTotal 0 displayed, Up 0, Down 0

Transit RSVP: 0 sessionsTotal 0 displayed, Up 0, Down 0

lab@mxB-1> show rsvp session extensive Ingress RSVP: 3 sessions

192.168.2.2 From: 192.168.2.1, LSPstate: Up, ActiveRoute: 0 LSPname: lsp-bronze-pe1-to-pe2-2, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 308768 Resv style: 1 FF, Label in: -, Label out: 308768 Time left: -, Since: Fri Dec 10 18:22:21 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 2 receiver 20119 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 172.22.220.2 (ge-1/0/0.220) 5 pkts RESV rcvfrom: 172.22.220.2 (ge-1/0/0.220) 5 pkts

Junos MPLS and VPNs


Explct route: 172.22.220.2 172.22.201.2 172.22.205.2 172.22.204.2 172.22.223.1 Record route: <self> 172.22.220.2 172.22.201.2 172.22.205.2 172.22.204.2 172.22.223.1

192.168.2.2 From: 192.168.2.1, LSPstate: Up, ActiveRoute: 0 LSPname: lsp-gold-pe1-to-pe2-2, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 308784 Resv style: 1 FF, Label in: -, Label out: 308784 Time left: -, Since: Fri Dec 10 18:22:21 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 2 receiver 20120 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 172.22.220.2 (ge-1/0/0.220) 5 pkts RESV rcvfrom: 172.22.220.2 (ge-1/0/0.220) 5 pkts Explct route: 172.22.220.2 172.22.201.2 172.22.205.2 172.22.204.2 172.22.223.1 Record route: <self> 172.22.220.2 172.22.201.2 172.22.205.2 172.22.204.2 172.22.223.1

192.168.2.2 From: 192.168.2.1, LSPstate: Up, ActiveRoute: 0 LSPname: lsp-silver-pe1-to-pe2-2, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 308816 Resv style: 1 FF, Label in: -, Label out: 308816 Time left: -, Since: Fri Dec 10 18:23:10 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 3 receiver 20121 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 172.22.220.2 (ge-1/0/0.220) 3 pkts RESV rcvfrom: 172.22.220.2 (ge-1/0/0.220) 3 pkts Explct route: 172.22.220.2 172.22.201.2 172.22.206.2 172.22.222.1 Record route: <self> 172.22.220.2 172.22.201.2 172.22.206.2 172.22.222.1 Total 3 displayed, Up 3, Down 0

Egress RSVP: 0 sessionsTotal 0 displayed, Up 0, Down 0


Junos MPLS and VPNs


Question: Are all three LSPs up?

Answer: Yes, each of the LSPs should be up.

Question: What path are each of the LSPs taking through the network? List the routers that the LSPs traverse.

Answer: Each of the three LSPs should be traversing the exact same path. They should be traversing some combination of P1, P2, P3, and the remote PE router. If your LSPs are not taking this path, please check your configuration. To have your router recalculate the path through the network, issue the clear rsvp session command.

Part 4: Adding Administrative Groups to Core-Facing Interfaces

In this lab part, you will add administrative groups to your core-facing interfaces. Refer to the lab diagram to determine the administrative groups to be applied to the interfaces. The P router interfaces have been preconfigured with the administrative groups listed on the diagram.

Step 4.1

Enter configuration mode and navigate to the [edit protocols] hierarchy. Define an administrative group called gold that uses a value of 1.


[edit]lab@mxB-1# edit protocols

[edit protocols]lab@mxB-1# set mpls admin-groups gold 1

Step 4.2

Define an administrative group called silver that uses a value of 2.

[edit protocols]lab@mxB-1# set mpls admin-groups silver 2

Step 4.3

Define an administrative group called bronze that uses a value of 3.

[edit protocols]lab@mxB-1# set mpls admin-groups bronze 3

Junos MPLS and VPNs


Step 4.4

Apply the administrative groups (as listed in the lab diagram) to the core-facing interfaces. Exit configuration mode and use the show mpls interface command to verify that the correct administrative groups have been applied.

[edit protocols]lab@mxB-1# set mpls interface ge-1/0/0.2xy admin-group silver

[edit protocols]lab@mxB-1# set mpls interface ge-1/0/0.2xy admin-group bronze

[edit protocols]lab@mxB-1# set mpls interface ge-1/0/1.2xy admin-group gold

[edit protocols]lab@mxB-1# commit and-quit commit completeExiting configuration mode

lab@mxB-1> show mpls interface Interface State Administrative groupsge-1/0/0.220 Up bronze silverge-1/0/1.221 Up gold

Question: What administrative group have been applied to the interfaces?

Answer: On your PE routers, the ge-1/0/0.2xy interface should be listed as silver and bronze. The ge-1/0/1.2xy interface should be listed as gold.

Step 4.5

View the TED and determine whether or not your router is advertising the correct colors (administrative groups) to all other routers in the network.

lab@mxB-1> show ted database 192.168.x.y extensive TED database: 0 ISIS nodes 25 INET nodesNodeID: 192.168.2.1 Type: Rtr, Age: 112 secs, LinkIn: 2, LinkOut: 2 Protocol: OSPF(0.0.0.0) To: 172.22.220.2-1, Local: 172.22.220.1, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 Color: 0xc bronze silver Metric: 1 Static BW: 1000Mbps Reservable BW: 1000Mbps Available BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps Interface Switching Capability Descriptor(1):

Junos MPLS and VPNs


Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps To: 172.22.221.2-1, Local: 172.22.221.1, Remote: 0.0.0.0 Local interface index: 0, Remote interface index: 0 Color: 0x2 gold Metric: 1 Static BW: 1000Mbps Reservable BW: 1000Mbps Available BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps Interface Switching Capability Descriptor(1): Switching type: Packet Encoding type: Packet Maximum LSP BW [priority] bps: [0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps [4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps

Question: Is your router advertising the correct color settings to other routers in the network?

Answer: In the TED , the ge-1/0/0.2xy interface should be listed as silver and bronze. The ge-1/0/1.2xy interface should be listed as gold.


Part 5: Configuring LSPs to Take Gold, Silver, and Bronze Paths Using CSPF

In this lab part, you will modify the configuration of your LSPs so that they will take a particular path through the network. By specifying the administrative groups to include in the CSPF algorithm, the gold LSP will take the gold path, the silver LSP will take the silver path, and the bronze LSP will take the bronze path through the network.

Step 5.1

Enter configuration mode and navigate to the [edit protocols mpls] hierarchy, Modify the primary path for the gold LSP so that it takes only the gold path through the lab network, ensuring that it continues to pass through P2.


[edit]

Junos MPLS and VPNs


lab@mxB-1# edit protocols mpls

[edit protocols mpls]lab@mxB-1# set label-switched-path lsp-gold-pey-to-pez-x primary path-name admin-group include-any gold

Step 5.2

Modify the primary path for the silver LSP so that it takes only the silver path through the lab network ensuring that it continues to pass through P2.

[edit protocols mpls]lab@mxB-1# set label-switched-path lsp-silver-pey-to-pez-x primary path-name admin-group include-any silver

Step 5.3

Modify the primary path for the bronze LSP so that it takes only the bronze path through the lab network ensuring that it continues to pass through P2. Commit your configuration and exit to operational mode.

[edit protocols mpls]lab@mxB-1# set label-switched-path lsp-bronze-pey-to-pez-x primary path-name admin-group include-any bronze

[edit protocols mpls]lab@mxB-1# show admin-groups { gold 1; silver 2; bronze 3;}label-switched-path lsp-gold-pe1-to-pe2-2 { to 192.168.2.2; primary via-P2 { admin-group include-any gold; }}label-switched-path lsp-silver-pe1-to-pe2-2 { to 192.168.2.2; primary via-P2 { admin-group include-any silver; }}label-switched-path lsp-bronze-pe1-to-pe2-2 { to 192.168.2.2; primary via-P2 { admin-group include-any bronze; }}path via-P2 { 192.168.5.2 loose;}interface ge-1/0/0.220 { admin-group [ silver bronze ];}interface ge-1/0/1.221 {

Junos MPLS and VPNs


admin-group gold;}

[edit protocols mpls]lab@mxB-1# commit and-quit commit completeExiting configuration mode

Step 5.4

Verify that each LSP is traversing the correct, colored path as well as passing through P2.

lab@mxB-1> show rsvp session Ingress RSVP: 3 sessionsTo From State Rt Style Labelin Labelout LSPname 192.168.2.2 192.168.2.1 Up 0 1 FF - 308880 lsp-bronze-pe1-to-pe2-2192.168.2.2 192.168.2.1 Up 0 1 FF - 306720 lsp-gold-pe1-to-pe2-2192.168.2.2 192.168.2.1 Up 0 1 FF - 308912 lsp-silver-pe1-to-pe2-2Total 3 displayed, Up 3, Down 0

Egress RSVP: 3 sessionsTo From State Rt Style Labelin Labelout LSPname 192.168.2.1 192.168.2.2 Up 0 1 FF 3 - lsp-bronze-pe2-to-pe1-2192.168.2.1 192.168.2.2 Up 0 1 FF 3 - lsp-gold-pe2-to-pe1-2192.168.2.1 192.168.2.2 Up 0 1 FF 3 - lsp-silver-pe2-to-pe1-2Total 3 displayed, Up 3, Down 0


lab@mxB-1> show rsvp session detail Ingress RSVP: 3 sessions

192.168.2.2 From: 192.168.2.1, LSPstate: Up, ActiveRoute: 0 LSPname: lsp-bronze-pe1-to-pe2-2, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 308880 Resv style: 1 FF, Label in: -, Label out: 308880 Time left: -, Since: Fri Dec 10 19:28:58 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 3 receiver 20119 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 172.22.220.2 (ge-1/0/0.220) 3 pkts RESV rcvfrom: 172.22.220.2 (ge-1/0/0.220) 3 pkts

Junos MPLS and VPNs


Explct route: 172.22.220.2 172.22.201.2 172.22.205.2 172.22.204.2 172.22.207.1 172.22.222.1 Record route: <self> 172.22.220.2 172.22.201.2 172.22.205.2 172.22.204.2 172.22.207.1 172.22.222.1

192.168.2.2 From: 192.168.2.1, LSPstate: Up, ActiveRoute: 0 LSPname: lsp-gold-pe1-to-pe2-2, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 306720 Resv style: 1 FF, Label in: -, Label out: 306720 Time left: -, Since: Fri Dec 10 19:28:58 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 3 receiver 20120 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 172.22.221.2 (ge-1/0/1.221) 3 pkts RESV rcvfrom: 172.22.221.2 (ge-1/0/1.221) 3 pkts Explct route: 172.22.221.2 172.22.202.1 172.22.201.2 172.22.205.2 172.22.204.2 172.22.223.1 Record route: <self> 172.22.221.2 172.22.202.1 172.22.201.2 172.22.205.2 172.22.204.2 172.22.223.1

192.168.2.2 From: 192.168.2.1, LSPstate: Up, ActiveRoute: 0 LSPname: lsp-silver-pe1-to-pe2-2, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 308912 Resv style: 1 FF, Label in: -, Label out: 308912 Time left: -, Since: Fri Dec 10 19:28:58 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 4 receiver 20121 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 172.22.220.2 (ge-1/0/0.220) 3 pkts RESV rcvfrom: 172.22.220.2 (ge-1/0/0.220) 3 pkts Explct route: 172.22.220.2 172.22.202.2 172.22.203.2 172.22.205.1 172.22.206.2 172.22.222.1 Record route: <self> 172.22.220.2 172.22.202.2 172.22.203.2 172.22.205.1 172.22.206.2 172.22.222.1 Total 3 displayed, Up 3, Down 0...

Junos MPLS and VPNs


Question: List the routers that the gold LSP traverses. Does it traverse the expected path?

Answer: The gold LSP traverses all routers along the gold path including P2. This path is expected.

Question: List the routers that the silver LSP traverses. Does it traverse the expected path?

Answer: The silver LSP traverses all routers along the silver path including P2. This path is expected.

Question: List the routers that the bronze LSP traverses. Does it traverse the expected path?

Answer: The bronze LSP traverses all routers along the bronze path including P2. This path is expected.


www.juniper.net Traffic Protection (Detailed) • Lab 4–110.a.10.3R1.9

Lab 4Traffic Protection (Detailed)

Overview

In this lab, you will create a baseline multiprotocol label switching (MPLS) network and then create label switched paths (LSPs) using different traffic protection mechanisms.



• Create a baseline network.

• Define an Resource Reservation Protocol (RSVP) signalled LSP to the remote provider edge (PE) router.

• Add primary/secondary path protection to an LSP.

• Add secondary/secondary path protection to an LSP.

• Add fast-reroute protection to an LSP.

• Add node-link protection to an LSP.

• Add link protection to an LSP.

Junos MPLS and VPNs

Lab 4–2 • Traffic Protection (Detailed) www.juniper.net

Part 1: Creating the Baseline Network

In this lab part, you will configure the baseline network for the lab. You will load the baseline configuration that was saved at the end of Lab 1 and then enable RSVP and MPLS on the core-facing interfaces. Please refer to the lab diagram titled “Lab 3: CSPF”.

Step 1.1


lab@mxC-1> configure Entering configuration mode

[edit]lab@mxC-1# load override jmv-lab1-Routername-baseline load complete

[edit]lab@mxC-1# commit and-quit commit completeExiting configuration mode

Step 1.2

Verify that your PE router has established Open Shortest Path First (OSPF) adjacencies with the neighboring P routers.

lab@mxC-1> show ospf neighbor Address Interface State ID Pri Dead172.22.230.2 ge-1/0/0.230 Full 192.168.5.1 128 31172.22.231.2 ge-1/0/1.231 Full 192.168.5.4 128 39


Answer: The neighboring P routers should be in a Full state with your PE router. If they are not, double check the interface and OSPF settings. If you need further assistance, consult with your instructor.

Step 1.3


lab@mxC-1> show bgp neighbor 192.168.x.yPeer: 192.168.3.2+179 AS 65512 Local: 192.168.3.1+59514 AS 65512 Type: Internal State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive

Junos MPLS and VPNs

www.juniper.net Traffic Protection (Detailed) • Lab 4–3

Last Error: None Options: <Preference LocalAddress Refresh> Local Address: 192.168.3.1 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.3.2 Local ID: 192.168.3.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 65512) Peer does not support Addpath Table inet.0 Bit: 10001 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Last traffic (seconds): Received 20 Sent 10 Checked 39 Input messages: Total 1211 Updates 3 Refreshes 0 Octets 23058 Output messages: Total 1212 Updates 2 Refreshes 0 Octets 23136

lab@mxC-1> show bgp summary Groups: 3 Peers: 3 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...10.0.30.1 65512 11 10 0 0 3:19 Establ ce3-1.inet.0: 0/0/0/010.0.30.2 65301 10 12 0 1 3:19 Establ inet.0: 0/0/0/0192.168.3.2 65512 1212 1213 0 0 9:07:01 Establ inet.0: 0/0/0/0

Junos MPLS and VPNs


Question: Has your PE router established a neighbor relationship with the remote PE router?


Step 1.4

For an interface to support the forwarding of MPLS packets, you must enable the MPLS family on each interface. Enter configuration mode and navigate to the [edit interfaces] hierarchy. Enable family mpls on both of the core facing interfaces.


[edit]lab@mxC-1# edit interfaces

[edit interfaces]lab@mxC-1# set ge-1/0/0 unit 2xy family mpls


Step 1.5

Navigate to the [edit protocols mpls] hierarchy and configure the MPLS protocol on the core-facing interfaces.

[edit interfaces]lab@mxC-1# top edit protocols mpls

[edit protocols mpls]lab@mxC-1# set interface ge-1/0/0.2xy

[edit protocols mpls]lab@mxC-1# set interface ge-1/0/1.2xy

Step 1.6

Navigate to the [edit protocols rsvp] hierarchy and configure the RSVP protocol on the core-facing interfaces.

Junos MPLS and VPNs


[edit protocols mpls]lab@mxC-1# top edit protocols rsvp

[edit protocols rsvp]lab@mxC-1# set interface ge-1/0/0.2xy


Step 1.7

Navigate to the [edit protocols ospf] hierarchy and enable traffic-engineering so that your router will flood its own OpaqArea links state advertisement (LSA) and use these LSA types to build and use the traffic engineering database (TED) for constrained shortest path first (CSPF) calculations. Commit your configuration and exit to operational mode.

[edit protocols rsvp]lab@mxC-1# top edit protocols ospf

[edit protocols ospf]lab@mxC-1# set traffic-engineering

[edit protocols ospf]lab@mxC-1# commit and-quit commit complete

Step 1.8


lab@mxC-1> show mpls interface Interface State Administrative groupsge-1/0/0.230 Up <none>ge-1/0/1.231 Up <none>

lab@mxC-1> show rsvp interface RSVP interface: 2 active Active Subscr- Static Available Reserved HighwaterInterface State resv iption BW BW BW markge-1/0/0.230Up 0 100% 1000Mbps 1000Mbps 0bps 0bps ge-1/0/1.231Up 0 100% 1000Mbps 1000Mbps 0bps 0bps

Junos MPLS and VPNs


Part 2: Redistributing Routes into BGP

In this lab part, each PE router will be configured for a static route. You will then redistribute that static route into BGP using policy. Review the lab diagram to verify the static route.

Step 2.1

Enter configuration mode and navigate to the [edit routing-options] hierarchy. Configure the static route associated with your PE. Configure a next hop of reject for that route.


[edit]lab@mxC-1# edit routing-options

[edit routing-options]lab@mxC-1# set static route 10.0.y/24 reject

Step 2.2

Navigate to the [edit policy-options] hierarchy and configure a routing policy called statics to redistribute the static route into BGP.

[edit routing-options]lab@mxC-1# top edit policy-options

[edit policy-options]lab@mxC-1# set policy-statement statics term 10 from protocol static

[edit policy-options]lab@mxC-1# set policy-statement statics term 10 then accept

Step 2.3

Navigate to the [edit protocols bgp] hierarchy and apply the policy as an export policy to the remote PE neighbor. Commit your configuration and exit to operation mode.

[edit policy-options]lab@mxC-1# top edit protocols bgp

[edit protocols bgp]lab@mxC-1# set group my-int-group export statics

[edit protocols bgp]lab@mxC-1# commit and-quit commit completeExiting configuration mode

Step 2.4

Verify that you are sending a route to your remote PE neighbor as well as receiving a route.

Junos MPLS and VPNs


lab@mxC-1> show route advertising-protocol bgp 192.168.x.y

inet.0: 45 destinations, 45 routes (45 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 10.0.1.0/24 Self 100 I

lab@mxC-1> show route receive-protocol bgp 192.168.x.y

inet.0: 45 destinations, 45 routes (45 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 10.0.2.0/24 192.168.3.2 100 I


mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)


Part 3: Creating an LSP to the Remote PE

In this lab part, you will create an RSVP-signalled LSP from your PE to the remote PE. The second router along the path of the LSP must be either P1 or P3 depending on the PE router that you are configuring. You will specify a strict hop of the provider router’s connecting interface. Refer to the lab diagram titled “Lab 4: Traffic Protection” to determine the path of your LSP.

Step 3.1

Enter configuration mode and navigate to the [edit protocols mpls] hierarchy. Create a path for your LSP named strict-first-hop using the hops listed in the following table:

Ingress PE Strict Hop Loose Hop

mxA-1 172.22.210.2 192.168.5.6

mxA-2 172.22.212.2 192.168.5.4

mxB-1 172.22.220.2 192.168.5.6

mxB-2 172.22.222.2 192.168.5.4

mxC-1 172.22.230.2 192.168.5.6

mxC-2 172.22.232.2 192.168.5.4

mxD-1 172.22.240.2 192.168.5.6

mxD-2 172.22.242.2 192.168.5.4

Junos MPLS and VPNs



[edit]lab@mxC-1# edit protocols mpls

[edit protocols mpls]lab@mxC-1# set path strict-first-hop 172.22.x.y strict

[edit protocols mpls]lab@mxC-1# set path strict-first-hop 192.168.x.y loose

Step 3.2

Configure an LSP named pey-to-pez-x to the remote PE with a primary path using the path you created in the previous step. Modify the LSP with the no-cspf command. Commit your configuration and exit configuration mode and verify that your LSP is up.

[edit protocols mpls]lab@mxC-1# set label-switched-path pey-to-pez-x to 192.168.x.y primary strict-first-hop

[edit]lab@mxC-1# set label-switched-path pey-to-pez-x no-cspf

[edit protocols mpls]lab@mxC-1# commit and-quit commit completeExiting configuration mode

Step 3.3

Verify that the new LSP is up and is currently traversing the correct downstream P router.

lab@mxC-1> show rsvp session ingress Ingress RSVP: 1 sessionsTo From State Rt Style Labelin Labelout LSPname 192.168.3.2 192.168.3.1 Up 1 1 FF - 307296 pe1-to-pe2-3Total 1 displayed, Up 1, Down 0

lab@mxC-1> show rsvp session ingress detail Ingress RSVP: 1 sessions

192.168.3.2 From: 192.168.3.1, LSPstate: Up, ActiveRoute: 1 LSPname: pe1-to-pe2-3, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 307296 Resv style: 1 FF, Label in: -, Label out: 307296 Time left: -, Since: Mon Dec 13 22:47:51 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 64624 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500

Junos MPLS and VPNs


Path MTU: received 1500 PATH sentto: 172.22.230.2 (ge-1/0/0.230) 3 pkts RESV rcvfrom: 172.22.230.2 (ge-1/0/0.230) 3 pkts Explct route: 172.22.230.2 192.168.5.6 Record route: <self> 172.22.230.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.233.1 Total 1 displayed, Up 1, Down 0

Question: Is the new LSP up?

Answer: Yes, the LSP should be up.

Question: What path is the LSPs taking through the network? List the routers that the LSPs traverse.

Answer: The LSP should at least traverse the routers listed in the table.

Step 3.4

Enter configuration mode and disable the interface on your PE router that is being used by the primary path of the LSP. Commit your configuration and exit to operational mode.


[edit]lab@mxC-1# set interfaces ge-1/0/0 disable


Step 3.5

Verify the status of the LSP.

lab@mxC-1> show rsvp session ingressIngress RSVP: 1 sessionsTo From State Rt Style Labelin Labelout LSPname 192.168.3.2 192.168.3.1 Dn 0 0 - - - pe1-to-pe2-3Total 1 displayed, Up 0, Down 1

Junos MPLS and VPNs


Question: What happens to the status of the LSP while the interface is disabled?

Answer: The LSP will go to a down state and will remain in a down state until the failed link is repaired. The LSP will be unusable during that time because no traffic protection mechanisms are enabled.

Step 3.6

Enter configuration mode and enable the interface on your PE router that is being used by the primary path of the LSP. Commit your configuration and exit to operational mode.


[edit]lab@mxC-1# delete interfaces ge-1/0/0 disable


Step 3.7

Verify that the LSP is up using the show rsvp session ingress command.

lab@mxC-1> show rsvp session ingressIngress RSVP: 1 sessionsTo From State Rt Style Labelin Labelout LSPname 192.168.3.2 192.168.3.1 Up 1 1 FF - 307360 pe1-to-pe2-3Total 1 displayed, Up 1, Down 0

Part 4: Configuring a Secondary Path for Added Protection

In this lab part, you will configure a secondary path for the LSP to add traffic protection to the LSP.

Step 4.1

Enter configuration mode and navigate to the [edit protocols mpls] hierarchy. Create a secondary path called any-path that lists no hops. That is, this path should make it as easy as possible for the network to build a secondary path.



Junos MPLS and VPNs


[edit protocols mpls]lab@mxC-1# set path any-path

Step 4.2

To provide traffic protection to the existing LSP, apply the path created in the previous step as a secondary path for the LSP. Commit your configuration and exit configuration mode.

[edit protocols mpls]lab@mxC-1# set label-switched-path pey-to-pez-x secondary any-path


Step 4.3

Verify that the new LSP is up and is currently traversing the correct next-hop P router.


192.168.3.2 From: 192.168.3.1, LSPstate: Up, ActiveRoute: 1 LSPname: pe1-to-pe2-3, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 307360 Resv style: 1 FF, Label in: -, Label out: 307360 Time left: -, Since: Mon Dec 13 22:47:51 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 64624 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 172.22.230.2 (ge-1/0/0.230) 495 pkts RESV rcvfrom: 172.22.230.2 (ge-1/0/0.230) 492 pkts Explct route: 172.22.230.2 192.168.5.6 Record route: <self> 172.22.230.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.233.1 Total 1 displayed, Up 1, Down 0

Question: Is the secondary path in an up state? Why or why not?

Answer: The secondary should not be up. Without the standby option configured, the secondary will remain down until the primary has failed.

Junos MPLS and VPNs


Step 4.4





Step 4.5


lab@mxC-1> show rsvp session ingress extensive Ingress RSVP: 2 sessions

192.168.3.2 From: 192.168.3.1, LSPstate: Dn, ActiveRoute: 0 LSPname: pe1-to-pe2-3, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: - Resv style: 0 -, Label in: -, Label out: - Time left: -, Since: Mon Dec 13 22:47:51 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 64624 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 0 PATH sentto: [bad strict route] Explct route: 172.22.230.2 192.168.5.6 Record route: <self> ...incomplete

192.168.3.2 From: 192.168.3.1, LSPstate: Up, ActiveRoute: 1 LSPname: pe1-to-pe2-3, LSPpath: Secondary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 303840 Resv style: 1 FF, Label in: -, Label out: 303840 Time left: -, Since: Tue Dec 14 04:54:52 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 2 receiver 64625 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 172.22.231.2 (ge-1/0/1.231) 3 pkts RESV rcvfrom: 172.22.231.2 (ge-1/0/1.231) 3 pkts

Junos MPLS and VPNs


Record route: <self> 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 Total 2 displayed, Up 1, Down 1


Answer: The primary path of the LSP will go to a down state and will remain in a down state until the failed link is repaired. However, because a secondary path has been configured, when the link fails the LSP is then re-signalled by RSVP and the LSP comes back up on the secondary path. The LSP will be unusable for only a short period while the secondary path is signaled.

Step 4.6





Step 4.7

Use the show mpls lsp extensive command to verify the status of the LSP.

lab@mxC-1> show mpls lsp extensive Ingress LSP: 1 sessions

192.168.3.2 From: 192.168.3.1, State: Up, ActiveRoute: 1, LSPname: pe1-to-pe2-3 ActivePath: any-path (secondary) LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 Time remaining before reverting: 44 Primary strict-first-hop State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):

Junos MPLS and VPNs


172.22.230.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.233.1 20 Dec 14 04:56:02.226 Record Route: 172.22.230.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.233.1 19 Dec 14 04:56:02.226 Up 18 Dec 14 04:55:38.083 Explicit Route: bad strict route[4 times] 17 Dec 14 04:54:52.893 Deselected as active 16 Dec 14 04:54:52.889 No Route toward dest 15 Dec 14 04:54:52.887 172.22.230.1: Down 14 Dec 14 04:44:47.072 Selected as active path 13 Dec 14 04:44:47.071 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.233.1 12 Dec 14 04:44:47.071 Up 11 Dec 14 04:44:25.487 Explicit Route: bad strict route[5 times] 10 Dec 14 04:43:29.292 Deselected as active 9 Dec 14 04:43:29.292 No Route toward dest 8 Dec 14 04:43:29.291 172.22.230.1: Down 7 Dec 13 22:48:45.792 Record Route: 172.22.230.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.233.1 6 Dec 13 22:48:45.792 Up 5 Dec 13 22:48:45.792 172.22.230.1: Down 4 Dec 13 22:47:51.791 Selected as active path 3 Dec 13 22:47:51.789 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.233.1 2 Dec 13 22:47:51.789 Up 1 Dec 13 22:47:51.771 Originate Call *Secondary any-path State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 6 Dec 14 04:55:46.914 Up 5 Dec 14 04:55:46.914 172.22.231.1: Down 4 Dec 14 04:54:52.944 Selected as active path 3 Dec 14 04:54:52.940 Record Route: 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 2 Dec 14 04:54:52.940 Up 1 Dec 14 04:54:52.892 Originate Call Created: Mon Dec 13 22:47:51 2010Total 1 displayed, Up 1, Down 0

Question: Which path is being used by the LSP immediately after enabling the interface? Why?

Answer: The secondary path is still being used by the LSP. The output of the command shows that it will be about 44 seconds or so before traffic will be moved over to the primary path. This delay is a safeguard against a flapping interface.

Junos MPLS and VPNs


Part 5: Configuring Secondary Standby Protection

In this lab part, you will configure a secondary path that will be on hot standby for the LSP to add even more traffic protection to the LSP.

Step 5.1

Enter configuration mode and navigate to the [edit protocols mpls] hierarchy. To provide slightly more traffic protection to the existing LSP, apply the any-path path as a standby secondary path for the LSP. Commit your configuration and exit configuration mode and verify that your LSP is up.



[edit protocols mpls]lab@mxC-1# set label-switched-path pey-to-pez-x secondary any-path standby


Step 5.2

Verify that the new LSP is up using the primary path. Also, verify that the secondary path is up in a standby state.

lab@mxC-1> show mpls lsp ingress extensive Ingress LSP: 1 sessions

192.168.3.2 From: 192.168.3.1, State: Up, ActiveRoute: 1, LSPname: pe1-to-pe2-3 ActivePath: strict-first-hop (primary) LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary strict-first-hop State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.230.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.233.1 21 Dec 14 04:57:03.688 Selected as active path: due to 'primary' 20 Dec 14 04:56:02.226 Record Route: 172.22.230.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.233.1 19 Dec 14 04:56:02.226 Up 18 Dec 14 04:55:38.083 Explicit Route: bad strict route[4 times] 17 Dec 14 04:54:52.893 Deselected as active 16 Dec 14 04:54:52.889 No Route toward dest 15 Dec 14 04:54:52.887 172.22.230.1: Down 14 Dec 14 04:44:47.072 Selected as active path

Junos MPLS and VPNs


13 Dec 14 04:44:47.071 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.233.1 12 Dec 14 04:44:47.071 Up 11 Dec 14 04:44:25.487 Explicit Route: bad strict route[5 times] 10 Dec 14 04:43:29.292 Deselected as active 9 Dec 14 04:43:29.292 No Route toward dest 8 Dec 14 04:43:29.291 172.22.230.1: Down 7 Dec 13 22:48:45.792 Record Route: 172.22.230.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.233.1 6 Dec 13 22:48:45.792 Up 5 Dec 13 22:48:45.792 172.22.230.1: Down 4 Dec 13 22:47:51.791 Selected as active path 3 Dec 13 22:47:51.789 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.233.1 2 Dec 13 22:47:51.789 Up 1 Dec 13 22:47:51.771 Originate Call Standby any-path State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 16 Dec 14 05:00:53.345 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 15 Dec 14 05:00:53.345 Up 14 Dec 14 05:00:08.351 ResvTear received 13 Dec 14 05:00:08.351 172.22.230.1: Down 12 Dec 14 05:00:08.351 172.22.206.2: Session preempted 11 Dec 14 04:59:59.344 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 10 Dec 14 04:59:59.344 Up 9 Dec 14 04:59:59.326 Originate Call 8 Dec 14 04:58:31.270 Clear Call 7 Dec 14 04:57:03.688 Deselected as active: due to 'primary' 6 Dec 14 04:55:46.914 Up 5 Dec 14 04:55:46.914 172.22.231.1: Down 4 Dec 14 04:54:52.944 Selected as active path 3 Dec 14 04:54:52.940 Record Route: 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 2 Dec 14 04:54:52.940 Up 1 Dec 14 04:54:52.892 Originate Call Created: Mon Dec 13 22:47:51 2010Total 1 displayed, Up 1, Down 0

Question: Is the primary path up? Secondary?

Answer: Yes, the primary and secondary path should be up.

Junos MPLS and VPNs


Question: What path is the secondary path taking through the network? List the routers that the LSPs traverse.

Answer: The Junos operating system attempts to signal a secondary standby LSP along a different outbound path than the primary.

Step 5.3

Enter configuration mode and disable the interface on your PE that is being used by the primary path of the LSP. Commit your configuration and exit to operational mode.




Step 5.4

Verify the status of the LSP using the show mpls lsp ingress extensive command.


192.168.3.2 From: 192.168.3.1, State: Up, ActiveRoute: 1, LSPname: pe1-to-pe2-3 ActivePath: any-path (secondary) LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 Primary strict-first-hop State: Dn Priorities: 7 0 SmartOptimizeTimer: 180 25 Dec 14 05:03:28.687 Explicit Route: bad strict route[3 times] 24 Dec 14 05:03:23.967 Deselected as active 23 Dec 14 05:03:23.965 No Route toward dest 22 Dec 14 05:03:23.962 172.22.230.1: Down 21 Dec 14 04:57:03.688 Selected as active path: due to 'primary' 20 Dec 14 04:56:02.226 Record Route: 172.22.230.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.233.1 19 Dec 14 04:56:02.226 Up 18 Dec 14 04:55:38.083 Explicit Route: bad strict route[4 times] 17 Dec 14 04:54:52.893 Deselected as active 16 Dec 14 04:54:52.889 No Route toward dest

Junos MPLS and VPNs


15 Dec 14 04:54:52.887 172.22.230.1: Down 14 Dec 14 04:44:47.072 Selected as active path 13 Dec 14 04:44:47.071 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.233.1 12 Dec 14 04:44:47.071 Up 11 Dec 14 04:44:25.487 Explicit Route: bad strict route[5 times] 10 Dec 14 04:43:29.292 Deselected as active 9 Dec 14 04:43:29.292 No Route toward dest 8 Dec 14 04:43:29.291 172.22.230.1: Down 7 Dec 13 22:48:45.792 Record Route: 172.22.230.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.233.1 6 Dec 13 22:48:45.792 Up 5 Dec 13 22:48:45.792 172.22.230.1: Down 4 Dec 13 22:47:51.791 Selected as active path 3 Dec 13 22:47:51.789 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.233.1 2 Dec 13 22:47:51.789 Up 1 Dec 13 22:47:51.771 Originate Call *Standby any-path State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 21 Dec 14 05:03:28.700 Selected as active path 20 Dec 14 05:03:28.699 Record Route: 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 19 Dec 14 05:03:28.699 Up 18 Dec 14 05:03:23.966 No Route toward dest 17 Dec 14 05:03:23.965 172.22.230.1: Down 16 Dec 14 05:00:53.345 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 15 Dec 14 05:00:53.345 Up 14 Dec 14 05:00:08.351 ResvTear received 13 Dec 14 05:00:08.351 172.22.230.1: Down 12 Dec 14 05:00:08.351 172.22.206.2: Session preempted 11 Dec 14 04:59:59.344 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 10 Dec 14 04:59:59.344 Up 9 Dec 14 04:59:59.326 Originate Call 8 Dec 14 04:58:31.270 Clear Call 7 Dec 14 04:57:03.688 Deselected as active: due to 'primary' 6 Dec 14 04:55:46.914 Up 5 Dec 14 04:55:46.914 172.22.231.1: Down 4 Dec 14 04:54:52.944 Selected as active path 3 Dec 14 04:54:52.940 Record Route: 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 2 Dec 14 04:54:52.940 Up 1 Dec 14 04:54:52.892 Originate Call Created: Mon Dec 13 22:47:51 2010Total 1 displayed, Up 1, Down 0

Junos MPLS and VPNs



Answer: The primary path of the LSP will go to a down state and will remain in a down state until the failed link is repaired. However, because a standby secondary LSP has been configured, when the link fails the secondary path almost immediately available for use by the LSP. The LSP will be usable for the entire time that the primary path is down except for the short time that it takes to change the next hop in the PFE forwarding table.

Step 5.5





Step 5.6

Use the show mpls lsp ingress extensive command to verify the status of the LSP.


192.168.3.2 From: 192.168.3.1, State: Up, ActiveRoute: 1, LSPname: pe1-to-pe2-3 ActivePath: any-path (secondary) LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 Time remaining before reverting: 50 Primary strict-first-hop State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.230.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.233.1

Junos MPLS and VPNs


27 Dec 14 05:04:52.838 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.233.1 26 Dec 14 05:04:52.837 Up 25 Dec 14 05:04:38.229 Explicit Route: bad strict route[5 times] 24 Dec 14 05:03:23.967 Deselected as active 23 Dec 14 05:03:23.965 No Route toward dest 22 Dec 14 05:03:23.962 172.22.230.1: Down 21 Dec 14 04:57:03.688 Selected as active path: due to 'primary' 20 Dec 14 04:56:02.226 Record Route: 172.22.230.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.233.1 19 Dec 14 04:56:02.226 Up 18 Dec 14 04:55:38.083 Explicit Route: bad strict route[4 times] 17 Dec 14 04:54:52.893 Deselected as active 16 Dec 14 04:54:52.889 No Route toward dest 15 Dec 14 04:54:52.887 172.22.230.1: Down 14 Dec 14 04:44:47.072 Selected as active path 13 Dec 14 04:44:47.071 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.233.1 12 Dec 14 04:44:47.071 Up 11 Dec 14 04:44:25.487 Explicit Route: bad strict route[5 times] 10 Dec 14 04:43:29.292 Deselected as active 9 Dec 14 04:43:29.292 No Route toward dest 8 Dec 14 04:43:29.291 172.22.230.1: Down 7 Dec 13 22:48:45.792 Record Route: 172.22.230.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.233.1 6 Dec 13 22:48:45.792 Up 5 Dec 13 22:48:45.792 172.22.230.1: Down 4 Dec 13 22:47:51.791 Selected as active path 3 Dec 13 22:47:51.789 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.207.2 172.22.233.1 2 Dec 13 22:47:51.789 Up 1 Dec 13 22:47:51.771 Originate Call *Standby any-path State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 21 Dec 14 05:03:28.700 Selected as active path 20 Dec 14 05:03:28.699 Record Route: 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 19 Dec 14 05:03:28.699 Up 18 Dec 14 05:03:23.966 No Route toward dest 17 Dec 14 05:03:23.965 172.22.230.1: Down 16 Dec 14 05:00:53.345 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 15 Dec 14 05:00:53.345 Up 14 Dec 14 05:00:08.351 ResvTear received 13 Dec 14 05:00:08.351 172.22.230.1: Down 12 Dec 14 05:00:08.351 172.22.206.2: Session preempted 11 Dec 14 04:59:59.344 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 10 Dec 14 04:59:59.344 Up 9 Dec 14 04:59:59.326 Originate Call 8 Dec 14 04:58:31.270 Clear Call

Junos MPLS and VPNs


7 Dec 14 04:57:03.688 Deselected as active: due to 'primary' 6 Dec 14 04:55:46.914 Up 5 Dec 14 04:55:46.914 172.22.231.1: Down 4 Dec 14 04:54:52.944 Selected as active path 3 Dec 14 04:54:52.940 Record Route: 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 2 Dec 14 04:54:52.940 Up 1 Dec 14 04:54:52.892 Originate Call Created: Mon Dec 13 22:47:50 2010Total 1 displayed, Up 1, Down 0

Question: What path is being used by the LSP immediately after enabling the interface? Why?

Answer: The secondary path is still being used by the LSP. The output of the command shows that it will be about 50 seconds or so before traffic will be moved over to the primary path. This delay is a safeguard against a flapping interface.

Step 5.7

After the LSP has reverted to the primary path, view the forwarding table to see the next hop of the BGP route being advertised by the remote PE router.

lab@mxC-1> show route forwarding-table destination 10.0.y.0 Routing table: default.inetInternet:Destination Type RtRef Next hop Type Index NhRef Netif10.0.2.0/24 user 0 indr 1048575 2 172.22.230.2 Push 307424 584 1 ge-1/0/0.230

Question: How many next hops are associated with the received BGP route?

Answer: By default, only one next hop is installed in the forwarding table.

Junos MPLS and VPNs


Question: When using a standby secondary LSP, a very short time exists when traffic cannot be forwarded through the secondary path at the moment of primary failure. The cause of this short delay is the time it takes to install the new next hop in the forwarding table of the PFE. Can you shorten this delay? How?

Answer: To shorten the time that it takes to forward traffic using the secondary path, a load balancing policy can be applied to the forwarding table, which will cause the next hop of the secondary path to be placed in the forwarding table prior to a failure.

Step 5.8

Enter configuration mode and navigate to the [edit policy-options] hierarchy. Create a load balancing policy called load-balance that performs load balancing on all prefixes.


[edit]lab@mxC-1# edit policy-options

[edit policy-options]lab@mxC-1# set policy-statement load-balance term 10 then load-balance per-packet

Step 5.9

Navigate to the [edit routing-options] hierarchy. Apply the load-balance policy as an export policy to the forwarding table. Commit your configuration and exit to operational mode.

[edit policy-options]lab@mxC-1# top edit routing-options

[edit routing-options]lab@mxC-1# set forwarding-table export load-balance

[edit routing-options]lab@mxC-1# commit and-quit commit completeExiting configuration mode

Junos MPLS and VPNs


Step 5.10

View the forwarding table to see the next hop of the BGP route being advertised by the remote PE router.

lab@mxC-1> show route forwarding-table destination 10.0.y.0 Routing table: default.inetInternet:Destination Type RtRef Next hop Type Index NhRef Netif10.0.2.0/24 user 0 indr 1048575 2 ulst 1048576 2 172.22.230.2 Push 307424 584 1 ge-1/0/0.230 172.22.231.2 Push 303888 583 1 ge-1/0/1.231

Question: How many next hops are associated with the received BGP route?

Answer: Two next hops should exist in the forwarding table. This should shorten the delay in the event of a failure of the primary path.

Part 6: Examining a Secondary/Secondary Protected LSP

In this lab part, you will familiarize yourself with the behavior of an LSP with no primary path. Instead, the LSP will have two secondary paths.

Step 6.1

Enter configuration mode navigate to the [edit protocols mpls] hierarchy. Delete the LSP from the previous sections of the lab.



[edit protocols mpls]lab@mxC-1# delete label-switched-path pey-to-pez-x

Step 6.2

Create a no-cspf LSP named pey-to-pez-x to the remote PE with two secondary paths. The first secondary path uses the strict-first-hop path and the next uses the any-path path. Order is important!!! Commit your configuration and exit to operational mode.

[edit protocols mpls]lab@mxC-1# set label-switched-path pey-to-pez-x to 192.168.x.y no-cspf

[edit protocols mpls]

Junos MPLS and VPNs


lab@mxC-1# set label-switched-path pey-to-pez-x secondary strict-first-hop

[edit protocols mpls]lab@mxC-1# set label-switched-path pey-to-pez-x secondary any-path


Step 6.3


lab@mxC-1> show mpls lsp ingress extensiveIngress LSP: 1 sessions

192.168.3.2 From: 192.168.3.1, State: Up, ActiveRoute: 1, LSPname: pe1-to-pe2-3 ActivePath: strict-first-hop (secondary) LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Secondary strict-first-hop State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.230.2 172.22.201.2 172.22.205.2 172.22.204.2 172.22.233.1 7 Dec 14 13:52:42.026 Record Route: 172.22.230.2 172.22.201.2 172.22.205.2 172.22.204.2 172.22.233.1 6 Dec 14 13:52:42.026 Up 5 Dec 14 13:52:42.026 172.22.230.1: Down 4 Dec 14 13:52:33.051 Selected as active path 3 Dec 14 13:52:33.049 Record Route: 172.22.230.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.233.1 2 Dec 14 13:52:33.049 Up 1 Dec 14 13:52:33.008 Originate Call Secondary any-path State: Dn Priorities: 7 0 SmartOptimizeTimer: 180 10 Dec 14 13:54:01.644 Clear Call 9 Dec 14 13:53:39.030 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 8 Dec 14 13:53:39.030 Up 7 Dec 14 13:52:51.030 No Route toward dest[3 times] 6 Dec 14 13:52:47.970 172.22.230.1: Down 5 Dec 14 13:52:47.970 No Route toward dest 4 Dec 14 13:52:45.042 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 3 Dec 14 13:52:45.042 Up 2 Dec 14 13:52:42.031 No Route toward dest[2 times] 1 Dec 14 13:52:42.027 Originate Call Created: Tue Dec 14 13:52:29 2010Total 1 displayed, Up 1, Down 0

Junos MPLS and VPNs


Question: Which secondary path is being used by the LSP?

Answer: The strict-first-hop path is currently being used because it was the first secondary path listed in the configuration.

Step 6.4

Enter configuration mode and disable the interface on your PE that is being used by the primary path of the LSP. Commit your configuration and exit to operational mode.




Step 6.5



192.168.3.2 From: 192.168.3.1, State: Up, ActiveRoute: 1, LSPname: pe1-to-pe2-3 ActivePath: any-path (secondary) LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 Secondary strict-first-hop State: Dn Priorities: 7 0 SmartOptimizeTimer: 180 11 Dec 14 13:58:06.475 Explicit Route: bad strict route[3 times] 10 Dec 14 13:58:01.513 Deselected as active 9 Dec 14 13:58:01.509 No Route toward dest 8 Dec 14 13:58:01.509 172.22.230.1: Down 7 Dec 14 13:52:42.026 Record Route: 172.22.230.2 172.22.201.2 172.22.205.2 172.22.204.2 172.22.233.1 6 Dec 14 13:52:42.026 Up 5 Dec 14 13:52:42.026 172.22.230.1: Down 4 Dec 14 13:52:33.051 Selected as active path 3 Dec 14 13:52:33.049 Record Route: 172.22.230.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.233.1 2 Dec 14 13:52:33.049 Up 1 Dec 14 13:52:33.008 Originate Call

Junos MPLS and VPNs


*Secondary any-path State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 14 Dec 14 13:58:01.562 Selected as active path 13 Dec 14 13:58:01.561 Record Route: 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 12 Dec 14 13:58:01.561 Up 11 Dec 14 13:58:01.512 Originate Call 10 Dec 14 13:54:01.644 Clear Call 9 Dec 14 13:53:39.030 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 8 Dec 14 13:53:39.030 Up 7 Dec 14 13:52:51.030 No Route toward dest[3 times] 6 Dec 14 13:52:47.970 172.22.230.1: Down 5 Dec 14 13:52:47.970 No Route toward dest 4 Dec 14 13:52:45.042 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 3 Dec 14 13:52:45.042 Up 2 Dec 14 13:52:42.031 No Route toward dest[2 times] 1 Dec 14 13:52:42.027 Originate Call Created: Tue Dec 14 13:52:28 2010Total 1 displayed, Up 1, Down 0


Answer: The first secondary path of the LSP goes to a down state and remain in a down state. However, another secondary LSP is signaled to provide traffic protection for the LSP.

Step 6.6

Enter configuration mode and enable the interface on your PE that is used by the primary path of the LSP. Commit your configuration and exit to operational mode.




Junos MPLS and VPNs


Step 6.7



192.168.3.2 From: 192.168.3.1, State: Up, ActiveRoute: 1, LSPname: pe1-to-pe2-3 ActivePath: any-path (secondary) LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 Secondary strict-first-hop State: Dn Priorities: 7 0 SmartOptimizeTimer: 180 12 Dec 14 13:58:25.076 Clear Call 11 Dec 14 13:58:12.040 Explicit Route: bad strict route[4 times] 10 Dec 14 13:58:01.513 Deselected as active 9 Dec 14 13:58:01.509 No Route toward dest 8 Dec 14 13:58:01.509 172.22.230.1: Down 7 Dec 14 13:52:42.026 Record Route: 172.22.230.2 172.22.201.2 172.22.205.2 172.22.204.2 172.22.233.1 6 Dec 14 13:52:42.026 Up 5 Dec 14 13:52:42.026 172.22.230.1: Down 4 Dec 14 13:52:33.051 Selected as active path 3 Dec 14 13:52:33.049 Record Route: 172.22.230.2 172.22.202.2 172.22.203.2 172.22.204.2 172.22.233.1 2 Dec 14 13:52:33.049 Up 1 Dec 14 13:52:33.008 Originate Call *Secondary any-path State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 14 Dec 14 13:58:01.562 Selected as active path 13 Dec 14 13:58:01.561 Record Route: 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 12 Dec 14 13:58:01.561 Up 11 Dec 14 13:58:01.512 Originate Call 10 Dec 14 13:54:01.644 Clear Call 9 Dec 14 13:53:39.030 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 8 Dec 14 13:53:39.030 Up 7 Dec 14 13:52:51.030 No Route toward dest[3 times] 6 Dec 14 13:52:47.970 172.22.230.1: Down 5 Dec 14 13:52:47.970 No Route toward dest 4 Dec 14 13:52:45.042 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 3 Dec 14 13:52:45.042 Up 2 Dec 14 13:52:42.031 No Route toward dest[2 times] 1 Dec 14 13:52:42.027 Originate Call Created: Tue Dec 14 13:52:29 2010Total 1 displayed, Up 1, Down 0

Junos MPLS and VPNs


Question: Which path is used by the LSP immediately after enabling the interface? Why?

Answer: The secondary path is still used and will continue to be used by the LSP. If no primary paths are configured, the new secondary paths will not revert to the old secondary path as long as no failures occur along the path of the new secondary path.

Part 7: Examining a Fast-Reroute Protected LSP

In this lab part, you will become familiar with an LSP that is protected by fast-reroute.

Step 7.1





Step 7.2

Create an no-cspf LSP named pey-to-pez-x to the remote PE with fast-reroute enabled. The LSP should have a primary path using the strict-first-hop path. Commit your configuration and exit to operational mode.


[edit protocols mpls]lab@mxC-1# set label-switched-path pey-to-pez-x to 192.168.x.y fast-reroute

[edit protocols mpls]lab@mxC-1# set label-switched-path pey-to-pez-x to 192.168.x.y primary strict-first-hop


Step 7.3

Use the show rsvp session ingress detail command to verify the status of the LSP.

Junos MPLS and VPNs



192.168.3.2 From: 192.168.3.1, LSPstate: Up, ActiveRoute: 1 LSPname: pe1-to-pe2-3, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 307488 Resv style: 1 FF, Label in: -, Label out: 307488 Time left: -, Since: Tue Dec 14 14:06:11 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 5 receiver 58977 protocol 0 FastReroute desired PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 172.22.230.2 (ge-1/0/0.230) 7 pkts RESV rcvfrom: 172.22.230.2 (ge-1/0/0.230) 10 pkts Explct route: 172.22.230.2 192.168.5.6 Record route: <self> 172.22.230.2 172.22.201.2 172.22.205.2 172.22.204.2 172.22.233.1 Detour is Up Detour Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Detour adspec: sent MTU 1500 Path MTU: received 1500 Detour PATH sentto: 172.22.231.2 (ge-1/0/1.231) 4 pkts Detour RESV rcvfrom: 172.22.231.2 (ge-1/0/1.231) 2 pkts Detour Explct route: 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 Detour Record route: <self> 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 Detour Label out: 303952Total 1 displayed, Up 1, Down 0

Question: Has the PE router signaled to the downstream routers that fast-reroute is desired?

Answer: Yes, fast-reroute has been signaled. The output of the show rsvp session command verifies this fact.

Question: Has your PE router signaled a detour path around the immediate downstream node? If so, what is the path of the detour?

Answer: Yes, the detour should have been signaled. The path will vary from PE router to PE router.

Junos MPLS and VPNs


Step 7.4





Step 7.5



192.168.3.2 From: 192.168.3.1, State: Up, ActiveRoute: 1, LSPname: pe1-to-pe2-3 ActivePath: strict-first-hop (primary) FastReroute desired LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary strict-first-hop State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.231.2 172.22.203.2 172.22.204.2(flag=1) 172.22.233.1 15 Dec 14 14:08:03.957 Tunnel local repaired[5 times] 14 Dec 14 14:07:54.952 Record Route: 172.22.231.2 172.22.203.2 172.22.204.2(flag=1) 172.22.233.1 13 Dec 14 14:07:54.952 172.22.230.1: Tunnel local repaired 12 Dec 14 14:07:54.952 172.22.230.1: Down 11 Dec 14 14:06:20.369 Fast-reroute Detour Up 10 Dec 14 14:06:14.481 Record Route: 172.22.230.2(flag=9) 172.22.201.2(flag=9) 172.22.205.2(flag=9) 172.22.204.2(flag=1) 172.22.233.1 9 Dec 14 14:06:14.481 Record Route: 172.22.230.2(flag=9) 172.22.201.2(flag=9) 172.22.205.2(flag=9) 172.22.204.2 172.22.233.1 8 Dec 14 14:06:14.481 Record Route: 172.22.230.2(flag=9) 172.22.201.2(flag=9) 172.22.205.2 172.22.204.2 172.22.233.1 7 Dec 14 14:06:14.481 Record Route: 172.22.230.2(flag=9) 172.22.201.2 172.22.205.2 172.22.204.2 172.22.233.1 6 Dec 14 14:06:11.482 Selected as active path 5 Dec 14 14:06:11.482 Record Route: 172.22.230.2 172.22.201.2 172.22.205.2 172.22.204.2 172.22.233.1 4 Dec 14 14:06:11.481 Up 3 Dec 14 14:06:11.364 Originate Call

Junos MPLS and VPNs


2 Dec 14 14:06:11.363 Clear Call 1 Dec 14 14:06:11.353 Originate Call Created: Tue Dec 14 13:52:29 2010Total 1 displayed, Up 1, Down 0


Answer: The LSP remains up but the fast-reroute detour path is used.

Step 7.6





Step 7.7



192.168.3.2 From: 192.168.3.1, LSPstate: Up, ActiveRoute: 1 LSPname: pe1-to-pe2-3, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 307504 Resv style: 1 FF, Label in: -, Label out: 307504 Time left: -, Since: Tue Dec 14 14:06:11 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 5 receiver 58977 protocol 0 FastReroute desired PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 172.22.230.2 (ge-1/0/0.230) 11 pkts RESV rcvfrom: 172.22.230.2 (ge-1/0/0.230) 20 pkts Explct route: 172.22.230.2 192.168.5.6

Junos MPLS and VPNs


Record route: <self> 172.22.230.2 172.22.201.2 172.22.205.2 172.22.204.2 172.22.233.1 Detour is Up Detour Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Detour adspec: sent MTU 1500 Path MTU: received 1500 Detour PATH sentto: 172.22.231.2 (ge-1/0/1.231) 15 pkts Detour RESV rcvfrom: 172.22.231.2 (ge-1/0/1.231) 12 pkts Detour Explct route: 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 Detour Record route: <self> 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 Detour Label out: 303952Total 1 displayed, Up 1, Down 0

Question: Which path is used by the LSP immediately after enabling the interface? Why?

Answer: Once the interface is up, the PE router signals a new LSP, moves traffic over to the new LSP, and then removes the old LSP.

Part 8: Examining Link and Node-Link Protected LSPs

In this lab part, you will become familiar with an LSP that is protected by link and node-link protection.

Step 8.1





Step 8.2

Create an no-cspf LSP named pey-to-pez-x to the remote PE router with node-link protection enabled. The LSP should have a primary path using the strict-first-hop path.


[edit protocols mpls]lab@mxC-1# set label-switched-path pey-to-pez-x primary strict-first-hop

Junos MPLS and VPNs


[edit protocols mpls]lab@mxC-1# set label-switched-path pey-to-pez-x node-link-protection

Step 8.3

In the previous part of the lab, you found that the fast-reroute feature allowed the ingress PE to signal to all downstream routers that they must build detour paths around the immediate downstream node. In the case of fast-reroute, no special configuration was needed on any downstream router to build detour paths. In the case of link and node-link protection, you must specify each individual link within your network topology that can be protected.

Navigate to the [edit protocols rsvp] hierarchy and configure the ge-1/0/0.2xy interface to allow link protection capabilities. Commit your configuration and exit to operational mode.


[edit protocols rsvp]lab@mxC-1# set interface ge-1/0/0.2xy link-protection

[edit protocols rsvp]lab@mxC-1# commit and-quit commit completeExiting configuration mode

Step 8.4



192.168.3.2 From: 192.168.3.1, LSPstate: Up, ActiveRoute: 1 LSPname: pe1-to-pe2-3, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 307520 Resv style: 1 SE, Label in: -, Label out: 307520 Time left: -, Since: Tue Dec 14 14:18:00 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 58979 protocol 0 Node/Link protection desired Type: Protection down PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 172.22.230.2 (ge-1/0/0.230) 3 pkts RESV rcvfrom: 172.22.230.2 (ge-1/0/0.230) 3 pkts Explct route: 172.22.230.2 192.168.5.6 Record route: <self> 192.168.5.1 (node-id) 172.22.230.2 192.168.5.4 (node-id) 172.22.202.2 192.168.5.5 (node-id) 172.22.203.2 192.168.5.6 (node-id)

Junos MPLS and VPNs


172.22.204.2 192.168.3.2 (node-id) 172.22.233.1

192.168.5.4 From: 192.168.3.1, LSPstate: Up, ActiveRoute: 0 LSPname: Bypass->172.22.230.2->172.22.202.2 LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 3 Resv style: 1 SE, Label in: -, Label out: 3 Time left: -, Since: Tue Dec 14 14:18:10 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 58980 protocol 0 Type: Bypass LSP Number of data route tunnel through: 0 Number of RSVP session tunnel through: 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 172.22.231.2 (ge-1/0/1.231) 3 pkts RESV rcvfrom: 172.22.231.2 (ge-1/0/1.231) 3 pkts Explct route: 172.22.231.2 Record route: <self> 172.22.231.2 Total 2 displayed, Up 2, Down 0

Question: Is the bypass LSP up?

Answer: Yes, the bypass LSP should be up.

Question: Does the bypass LSP provide protection for the failure of the P router that is directly connected to you through the ge-1/0/0 link?

Answer: Yes. Use the record route information for the bypass LSP to determine the path of the bypass LSP.

Step 8.5

Enter configuration mode navigate to the [edit protocols mpls] hierarchy. Modify your LSP to provide link protection.



[edit protocols mpls]lab@mxC-1# set label-switched-path pey-to-pez-x link-protection

Junos MPLS and VPNs


Step 8.6

View your MPLS configuration and verify that link protection is configured. Commit your configuration and exit to operational mode.

[edit protocols mpls]lab@mxC-1# show label-switched-path pe1-to-pe2-3 { to 192.168.3.2; no-cspf; link-protection; primary strict-first-hop;}path strict-first-hop { 172.22.230.2 strict; 192.168.5.6 loose;}path any-path;interface ge-1/0/0.230;interface ge-1/0/1.231;


Question: Looking at your configuration, are both link and node-link protection configured for your LSP?

Answer: No, only one of those options can be configured at a time. Only link-protection should be configured at this time.

Step 8.7



192.168.3.2 From: 192.168.3.1, LSPstate: Up, ActiveRoute: 1 LSPname: pe1-to-pe2-3, LSPpath: Primary LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 307552 Resv style: 1 SE, Label in: -, Label out: 307552 Time left: -, Since: Tue Dec 14 14:22:55 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 58985 protocol 0 Link protection desired Type: Protection down

Junos MPLS and VPNs


PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 172.22.230.2 (ge-1/0/0.230) 3 pkts RESV rcvfrom: 172.22.230.2 (ge-1/0/0.230) 3 pkts Explct route: 172.22.230.2 192.168.5.6 Record route: <self> 192.168.5.1 (node-id) 172.22.230.2 192.168.5.2 (node-id) 172.22.201.2 192.168.5.3 (node-id) 172.22.206.2 192.168.5.6 (node-id) 172.22.207.2 192.168.3.2 (node-id) 172.22.233.1

192.168.5.1 From: 192.168.3.1, LSPstate: Up, ActiveRoute: 0 LSPname: Bypass->172.22.230.2 LSPtype: Static Configured Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 304048 Resv style: 1 SE, Label in: -, Label out: 304048 Time left: -, Since: Tue Dec 14 14:23:16 2010 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 58987 protocol 0 Type: Bypass LSP Number of data route tunnel through: 0 Number of RSVP session tunnel through: 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 172.22.231.2 (ge-1/0/1.231) 2 pkts RESV rcvfrom: 172.22.231.2 (ge-1/0/1.231) 2 pkts Explct route: 172.22.231.2 172.22.202.1 Record route: <self> 172.22.231.2 172.22.202.1 Total 2 displayed, Up 2, Down 0

Question: Is the bypass LSP up?

Answer: Yes, the bypass LSP should be up..

Question: Does the bypass LSP provide protection for the failure of the ge-1/0/0 link?

Answer: Yes. Use the record route information for the bypass LSP to determine the path of the bypass LSP.

Step 8.8 (Optional)

Enter configuration mode and disable the interface on your PE router that is used by the primary path of the LSP. Commit your configuration and exit to operational mode. Verify that protection occurs using the methods learned in this lab.

Junos MPLS and VPNs



www.juniper.net Miscellaneous MPLS Features (Detailed) • Lab 5–110.a.10.3R1.9

Lab 5Miscellaneous MPLS Features (Detailed)

Overview

This lab demonstrates configuration and monitoring of miscellaneous Resource Reservation Protocol (RSVP) and Label Distribution Protocol (LDP) features on routers running the Junos operating system. In this lab, you use the command-line interface (CLI) to configure and monitor RSVP label-switched paths (LSPs) and enable miscellaneous features.



• Configure an RSVP LSP to install a route in inet.0.

• Configure multiprotocol label switching (MPLS) traffic engineering to install a route in inet.0.

• Use policy to control LSP selection.

• Use metrics to control LSP selection.

• Configure the network to not decrement time-to-live (TTL).

• Configure a router to signal explicit null.

• Configure a router to automatically adjust the RSVP reservation based on observed bandwidth.

• Use MPLS pings to monitor connectivity.

Junos MPLS and VPNs

Lab 5–2 • Miscellaneous MPLS Features (Detailed) www.juniper.net

Part 1: Configuring the Baseline Network

In this lab part, you will configure the baseline network for the lab. You will load the baseline configuration that was saved at the end of Lab 1 and then enable RSVP and MPLS on the core-facing interfaces. After enabling the protocols, you will configure an LSP to traverse the network to terminate at the remote provider edge (PE) router. Please refer to the lab diagram titled “Lab 5: Parts 1-3—Miscellaneous MPLS” for interface addressing and network information.

Step 1.1



[edit]lab@mxC-1# load override jmv-lab1-RouterName-baseline load complete


lab@mxC-1>

Step 1.2

Verify that your PE router has established Open Shortest Path First (OSPF) adjacencies with the neighboring routers.

lab@mxC-1> show ospf neighbor Address Interface State ID Pri Dead172.22.230.2 ge-1/0/0.230 Full 192.168.5.1 128 34172.22.231.2 ge-1/0/1.231 Full 192.168.5.4 128 35


Answer: The neighboring provider routers should be in a Full state with your PE router. If they are not, double check the interface and OSPF settings. If you need further assistance, consult with your instructor.

Step 1.3


Junos MPLS and VPNs

www.juniper.net Miscellaneous MPLS Features (Detailed) • Lab 5–3

lab@mxC-1> show bgp summary Groups: 3 Peers: 3 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...10.0.30.1 65512 16 17 0 0 6:20 Establ ce2-1.inet.0: 0/0/0/010.0.30.2 65301 16 16 0 0 6:20 Establ inet.0: 0/0/0/0192.168.3.2 65512 13 14 0 0 5:12 Establ inet.0: 0/0/0/0

Question: Is the neighbor relationship in the established state with the remote PE?

Answer: The remote PE should be in an established state with your PE router. If it is not, double check the interface and BGP settings. If you need further assistance, consult with your instructor.

Step 1.4

Enter into configuration mode and navigate to the [edit interfaces] hierarchy. Configure the core facing interfaces to allow MPLS traffic.


[edit]lab@mxC-1# edit interfaces



Step 1.5

Navigate to [edit protocols mpls] hierarchy and add the interface all statement. As good practice, disable the management interface.

[edit interfaces]lab@mxC-1# top edit protocols mpls

[edit protocols mpls]lab@mxC-1# set interface all

[edit protocols mpls]lab@mxC-1# set interface fxp0 disable

Junos MPLS and VPNs


Step 1.6

Commit the configuration changes and review the interfaces that are participating in MPLS to ensure you have the proper configuration by executing the run show mpls interface command.

[edit protocols mpls]lab@mxC-1# commit commit complete

[edit protocols mpls]lab@mxC-1# run show mpls interface Interface State Administrative groupsge-1/0/0.230 Up <none>ge-1/0/1.231 Up <none>

Question: Do you see the correct interfaces participating in MPLS?

Answer: You should see both your core facing interfaces displayed in the output. If you do not please review your configuration and ensure that you have family mpls configured on the correct interfaces. If you need further assistance, consult with your instructor.

Step 1.7

Navigate to the [edit protocols rsvp] hierarchy. Add the appropriate core-facing interfaces manually. Remember that you must specify the correct unit number when adding interfaces to any protocol configuration. Review the configuration before committing to ensure the interfaces are correct. When you are satisfied with the changes, commit and exit to operational mode.




[edit protocols rsvp]lab@mxC-1# show interface ge-1/0/0.230;interface ge-1/0/1.231;

[edit protocols rsvp]lab@mxC-1# commit and-quit commit completeExiting configuration mode

Junos MPLS and VPNs


Step 1.8

Using operational mode show commands, verify that the RSVP is configured correctly on the core-facing interfaces.

lab@mxC-1> show rsvp interface RSVP interface: 2 active Active Subscr- Static Available Reserved HighwaterInterface State resv iption BW BW BW markge-1/0/0.230Up 0 100% 1000Mbps 1000Mbps 0bps 0bps ge-1/0/1.231Up 0 100% 1000Mbps 1000Mbps 0bps 0bps

Step 1.9

Enter configuration mode and enable traffic-engineering under [edit protocols ospf] so that your router will flood its own OpaqArea link-state advertisement (LSA) and use these LSA types to build and use the traffic engineering database (TED) for Constrained Shortest Path First (CSPF) calculations.


[edit]lab@mxC-1# edit protocols ospf

[edit protocols ospf]lab@mxC-1# set traffic-engineering

Step 1.10

Add the configuration for creating a RSVP LSP to the remote PE router. Navigate to the [edit protocols mpls] hierarchy and create a LSP named pey-to-pez-x. For example, if you are assigned router mxA-1, your peer router is mxA-2. The LSP should be named pe1-to-pe2-1. Your LSP should egress at your remote peers loopback address. Verify the configuration looks correct. Commit and exit to operation mode when you are satisfied with the changes.

[edit protocols ospf]lab@mxC-1# top edit protocols mpls

[edit protocols mpls]lab@mxC-1# set label-switched-path pey-to-pez-x to 192.168.x.y

[edit protocols mpls]lab@mxC-1# show label-switched-path pe1-to-pe2-3 { to 192.168.3.2;}interface all;interface fxp0.0 { disable;}

Junos MPLS and VPNs



lab@mxC-1>

Step 1.11

Verify the status of your recently configured LSP reviewing the information displayed by issuing the show mpls lsp command.

lab@mxC-1> show mpls lsp Ingress LSP: 1 sessionsTo From State Rt P ActivePath LSPname192.168.3.2 192.168.3.1 Up 0 * pe1-to-pe2-3Total 1 displayed, Up 1, Down 0



Question: How many LSPs are reflected in the output and what are the terminating points?

Answer: If the remote team has finished configuring their LSP, you should see two LSPs. The LSP you configured should be displayed under the Ingress section and the other should be displayed under the Egress section. If the remote team has not finished their configuration you will only see the entry under the Ingress section. The terminating points of both LSP should be the loopback address of the ingress and egress routers.


Junos MPLS and VPNs


Part 2: Configuring a RSVP LSP to Install a Route in the inet.0 Table

In this lab part, you will add another interface to the OSPF network. Including the new interface in OSPF will allow you to establish reachability for the remote team. After establishing reachability, you will configure the router to install the remote team’s route as a destination that will use the established LSP for all traffic to the new network. Please refer to the lab diagram titled “Lab 5: Parts 1-3—Miscellaneous MPLS” for network information.

Step 2.1

Enter configuration mode and navigate to the [edit protocols ospf area 0.0.0.0] hierarchy and add the new interface to the existing configuration as a passive interface. We are adding the interface as passive because we are adding the interface for demonstrative purposes and will not be establishing a neighbor relationship on that interface. After you are satisfied with the changes, commit and exit to operational mode. Using show commands, verify the new interface is participating in your OSPF network.


[edit]lab@mxC-1# edit protocols ospf area 0

[edit protocols ospf area 0.0.0.0]lab@mxC-1# set interface ge-1/0/4 passive

[edit protocols ospf area 0.0.0.0]lab@mxC-1# commit and-quit commit completeExiting configuration mode

lab@mxC-1> show ospf interface Interface State Area DR ID BDR ID Nbrsge-1/0/0.230 BDR 0.0.0.0 192.168.5.1 192.168.3.1 1ge-1/0/1.231 BDR 0.0.0.0 192.168.5.4 192.168.3.1 1ge-1/0/4.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0lo0.0 DR 0.0.0.0 192.168.3.1 0.0.0.0 0

Step 2.2

Verify with your remote team that they have completed the previous task. Once they have completed these steps, you will verify that you are receiving the new network as an OSPF route.

lab@mxC-1> show route 10.0.xy.0/24


10.0.31.0/24 *[OSPF/10] 00:05:30, metric 5 to 172.22.230.2 via ge-1/0/0.230 > to 172.22.231.2 via ge-1/0/1.231

Junos MPLS and VPNs


Question: Do you have the remote network in your routing table?

Answer: Yes, you should see the remote network in your routing table as an OSPF route. If you do not see the route, verify with your remote team that they have added the interface correctly. If you are having difficulty request assistance from your instructor.

Step 2.3

Enter into configuration mode and navigate to the [edit protocols mpls label-switched-path pey-to-pez-x] hierarchy. Using the install statement, add the remote network to your inet.3 routing table. Commit your changes and verify that the route has been added to the inet.3 routing table and points to the correct LSP.


[edit]lab@mxC-1# edit protocols mpls label-switched-path pey-to-pez-x

[edit protocols mpls label-switched-path pe1-to-pe2-3]lab@mxC-1# set install 10.0.xy.0/24

[edit protocols mpls label-switched-path pe1-to-pe2-3]lab@mxC-1# commit commit complete

[edit protocols mpls label-switched-path pe1-to-pe2-3]lab@mxC-1# run show route table inet.3


10.0.31.0/24 *[RSVP/7/1] 00:00:05, metric 4 > to 172.22.231.2 via ge-1/0/1.231, label-switched-path pe1-to-pe2-3192.168.3.2/32 *[RSVP/7/1] 00:00:05, metric 4 > to 172.22.231.2 via ge-1/0/1.231, label-switched-path pe1-to-pe2-3

Question: Do you see the route in your inet.3 routing table?

Answer: You should see the route in the table and it should be pointing to the LSP you installed it for. If you do not see the route review your configuration and contact the instructor as necessary.

Junos MPLS and VPNs


Step 2.4

View the new route to determine if your router is using the OSPF route or the RSVP route for internal traffic. Remember that only BGP traffic can use the contents of the inet.3 routing table to resolve the next hop and internal traffic will resolve the next hop using the inet.0 routing table.

[edit protocols mpls label-switched-path pe1-to-pe2-3]lab@mxC-1# run show route 10.0.xy.0/24




10.0.31.0/24 *[RSVP/7/1] 00:03:21, metric 4 > to 172.22.231.2 via ge-1/0/1.231, label-switched-path pe1-to-pe2-3

Question: Is your internal traffic going to use the OSPF route or the RSVP route?

Answer: Your internal traffic is going to use the OSPF route when resolving the next hop. The RSVP route is only installed in the inet.3 routing table. Internal traffic does not have access to the inet.3 routing table for next-hop resolution.

Step 2.5

Include the RSVP route in the inet.0 routing table, so that internal traffic can also use the LSP. Include this route by adding the active option to the route you installed under the LSP. After adding this option, commit and exit to operational mode. Verify that you can now see the RSVP route in your inet.0 routing table.

[edit protocols mpls label-switched-path pe1-to-pe2-3]lab@mxC-1# set install 10.0.xy.0/24 active

[edit protocols mpls label-switched-path pe1-to-pe2-3]lab@mxC-1# commit and-quit commit completeExiting configuration mode



Junos MPLS and VPNs


10.0.31.0/24 *[RSVP/7/1] 00:00:12, metric 4 > to 172.22.230.2 via ge-1/0/0.230, label-switched-path pe1-to-pe2-3 [OSPF/10] 00:14:42, metric 5 to 172.22.230.2 via ge-1/0/0.230 > to 172.22.231.2 via ge-1/0/1.231

Question: Do you see the RSVP route in your inet.0 routing table?

Answer: Yes, you should now see that you have a RSVP route installed in your inet.0 routing table that points to your LSP. If you do not see the RSVP route, review your configuration and contact your instructor as needed.

Question: Which route will be used when resolving internal traffic?

Answer: Internal traffic will use the RSVP route to resolve next hops.

Question: Which route will be used when resolving external traffic (BGP) next hops?

Answer: External traffic will use the RSVP route.

Part 3: Configuring MPLS Traffic Engineering to Install an inet.0 Route

In this lab part, you will configure MPLS traffic engineering to move routes from inet.3 into the inet.0 routing table for both BGP and internal gateway protocol (IGP) routes. You will then use the traceroute utility to verify that the traffic is using the LSP for internal traffic. Please refer to the lab diagram titled “Lab 5: Parts 1-3—Miscellaneous MPLS” for network information.

Step 3.1

Enter into configuration mode and navigate to the [edit protocols mpls label-switched-path pey-to-pez-x] hierarchy. Remove the active option from the installed route. Review your configuration change before proceeding. When you are satisfied with the change, issue a commit and exit to operational mode. Verify that you no longer have the RSVP route in your inet.0 routing table.

Junos MPLS and VPNs



[edit]lab@mxC-1# edit protocols mpls label-switched-path pey-to-pez-x

[edit protocols mpls label-switched-path pe1-to-pe2-3]lab@mxC-1# show to 192.168.3.2;install 10.0.31.0/24 active;

[edit protocols mpls label-switched-path pe1-to-pe2-3]lab@mxC-1# delete install 10.0.xy.0/24 active

[edit protocols mpls label-switched-path pe1-to-pe2-3]lab@mxC-1# show to 192.168.3.2;install 10.0.31.0/24;

[edit protocols mpls label-switched-path pe1-to-pe2-3]lab@mxC-1# commit and-quit commit completeExiting configuration mode






Question: Which protocol is being used in the inet.0 routing table?

Answer: The OSPF route should be the only route in the inet.0 routing table. If you still see the RSVP route, review your LSP configuration. If you are still having problems, contact your instructor for assistance.

Junos MPLS and VPNs


Step 3.2

Enter into configuration mode and navigate to the [edit protocols mpls] hierarchy and enable traffic engineering to move routes from inet.3 into the inet.0 routing table for both BGP and IGP routes. Commit your configuration changes and exit out of configuration mode. Verify that your inet.0 route table contains the RSVP route to the remote network specified to use the LSP.



[edit protocols mpls]lab@mxC-1# set traffic-engineering ?Possible completions: bgp BGP destinations only bgp-igp BGP and IGP destinations bgp-igp-both-ribs BGP and IGP destinations with routes in both routing tables mpls-forwarding Use MPLS routes for forwarding, not routing[edit protocols mpls]lab@mxC-1# set traffic-engineering bgp-igp


lab@mxC-1> show route 10.0.xy.2


10.0.31.0/24 *[RSVP/7/1] 00:00:22, metric 4 > to 172.22.231.2 via ge-1/0/1.231, label-switched-path pe1-to-pe2-3 [OSPF/10] 00:00:22, metric 5 > to 172.22.230.2 via ge-1/0/0.230 to 172.22.231.2 via ge-1/0/1.231

Step 3.3

Using the traceroute utility verify that internal traffic will use the LSP when sending traffic to the remote network.

Junos MPLS and VPNs


lab@mxC-1> traceroute 10.0.xy.1 traceroute to 10.0.31.1 (10.0.31.1), 30 hops max, 40 byte packets 1 172.22.231.2 (172.22.231.2) 0.591 ms 0.455 ms 0.434 ms MPLS Label=303600 CoS=0 TTL=1 S=1 2 172.22.203.2 (172.22.203.2) 0.479 ms 0.468 ms 0.469 ms MPLS Label=303536 CoS=0 TTL=1 S=1 3 172.22.204.2 (172.22.204.2) 0.494 ms 0.486 ms 0.478 ms MPLS Label=304080 CoS=0 TTL=1 S=1 4 10.0.31.1 (10.0.31.1) 0.481 ms 0.435 ms 0.420 ms

Question: Does your traceroute complete?

Answer: Yes, your should see the traceroute responses from all routers along the path.

Question: Do you see MPLS label values associated with the traceroute responses?

Answer: Yes, you should see MPLS label values. If you do not, please review your configuration and request assistance from your instructor as needed.

Part 4: Using Policy to Control LSP Selection

In this lab part, you will use policy to control which LSP certain traffic traverses. You will begin by removing the extra interface from OSPF that was added in Part 2. You will create two new LSPs that take different paths through the core network. You will then create two static routes and export these routes to your BGP peer. Finally, you will create and apply a policy to send traffic destined to the two routes—received from your neighbor—down separate LSPs. Please refer to the lab diagram titled “Lab 5: Parts 4-9—Miscellaneous MPLS” for the remainder of this lab.

Step 4.1

Enter into configuration mode and begin by removing the interface that we added in Part 2. You must also remove this interface from your OSPF configuration.


[edit]lab@mxC-1# delete protocols ospf area 0 interface ge-1/0/4

Junos MPLS and VPNs


Step 4.2

Navigate to the [edit protocols mpls] hierarchy and remove the existing label switched path. You also must remove the traffic engineering configuration. Create two paths named one and two. Specify the different loose hops you want each LSP path to signal along. The configuration example with signal path one across the top of the network using the P1, P2, and P3 routers. Path two will signal across the bottom using P4, P5, and P6 routers.



[edit protocols mpls]lab@mxC-1# delete traffic-engineering

[edit protocols mpls]lab@mxC-1# set path one 192.168.5.y loose



[edit protocols mpls]lab@mxC-1# set path two 192.168.5.y loose



[edit protocols mpls]lab@mxC-1# show path one { 192.168.5.1 loose; 192.168.5.2 loose; 192.168.5.3 loose;}path two { 192.168.5.4 loose; 192.168.5.5 loose; 192.168.5.6 loose;}interface all;interface fxp0.0 { disable;

Junos MPLS and VPNs


Step 4.3

Create two label switched paths named lsp-1 and lsp-2. Apply path one to lsp-1 as the primary path and apply path two to lsp-2 as the primary path. Both LSPs should terminate at the remote PE router’s loopback. Before committing your configuration changes, review the changes. After you are satisfied with the changes commit and exit to operational mode.

[edit protocols mpls]lab@mxC-1# set label-switched-path lsp-1 to 192.168.x.y primary one

[edit protocols mpls]lab@mxC-1# set label-switched-path lsp-2 to 192.168.x.y primary two

[edit protocols mpls]lab@mxC-1# show label-switched-path lsp-1 { to 192.168.3.2; primary one;}label-switched-path lsp-2 { to 192.168.3.2; primary two;}path one { 192.168.5.1 loose; 192.168.5.2 loose; 192.168.5.3 loose;}path two { 192.168.5.4 loose; 192.168.5.5 loose; 192.168.5.6 loose;}interface all;interface fxp0.0 { disable;}


Step 4.4

Using show commands, verify that your LSPs are established and traversing the core network as expected based on your explicit paths.

lab@mxC-1> show mpls lsp Ingress LSP: 2 sessionsTo From State Rt P ActivePath LSPname192.168.3.2 192.168.3.1 Up 0 * one lsp-1192.168.3.2 192.168.3.1 Up 0 * two lsp-2Total 2 displayed, Up 2, Down 0

Egress LSP: 2 sessions

Junos MPLS and VPNs


To From State Rt Style Labelin Labelout LSPname 192.168.3.1 192.168.3.2 Up 0 1 FF 3 - lsp-1192.168.3.1 192.168.3.2 Up 0 1 FF 3 - lsp-2Total 2 displayed, Up 2, Down 0


lab@mxC-1> show mpls lsp extensive ingress Ingress LSP: 2 sessions

192.168.3.2 From: 192.168.3.1, State: Up, ActiveRoute: 0, LSPname: lsp-1 ActivePath: one (primary) LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary one State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 4) 172.22.230.2 S 172.22.201.2 S 172.22.206.2 S 172.22.232.1 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 5 Dec 13 14:17:38.884 Selected as active path 4 Dec 13 14:17:38.882 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 3 Dec 13 14:17:38.882 Up 2 Dec 13 14:17:38.868 Originate Call 1 Dec 13 14:17:38.868 CSPF: computation result accepted 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 Created: Mon Dec 13 14:17:38 2010

192.168.3.2 From: 192.168.3.1, State: Up, ActiveRoute: 0, LSPname: lsp-2 ActivePath: two (primary) LSPtype: Static Configured LoadBalance: Random Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary two State: Up Priorities: 7 0 SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 4) 172.22.231.2 S 172.22.203.2 S 172.22.204.2 S 172.22.233.1 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 5 Dec 13 14:17:38.985 Selected as active path 4 Dec 13 14:17:38.983 Record Route: 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1 3 Dec 13 14:17:38.983 Up 2 Dec 13 14:17:38.869 Originate Call 1 Dec 13 14:17:38.869 CSPF: computation result accepted 172.22.231.2 172.22.203.2 172.22.204.2 172.22.233.1

Junos MPLS and VPNs


Created: Mon Dec 13 14:17:38 2010Total 2 displayed, Up 2, Down 0

Question: Are your LSPs in an Up state?

Answer: Yes, your LSPs should be up and functional at this point. If they are not up, review your configuration. If you need assistance, please contact your instructor.

Question: Do your LSPs traverse the core network as expected?

Answer: Yes, your LSPs should follow the path you defined. If they do not follow the expected path, review your configuration. If you need additional assistance, contact your instructor.

Step 4.5

Enter into configuration mode, navigate to the [edit routing-options] hierarchy, and define the static routes outlined on the network diagram for the device you are configuring. After creating these routes, you will create a policy named export-static that will export these routes to your internal BGP (IBGP) peer. After creating the policy, you must apply it as an export policy to your IBGP group. Commit your configuration changes and exit to operational mode. Verify that your router is now sending these routes to your neighbor and that you are receiving the remote static prefixes from the remote peer.


[edit]lab@mxC-1# edit routing-options

[edit routing-options]lab@mxC-1# set static route 10.x.y.0/24 receive

[edit routing-options]lab@mxC-1# set static route 10.x.y.0/24 receive

[edit routing-options]lab@mxC-1# top edit policy-options policy-statement export-static

[edit policy-options policy-statement export-static]lab@mxC-1# set from protocol static

Junos MPLS and VPNs


[edit policy-options policy-statement export-static]lab@mxC-1# set then accept

[edit policy-options policy-statement export-static]lab@mxC-1# show from protocol static;then accept;

[edit policy-options policy-statement export-static]lab@mxC-1# top edit protocols bgp group my-int-group

[edit protocols bgp group my-int-group]lab@mxC-1# set export export-static

[edit protocols bgp group my-int-group]lab@mxC-1# commit and-quit commit completeExiting configuration mode

lab@mxC-1> show route advertising-protocol bgp 192.168.x.y

inet.0: 48 destinations, 48 routes (48 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 10.3.1.0/24 Self 100 I* 10.3.2.0/24 Self 100 I

lab@mxC-1> show route receive-protocol bgp 192.168.x.y

inet.0: 48 destinations, 48 routes (48 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 10.3.3.0/24 192.168.3.2 100 I* 10.3.4.0/24 192.168.3.2 100 I




lab@mxC-1> show route protocol bgp


10.3.3.0/24 *[BGP/170] 00:02:14, localpref 100, from 192.168.3.2 AS path: I to 172.22.230.2 via ge-1/0/0.230, label-switched-path lsp-1 > to 172.22.231.2 via ge-1/0/1.231, label-switched-path lsp-210.3.4.0/24 *[BGP/170] 00:02:14, localpref 100, from 192.168.3.2 AS path: I to 172.22.230.2 via ge-1/0/0.230, label-switched-path lsp-1 > to 172.22.231.2 via ge-1/0/1.231, label-switched-path lsp-2...

Junos MPLS and VPNs


Question: What LSPs do the routes you received from your neighbor point to as next hops?

Answer: Both routes should display both LSPs a possible next hops. While only one is selected as the active next hop, both LSPs are available.

Step 4.6

Enter into configuration mode and create a policy named lsp-policy. Create a term named lsp-1. Under this term you will match the first BGP prefix received from your peer and change the next-hop to your LSP named lsp-1. You will accept this route. Then, you will create a second term named lsp-2, which will match on the second BGP route and change the next-hop to lsp-2. This route also needs to have the accept action.


[edit]lab@mxC-1# edit policy-options policy-statement lsp-policy

[edit policy-options policy-statement lsp-policy]lab@mxC-1# set term lsp-1 from protocol bgp

[edit policy-options policy-statement lsp-policy]lab@mxC-1# set term lsp-1 from route-filter 10.x.y.0/24 exact

[edit policy-options policy-statement lsp-policy]lab@mxC-1# set term lsp-1 then install-nexthop lsp lsp-1

[edit policy-options policy-statement lsp-policy]lab@mxC-1# set term lsp-1 then accept

[edit policy-options policy-statement lsp-policy]lab@mxC-1# set term lsp-2 from protocol bgp

[edit policy-options policy-statement lsp-policy]lab@mxC-1# set term lsp-2 from route-filter 10.x.y.0/24 exact

[edit policy-options policy-statement lsp-policy]lab@mxC-1# set term lsp-2 then install-nexthop lsp lsp-2

[edit policy-options policy-statement lsp-policy]lab@mxC-1# set term lsp-2 then accept

[edit policy-options policy-statement lsp-policy]lab@mxC-1# show term lsp-1 { from { protocol bgp; route-filter 10.3.3.0/24 exact;

Junos MPLS and VPNs


} then { install-nexthop lsp lsp-1; accept; }}term lsp-2 { from { protocol bgp; route-filter 10.3.4.0/24 exact; } then { install-nexthop lsp lsp-2; accept; }}

Step 4.7

Navigate to the [edit routing-options] hierarchy and apply the policy lsp-policy as an export policy to the forwarding table. After applying the policy, commit your changes and exit to operational mode. Verify that the next hop for each of the remote BGP routes point to the correct LSP as defined in your policy.

[edit policy-options policy-statement lsp-policy]lab@mxC-1# top edit routing-options

[edit routing-options]lab@mxC-1# set forwarding-table export lsp-policy

[edit routing-options]lab@mxC-1# commit and-quit commit completeExiting configuration mode




10.3.3.0/24 *[BGP/170] 00:08:37, localpref 100, from 192.168.3.2 AS path: I > to 172.22.230.2 via ge-1/0/0.230, label-switched-path lsp-110.3.4.0/24 *[BGP/170] 00:08:37, localpref 100, from 192.168.3.2 AS path: I to 172.22.231.2 via ge-1/0/1.231, label-switched-path lsp-2...

Junos MPLS and VPNs


Question: Do you see the correct LSP selected as the next hop for each of your BGP routes?

Answer: Yes, you should see that the first route displayed has a next-hop of lsp-1 and the second route has a next-hop of lsp-2. If you do not see this, review your configuration and request assistance from your instructor as needed.


Part 5: Using LSP Metric to Control LSP Selection

In this lab part, you will configure the router to use metrics to control LSP selection. You will begin by removing the policy you created in the Part 4. You must also remove the export policy applied to the forwarding table. You will look at the current state of the BGP routes and determined the metric value calculated from the IGP for each of the RSVP routes. You will then manually set the metric on one of the LSPs to be higher than the IGP calculated value. You will then verify the changes and review the changes to the routing table.

Step 5.1

Enter into configuration mode and remove the policy you created in Part 4. You must also remove the export policy applied to the forwarding table because it is no longer defined. Commit your changes when you are ready to proceed.


[edit]lab@mxC-1# delete policy-options policy-statement lsp-policy

[edit]lab@mxC-1# delete routing-options forwarding-table export

[edit]lab@mxC-1# commit commit complete

Step 5.2

Review the current status of your BGP routes received from your peer. Review the RSVP routes to determine what metric is being calculated from the IGP. This status review provides the current values so that when you manually assign a metric, you can verify that the changes have been applied correctly.

Junos MPLS and VPNs


[edit]lab@mxC-1# run show route protocol bgp


10.3.3.0/24 *[BGP/170] 00:13:00, localpref 100, from 192.168.3.2 AS path: I to 172.22.230.2 via ge-1/0/0.230, label-switched-path lsp-1 > to 172.22.231.2 via ge-1/0/1.231, label-switched-path lsp-210.3.4.0/24 *[BGP/170] 00:13:00, localpref 100, from 192.168.3.2 AS path: I to 172.22.230.2 via ge-1/0/0.230, label-switched-path lsp-1 > to 172.22.231.2 via ge-1/0/1.231, label-switched-path lsp-2...

[edit]lab@mxC-1# run show route table inet.3


192.168.3.2/32 *[RSVP/7/1] 03:57:27, metric 4 > to 172.22.230.2 via ge-1/0/0.230, label-switched-path lsp-1 to 172.22.231.2 via ge-1/0/1.231, label-switched-path lsp-2

Question: Why do you see both LSPs as available next hops?

Answer: You see both LSP as next hops because they have been calculated as equal cost paths. They both have a metric of 4.

Question: What is the metric of both RSVP LSPs that was calculated from the IGP?

Answer: The metric for both RSVP LSPs should be 4.

Step 5.3

Navigate to the [edit protocols mpls] hierarchy and set the metric to 8 for lsp-2. After changing the metric, commit your configuration and exit to operational mode. Review the BGP routes for changes and verify the metric change is reflected by the RSVP routes.

Junos MPLS and VPNs



[edit protocols mpls]lab@mxC-1# set label-switched-path lsp-2 metric 8




10.3.3.0/24 *[BGP/170] 00:16:48, localpref 100, from 192.168.3.2 AS path: I > to 172.22.230.2 via ge-1/0/0.230, label-switched-path lsp-110.3.4.0/24 *[BGP/170] 00:16:48, localpref 100, from 192.168.3.2 AS path: I > to 172.22.230.2 via ge-1/0/0.230, label-switched-path lsp-1...

lab@mxC-1> show route table inet.3

192.168.3.2/32 *[RSVP/7/1] 04:00:56, metric 4 > to 172.22.230.2 via ge-1/0/0.230, label-switched-path lsp-1 [RSVP/7/1] 00:00:26, metric 8 > to 172.22.231.2 via ge-1/0/1.231, label-switched-path lsp-2

Question: What changes do you see in the routing tables?

Answer: The two next hops for the BGP routes are no longer available because they are no longer equal cost paths.

Question: What is the metric of both RSVP LSP routes after the change?

Answer: The metric for RSVP lsp-1 should be 4 and the metric for RSVP lsp-2 should be 8.

Junos MPLS and VPNs


Part 6: Configuring Your Router to Not Decrement the TTL

In this lab part, you will configure the router to not decrement the TTL. First, you will look at the default TTL handling behavior. You will configure the router so that the TTL is not decremented as packets traverse the MPLS network.

Step 6.1

Enter into configuration mode and navigate to the [edit protocols mpls] hierarchy. Enable traffic-engineering bgp-igp. This will allow you to traceroute to the remote teams loopback address. We will be using traceroute to demonstrate the behavior with TTL handling. Commit the change and exit to operational mode before proceeding. By using traffic engineering, it allows internal traffic to use the RSVP routes to get to the remote team’s loopback address.



[edit protocols mpls]lab@mxC-1# set traffic-engineering bgp-igp

[edit protocols mpls]lab@mxC-1# commit and quitcommit completeExiting configuration mode

lab@mxC-1>

Step 6.2

Verify the default behavior by using the traceroute utility. You can now traceroute to the remote team’s loopback address.

lab@mxC-1> traceroute 192.168.x.y traceroute to 192.168.3.2 (192.168.3.2), 30 hops max, 40 byte packets 1 172.22.230.2 (172.22.230.2) 0.605 ms 11.032 ms 0.442 ms MPLS Label=307136 CoS=0 TTL=1 S=1 2 172.22.201.2 (172.22.201.2) 0.466 ms 0.479 ms 0.468 ms MPLS Label=307232 CoS=0 TTL=1 S=1 3 172.22.206.2 (172.22.206.2) 0.497 ms 0.491 ms 0.485 ms MPLS Label=306384 CoS=0 TTL=1 S=1 4 192.168.3.2 (192.168.3.2) 0.484 ms 0.428 ms 0.418 ms

Question: How many devices respond to the traceroute request?

Answer: You should see four responses. One for each device, including the destination PE device.

Junos MPLS and VPNs


Step 6.3

Enter into configuration mode and navigate to the [edit protocols mpls] hierarchy. Configure the router so that the TTL is not decremented by using the no-decrement-ttl statement under the MPLS protocol. Commit the configuration and exit to operational mode before proceeding to the next step.



[edit protocols mpls]lab@mxC-1# set no-decrement-ttl

[edit protocols mpls]lab@mxC-1# commit and-quitcommit completeExiting configuration mode

lab@mxC-1>

Step 6.4

Use the traceroute utility again to view the change in behavior.

lab@mxC-1> traceroute 192.168.x.y traceroute to 192.168.3.2 (192.168.3.2), 30 hops max, 40 byte packets 1 192.168.3.2 (192.168.3.2) 0.631 ms 0.441 ms 0.424 ms

Question: How many responses do you see now?

Answer: You should only see one response. This is the response from the egress device. This makes the MPLS network transparent.

Part 7: Configuring Your Router to Signal Explicit Null

In this lab part, you will configure your router to signal explicit null. Using explicit null notifies the penultimate label-switching router (LSR) that the egress router will remove the MPLS label. You will compare the Labelin value before and after configuring the router to signal explicit null.

Step 7.1

View the Labelin value before you configure the router to signal explicit null. You should expect to see a value of 3 for both LSPs.

Junos MPLS and VPNs


lab@mxC-1> show mpls lsp egress Egress LSP: 2 sessionsTo From State Rt Style Labelin Labelout LSPname 192.168.3.1 192.168.3.2 Up 0 1 FF 3 - lsp-1192.168.3.1 192.168.3.2 Up 0 1 FF 3 - lsp-2Total 2 displayed, Up 2, Down 0

Step 7.2

Enter into configuration mode and navigate to the [edit protocols mpls] hierarchy. Configure your router to signal explicit null by using the explicit-null command. This command tells the router to signal the upstream LSR (penultimate router) that it expects to receive a MPLS label. In operation, instead of signaling a value of 3 upstream (default behavior), the egress router will signal a value of 0 upstream. Commit the changes and exit to operational mode before proceeding to the next step.



[edit protocols mpls]lab@mxC-1# set explicit-null

[edit protocols mpls]lab@mxC-1# commit and-quitcommit completeExiting configuration mode

Step 7.3

View the Labelin value now that you have configured the router to signal explicit null. You should expect to see a value of 0 for both LSPs.

lab@mxC-1> show mpls lsp egress Egress LSP: 2 sessionsTo From State Rt Style Labelin Labelout LSPname 192.168.3.1 192.168.3.2 Up 0 1 FF 0 - lsp-1192.168.3.1 192.168.3.2 Up 0 1 FF 0 - lsp-2Total 2 displayed, Up 2, Down 0

Question: Is the value of the Labelin field what you expect to see?

Answer: Yes, the Labelin value should be 0. If it is not please review your configuration and request assistance from your instructor as needed.

Junos MPLS and VPNs


Part 8: Configuring Your Router to Automatically Adjust the RSVP Reservation Based on Observed Bandwidth

In this lab part, you will configure your router to monitor and automatically adjust the RSVP reservation based on the observed bandwidth. The first step to setting up automatic bandwidth provisioning is to enable statistics monitoring for the MPLS protocol. This allows MPLS to track and monitor bandwidth utilization over a specified time period (default 24 hours.). Next, you will enable the automatic bandwidth provisioning on one of your established LSPs.

Step 8.1

Enter into configuration mode and navigate to the [edit protocols mpls statistics] hierarchy. Enable MPLS statistics monitoring by creating a file named auto-stats and configuring the auto-bandwidth statement.


[edit]lab@mxC-1# edit protocols mpls statistics

[edit protocols mpls statistics]lab@mxC-1# set file auto-stats

[edit protocols mpls statistics]lab@mxC-1# set auto-bandwidth

Step 8.2

Navigate to the [edit protocols mpls] and enable auto-bandwidth under the existing LSP lsp-1. Commit your changes and exit to operational mode before proceeding to the next step.

[edit protocols mpls statistics]lab@mxC-1# up

[edit protocols mpls]lab@mxC-1# set label-switched-path lsp-1 auto-bandwidth


lab@mxC-1>

Step 8.3

Verify that your configuration changes have taken affect on the LSP by executing the show mpls lsp ingress name lsp-1 extensive command.

lab@mxC-1> show mpls lsp ingress name lsp-1 extensive Ingress LSP: 2 sessions

192.168.3.2 From: 192.168.3.1, State: Up, ActiveRoute: 3, LSPname: lsp-1

Junos MPLS and VPNs


ActivePath: one (primary) LSPtype: Static Configured LoadBalance: Random Autobandwidth AdjustTimer: 86400 secs Max AvgBW util: 0bps, Bandwidth Adjustment in 86391 second(s). Overflow limit: 0, Overflow sample count: 0 Encoding type: Packet, Switching type: Packet, GPID: IPv4 *Primary one State: Up, No-decrement-ttl Priorities: 7 0 SmartOptimizeTimer: 180 Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 4) 172.22.230.2 S 172.22.201.2 S 172.22.206.2 S 172.22.232.1 S Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID): 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 5 Dec 13 18:25:22.791 Selected as active path 4 Dec 13 18:25:22.791 Record Route: 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 3 Dec 13 18:25:22.790 Up 2 Dec 13 18:25:22.776 Originate Call 1 Dec 13 18:25:22.776 CSPF: computation result accepted 172.22.230.2 172.22.201.2 172.22.206.2 172.22.232.1 Created: Mon Dec 13 18:25:23 2010Total 1 displayed, Up 1, Down 0

Question: When will the next LSP adjustment happen?

Answer: Answers will vary depending on the duration between enabling the auto-bandwidth feature and executing the show command. In our example above the next adjustment will happen in 86391 seconds.

Part 9: Using MPLS Ping to Verify LSP Connectivity

In this lab part, you will use MPLS Pings to verify LSP connectivity to the egress node.

Step 9.1

Verify the connectivity of lsp-1 by executing the command ping mpls rsvp lsp-1.

lab@mxC-1> ping mpls rsvp lsp-1 !!!!!--- lsping statistics ---5 packets transmitted, 5 packets received, 0% packet loss

Junos MPLS and VPNs


Question: Do the pings complete?

Answer: Yes, your pings should complete at this point. If they do not check with the remote team and ensure they have the 127.0.0.1/32 address assigned to their loopback. If you need assistance, consult with your instructor.


Junos MPLS and VPNs


www.juniper.net VPN Baseline Configuration (Detailed) • Lab 6–110.a.10.3R1.9

Lab 6VPN Baseline Configuration (Detailed)

Overview

In this lab, you will configure the request for comments (RFC) 4364 infrastructure that will be used to support Layer 3 virtual private networks (VPNs) in subsequent labs.



• Familiarize yourself with this lab and reset the configuration.

• Configure interface addresses and families on your provider edge (PE) and customer edge (CE) routers.

• Enable traffic engineering.

• Configure internal Multiprotocol Border Gateway Protocol (MP-IBGP) peering between communicating PE routers.

• Configure a route distinguisher ID.

• Configure CE routing options.

• Verify proper infrastructure operation.

• Save your baseline configuration for use in future labs.

Junos MPLS and VPNs

Lab 6–2 • VPN Baseline Configuration (Detailed) www.juniper.net

Part 1: Creating the Baseline SP Network and Enabling PE for Layer 3 VPN Signaling

In this lab part, you will configure the baseline network for the lab. You will load the baseline configuration saved at the end of Lab 1 and then enable Resource Reservation Protocol (RSVP) and multiprotocol label switching (MPLS) on the core-facing interfaces, configure MP-BGP, and configure a route-distinguisher ID. Finally, you will configure a virtual router to represent the CE router attached to your PE router. Please refer to the lab diagram titled “Lab 6: Part 1—VPN Baseline (PE)”.

Step 1.1

Enter configuration mode and load the baseline configuration for your PE router. The file is saved in the /var/home/lab directory and is named jmv-lab1-RouterName-baseline.


[edit]lab@mxB-1# load override jmv-lab1-RouterName-baseline load complete

Step 1.2

For an interface to support the forwarding of MPLS packets, you must enable the MPLS family on each interface. Navigate to the [edit interfaces] hierarchy and enable family mpls on both of the core-facing interfaces.




Step 1.3

Navigate to the [edit protocols] hierarchy and configure the MPLS protocol on the core-facing interfaces.

[edit interfaces]lab@mxB-1# top edit protocols



Step 1.4

Configure the RSVP protocol on the core-facing interfaces.

Junos MPLS and VPNs

www.juniper.net VPN Baseline Configuration (Detailed) • Lab 6–3



Step 1.5

Enable traffic-engineering under [edit protocols ospf] so that your router will flood its own OpaqArea link state advertisement (LSA) and use these LSA types to build and use the traffic engineering database (TED) for constrained shortest path first (CSPF) calculations.

[edit protocols]lab@mxB-1# set ospf traffic-engineering

Step 1.6

To allow the exchange of Layer 3 VPN routes, enable the inet-vpn unicast network layer reachability information (NLRI) for your PE router’s BGP session with the remote PE router. Make sure to also enable the exchange of standard unicast IP version 4 (IPv4) routes as well.

[edit protocols]lab@mxB-1# set bgp group my-int-group family inet unicast

[edit protocols]lab@mxB-1# set bgp group my-int-group family inet-vpn unicast

Step 1.7

To allow for the automatic generation of route distinguishers, navigate to the [edit routing-options] hierarchy and specify the route-distinguisher-id using your PE router’s loopback address. Commit your configuration and exit out to operational mode.

[edit protocols]lab@mxB-1# top edit routing-options

[edit routing-options]lab@mxB-1# set route-distinguisher-id 192.168.x.y

[edit routing-options]lab@mxB-1# commit and-quit commit completeExiting configuration mode

Step 1.8


lab@mxB-1> show mpls interface Interface State Administrative groupsge-1/0/0.220 Up <none>ge-1/0/1.221 Up <none>

lab@mxB-1> show rsvp interface RSVP interface: 2 active

Junos MPLS and VPNs


Active Subscr- Static Available Reserved HighwaterInterface State resv iption BW BW BW markge-1/0/0.220Up 0 100% 1000Mbps 1000Mbps 0bps 0bps

ge-1/0/1.221Up 0 100% 1000Mbps 1000Mbps 0bps 0bps

Step 1.9

Verify that your PE router has established Open Shortest Path First (OSPF) adjacencies with the neighboring provider (P) routers.



Answer: The neighboring P routers should be in a Full state with your PE router. If they are not, double check the interface and OSPF settings. If you need further assistance, consult with your instructor.

Step 1.10

Verify that your PE router has established a BGP neighbor relationship with the remote PE router.

lab@mxB-1> show bgp neighbor 192.168.x.yPeer: 192.168.2.2+50688 AS 65512 Local: 192.168.2.1+179 AS 65512 Type: Internal State: Established Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ statics ] Options: <Preference LocalAddress AddressFamily Rib-group Refresh> Address families configured: inet-unicast inet-vpn-unicast Local Address: 192.168.2.1 Holdtime: 90 Preference: 170 Number of flaps: 1 Last flap event: RecvNotify Error: 'Cease' Sent: 0 Recv: 1 Peer ID: 192.168.2.2 Local ID: 192.168.2.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down NLRI for restart configured on peer: inet-unicast inet-vpn-unicast NLRI advertised by peer: inet-unicast inet-vpn-unicast NLRI for this session: inet-unicast inet-vpn-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast inet-vpn-unicast

Junos MPLS and VPNs


NLRI that restart is negotiated for: inet-unicast inet-vpn-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 65512) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 1 Received prefixes: 1 Accepted prefixes: 1 Suppressed due to damping: 0 Advertised prefixes: 1 Table bgp.l3vpn.0 RIB State: BGP restart is complete RIB State: VPN restart is complete Send state: not advertising Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Last traffic (seconds): Received 27 Sent 27 Checked 27 Input messages: Total 4 Updates 2 Refreshes 0 Octets 157 Output messages: Total 4 Updates 1 Refreshes 0 Octets 176 Output Queue[0]: 0 Output Queue[1]: 0

lab@mxB-1> show bgp summary Groups: 3 Peers: 3 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...10.0.20.1 65512 9421 9422 0 0 2d 23:07:23 Establ ce2-1.inet.0: 0/0/0/010.0.20.2 65201 9421 9421 0 0 2d 23:07:23 Establ inet.0: 0/0/0/0192.168.2.2 65512 9488 9496 0 1 2d 23:38:57 Establ inet.0: 0/0/0/0

Question: Is the neighbor relationship in the established state with the remote PE?


Junos MPLS and VPNs


Question: What NLRI type has been negotiated between your PE router and the remote PE router?

Answer: Using the show bgp neighbor command, you should see that the NLRI for this session should be inet-unicast and inet-vpn-unicast.

Part 2: Configuring the CE Router Properties

In this lab part, you will create a virtual router type routing instance on your device. This virtual router will act as the CE router for the bulk of the rest of the Layer 3 VPN labs.

Step 2.1

Familiarize yourself with the lab diagram titled “Lab 6: Part 2—VPN Baseline (CE)”. Each group of students will delete the CE router from previous labs and create a new CE router.

Step 2.2

Enter configuration mode, navigate to the [edit routing-instances] hierarchy, and delete the configuration for the CE virtual router.


[edit]lab@mxB-1# edit routing-instances

[edit routing-instances]lab@mxB-1# delete cex-y

Step 2.3

Navigate to the [edit interfaces] hierarchy. Delete the configuration for ge-1/0/4 and ge-1/1/4.

[edit routing-instances]lab@mxB-1# top edit interfaces

[edit interfaces]lab@mxB-1# delete ge-1/0/4


Junos MPLS and VPNs


Step 2.4

Configure your new CE router’s ge-1/1/4 interface, which will be used to connect to your local PE router in future labs. Use the lab diagram to determine the correct addressing.

[edit interfaces]lab@mxB-1# set ge-1/1/4 vlan-tagging unit 6x0 vlan-id 6x0

[edit interfaces]lab@mxB-1# set ge-1/1/4 vlan-tagging unit 6x0 family inet address 10.0.xy.2/24

Step 2.5

Navigate to the [edit routing-instances] hierarchy. Configure your CE router’s routing instance specifying a routing instance type of virtual-router and apply the lo0.1 and ge-1/1/4 interfaces to the instance.

[edit interfaces]lab@mxB-1# top edit routing-instances

[edit routing-instances]lab@mxB-1# set cex-y instance-type virtual-router

[edit routing-instances]lab@mxB-1# set cex-y interface ge-1/1/4.6x0

[edit routing-instances]lab@mxB-1# set cex-y interface lo0.1

Step 2.6

Configure your CE router’s autonomous system (AS) number.

[edit routing-instances]lab@mxB-1# set cex-y routing-options autonomous-system 65x01

Step 2.7

Configure your CE router’s static routes as listed on the lab diagram. Use a next hop of reject for each of the four static routes.

[edit routing-instances]lab@mxB-1# set cex-y routing-options static route 172.x0.y/24 reject




Junos MPLS and VPNs


Step 2.8

Navigate to the [edit policy-options] hierarchy. Create a routing policy that will allow for the redistribution of your direct and static routes. This policy will eventually be used to advertise routes from the CE router to the PE router. Commit your configuration and exit to operational mode.

[edit routing-instances]lab@mxB-1# top edit policy-options

[edit policy-options]lab@mxB-1# set policy-statement exp-policy term 10 from protocol static

[edit policy-options]lab@mxB-1# set policy-statement exp-policy term 10 then accept

[edit policy-options]lab@mxB-1# set policy-statement exp-policy term 20 from protocol direct

[edit policy-options]lab@mxB-1# set policy-statement exp-policy term 20 then accept

[edit policy-options]lab@mxB-1# commit and-quit commit completeExiting configuration mode

Step 2.9

View the CE router’s routing table and ensure that the correct direct and static routes are now installed in the table.

lab@mxB-1> show route table cex-y


10.0.20.0/24 *[Direct/0] 00:38:46 > via ge-1/1/4.62010.0.20.2/32 *[Local/0] 00:38:46 Local via ge-1/1/4.620172.20.0.0/24 *[Static/5] 00:00:09 Reject172.20.1.0/24 *[Static/5] 00:00:09 Reject172.20.2.0/24 *[Static/5] 00:00:09 Reject172.20.3.0/24 *[Static/5] 00:00:09 Reject192.168.12.1/32 *[Direct/0] 00:38:46 > via lo0.1

Junos MPLS and VPNs


Question: What routes appear in your CE router’s routing table?

Answer: The networks associated with ge-1/1/4 and lo0 should appear in the CE router’s routing table. Also, the four static routes should also appear. If these routes do not exist, go back and verify your configuration.

Step 2.10

Save the configuration for future labs in this course. Save your configuration as jmv-RouterName-vpn-baseline.

lab@mxB-1> show configuration | save jmv-RouterName-vpn-baseline Wrote 157 lines of output to 'jmv-mxB-1-vpn-baseline'


Junos MPLS and VPNs


www.juniper.net Layer 3 VPN with Static and BGP Routing (Detailed) • Lab 7–110.a.10.3R1.9

Lab 7Layer 3 VPN with Static and BGP Routing (Detailed)

Overview

In this lab, you will establish a point-to-point Layer 3 VPN using RSVP signaling between provider edge (PE) routers. You will also configure both static and BGP routing between your PE and customer edge (CE) routers. You will share your routes with the remote PE router through the Layer 3 VPN using Multiprotocol Border Gateway Protocol (MP-BGP).



• Load the VPN baseline configuration for your router. This configuration includes your baseline core configuration including OSPF and BGP. The baseline also contains a virtual router configuration that will act as your CE router for this lab.

• Configure an RSVP-signaled label-switched path (LSP) to the remote PE router.

• Create and establish a Layer 3 VPN over the core network.

• Configure static routing between your PE and CE router and share your static PE routes through the Layer 3 VPN using MP-BGP.

• Configure BGP routing between your PE and CE routers and share CE routes through the Layer 3 VPN using MP-BGP.

• Verify connectivity and behavior using command-line interface (CLI) operational mode commands including ping and commands used to examine routing tables and PE-PE BGP announcements.

Junos MPLS and VPNs

Lab 7–2 • Layer 3 VPN with Static and BGP Routing (Detailed) www.juniper.net

Part 1: Loading and Verifying the VPN Baseline Configuration

In this lab part, you will load the VPN baseline configuration you saved in Lab 6. After loading the configuration you will verify the core network is operating as expected. You will review the CE instance configuration so you are familiar with the contents.

Step 1.1

Enter into configuration mode and load the VPN baseline configuration by executing the command: load override jmv-RouterName-vpn-baseline. Commit your configuration changes and exit to operational mode.


[edit]lab@mxA-1# load override jmv-RouterName-vpn-baseline load complete


lab@mxA-1>

Step 1.2

Verify your OSPF and BGP neighborships are established correctly.


lab@mxA-1> show bgp summary Groups: 1 Peers: 1 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0bgp.l3vpn.0 0 0 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...192.168.1.2 65512 410 411 0 1 3:03:52 Establ inet.0: 0/0/0/0 bgp.l3vpn.0: 0/0/0/0

Junos MPLS and VPNs

www.juniper.net Layer 3 VPN with Static and BGP Routing (Detailed) • Lab 7–3

Question: Are your OSPF neighbors in a Full state?

Answer: Yes, your OSPF neighbors should be in a Full state. If they are not, please review your configuration and ensure the remote team has completed Step 1.1. Please request assistance from your instructor, if needed.

Question: Is your BGP peering up and functional?

Answer: Yes, your BGP neighborship should be up and working. If they are not, please review your configuration and ensure the remote team has completed Step 1.1. Please request assistance from your instructor, if needed.

Step 1.3

Enter into configuration mode. Review and familiarize yourself with the CE instance configuration.


[edit]lab@mxA-1# show routing-instances cex-y instance-type virtual-router;interface ge-1/1/4.610;interface lo0.1;routing-options { static { route 172.10.0.0/24 reject; route 172.10.1.0/24 reject; route 172.10.2.0/24 reject; route 172.10.3.0/24 reject; } autonomous-system 65101;}

Question: What type of instance is being used.

Answer: The instance type is virtual-router.

Junos MPLS and VPNs


Question: How many static routes are configured for this instance?

Answer: You should see four static routes all configured with a reject action associated.

Part 2: Establishing an RSVP Signaled LSP Between PE Routers

In this lab part, you will configure an RSVP-signaled LSP between the PE routers. You will verify reachability using the MPLS ping utility.

Step 2.1

Navigate to the [edit protocols mpls] hierarchy and configure a label-switched-path called pey-to-pez-x. For example, if you are assigned router mxA-1, your peer router is mxA-2. The LSP would be named pe1-to-pe2-1. Your LSP should egress at your remote peer’s loopback address. Verify the configuration looks correct. Commit and exit to operation mode when you are satisfied with the changes.



[edit protocols mpls]lab@mxA-1# show label-switched-path pe1-to-pe2-1 { to 192.168.1.2;}interface ge-1/0/0.210;interface ge-1/0/1.211;


lab@mxA-1>

Step 2.2

Verify that the RSVP LSP you just configured is up and functional. Ensure that you have bidirectional LSPs before proceeding. Review the inet.3 routing table to verify that the RSVP route is present and ready to use.

lab@mxA-1> show mpls lsp Ingress LSP: 1 sessionsTo From State Rt P ActivePath LSPname192.168.1.2 192.168.1.1 Up 0 * pe1-to-pe2-1Total 1 displayed, Up 1, Down 0

Junos MPLS and VPNs




lab@mxA-1> show route table inet.3



Question: Do you see bidirectional LSPs established?

Answer: You should see both an ingress LSP as well as a egress LSP entry. If you do not, please check with the remote team and verify they have completed Step 2.1. If you are still having problems, review your configuration and ask your instructor for assistance, if needed.

Question: Is your RSVP route present in the inet.3 routing table?

Answer: Yes, you should see a single RSVP route in your inet.3 routing table for the loopback address of the remote team’s PE router.

Step 2.3

Verify MPLS connectivity using the MPLS ping utility.

lab@mxA-1> ping mpls rsvp pey-to-pez-x !!!!!--- lsping statistics ---5 packets transmitted, 5 packets received, 0% packet loss

Question: Does your MPLS ping complete?

Answer: Yes, your ping should complete. If it does not, please review your configuration and ask your instructor for assistance, if needed.

Junos MPLS and VPNs



Part 3: Configuring the PE to CE Interface

In this lab part, you will configure the PE to CE interface. You will verify reachability using the ping utility.

Step 3.1

Enter configuration mode and navigate to the [edit interfaces] hierarchy. Configure the appropriate interface properties found on the Lab 5 network diagram. Commit your changes and exit to operational mode to verify reachability to the CE interface.



[edit interfaces]lab@mxA-1# set ge-1/0/4 vlan-tagging unit 6x0 vlan-id 6x0 family inet address 10.0.xy.1/24


lab@mxA-1>

Step 3.2

Verify connectivity to the CE device using the ping utility with a count value of 3.

lab@mxA-1> ping 10.0.xy.2 count 3 PING 10.0.10.2 (10.0.10.2): 56 data bytes64 bytes from 10.0.10.2: icmp_seq=0 ttl=64 time=0.502 ms64 bytes from 10.0.10.2: icmp_seq=1 ttl=64 time=0.426 ms64 bytes from 10.0.10.2: icmp_seq=2 ttl=64 time=0.434 ms


Question: Does your ping complete?

Answer: Yes, your ping should complete. If it does not, please review your configuration and ask your instructor for assistance, if needed.

Junos MPLS and VPNs


Part 4: Configuring a Layer 3 VPN Instance

In this lab part, you will configure a Layer 3 VPN instance. You will assign a unique route distinguisher and a unique route target. You will include your CE facing interface within this instance. In this lab, you will be using the vrf-target option because of its simplicity. Please note that vrf-import and vrf-export policies would work also.

Step 4.1

Enter into configuration mode and navigate to the [edit routing-instances] hierarchy. Create a new VPN routing and forwarding (VRF) instance named vpn-x.


[edit]lab@mxA-1# edit routing-instances

[edit routing-instances]lab@mxA-1# set vpn-x instance-type vrf

Step 4.2

Navigate to the [edit routing-instances vpn-x] hierarchy. Create a route distinguisher using your local loopback address to uniquely identify routes advertised from this router. The format should look like this: 192.168.x.y:1.

[edit routing-instances]lab@mxA-1# edit vpn-x

[edit routing-instances vpn-1]lab@mxA-1# set route-distinguisher 192.168.x.y:1

Step 4.3

Configure your route target. As mentioned previously, you will be using the vrf-target option. Your target will contain the local autonomous system (AS) number and will be uniquely identified by using your pod value. The format for defining your vrf-target is: target:65512:x.

[edit routing-instances vpn-1]lab@mxA-1# set vrf-target target:65512:x

Step 4.4

Include the CE facing interface in your VRF instance.

[edit routing-instances vpn-1]lab@mxA-1# set interface ge-1/0/4.6x0

Junos MPLS and VPNs


Step 4.5

Review your recent configuration changes. When you are satisfied with these changes, commit your configuration and exit to operational mode.

[edit routing-instances vpn-1]lab@mxA-1# show instance-type vrf;interface ge-1/0/4.610;route-distinguisher 192.168.1.1:1;vrf-target target:65512:1;

[edit routing-instances vpn-1]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 4.6

Verify that your VRF routing table has been created and it contains the local and direct routes for your CE facing interface. You can accomplish this by issuing the command: show route table vpn-x.inet.0

lab@mxA-1> show route table vpn-x.inet.0

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

10.0.10.0/24 *[Direct/0] 00:43:48 > via ge-1/0/4.61010.0.10.1/32 *[Local/0] 00:43:48 Local via ge-1/0/4.610

Question: Do you see your local and direct routes?

Answer: You should see a local route for the interface you configured (10.0.xy.1/32) and a direct route for the network attached to that interface (10.0.xy.0/24). If you do not see these routes, please review your configuration and ask your instructor for assistance, if needed.


Junos MPLS and VPNs


Part 5: Configuring Static Routing Between the PE and CE Routers

In this lab part, you will configure static routes to pass traffic from your PE router to your CE router. These routes will be passed through the MP-BGP session to the remote PE router so that traffic can be routed from the remote CE site. You will configure a default route on your CE router. You will configure static routes on your PE router, under your VRF instance, for the four static routes already created on the CE device. You will also configure a static route for the loopback address of your CE router. You will verify that these routes are shared with the remote PE device and you must also verify that you are receiving the routes from the remote PE. You will use the ping utility to test the CE to CE connectivity over the Layer 3 VPN.

Step 5.1

Enter configuration mode and navigate to the [edit routing-instances cex-y routing-options] hierarchy. Configure a static default route that points to the PE interface address as the next hop.


[edit]lab@mxA-1# edit routing-instances cex-y routing-options

[edit routing-instances ce1-1 routing-options]lab@mxA-1# set static route 0/0 next-hop 10.0.xy.1

Step 5.2

Navigate to the [edit routing-instances vpn-x routing-options] hierarchy. Configure the static routes in your PE instance for the static networks that reside on your CE device. You must also configure a static route for the loopback address of your CE device. All static route next hops should point to the CE interface address.

[edit routing-instances ce1-1 routing-options]lab@mxA-1# top edit routing-instances vpn-x routing-options

[edit routing-instances vpn-1 routing-options]lab@mxA-1# set static route 172.x0.y.0/24 next-hop 10.0.xy.2




[edit routing-instances vpn-1 routing-options]lab@mxA-1# set static route 192.168.1x.y next-hop 10.0.xy.2

[edit routing-instances vpn-1 routing-options]lab@mxA-1# commit and-quit commit complete

Junos MPLS and VPNs


Exiting configuration mode

lab@mxA-1>

Step 5.3

Verify that you are advertising your routes to the remote PE router.


vpn-1.inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 10.0.10.0/24 Self 100 I* 172.10.0.0/24 Self 100 I* 172.10.1.0/24 Self 100 I* 172.10.2.0/24 Self 100 I* 172.10.3.0/24 Self 100 I* 192.168.11.1/32 Self 100 I

Question: What routes are being advertised to the remote PE router?

Answer: You should see the PE-CE network, the four static routes that you created under the VRF instance and the loopback address for the CE device. If you do not see these routes, please review your configuration and request assistance from your instructor, if needed.

Step 5.4

Verify that you are receiving routes from the remote PE router.





vpn-1.inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 10.0.11.0/24 192.168.1.2 100 I* 172.10.4.0/24 192.168.1.2 100 I* 172.10.5.0/24 192.168.1.2 100 I* 172.10.6.0/24 192.168.1.2 100 I* 172.10.7.0/24 192.168.1.2 100 I* 192.168.11.2/32 192.168.1.2 100 I


bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

Junos MPLS and VPNs


Prefix Nexthop MED Lclpref AS path 192.168.1.2:1:10.0.11.0/24 * 192.168.1.2 100 I 192.168.1.2:1:172.10.4.0/24 * 192.168.1.2 100 I 192.168.1.2:1:172.10.5.0/24 * 192.168.1.2 100 I 192.168.1.2:1:172.10.6.0/24 * 192.168.1.2 100 I 192.168.1.2:1:172.10.7.0/24 * 192.168.1.2 100 I 192.168.1.2:1:192.168.11.2/32 * 192.168.1.2 100 I

Question: What routes are you receiving from the remote PE router?

Answer: You should be receiving the remote PE-CE network, the four static routes that were created under the VRF instance and the loopback address for the remote CE device. If you do not see these routes, please review your configuration and ensure that the remote team has completed Step 5.2. Please request assistance from your instructor, if needed.

Step 5.5

Review the routes that are installed in your VRF table.



10.0.10.0/24 *[Direct/0] 00:43:27 > via ge-1/0/4.61010.0.10.1/32 *[Local/0] 00:43:27 Local via ge-1/0/4.61010.0.11.0/24 *[BGP/170] 00:43:27, localpref 100, from 192.168.1.2 AS path: I > to 172.22.211.2 via ge-1/0/1.211, label-switched-path pe1-to-pe2-1172.10.0.0/24 *[Static/5] 00:07:54 > to 10.0.10.2 via ge-1/0/4.610172.10.1.0/24 *[Static/5] 00:07:54 > to 10.0.10.2 via ge-1/0/4.610172.10.2.0/24 *[Static/5] 00:07:54 > to 10.0.10.2 via ge-1/0/4.610172.10.3.0/24 *[Static/5] 00:07:54 > to 10.0.10.2 via ge-1/0/4.610172.10.4.0/24 *[BGP/170] 00:43:27, localpref 100, from 192.168.1.2

Junos MPLS and VPNs


AS path: I > to 172.22.211.2 via ge-1/0/1.211, label-switched-path pe1-to-pe2-1172.10.5.0/24 *[BGP/170] 00:43:27, localpref 100, from 192.168.1.2 AS path: I > to 172.22.211.2 via ge-1/0/1.211, label-switched-path pe1-to-pe2-1172.10.6.0/24 *[BGP/170] 00:43:27, localpref 100, from 192.168.1.2 AS path: I > to 172.22.211.2 via ge-1/0/1.211, label-switched-path pe1-to-pe2-1172.10.7.0/24 *[BGP/170] 00:43:27, localpref 100, from 192.168.1.2 AS path: I > to 172.22.211.2 via ge-1/0/1.211, label-switched-path pe1-to-pe2-1192.168.11.1/32 *[Static/5] 00:07:54 > to 10.0.10.2 via ge-1/0/4.610192.168.11.2/32 *[BGP/170] 00:43:27, localpref 100, from 192.168.1.2 AS path: I > to 172.22.211.2 via ge-1/0/1.211, label-switched-path pe1-to-pe2-1

Question: Do you see all the remote PE routes?

Answer: Yes, you should see all the remote PE routes.

Step 5.6

Verify you have connectivity from CE to CE through the Layer 3 VPN by using the ping utility. You will ping the remote CE routers loopback address while sourcing the packets from your local CE’s loopback address. You will send five packets for this test. This can be accomplished using the following command: ping 192.168.1x.y source 192.168.1x.y routing-instance cex-y count 5



Junos MPLS and VPNs


Question: Do all your ping packets complete?

Answer: Yes, they should all complete. If they do not, please review your configuration and consult with your instructor, if needed.


Part 6: Configuring BGP Routing Between the PE and CE Routers

In this lab part, you will configure BGP routing to pass routes from your PE to your CE router. These routes will be passed through the MP-BGP session to the remote PE router so that traffic can be routed from the remote CE site. You will verify that your routes are shared with the remote PE device and you will also need to verify that you are receiving the routes from the remote PE. You will use the ping utility to test the CE to CE connectivity over the Layer 3 VPN.

Step 6.1

Enter into configuration mode and navigate to the [edit routing-instances vpn-x routing-options] hierarchy. Delete all static routes that have been applied to the VRF instance.


[edit]lab@mxA-1# edit routing-instances vpn-x routing-options

[edit routing-instances vpn-1 routing-options]lab@mxA-1# delete static

Step 6.2

Navigate to the [edit routing-instances cex-y routing-options] hierarchy. Remove the static default route that you created in Part 5. Commit and exit to operational mode before proceeding.

[edit routing-instances vpn-1 routing-options]lab@mxA-1# top edit routing-instances cex-y routing-options

[edit routing-instances ce1-1 routing-options]lab@mxA-1# delete static route 0/0

Junos MPLS and VPNs


[edit routing-instances ce1-1 routing-options]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 6.3

View the routes in your VRF table to verify that you are no longer receiving routes from the remote PE router.




Question: What routes are currently present in your VRF table?

Answer: You should only see the direct and local routes for your PE to CE network and interface.

Step 6.4

Enter into configuration mode and navigate to the [edit routing-instances cex-y protocols bgp] hierarchy. Create an external group called my-ext-group and specify your neighbor address. You must also define your peer-as. Apply the policy exp-policy that you created in Lab 6, as an export policy to your EBGP group. Review your configuration before moving on to the next step.


[edit]lab@mxA-1# edit routing-instances cex-y protocols bgp


Junos MPLS and VPNs




[edit routing-instances ce1-1 protocols bgp]lab@mxA-1# set group my-ext-group export exp-policy

[edit routing-instances ce1-1 protocols bgp]lab@mxA-1# show group my-ext-group { type external; export exp-policy; peer-as 65512; neighbor 10.0.10.1;}

Step 6.5

Navigate to the [edit routing-instances vpn-x protocols bgp] hierarchy. Create an external group called my-ext-group and specify your neighbor address. You must also define your peer-as. Review your configuration, Commit, and exit to operational mode before moving on to the next step.

[edit routing-instances ce1-1 protocols bgp]lab@mxA-1# top edit routing-instances vpn-x protocols bgp

[edit routing-instances vpn-1 protocols bgp]lab@mxA-1# set group my-ext-group type external

[edit routing-instances vpn-1 protocols bgp]lab@mxA-1# set group my-ext-group neighbor 10.0.xy.2

[edit routing-instances vpn-1 protocols bgp]lab@mxA-1# set group my-ext-group peer-as 65x01

[edit routing-instances vpn-1 protocols bgp]lab@mxA-1# show group my-ext-group { type external; peer-as 65101; neighbor 10.0.10.2;}

[edit routing-instances vpn-1 protocols bgp]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Junos MPLS and VPNs


Step 6.6

Verify on the PE that you are receiving the advertised BGP routes from your CE router.





vpn-1.inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 10.0.10.0/24 10.0.10.2 65101 I* 172.10.0.0/24 10.0.10.2 65101 I* 172.10.1.0/24 10.0.10.2 65101 I* 172.10.2.0/24 10.0.10.2 65101 I* 172.10.3.0/24 10.0.10.2 65101 I* 192.168.11.1/32 10.0.10.2 65101 I



Question: Do you see the static routes that you exported with the policy you applied?

Answer: Yes, you should see a route entry for each of the static routes configured as well as the loopback address and the network between your PE and CE routers.If you do not, please review your configuration and request assistance from your instructor, if needed.

Step 6.7

Verify that your PE router is advertising your VPN routes to the remote PE router.


vpn-1.inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 10.0.10.0/24 Self 100 I* 172.10.0.0/24 Self 100 65101 I* 172.10.1.0/24 Self 100 65101 I* 172.10.2.0/24 Self 100 65101 I* 172.10.3.0/24 Self 100 65101 I* 192.168.11.1/32 Self 100 65101 I

Junos MPLS and VPNs


Question: Are you advertising all the bgp routes you are learning from your CE router?

Answer: Yes, you should be advertising all the routes you received from your CE router. If you are not, please review your configuration and request assistance from your instructor, if needed.

Step 6.8

Verify that you are receiving the VPN routes being advertised from the remote PE router.





vpn-1.inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 10.0.11.0/24 192.168.1.2 100 I* 172.10.4.0/24 192.168.1.2 100 65101 I* 172.10.5.0/24 192.168.1.2 100 65101 I* 172.10.6.0/24 192.168.1.2 100 65101 I* 172.10.7.0/24 192.168.1.2 100 65101 I* 192.168.11.2/32 192.168.1.2 100 65101 I


bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 192.168.1.2:1:10.0.11.0/24 * 192.168.1.2 100 I 192.168.1.2:1:172.10.4.0/24 * 192.168.1.2 100 65101 I 192.168.1.2:1:172.10.5.0/24 * 192.168.1.2 100 65101 I 192.168.1.2:1:172.10.6.0/24 * 192.168.1.2 100 65101 I 192.168.1.2:1:172.10.7.0/24 * 192.168.1.2 100 65101 I 192.168.1.2:1:192.168.11.2/32 * 192.168.1.2 100 65101 I

Junos MPLS and VPNs


Question: Are you receiving all the expected routes that are being exported from the remote PE and CE routers?

Answer: Yes, you should see all the routes that were exported by the remote CE router and later advertised from the remote PE router through the VPN. If you do not see these routes, please review your configuration and ensure that the remote team has completed Step 6.6. Please request assistance from your instructor, if needed.

Step 6.9

Review the BGP routes you are receiving on your CE router.




ce1-1.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 10.0.11.0/24 10.0.10.1 65512 I

vpn-1.inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)



Question: Are you receiving all the remote network routes from your PE router?

Answer: No, you are not receiving these routes.

Question: What additional steps must you take to determine why the routes are not being received at your CE router?

Answer: You must verify that the PE router is actually sending the routes to the CE router. You should also look at one of these routes to see whether you can determine the cause of the problem.

Junos MPLS and VPNs


Step 6.10

Verify that your PE router is advertising these routes to your CE router.


vpn-1.inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 10.0.11.0/24 Self I

Question: Do you see all the remote network routes being advertised to your CE router?

Answer: No, you will not see these routes being advertised.

Step 6.11

Take an extensive look at one of the routes you are receiving from the remote PE router but are not advertising to your CE router.

lab@mxA-1> show route 172.x0.y.0/24 extensive

vpn-1.inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)172.10.4.0/24 (1 entry, 1 announced)TSI:KRT in-kernel 172.10.4.0/24 -> {indirect(1048575)} *BGP Preference: 170/-101 Route Distinguisher: 192.168.1.2:1 Next hop type: Indirect Next-hop reference count: 18 Source: 192.168.1.2 Next hop type: Router, Next hop index: 616 Next hop: 172.22.211.2 via ge-1/0/1.211 weight 0x1, selected Label-switched-path pe1-to-pe2-1 Label operation: Push 300448, Push 301344(top) Protocol next hop: 192.168.1.2 Push 300448 Indirect next hop: 284d4b0 1048575 State: <Secondary Active Int Ext> Local AS: 65512 Peer AS: 65512 Age: 11:26:07 Metric2: 4 Task: BGP_65512.192.168.1.2+50523 Announcement bits (1): 0-KRT AS path: 65101 I Communities: target:65512:1 Import Accepted VPN Label: 300448 Localpref: 100 Router ID: 192.168.1.2 Primary Routing Table bgp.l3vpn.0 Indirect next hops: 1 Protocol next hop: 192.168.1.2 Metric: 4 Push 300448

Junos MPLS and VPNs


Indirect next hop: 284d4b0 1048575 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 172.22.211.2 via ge-1/0/1.211 weight 0x1 192.168.1.2/32 Originating RIB: inet.3 Metric: 4 Node path count: 1 Forwarding nexthops: 1 Nexthop: 172.22.211.2 via ge-1/0/1.211


192.168.1.2:1:172.10.4.0/24 (1 entry, 0 announced) *BGP Preference: 170/-101 Route Distinguisher: 192.168.1.2:1 Next hop type: Indirect Next-hop reference count: 18 Source: 192.168.1.2 Next hop type: Router, Next hop index: 616 Next hop: 172.22.211.2 via ge-1/0/1.211 weight 0x1, selected Label-switched-path pe1-to-pe2-1 Label operation: Push 300448, Push 301344(top) Protocol next hop: 192.168.1.2 Push 300448 Indirect next hop: 284d4b0 1048575 State: <Active Int Ext> Local AS: 65512 Peer AS: 65512 Age: 11:26:07 Metric2: 4 Task: BGP_65512.192.168.1.2+50523 AS path: 65101 I Communities: target:65512:1 Import Accepted VPN Label: 300448 Localpref: 100 Router ID: 192.168.1.2 Secondary Tables: vpn-1.inet.0 Indirect next hops: 1 Protocol next hop: 192.168.1.2 Metric: 4 Push 300448 Indirect next hop: 284d4b0 1048575 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 172.22.211.2 via ge-1/0/1.211 weight 0x1 192.168.1.2/32 Originating RIB: inet.3 Metric: 4 Node path count: 1 Forwarding nexthops: 1 Nexthop: 172.22.211.2 via ge-1/0/1.211

Question: What is the AS path of this route?

Answer: The AS path is 65101 I.

Junos MPLS and VPNs


Question: What is the AS of your CE router?

Answer: The AS of your CE router is 65101.

Question: Will the PE router advertise routes to an EBGP peer when the peer’s AS number is present in the AS path?

Answer: No, BGP views this behavior as a potential routing loop and will not advertise these routes.

Step 6.12

Enter into configuration mode and navigate to the [edit routing-instances vpn-x protocols bgp] hierarchy. Configure the external group to override the AS. Remember that we discussed a few methods for overcoming this challenge. You will be using the as-override option because of simplicity. Commit and exit to operational mode.


[edit]lab@mxA-1# edit routing-instances vpn-x protocols bgp

[edit routing-instances vpn-1 protocols bgp]lab@mxA-1# set group my-ext-group as-override

[edit routing-instances vpn-1 protocols bgp]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 6.13

Verify that your CE router is now receiving the routes from your PE router after the change.




ce1-1.inet.0: 13 destinations, 18 routes (13 active, 0 holddown, 5 hidden) Prefix Nexthop MED Lclpref AS path* 10.0.11.0/24 10.0.10.1 65512 I* 172.10.4.0/24 10.0.10.1 65512 65512 I* 172.10.5.0/24 10.0.10.1 65512 65512 I* 172.10.6.0/24 10.0.10.1 65512 65512 I* 172.10.7.0/24 10.0.10.1 65512 65512 I

Junos MPLS and VPNs


* 192.168.11.2/32 10.0.10.1 65512 65512 I




Question: Do you now see the routes being sent from the remote team in your CE router’s routing table?

Answer: Yes, you should see all the routes being advertised from the remote CE and PE routers. If you do not, please review your configuration and request assistance from your instructor, if needed.

Step 6.14

Verify that you have connectivity from CE to CE through the Layer 3 VPN by using the ping utility. You will ping the remote CE router’s loopback address while sourcing the packets from your local CE router’s loopback address. You will send five packets for this test. This task can be accomplished using the following command: ping 192.168.1x.y source 192.168.1x.y routing-instance cex-y count 5 .



Question: Do your ping requests complete?

Answer: Yes, your ping requests should complete. If they do not, review your configuration and ensure that the remote team has completed Step 6.13. Please request assistance from your instructor, if needed.


www.juniper.net Route Reflection and Internet Access (Detailed) • Lab 8–110.a.10.3R1.9

Lab 8Route Reflection and Internet Access (Detailed)

Overview

In this lab, you will establish two point-to-point Layer 3 virtual private networks (VPNs) using RSVP signaling between provider edge (PE) routers. You will alter your internal BGP (IBGP) configuration to peer with a preconfigured route reflector in the core network. You will implement route target filtering on your PE router and you will configure Internet access for the customer edge (CE) router through your PE router.




• Reconfigure your IBGP peering, so that your router peers with the route reflector.

• Configure LDP-signaled label-switched paths (LSPs) to the remote PE router.

• Create a second virtual router that will act as a second CE router and customer network.

• Create and establish two Layer 3 VPNs over the core network.

• Configure BGP routing between your PE and CE routers and share your CE routes through the Layer 3 VPNs using Multiprotocol Border Gateway Protocol (MP-BGP).

• Implement route target filtering on your PE router.

• Configure Internet access for your CE router through your PE router.

• Verify connectivity and behavior throughout the lab using command-line interface (CLI) operational mode commands including ping and commands used to examine routing tables and PE-PE BGP announcements.

Junos MPLS and VPNs

Lab 8–2 • Route Reflection and Internet Access (Detailed) www.juniper.net


In this lab part, you will load the VPN baseline configuration you saved in Lab 6. After loading the configuration, you will verify the core network is operating as expected. You will review the CE instance configuration so you are familiar with the contents.

Step 1.1

Enter into configuration mode and load the VPN baseline configuration by executing the load override jmv-RouterName-vpn-baseline command. Commit your configuration changes and exit to operational mode.




lab@mxA-1>

Step 1.2




Junos MPLS and VPNs

www.juniper.net Route Reflection and Internet Access (Detailed) • Lab 8–3




Answer: Yes, your BGP neighborship should be up and working. If it is not, please review your configuration and ensure the remote team has completed Step 1.1. Please request assistance from your instructor, if needed.

Step 1.3




Junos MPLS and VPNs


Part 2: Configuring Your PE Router to Peer with the Route Reflector

In this lab part, you will reconfigure your IBGP peering so that it peers with a preconfigured route reflector in your core network. You will alter the neighbor address so that you peer with the P2 router in your core network. You will verify that the neighborship establishes and that you are receiving the correct network layer reachability information (NLRI) needed to establish a Layer 3 VPN.

Step 2.1

Navigate to the [edit protocols bgp group my-int-group] hierarchy. Change the current neighbor address using the rename option and add the correct address to peer with the P2 router, which is the acting route reflector for the core network. Commit your change and exit to operational mode.

[edit]lab@mxA-1# edit protocols bgp group my-int-group

[edit protocols bgp group my-int-group]lab@mxA-1# show type internal;local-address 192.168.1.1;family inet { unicast;}family inet-vpn { unicast;}neighbor 192.168.1.2;

[edit protocols bgp group my-int-group]lab@mxA-1# rename neighbor 192.168.x.y to neighbor 192.168.5.2

[edit protocols bgp group my-int-group]lab@mxA-1# show type internal;local-address 192.168.1.1;family inet { unicast;}family inet-vpn { unicast;}

neighbor 192.168.5.2;


lab@mxA-1>

Junos MPLS and VPNs


Step 2.2

Verify that your neighborship has established with the route reflector. Review the BGP neighborship to ensure that you are receiving the correct NLRI to establish a Layer 3 VPN.

lab@mxA-1> show bgp summary Groups: 1 Peers: 1 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0bgp.l3vpn.0 0 0 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...192.168.5.2 65512 67 66 0 0 28:33 Establ inet.0: 0/0/0/0 bgp.l3vpn.0: 0/0/0/0

lab@mxA-1> show bgp neighbor 192.168.5.2 Peer: 192.168.5.2+179 AS 65512 Local: 192.168.1.1+49425 AS 65512 Type: Internal State: Established Flags: <ImportEval Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ statics ] Options: <Preference LocalAddress AddressFamily Rib-group Refresh> Address families configured: inet-unicast inet-vpn-unicast Local Address: 192.168.1.1 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.5.2 Local ID: 192.168.1.1 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down NLRI for restart configured on peer: inet-unicast inet-vpn-unicast NLRI advertised by peer: inet-unicast inet-vpn-unicast route-target NLRI for this session: inet-unicast inet-vpn-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast inet-vpn-unicast route-target NLRI that restart is negotiated for: inet-unicast inet-vpn-unicast NLRI of received end-of-rib markers: inet-unicast inet-vpn-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 65512) Peer does not support Addpath Table inet.0 Bit: 20000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Advertised prefixes: 0 Table bgp.l3vpn.0 RIB State: BGP restart is complete RIB State: VPN restart is complete Send state: not advertising

Junos MPLS and VPNs


Active prefixes: 0 Received prefixes: 0 Accepted prefixes: 0 Suppressed due to damping: 0 Last traffic (seconds): Received 20 Sent 5 Checked 37 Input messages: Total 67 Updates 2 Refreshes 0 Octets 1288 Output messages: Total 67 Updates 0 Refreshes 0 Octets 1344 Output Queue[1]: 0 Output Queue[2]: 0

Question: Is the neighborship established with your new BGP peer?

Answer: Yes, your new BGP session should be established with the route reflector. If it is not, please review your configuration and request assistance from your instructor, if needed.

Question: What NLRIs are you receiving from the route reflector neighbor?

Answer: You should be receiving both inet unicast and inet-vpn unicast and route-target from the route reflector peer.

Question: Which NLRI allows you to send and receive information about Layer 3 VPNs?

Answer: The inet-vpn unicast is the one you need to send and receive Layer 3 VPN information.

Part 3: Establishing LDP Signaled LSPs Between PE Routers and Router Reflector

In this lab part, you will use LDP to signal LSPs to the remote PE router through the core network as well as to the Route Reflector. You will verify that the LDP LSPs are established and that the LDP routes are installed in your routing table.

Step 3.1

Enter into configuration mode and navigate to the [edit protocols ldp] hierarchy. Add the interface all statement to include all interfaces in LDP. As good practice, remember to disable the management interface. Commit and exit to operation mode when you are satisfied with the changes.

Junos MPLS and VPNs




[edit protocols ldp]lab@mxA-1# set interface all

[edit protocols ldp]lab@mxA-1# set interface fxp0 disable


lab@mxA-1>

Step 3.2

Verify that the LSPs are established and ready for use.

lab@mxA-1> show ldp neighbor Address Interface Label space ID Hold time172.22.210.2 ge-1/0/0.210 192.168.5.1:0 10172.22.211.2 ge-1/0/1.211 192.168.5.4:0 11


Step 3.3

Verify that the inet.3 routing table is created and contains the RSVP route to the remote PE router.



192.168.1.2/32 *[LDP/9] 00:12:12, metric 1 to 172.22.210.2 via ge-1/0/0.210, Push 307264 > to 172.22.211.2 via ge-1/0/1.211, Push 303760192.168.5.1/32 *[LDP/9] 00:12:12, metric 1 > to 172.22.210.2 via ge-1/0/0.210192.168.5.2/32 *[LDP/9] 00:12:12, metric 1 > to 172.22.210.2 via ge-1/0/0.210, Push 307040192.168.5.3/32 *[LDP/9] 00:12:12, metric 1 > to 172.22.210.2 via ge-1/0/0.210, Push 306688192.168.5.1/32 *[LDP/9] 00:12:12, metric 1 > to 172.22.211.2 via ge-1/0/1.211192.168.5.5/32 *[LDP/9] 00:12:12, metric 1 > to 172.22.211.2 via ge-1/0/1.211, Push 299808

Junos MPLS and VPNs


192.168.5.6/32 *[LDP/9] 00:12:12, metric 1 > to 172.22.211.2 via ge-1/0/1.211, Push 299840

Question: Do you see the LDP route to the remote PE router in your inet.3 routing table?

Answer: Yes, you should see the LDP route in the inet.3 routing table now. If you do not, please review your configuration and verify the state of your MPLS LSP is Up.

Part 4: Configuring Another CE Router Using a Virtual Router

In this lab part, you will create another virtual router type routing instance on your device. This virtual router will act as the second CE for this lab, which will allow you to configure two separate sites.

Step 4.1

Familiarize yourself with the lab diagram titled“Lab 8: Part 3-8—Layer 3 VPN Scaling and Internet Access”. Each group of students will configure a second CE router.

Step 4.2

Enter configuration mode and navigate to the [edit interfaces] hierarchy. Configure a loopback interface using unit 2—this unit will be used as your CE router’s loopback interface.



[edit interfaces]lab@mxA-1# set lo0 unit 2 family inet address 192.168.2x.y

Step 4.3

Configure your CE router’s ge-1/1/5 interface, which will be used to connect to your local PE router.

[edit interfaces]lab@mxA-1# set ge-1/1/5 vlan-tagging unit 6x1 vlan-id 6x1

[edit interfaces]lab@mxA-1# set ge-1/1/5 vlan-tagging unit 6x1 family inet address 10.1.xy.2/24

Step 4.4

Navigate to the [edit routing-instances cex-y] hierarchy and configure your CE router’s routing instance specifying a routing instance type of virtual-router and apply the lo0 and ge-1/1/5 interfaces to the instance.

Junos MPLS and VPNs


[edit interfaces]lab@mxA-1# top edit routing-instances cex-y

[edit routing-instances ce1-3]lab@mxA-1# set instance-type virtual-router

[edit routing-instances ce1-3]lab@mxA-1# set interface ge-1/1/5.6x1

[edit routing-instances ce1-3]lab@mxA-1# set interface lo0.2

Step 4.5

Configure your CE router’s autonomous system (AS) number.

[edit routing-instances ce1-3]lab@mxA-1# set routing-options autonomous-system 65x02

Step 4.6

Configure your CE router’s static routes as listed on the lab diagram. Use a next hop of reject for each of the four static routes. Commit your configuration and exit to operational mode.

[edit routing-instances ce1-3]lab@mxA-1# set routing-options static route 172.x1.y/24 reject





lab@mxA-1>

Step 4.7

View the CE router’s routing table and ensure that the correct direct and static routes are now installed in the table.

lab@mxA-1> show route table cex-y


10.1.10.0/24 *[Direct/0] 00:50:57 > via ge-1/1/5.61110.1.10.2/32 *[Local/0] 00:50:57

Junos MPLS and VPNs


Local via ge-1/1/5.611172.11.0.0/24 *[Static/5] 00:50:57 Reject172.11.1.0/24 *[Static/5] 00:50:57 Reject172.11.2.0/24 *[Static/5] 00:50:57 Reject172.11.3.0/24 *[Static/5] 00:50:57 Reject192.168.21.1/32 *[Direct/0] 00:50:57 > via lo0.2

Question: What routes appear in your CE router’s routing table?

Answer: The networks associated with the ge-1/1/5 and lo0 should appear in the CE router’s routing table. Also, the four static routes should also appear. If these routes do not exist, go back and verify your configuration.

Part 5: Configuring the PE to CE Interfaces

In this lab part, you will configure both of the PE to CE interfaces.You will verify reachability using the ping utility.

Step 5.1

Enter into configuration mode and navigate to the [edit interfaces] hierarchy. Configure the appropriate interface properties found on the lab diagram titled “Lab 8: Part 3-8—Layer 3 VPN Scaling and Internet Access”. You will configure the interfaces for each connection to the two CE routers. Commit your change and exit to operational mode to verify reachability to the CE interface.




[edit interfaces]lab@mxA-1# set ge-1/0/4 unit 6x0 family inet address 10.0.xy.1/24


[edit interfaces]lab@mxA-1# set ge-1/0/5 unit 6x1 family inet address 10.1.xy.1/24

Junos MPLS and VPNs



lab@mxA-1>

Step 5.2

Verify reachability to both CE routers by pinging their interfaces five times.

lab@mxA-1> ping 10.0.xy.2 count 5 PING 10.0.10.2 (10.0.10.2): 56 data bytes64 bytes from 10.0.10.2: icmp_seq=0 ttl=64 time=0.489 ms64 bytes from 10.0.10.2: icmp_seq=1 ttl=64 time=0.417 ms64 bytes from 10.0.10.2: icmp_seq=2 ttl=64 time=0.424 ms64 bytes from 10.0.10.2: icmp_seq=3 ttl=64 time=0.413 ms64 bytes from 10.0.10.2: icmp_seq=4 ttl=64 time=0.427 ms


lab@mxA-1> ping 10.1.xy.2 count 5 PING 10.1.10.2 (10.1.10.2): 56 data bytes64 bytes from 10.1.10.2: icmp_seq=0 ttl=64 time=1.016 ms64 bytes from 10.1.10.2: icmp_seq=1 ttl=64 time=0.399 ms64 bytes from 10.1.10.2: icmp_seq=2 ttl=64 time=0.387 ms64 bytes from 10.1.10.2: icmp_seq=3 ttl=64 time=0.429 ms64 bytes from 10.1.10.2: icmp_seq=4 ttl=64 time=0.429 ms


Question: Do the pings complete?

Answer: Yes, your ping tests should complete to both CE routers. If they do not, check your configuration of both the CE and PE interfaces to ensure you have configured the properties correctly. Please request assistance from the instructor, if needed.

Junos MPLS and VPNs


Part 6: Configuring Two Layer 3 VPN Instances

In this lab part, you will configure two Layer 3 VPN instances. You will create a VPN named vpnx-a, which will connect cex-1 with cex-2. You will then create a VPN named vpnx-b, which will connect cex-3 with cex-4. You will assign a unique route target to each instance and you will include your CE-facing interface within the appropriate instance. In this lab, you will be using the vrf-target option because of its simplicity. Please note that vrf-import and vrf-export policies would work also.

Step 6.1

Enter into configuration mode and navigate to the [edit routing-instances vpnx-a] hierarchy. Configure the routing instance specifying a routing instance type of vrf. Configure your route target. As mentioned previously, you will be using the vrf-target option. Your target will contain the local autonomous system (AS) number and a unique identifier. The format for defining your vrf-target for the vpnx-a instance is: target:65512:x01. Add the ge-1/0/4.6x0 interface to the routing instance. Review your configuration changes and commit when you are satisfied with the changes.


[edit]lab@mxA-1# edit routing-instances vpnx-a

[edit routing-instances vpn1-a]lab@mxA-1# set instance-type vrf

[edit routing-instances vpn1-a]lab@mxA-1# set vrf-target target:65512:x01

[edit routing-instances vpn1-a]lab@mxA-1# set interface ge-1/0/4.6x0

[edit routing-instances vpn1-a]lab@mxA-1# show instance-type vrf;interface ge-1/0/4.610;vrf-target target:65512:101;

[edit routing-instances vpn1-a]lab@mxA-1# commit commit complete

Junos MPLS and VPNs


Step 6.2

Navigate to the [edit routing-instances vpnx-b] hierarchy. Configure the routing instance specifying a routing instance type of vrf. Configure your route target. The format for defining your vrf-target for the vpnx-b instance is: target:65512:x02. Add the ge-1/0/5.6x1 interface to the routing instance. Review your configuration changes and when satisfied, commit and exit to operational mode.

[edit routing-instances vpn1-a]lab@mxA-1# top edit routing-instances vpnx-b

[edit routing-instances vpn1-b]lab@mxA-1# set instance-type vrf

[edit routing-instances vpn1-b]lab@mxA-1# set vrf-target target:65512:x02

[edit routing-instances vpn1-b]lab@mxA-1# set interface ge-1/0/5.6x1

[edit routing-instances vpn1-b]lab@mxA-1# show instance-type vrf;interface ge-1/0/5.611;vrf-target target:65512:102;

[edit routing-instances vpn1-b]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 6.3

Verify that both VRF tables are created and contain the local network routes.

lab@mxA-1> show route table vpnx-a

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


lab@mxA-1> show route table vpnx-b

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


Junos MPLS and VPNs


Question: What routes do the tables contain?

Answer: In each route table they should contain the Local and Direct routes for the interfaces that you included in the VRF instance.


Part 7: Configuring BGP Routing Between the PE and CE Routers

In this lab part, you will configure BGP routing to pass routes from your CE routers to your PE router. These routes will be passed through the MP-BGP session to the remote PE router so that traffic can be routed from the remote CE sites. You will verify that your routes are shared with the remote PE device and you will also need to verify that you are receiving the routes from the remote PE router for each of the configured VPNs. You will use the ping utility to test the CE to CE connectivity over the Layer 3 VPNs for each site.

Step 7.1

Enter into configuration mode and navigate to the [edit routing-instances vpnx-a protocols bgp] hierarchy. Create an external group called my-ext-group-a and specify your neighbor address. You must also define your peer-as. Remember to add the option as-override to your BGP group, because both the local CE router and the remote CE router are in the same AS. Review your configuration and commit before moving on to the next step.


[edit]lab@mxA-1# edit routing-instances vpnx-a protocols bgp

[edit routing-instances vpn1-a protocols bgp]lab@mxA-1# set group my-ext-group-a type external

[edit routing-instances vpn1-a protocols bgp]lab@mxA-1# set group my-ext-group-a neighbor 10.0.xy.2

[edit routing-instances vpn1-a protocols bgp]lab@mxA-1# set group my-ext-group-a peer-as 65x01

[edit routing-instances vpn1-a protocols bgp]lab@mxA-1# set group my-ext-group-a as-override

Junos MPLS and VPNs


[edit routing-instances vpn1-a protocols bgp]lab@mxA-1# show group my-ext-group-a { type external; peer-as 65101; as-override; neighbor 10.0.10.2;}

[edit routing-instances vpn1-a protocols bgp]lab@mxA-1# commit commit complete

Step 7.2

Navigate to the [edit routing-instances cex-y protocols bgp] hierarchy, where cex-y is your CE router connected to your VPNx-a instance. Create an external group called my-ext-group and specify your neighbor address. You must also define your peer-as. Apply the policy exp-policy that you created in Lab 6, as an export policy to your EBGP group. Review your configuration, commit, and exit to operational mode.

[edit routing-instances vpn1-a protocols bgp]lab@mxA-1# top edit routing-instances cex-y protocols bgp






[edit routing-instances ce1-1 protocols bgp]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Junos MPLS and VPNs


Step 7.3

Verify that you are receiving the static routes from your CE router at your PE router. You will also need to verify that you are sending these routes to the remote team through the route reflector. Verify that you are also receiving the remote CE router’s static routes at your PE router from the route reflector and that you are receiving the routes from the remote CE router on your local CE router. After verifying that the routes are present on all your routers, verify reachability to the remote CE router by pinging the loopback address five times. This task can be accomplished by issuing the ping 192.168.1x.y source 192.168.1x.y routing-instance cex-y count 5 command.






vpn1-a.inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 10.0.10.0/24 10.0.10.2 65101 I* 172.10.0.0/24 10.0.10.2 65101 I* 172.10.1.0/24 10.0.10.2 65101 I* 172.10.2.0/24 10.0.10.2 65101 I* 172.10.3.0/24 10.0.10.2 65101 I* 192.168.11.1/32 10.0.10.2 65101 I

vpn1-b.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)



lab@mxA-1> show route advertising-protocol bgp 192.168.5.2

vpn1-a.inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 10.0.10.0/24 Self 100 I* 172.10.0.0/24 Self 100 65101 I* 172.10.1.0/24 Self 100 65101 I* 172.10.2.0/24 Self 100 65101 I* 172.10.3.0/24 Self 100 65101 I* 192.168.11.1/32 Self 100 65101 I

Note

Check with the team configuring the remote CE router and ensure that they have completed Step 7.2 before proceeding to the next step.

Junos MPLS and VPNs


vpn1-b.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 10.1.10.0/24 Not advertised 100 I

lab@mxA-1> show route receive-protocol bgp 192.168.5.2





vpn1-a.inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 10.0.11.0/24 192.168.1.2 100 I* 172.10.4.0/24 192.168.1.2 100 65101 I* 172.10.5.0/24 192.168.1.2 100 65101 I* 172.10.6.0/24 192.168.1.2 100 65101 I* 172.10.7.0/24 192.168.1.2 100 65101 I* 192.168.11.2/32 192.168.1.2 100 65101 I



bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 192.168.1.2:7:10.0.11.0/24 * 192.168.1.2 100 I 192.168.1.2:7:172.10.4.0/24 * 192.168.1.2 100 65101 I 192.168.1.2:7:172.10.5.0/24 * 192.168.1.2 100 65101 I 192.168.1.2:7:172.10.6.0/24 * 192.168.1.2 100 65101 I 192.168.1.2:7:172.10.7.0/24 * 192.168.1.2 100 65101 I 192.168.1.2:7:192.168.11.2/32 * 192.168.1.2 100 65101 I




ce1-1.inet.0: 13 destinations, 18 routes (13 active, 0 holddown, 5 hidden) Prefix Nexthop MED Lclpref AS path* 10.0.11.0/24 10.0.10.1 65512 I* 172.10.4.0/24 10.0.10.1 65512 65512 I* 172.10.5.0/24 10.0.10.1 65512 65512 I* 172.10.6.0/24 10.0.10.1 65512 65512 I

Junos MPLS and VPNs


* 172.10.7.0/24 10.0.10.1 65512 65512 I* 192.168.11.2/32 10.0.10.1 65512 65512 I


vpn1-a.inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)






Question: Are you receiving the routes from you CE router?

Answer: Yes, you should see the static routes and the route for the loopback interface.

Question: Are you sending the routes you learned from your CE router to the route reflector?

Answer: Yes, you should be advertising the CE routes to the route reflector.

Question: Are you receiving the routes being sent from the remote PE router for the remote CE network?

Answer: Yes, you should see the static route and loopback route from the remote CE network.

Junos MPLS and VPNs


Question: Are you receiving these routes at your CE router?

Answer: Yes, you should see the routes from the remote CE router on you local CE router.

Question: Did the ping test complete?

Answer: Yes, your pings should complete.

Step 7.4

Enter into configuration mode and navigate to the [edit routing-instances vpnx-b protocols bgp] hierarchy. Create an external group named my-ext-group-b and specify your neighbor address. You must also define your peer-as. Remember to add the option as-override to your BGP group, because both the local CE router and the remote CE router are in the same AS. Review your configuration and commit before proceeding to the next step.


[edit]lab@mxA-1# edit routing-instances vpnx-b protocols bgp

[edit routing-instances vpn1-b protocols bgp]lab@mxA-1# set group my-ext-group-b type external

[edit routing-instances vpn1-b protocols bgp]lab@mxA-1# set group my-ext-group-b neighbor 10.1.xy.2

[edit routing-instances vpn1-b protocols bgp]lab@mxA-1# set group my-ext-group-b peer-as 65x02

[edit routing-instances vpn1-b protocols bgp]lab@mxA-1# set group my-ext-group-b as-override

Note

If you are not receiving or sending any of the routes from the previous step, please review your configuration and work with the remote team for your pod. Request assistance from the instructor as needed.

Junos MPLS and VPNs


[edit routing-instances vpn1-b protocols bgp]lab@mxA-1# show group my-ext-group-b { type external; peer-as 65102; as-override; neighbor 10.1.10.2;}

[edit routing-instances vpn1-b protocols bgp]lab@mxA-1# commit commit complete

Step 7.5

Navigate to the [edit routing-instances cex-y protocols bgp] hierarchy, where cex-y is your CE router connected to your VPNx-b instance. Create an external group named my-ext-group and specify your neighbor address. You must also define your peer-as. Apply the policy exp-policy that you created in Lab 6, as an export policy to your EBGP group. Review your configuration, commit, and exit to operational mode.

[edit routing-instances vpn1-b protocols bgp]lab@mxA-1# top edit routing-instances cex-y protocols bgp






[edit routing-instances ce1-3 protocols bgp]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Junos MPLS and VPNs


Step 7.6

Verify all routes are being sent and received at the CE router. Because you verified that you can pass routes through the VPN to the remote PE router in Step 7.3, you will start the verification steps on the CE router. If the routes do not appear on the CE router then you will move your investigation to the PE router. After verifying the routes are present on all your routers, verify reachability to the remote CE router by sending a ping to the loopback address 5 times. This task can be accomplished by issuing the ping 192.168.2x.y source 192.168.2x.y routing-instance cex-y count 5 command.


ce1-3.inet.0: 13 destinations, 18 routes (13 active, 0 holddown, 5 hidden) Prefix Nexthop MED Lclpref AS path* 10.1.10.0/24 Self I* 172.11.0.0/24 Self I* 172.11.1.0/24 Self I* 172.11.2.0/24 Self I* 172.11.3.0/24 Self I* 192.168.21.1/32 Self I





ce1-3.inet.0: 13 destinations, 18 routes (13 active, 0 holddown, 5 hidden) Prefix Nexthop MED Lclpref AS path* 10.1.11.0/24 10.1.10.1 65512 I* 172.11.4.0/24 10.1.10.1 65512 65512 I* 172.11.5.0/24 10.1.10.1 65512 65512 I* 172.11.6.0/24 10.1.10.1 65512 65512 I* 172.11.7.0/24 10.1.10.1 65512 65512 I* 192.168.21.2/32 10.1.10.1 65512 65512 I

vpn1-a.inet.0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)




Note

Check with the team configuring the remote CE router and ensure that they have completed Step 7.5 before proceeding to the next step.

Junos MPLS and VPNs




Question: Are you receiving the remote CE router’s routes on your CE router?

Answer: Yes, you should see the routes from the remote CE router on you local CE router. If you are not receiving or sending any of the routes from the previous step, please review your configuration and work with the remote team for your pod. Request assistance from the instructor as needed.

Question: Did the ping test complete?

Answer: Yes, your pings should complete. If your pings do not complete, review the addresses you are using and ensure the remote team is receiving your routes from your CE device. Request assistance from the instructor, if needed.


Part 8: Implementing Route Target Filtering

In this lab part, you will implement router filtering on your PE router. You will alter the secondary CE router’s vrf-target, to demonstrate the purpose of route target filtering at the route reflector. You will review the default route advertising behavior from the route reflector by utilizing the keep all option. You will configure the router to signal route target filtering and verify the route reflector is no longer sending you routes with target values for which your PE router is not configured.

Junos MPLS and VPNs


Step 8.1

Enter into configuration mode and navigate to the [edit routing-instances vpnx-b] hierarchy. Alter the vrf-target you have configured for this VPN. If you are configuring pe1, then you change your target to target:65512:x03. If you are configuring pe2 you will change you target to target:65512:x04. After making this configuration change, commit and exit to operational mode.


[edit]lab@mxA-1# edit routing-instances vpnx-b

[edit routing-instances vpn1-b]lab@mxA-1# set vrf-target target:65512:x0y

[edit routing-instances vpn1-b]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 8.2

Review the routes that you have accepted and installed in your bgp.l3vpn.0 routing table.

lab@mxA-1> show route table bgp.l3vpn.0

bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both

192.168.1.2:7:10.0.11.0/24 *[BGP/170] 00:13:11, localpref 100, from 192.168.5.2 AS path: I to 172.22.210.2 via ge-1/0/0.210, Push 299968, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 299968, Push 303760(top)192.168.1.2:7:172.10.4.0/24 *[BGP/170] 00:13:11, localpref 100, from 192.168.5.2 AS path: 65101 I

Note

Your routes will be advertised to the route reflector, but when you receive the routes for the remote CE router, your PE router will evaluate the target value against the targets configured for your VPNs and reject the routes that do not match the local target values.

Junos MPLS and VPNs


to 172.22.210.2 via ge-1/0/0.210, Push 299968, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 299968, Push 303760(top)192.168.1.2:7:172.10.5.0/24 *[BGP/170] 00:13:11, localpref 100, from 192.168.5.2 AS path: 65101 I to 172.22.210.2 via ge-1/0/0.210, Push 299968, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 299968, Push 303760(top)192.168.1.2:7:172.10.6.0/24 *[BGP/170] 00:13:11, localpref 100, from 192.168.5.2 AS path: 65101 I to 172.22.210.2 via ge-1/0/0.210, Push 299968, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 299968, Push 303760(top)192.168.1.2:7:172.10.7.0/24 *[BGP/170] 00:13:11, localpref 100, from 192.168.5.2 AS path: 65101 I to 172.22.210.2 via ge-1/0/0.210, Push 299968, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 299968, Push 303760(top)192.168.1.2:7:192.168.11.2/32 *[BGP/170] 00:13:11, localpref 100, from 192.168.5.2 AS path: 65101 I to 172.22.210.2 via ge-1/0/0.210, Push 299968, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 299968, Push 303760(top)

Question: Do you see the vpnx-b routes for the remote CE router?

Answer: No, You should not see the routes. You should not have routes with the prefixes 172.x1.y.0/24 or the remote CE loopback value of 192.168.2x.y.

Step 8.3

Enter configuration mode and navigate to the [edit protocols bgp] hierarchy. Enable the keep all functionality for your BGP session. This functionality will cause the PE router to keep all VPN routes that are advertised to it from the route reflector, regardless of vrf-target value. Commit your configuration changes and exit to operational mode.

Junos MPLS and VPNs




[edit protocols bgp]lab@mxA-1# set keep all

[edit protocols bgp]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 8.4

Review the routes that you have accepted and installed in your bgp.l3vpn.0 routing table after adding the keep all functionality.



192.168.1.2:7:10.0.11.0/24 *[BGP/170] 00:00:01, localpref 100, from 192.168.5.2 AS path: I to 172.22.210.2 via ge-1/0/0.210, Push 300000, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 300000, Push 303760(top)192.168.1.2:7:172.10.4.0/24 *[BGP/170] 00:00:01, localpref 100, from 192.168.5.2 AS path: 65101 I to 172.22.210.2 via ge-1/0/0.210, Push 300000, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 300000, Push 303760(top)192.168.1.2:7:172.10.5.0/24 *[BGP/170] 00:00:01, localpref 100, from 192.168.5.2 AS path: 65101 I to 172.22.210.2 via ge-1/0/0.210, Push 300000, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 300000, Push 303760(top)192.168.1.2:7:172.10.6.0/24 *[BGP/170] 00:00:01, localpref 100, from 192.168.5.2 AS path: 65101 I to 172.22.210.2 via ge-1/0/0.210, Push 300000, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 300000, Push 303760(top)192.168.1.2:7:172.10.7.0/24 *[BGP/170] 00:00:01, localpref 100, from 192.168.5.2

Junos MPLS and VPNs


AS path: 65101 I to 172.22.210.2 via ge-1/0/0.210, Push 300000, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 300000, Push 303760(top)192.168.1.2:7:192.168.11.2/32 *[BGP/170] 00:00:01, localpref 100, from 192.168.5.2 AS path: 65101 I to 172.22.210.2 via ge-1/0/0.210, Push 300000, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 300000, Push 303760(top)192.168.1.2:8:10.1.11.0/24 *[BGP/170] 00:00:01, localpref 100, from 192.168.5.2 AS path: I > to 172.22.210.2 via ge-1/0/0.210, Push 300016, Push 307264(top) to 172.22.211.2 via ge-1/0/1.211, Push 300016, Push 303760(top)192.168.1.2:8:172.11.4.0/24 *[BGP/170] 00:00:01, localpref 100, from 192.168.5.2 AS path: 65102 I > to 172.22.210.2 via ge-1/0/0.210, Push 300016, Push 307264(top) to 172.22.211.2 via ge-1/0/1.211, Push 300016, Push 303760(top)192.168.1.2:8:172.11.5.0/24 *[BGP/170] 00:00:01, localpref 100, from 192.168.5.2 AS path: 65102 I > to 172.22.210.2 via ge-1/0/0.210, Push 300016, Push 307264(top) to 172.22.211.2 via ge-1/0/1.211, Push 300016, Push 303760(top)192.168.1.2:8:172.11.6.0/24 *[BGP/170] 00:00:01, localpref 100, from 192.168.5.2 AS path: 65102 I > to 172.22.210.2 via ge-1/0/0.210, Push 300016, Push 307264(top) to 172.22.211.2 via ge-1/0/1.211, Push 300016, Push 303760(top)192.168.1.2:8:172.11.7.0/24 *[BGP/170] 00:00:01, localpref 100, from 192.168.5.2 AS path: 65102 I > to 172.22.210.2 via ge-1/0/0.210, Push 300016, Push 307264(top) to 172.22.211.2 via ge-1/0/1.211, Push 300016, Push 303760(top)192.168.1.2:8:192.168.21.2/32 *[BGP/170] 00:00:01, localpref 100, from 192.168.5.2 AS path: 65102 I > to 172.22.210.2 via ge-1/0/0.210, Push 300016, Push 307264(top) to 172.22.211.2 via ge-1/0/1.211, Push 300016, Push 303760(top)

Junos MPLS and VPNs



Answer: Yes, You should see the routes even though they do not match any of your locally configured target values. You should see the routes with prefixes of 172.x1.y.0/24 and the remote CE loopback value of 192.168.2x.y.

Step 8.5

Enter into configuration mode and navigate to the [edit protocols bgp] hierarchy. Configure your router to signal the route target NLRI for the IBGP session to the route reflector.



[edit protocols bgp]lab@mxA-1# set group my-int-group family route-target

Step 8.6

Review the routes that you have accepted and installed in your bgp.l3vpn.0 routing table after configuring the PE router to implement the route target filtering NLRI to the route reflector.



192.168.1.2:7:10.0.11.0/24 *[BGP/170] 00:13:11, localpref 100, from 192.168.5.2 AS path: I to 172.22.210.2 via ge-1/0/0.210, Push 299968, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 299968, Push 303760(top)192.168.1.2:7:172.10.4.0/24 *[BGP/170] 00:13:11, localpref 100, from 192.168.5.2 AS path: 65101 I to 172.22.210.2 via ge-1/0/0.210, Push 299968, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 299968, Push 303760(top)192.168.1.2:7:172.10.5.0/24 *[BGP/170] 00:13:11, localpref 100, from 192.168.5.2 AS path: 65101 I

Junos MPLS and VPNs


to 172.22.210.2 via ge-1/0/0.210, Push 299968, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 299968, Push 303760(top)192.168.1.2:7:172.10.6.0/24 *[BGP/170] 00:13:11, localpref 100, from 192.168.5.2 AS path: 65101 I to 172.22.210.2 via ge-1/0/0.210, Push 299968, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 299968, Push 303760(top)192.168.1.2:7:172.10.7.0/24 *[BGP/170] 00:13:11, localpref 100, from 192.168.5.2 AS path: 65101 I to 172.22.210.2 via ge-1/0/0.210, Push 299968, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 299968, Push 303760(top)192.168.1.2:7:192.168.11.2/32 *[BGP/170] 00:13:11, localpref 100, from 192.168.5.2 AS path: 65101 I to 172.22.210.2 via ge-1/0/0.210, Push 299968, Push 307264(top) > to 172.22.211.2 via ge-1/0/1.211, Push 299968, Push 303760(top)


Answer: No, You should not see the routes. You should not have routes with the prefixes 172.x1.y.0/24 or the remote CE loopback value of 192.168.2x.y. If you do not see anything, wait a couple minutes and retry the command. It might take some time for the route table to refresh and for you to see routes in the table.

Part 9: Configuring Internet Access Using a Non-VRF Interface

In this lab part, you will establish Internet access for your CE router connected to the vpnx-a instance. You will create another logical unit on the same physical interface connecting the CE router to the PE router. You will create a static default route on the CE router that points to the PE router’s non-VRF interface as the next hop. You will configure the PE router’s non-VRF interface as passive in your IGP, to allow reachability to the CE router from the core network. You will ping one of the core router’s loopback interfaces from your CE device to simulate connectivity to the Internet (networks outside the VPN instance).

Junos MPLS and VPNs


Step 9.1

Enter configuration mode and navigate to the [edit interface] hierarchy. Refer to the lab diagram titled “Lab 8: Part 9—Layer 3 VPN Scaling and Internet Access”. Configure the additional logical unit, VLAN, and IP address for both the CE router interface and the PE router interface.



[edit interfaces]lab@mxA-1# set ge-1/0/4 unit x00 vlan-id x00 family inet address 10.2.xy.1/24

[edit interfaces]lab@mxA-1# set ge-1/1/4 unit x00 vlan-id x00 family inet address 10.2.xy.2/24

Step 9.2

Navigate to the [edit routing-instances cex-y] hierarchy and add the non-VRF interface. Configure a static default route that points to the non-vrf interface address as the next hop.

[edit interfaces]lab@mxA-1# top edit routing-instances cex-y

[edit routing-instances ce1-1]lab@mxA-1# set interface ge-1/1/4.x00

[edit routing-instances ce1-1]lab@mxA-1# set routing-options static route 0/0 next-hop 10.2.xy.1

Step 9.3

Navigate to the [edit routing-options] hierarchy and create a static route on your PE router that encompasses all of your static routes on your CE router in a single prefix (172.x0.y.0/22). The next hop for this route will be the CE interface address for the non-VRF connection. You will also need to add your CE router’s loopback address as a static route with the same next hop.

[edit routing-instances ce1-1]lab@mxA-1# top edit routing-options

[edit routing-options]lab@mxA-1# set static route 172.x0.y.0/22 next-hop 10.2.xy.2

[edit routing-options]lab@mxA-1# set static route 192.168.1x.y next-hop 10.2.xy.2

Junos MPLS and VPNs


Step 9.4

Navigate to the [edit policy-options] hierarchy. Create a policy named statics that will be used to redistribute your static routes into OSPF.

[edit routing-options]lab@mxA-1# top edit policy-options

[edit policy-options]lab@mxA-1# set policy-statement statics term 10 from protocol static

[edit policy-options]lab@mxA-1# set policy-statement statics term 10 then accept

Step 9.5

Navigate to the [edit protocols ospf] hierarchy and add the non-VRF interface as passive. Export the static routes you created in the previous step into your IGP by using the policy static. This action allows the IGP to route traffic back to the CE network through the non-VRF connection. Commit your changes and exit to operational mode.

[edit policy-options]lab@mxA-1# top edit protocols ospf

[edit protocols ospf]lab@mxA-1# set area 0 interface ge-1/0/4.x00 passive

[edit protocols ospf]lab@mxA-1# set export statics

[edit protocols ospf]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 9.6

Verify that you can ping the loopback address of one of the core routers five times, sourced from your CE router’s loopback address. You can review one of the network diagrams that outline the core network if you do not recall the loopback addresses of the core routers. In the example provided, the ping is destined to P6’s loopback, sourced from the CE router’s loopback.

lab@mxA-1> ping 192.168.5.6 source 192.168.1x.y routing-instance cex-y count 5 PING 192.168.5.6 (192.168.5.6): 56 data bytes64 bytes from 192.168.5.6: icmp_seq=0 ttl=61 time=0.619 ms64 bytes from 192.168.5.6: icmp_seq=1 ttl=61 time=0.678 ms64 bytes from 192.168.5.6: icmp_seq=2 ttl=61 time=0.559 ms64 bytes from 192.168.5.6: icmp_seq=3 ttl=61 time=0.554 ms64 bytes from 192.168.5.6: icmp_seq=4 ttl=61 time=0.546 ms


Junos MPLS and VPNs


Question: Do the ping requests complete?

Answer: Yes, the pings should complete. If they do not, please review your configuration and request assistance from your instructor as needed.


Junos MPLS and VPNs


www.juniper.net GRE Tunnel Integration (Detailed) • Lab 9–110.a.10.3R1.9

Lab 9GRE Tunnel Integration (Detailed)

Overview

In this lab, you will establish a point-to-point Layer 3 virtual private network (VPN) using a generic routing encapsulation (GRE) tunnel between provider edge (PE) routers. You will also configure OSPF routing between your PE and customer edge (CE) router. You will share your routes with the remote PE through the Layer 3 VPN using Multiprotocol Border Gateway Protocol (MP-BGP).




• Configure a VPN routing and forwarding (VRF) table and OSPF routing between your PE router and CE router and redistribute your CE router’s static routes into OSPF.

• Configure a GRE tunnel to the remote PE router.

• Create and add a static route to inet.3.

• Redistribute the MP-BGP routes learned from the remote PE into OSPF.

• Verify connectivity and behavior using operational mode commands including ping and commands used to examine routing tables, and PE-PE BGP announcements.

Junos MPLS and VPNs

Lab 9–2 • GRE Tunnel Integration (Detailed) www.juniper.net


In this lab part, you will load the VPN baseline configuration you saved in Lab 6. After loading the configuration you will verify the core network is operating as expected. You will review the CE instance configuration so you are familiar with the contents.

Step 1.1

Enter into configuration mode and load the VPN baseline configuration by executing the load override jmv-RouterName-vpn-baseline command. Commit your configuration changes and exit to operational mode.


[edit]lab@mxB-1# load override jmv-RouterName-vpn-baseline load complete


lab@mxB-1>

Step 1.2

Verify that your OSPF and BGP neighborships are established correctly.


lab@mxB-1> show bgp summary Groups: 1 Peers: 1 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0bgp.l3vpn.0 0 0 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...192.168.2.2 65512 264 259 0 1 1:52:47 Establ inet.0: 0/0/0/0 bgp.l3vpn.0: 0/0/0/0

Junos MPLS and VPNs

www.juniper.net GRE Tunnel Integration (Detailed) • Lab 9–3




Answer: Yes, your BGP neighborship should be up and working. If they are not, please review your configuration and ensure the remote team has completed Step 1.1. Please request assistance from your instructor, if needed.

Step 1.3



[edit]lab@mxB-1# show routing-instances cex-y instance-type virtual-router;interface ge-1/1/4.620;interface lo0.1;routing-options { static { route 172.10.0.0/24 reject; route 172.10.1.0/24 reject; route 172.10.2.0/24 reject; route 172.10.3.0/24 reject; } autonomous-system 65201;}

Question: Which type of instance is being used.


Junos MPLS and VPNs


Question: How may static routes are configured for this instance?



In this lab part, you will configure the PE to CE interface. You will verify reachability using the ping utility.

Step 2.1

Enter into configuration mode and navigate to the [edit interfaces] hierarchy. Configure the appropriate interface properties found on the Lab 9 network diagram. Commit your change and exit to operational mode to verify reachability to the CE interface.



[edit interfaces]lab@mxB-1# set ge-1/0/4 vlan-tagging unit 6x0 vlan-id 6x0 family inet address 10.0.xy.1/24

[edit interfaces]lab@mxB-1# commit and-quit commit completeExiting configuration mode

lab@mxB-1>

Step 2.2

Verify connectivity to the CE device using the ping utility with a count value of 3.

lab@mxB-1> ping 10.0.xy.2 count 3 PING 10.0.10.2 (10.0.10.2): 56 data bytes64 bytes from 10.0.10.2: icmp_seq=0 ttl=64 time=0.502 ms64 bytes from 10.0.10.2: icmp_seq=1 ttl=64 time=0.426 ms64 bytes from 10.0.10.2: icmp_seq=2 ttl=64 time=0.434 ms


Junos MPLS and VPNs


Question: Does your ping complete?

Answer: Yes, your ping should complete. If they do not, please review your configuration and request assistance from your instructor, if needed.

Part 3: Configuring a Layer 3 VPN Instance

In this lab part, you will configure a Layer 3 VPN instance. You will assign a unique route target to the VPN. You will include your CE-facing interface within this instance. In this lab, you will be using the vrf-target option because of its simplicity. Please note that vrf-import and vrf-export policies would work also.

Step 3.1

Enter into configuration mode and navigate to the [edit routing-instances] hierarchy. Create a new VRF instance named vpn-x.



[edit routing-instances]lab@mxB-1# set vpn-x instance-type vrf

Step 3.2

Navigate to the [edit routing-instances vpn-x] hierarchy. Configure your route target. As mentioned earlier, you will be using the vrf-target option. Your target will contain the local autonomous system (AS) number and will be uniquely identified by using your pod value. The format for defining you vrf-target is: target:65512:x.

[edit routing-instances]lab@mxB-1# edit vpn-x

[edit routing-instances vpn-2]lab@mxB-1# set vrf-target target:65512:x

Step 3.3

Include the CE-facing interface in your VRF instance.

[edit routing-instances vpn-2]lab@mxB-1# set interface ge-1/0/4.6x0

Step 3.4

Review your recent configuration changes. When you are satisfied with these changes, commit your configuration and exit to operational mode.

Junos MPLS and VPNs


[edit routing-instances vpn-2]lab@mxB-1# show instance-type vrf;interface ge-1/0/4.620;vrf-target target:65512:2;

[edit routing-instances vpn-2]lab@mxB-1# commit and-quit commit completeExiting configuration mode

lab@mxB-1>

Step 3.5

Verify that your VRF routing table has been created and it contains the local and direct routes for your CE-facing interface. You can accomplish this task by issuing the show route table vpn-x.inet.0 command.

lab@mxB-1> show route table vpn-x



Question: Do you see your local and direct routes?

Answer: You should see a local route for the interface you configured (10.0.xy.1/32) and a direct route for the network attached to that interface (10.0.xy.0/24). If you do not see these routes, please review your configuration and request assistance from your instructor, if needed.

Part 4: Configuring OSPF Routing Between the PE and CE Routers

In this lab part, you will configure OSPF routing between your PE and CE routers. These routes will be passed through the MP-BGP session to the remote PE router. You will verify that these routes are shared with the remote PE device and you will also need to verify that you are receiving the routes from the remote PE router.

Step 4.1

Enter into configuration mode and navigate to the [edit policy-options] hierarchy. Create a policy named statics that will be used to redistribute your CE router’s static routes into OSPF.

Junos MPLS and VPNs



[edit]lab@mxB-1# edit policy-options

[edit policy-options]lab@mxB-1# set policy-statement statics term 10 from protocol static

[edit policy-options]lab@mxB-1# set policy-statement statics term 10 then accept

Step 4.2

Navigate to the [edit routing-instances cex-y] hierarchy. Configure your CE router’s loopback and Ethernet interfaces as OSPF area 0.0.0.0 interfaces.

[edit policy-options]lab@mxB-1# top edit routing-instances cex-y

[edit routing-instances ce2-1]lab@mxB-1# set protocols ospf area 0 interface lo0.1

[edit routing-instances ce2-1]lab@mxB-1# set protocols ospf area 0 interface ge-1/1/4.6x0

Step 4.3

Apply the statics policy as an export policy to your CE router’s OSPF instance.

[edit routing-instances ce2-1]lab@mxB-1# set protocols ospf export statics

Step 4.4

Navigate to the [edit routing-instances vpn-x] hierarchy. Configure you PE router’s VRF interface an OSPF area 0.0.0.0 interface. Commit your configuration and exit to operational mode.

[edit routing-instances ce2-1]lab@mxB-1# top edit routing-instances vpn-x

[edit routing-instances vpn-2]lab@mxB-1# set protocols ospf area 0 interface ge-1/0/4.6x0


Step 4.5

Verify that the CE router and PE router have established an OSPF adjacency with each other.

lab@mxB-1> show ospf neighbor instance cex-y Address Interface State ID Pri Dead10.0.20.1 ge-1/1/4.620 Full 10.0.20.1 128 35

Junos MPLS and VPNs


Question: Has the CE router established an OSPF adjacency with the local PE router?

Answer: The CE router should have established an adjacency with the local PE router. If you do not see that the neighbor relationship is in a full state, please review your configuration and request assistance from your instructor, if needed.

Step 4.6

Verify that the static routes that are being redistributed by the CE router can be found in the VRF table of the PE router.



10.0.20.0/24 *[Direct/0] 00:36:22 > via ge-1/0/4.62010.0.20.1/32 *[Local/0] 00:36:22 Local via ge-1/0/4.620172.20.0.0/24 *[OSPF/150] 00:07:09, metric 0, tag 0 > to 10.0.20.2 via ge-1/0/4.620172.20.1.0/24 *[OSPF/150] 00:07:09, metric 0, tag 0 > to 10.0.20.2 via ge-1/0/4.620172.20.2.0/24 *[OSPF/150] 00:07:09, metric 0, tag 0 > to 10.0.20.2 via ge-1/0/4.620172.20.3.0/24 *[OSPF/150] 00:07:09, metric 0, tag 0 > to 10.0.20.2 via ge-1/0/4.620192.168.12.1/32 *[OSPF/10] 00:22:05, metric 1 > to 10.0.20.2 via ge-1/0/4.620224.0.0.5/32 *[OSPF/10] 00:22:55, metric 1 MultiRecv

Question: Are the static routes from the local CE router being received by your PE router as OSPF routes?

Answer: The PE router should have the 172.X0/16 routes in the VRF table as OSPF routes. If you do not see these routes, please review your policy configuration on the CE router and request assistance from your instructor, if needed.

Junos MPLS and VPNs


Step 4.7

Verify that you are advertising your OSPF routes to the remote PE router as BGP routes.

lab@mxB-1> show route advertising-protocol bgp 192.168.x.y

vpn-2.inet.0: 14 destinations, 14 routes (8 active, 0 holddown, 6 hidden) Prefix Nexthop MED Lclpref AS path* 10.0.20.0/24 Self 100 I* 172.20.0.0/24 Self 0 100 I* 172.20.1.0/24 Self 0 100 I* 172.20.2.0/24 Self 0 100 I* 172.20.3.0/24 Self 0 100 I* 192.168.12.1/32 Self 1 100 I

Question: What routes are being advertised to the remote PE router?

Answer: You should see the PE-CE network, the four 172.X0/16 routes, and the loopback address for the CE device. If you do not see these routes, please review your configuration and request assistance from your instructor, if needed.

Step 4.8

Verify that you are receiving routes from the remote PE router.

lab@mxB-1> show route receive-protocol bgp 192.168.x.y






Question: What routes are you receiving from the remote PE router?

Answer: You should notice that no BGP routes are being stored in the VRF table.

Junos MPLS and VPNs


Question: Why are no BGP routes being stored in the VRF table?

Answer: The routes are hidden due to a missing route to the remote PE router’s loopback in inet.3.

Step 4.9

Determine whether any hidden routes are being received from the remote PE router.

lab@mxB-1> show route hidden



10.0.21.0/24 [BGP/170] 00:49:21, localpref 100, from 192.168.2.2 AS path: I Unusable172.20.4.0/24 [BGP/170] 00:49:21, MED 0, localpref 100, from 192.168.2.2 AS path: I Unusable172.20.5.0/24 [BGP/170] 00:49:21, MED 0, localpref 100, from 192.168.2.2 AS path: I Unusable172.20.6.0/24 [BGP/170] 00:49:21, MED 0, localpref 100, from 192.168.2.2 AS path: I Unusable172.20.7.0/24 [BGP/170] 00:49:21, MED 0, localpref 100, from 192.168.2.2 AS path: I Unusable192.168.12.2/32 [BGP/170] 00:49:21, MED 1, localpref 100, from 192.168.2.2 AS path: I Unusable




192.168.2.2:27:10.0.21.0/24 [BGP/170] 00:49:21, localpref 100, from 192.168.2.2 AS path: I Unusable192.168.2.2:27:172.20.4.0/24 [BGP/170] 00:49:21, MED 0, localpref 100, from 192.168.2.2 AS path: I Unusable

Junos MPLS and VPNs


192.168.2.2:27:172.20.5.0/24 [BGP/170] 00:49:21, MED 0, localpref 100, from 192.168.2.2 AS path: I Unusable192.168.2.2:27:172.20.6.0/24 [BGP/170] 00:49:21, MED 0, localpref 100, from 192.168.2.2 AS path: I Unusable192.168.2.2:27:172.20.7.0/24 [BGP/170] 00:49:21, MED 0, localpref 100, from 192.168.2.2 AS path: I Unusable192.168.2.2:27:192.168.12.2/32 [BGP/170] 00:49:21, MED 1, localpref 100, from 192.168.2.2 AS path: I Unusable

Question: Are any hidden routes being received from the remote PE router? Why are the routes hidden?

Answer: The routes are hidden because no routes are in inet.3. The next hop is listed as unusable. There is a requirement that a route to the remote PE router’s loopback exists in inet.3. Remember that we have not yet configured an MPLS LSP which would install the necessary route.

Part 5: Establishing a GRE Tunnel Between PE Routers

In this lab part, you will configure a GRE tunnel between the PE routers.

Step 5.1

Enter configuration mode and navigate to the [edit chassis] hierarchy. Enable 1 Gbps tunnel service on FPC 1/PIC 0.


[edit]lab@mxB-1# edit chassis

[edit chassis]lab@mxB-1# set fpc 1 pic 0 tunnel-services bandwidth 1g

Junos MPLS and VPNs


Step 5.2

Navigate to the [edit interfaces] hierarchy and configure a tunnel interface named gr-1/0/10.0. The interface should source packets from the local PE router’s loopback address. The interface should be configured to send packets destined to the remote PE router’s loopback address. Finally, enable forwarding of MPLS and IPv4 traffic on the tunnel interface. Commit your configuration and exit to operational mode.

[edit chassis]lab@mxB-1# top edit interfaces

[edit interfaces]lab@mxB-1# set gr-1/0/10 unit 0 tunnel source 192.168.x.y

[edit interfaces]lab@mxB-1# set gr-1/0/10 unit 0 tunnel destination 192.168.x.y

[edit interfaces]lab@mxB-1# set gr-1/0/10 unit 0 family inet

[edit interfaces]lab@mxB-1# set gr-1/0/10 unit 0 family mpls


Step 5.3

Verify that the GRE interface is up and functional.

lab@mxB-1> show interfaces gr-1/0/10 terse Interface Admin Link Proto Local Remotegr-1/0/10 up up gr-1/0/10.0 up up inet mpls

Question: Is the gr-1/0/10 interface in the up state?

Answer: The tunnel interface should be in the up state. If not, check your configuration and ask your instructor for help, if needed.

Junos MPLS and VPNs


Part 6: Creating and Adding a Static Route to inet.3

Step 6.1

Enter configuration mode and navigate to the [edit routing-options] hierarchy. Create a static route to the loopback address of the remote PE router that will exist only in inet.3 and has a next hop of the gr-1/0/10.0 interface. Commit your configuration and exit to operational mode.


[edit]lab@mxB-1# edit routing-options

[edit routing-options]lab@mxB-1# set rib inet.3 static route 192.168.x.y/32 next-hop gr-1/0/10.0

[edit routing-options]lab@mxB-1# commit and-quit commit completeExiting configuration mode

Step 6.2

Verify that the new static route exists in inet.3 and only inet.3.

lab@mxB-1> show route 192.168.x.y


192.168.2.2/32 *[OSPF/10] 03:48:15, metric 4 > to 172.22.220.2 via ge-1/0/0.220 to 172.22.221.2 via ge-1/0/1.221


192.168.2.2/32 *[Static/5] 00:00:07 > via gr-1/0/10.0

Question: In which routing table has the static route been placed?

Answer: The route should only be in the inet.3 table. If not, check your configuration and ask your instructor for help if needed.

Junos MPLS and VPNs


Step 6.3

Review the routes that are installed in your VRF table.



10.0.20.0/24 *[Direct/0] 01:50:17 > via ge-1/0/4.62010.0.20.1/32 *[Local/0] 01:50:17 Local via ge-1/0/4.62010.0.21.0/24 *[BGP/170] 00:05:32, localpref 100, from 192.168.2.2 AS path: I > via gr-1/0/10.0, Push 299792172.20.0.0/24 *[OSPF/150] 01:21:04, metric 0, tag 0 > to 10.0.20.2 via ge-1/0/4.620172.20.1.0/24 *[OSPF/150] 01:21:04, metric 0, tag 0 > to 10.0.20.2 via ge-1/0/4.620172.20.2.0/24 *[OSPF/150] 01:21:04, metric 0, tag 0 > to 10.0.20.2 via ge-1/0/4.620172.20.3.0/24 *[OSPF/150] 01:21:04, metric 0, tag 0 > to 10.0.20.2 via ge-1/0/4.620172.20.4.0/24 *[BGP/170] 00:05:32, MED 0, localpref 100, from 192.168.2.2 AS path: I > via gr-1/0/10.0, Push 299792172.20.5.0/24 *[BGP/170] 00:05:32, MED 0, localpref 100, from 192.168.2.2 AS path: I > via gr-1/0/10.0, Push 299792172.20.6.0/24 *[BGP/170] 00:05:32, MED 0, localpref 100, from 192.168.2.2 AS path: I > via gr-1/0/10.0, Push 299792172.20.7.0/24 *[BGP/170] 00:05:32, MED 0, localpref 100, from 192.168.2.2 AS path: I > via gr-1/0/10.0, Push 299792192.168.12.1/32 *[OSPF/10] 01:36:00, metric 1 > to 10.0.20.2 via ge-1/0/4.620192.168.12.2/32 *[BGP/170] 00:05:32, MED 1, localpref 100, from 192.168.2.2 AS path: I > via gr-1/0/10.0, Push 299792224.0.0.5/32 *[OSPF/10] 01:36:50, metric 1 MultiRecv

Question: Do you see all the remote PE routes?

Answer: Yes, you should see all the remote PE routes.

Junos MPLS and VPNs


Question: What is the next hop for the routes that have been received from the remote PE router?

Answer: The next hop should be the gr-1/0/10.0 interface.

Step 6.4

Verify that you have connectivity from CE router to CE router through the Layer 3 VPN by using the ping utility. You will ping the remote CE router’s loopback address while sourcing the packets from your local CE router’s loopback address. You will send five packets for this test. This task can be accomplished using the following command: ping 192.168.1x.y source 192.168.1x.y routing-instance cex-y count 5 .

lab@mxB-1> ping 192.168.1x.y routing-instance cex-y count 5 PING 192.168.12.2 (192.168.12.2): 56 data bytesping: sendto: No route to hostping: sendto: No route to hostping: sendto: No route to hostping: sendto: No route to hostping: sendto: No route to host^C--- 192.168.12.2 ping statistics ---5 packets transmitted, 0 packets received, 100% packet loss

Question: Do all your ping packets complete? Can you think of a reason why they would not complete?

Answer: No, they should not succeed. Go through the next few steps of the lab to determine why they do not succeed.

Step 6.5

Review the routes that are installed in the CE router’s routing table.

lab@mxB-1> show route table cex-y


10.0.20.0/24 *[Direct/0] 04:00:04 > via ge-1/1/4.62010.0.20.2/32 *[Local/0] 04:00:04 Local via ge-1/1/4.620172.20.0.0/24 *[Static/5] 04:00:07 Reject172.20.1.0/24 *[Static/5] 04:00:07

Junos MPLS and VPNs


Reject172.20.2.0/24 *[Static/5] 04:00:07 Reject172.20.3.0/24 *[Static/5] 04:00:07 Reject192.168.12.1/32 *[Direct/0] 04:00:05 > via lo0.1224.0.0.5/32 *[OSPF/10] 01:42:45, metric 1 MultiRecv

Question: Do you see all the remote routes?

Answer: No, the remote routes should not exist in the CE router’s routing table.

Step 6.6

Review the LSAs that currently exist in the CE router’s link state database.

lab@mxB-1> show ospf database instance cex-y

OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 10.0.20.1 10.0.20.1 0x80000008 1004 0x22 0x1b92 36Router *192.168.12.1 192.168.12.1 0x80000009 1003 0x22 0xd79d 48Network *10.0.20.2 192.168.12.1 0x80000005 130 0x22 0x40c9 32 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern *172.20.0.0 192.168.12.1 0x80000003 1899 0x22 0xe098 36Extern *172.20.1.0 192.168.12.1 0x80000003 1472 0x22 0xd5a2 36Extern *172.20.2.0 192.168.12.1 0x80000003 1008 0x22 0xcaac 36Extern *172.20.3.0 192.168.12.1 0x80000003 545 0x22 0xbfb6 36

Question: Why do you think the remote networks are not present in your CE router’s link state database?

Answer: This answer will vary by student.

Junos MPLS and VPNs


Question: How are the routes learned from the remote PE routers? How are these routes characterized in your PE router’s VRF table? What protocol is running on the PE/CE link?

Answer: The routes from the remote PE router are learned through BGP. The routes appear as BGP routes in the PE router’s routing table. OSPF is running on the PE/CE link.

Question: Will the default OSPF export policy advertise routes learned by BGP?

Answer: BGP routes are not redistributed into OSPF by default. You must create and apply a policy to the VRF instance of OSPF to cause the redistribution of the BGP routes into OSPF.


Part 7: Redistributing BGP Routes into OSPF

In this lab part, you will configure a routing policy that will take the BGP routes learned from the remote PE router and redistribute them into OSPF.

Step 7.1

Enter configuration mode and navigate to the [edit policy-options] hierarchy. Create a policy named bgp-to-ospf that will will be used to redistribute BGP routes into OSPF.


[edit]lab@mxB-1# edit policy-options

[edit policy-options]lab@mxB-1# set policy-statement bgp-to-ospf term 10 from protocol bgp

[edit policy-options]lab@mxB-1# set policy-statement bgp-to-ospf term 10 then accept

Junos MPLS and VPNs


Step 7.2

Navigate to [edit routing-instances vpn-x] and apply the bgp-to-ospf policy as an export policy to the VRF’s OSPF instance. Commit your configuration and exit to operational mode.

[edit policy-options]lab@mxB-1# top edit routing-instances vpn-x

[edit routing-instances vpn-2]

lab@mxB-1# set protocols ospf export bgp-to-ospf


Step 7.3

Review the LSAs that currently exist in the CE router’s link state database.

lab@mxB-1> show ospf database instance cex-y

OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 10.0.20.1 10.0.20.1 0x8000000d 1201 0x22 0x178f 36Router *192.168.12.1 192.168.12.1 0x8000000d 1683 0x22 0xcfa1 48Network *10.0.20.2 192.168.12.1 0x80000009 826 0x22 0x38cd 32Summary 192.168.12.2 10.0.20.1 0x80000004 1576 0xa2 0xce53 28 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern 10.0.21.0 10.0.20.1 0x80000005 826 0xa2 0xb67f 36Extern *172.20.0.0 192.168.12.1 0x80000008 397 0x22 0xd69d 36Extern *172.20.1.0 192.168.12.1 0x80000007 2540 0x22 0xcda6 36Extern *172.20.2.0 192.168.12.1 0x80000007 2111 0x22 0xc2b0 36Extern *172.20.3.0 192.168.12.1 0x80000007 1254 0x22 0xb7ba 36Extern 172.20.4.0 10.0.20.1 0x80000005 451 0xa2 0x3f51 36Extern 172.20.5.0 10.0.20.1 0x80000005 76 0xa2 0x345b 36Extern 172.20.6.0 10.0.20.1 0x80000004 2326 0xa2 0x2b64 36Extern 172.20.7.0 10.0.20.1 0x80000004 1951 0xa2 0x206e 36

Question: Do any LSAs exist in the OSPF link state database that represent the network from the remote site? Why or why not?

Answer: Yes, the networks should now exist in the link state database. These routes were redistributed from BGP into OSPF in the previous steps of the lab.

Junos MPLS and VPNs


Question: What LSA types are being used to represent the remote networks? Like what type of OSPF router is the PE router behaving?

Answer: The networks are being represented by External LSAs. The PE router is acting like an AS boundary router in this case.

Step 7.4

Verify that you have connectivity from CE router to CE router through the Layer 3 VPN by using the ping utility. You will ping the remote CE router’s loopback address while sourcing the packets from your local CE router’s loopback address. You will send five packets for this test. This task can be accomplished using the following command: ping 192.168.1x.y source 192.168.1x.y routing-instance cex-y count 5 .

lab@mxB-1> ping 192.168.1x.y routing-instance cex-y count 5 PING 192.168.12.2 (192.168.12.2): 56 data bytes64 bytes from 192.168.12.2: icmp_seq=0 ttl=62 time=0.646 ms64 bytes from 192.168.12.2: icmp_seq=1 ttl=62 time=0.581 ms64 bytes from 192.168.12.2: icmp_seq=2 ttl=62 time=0.574 ms64 bytes from 192.168.12.2: icmp_seq=3 ttl=62 time=0.523 ms64 bytes from 192.168.12.2: icmp_seq=4 ttl=62 time=0.573 ms



Answer: Yes, they should all complete. if they do not, please review your configuration and request assistance from your instructor, if needed.


Junos MPLS and VPNs


www.juniper.net BGP Layer 2 VPNs (Detailed) • Lab 10–110.a.10.3R1.9

Lab 10BGP Layer 2 VPNs (Detailed)

Overview

In this lab, you will establish a point-to-point BGP Layer 2 virtual private network (VPN) using LDP signaling between provider edge (PE) routers. Once the virtual LAN (VLAN)-based Layer 2 VPN is operational, you will configure the customer edge (CE) routers to run one of several available routing protocols and advertise their static route and loopback address blocks. Because this is a BGP Layer 2 VPN, the PE routers will not interact with the routing protocols used on the CE routers.




• Configure an LDP-signaled label-switched path (LSP) to the remote PE router.

• Add protocol BGP support for the Layer 2 VPN network layer reachability information (NLRI).

• Create and establish a BGP Layer 2 VPN over the core network.

• Add OSPF to your CE network and create a neighborship between your CE router and the remote CE router.

• Export your static routes into OSPF and share these routes with the remote CE network.

• Verify connectivity and behavior using operational mode commands including ping and commands used to examine routing tables.

Junos MPLS and VPNs

Lab 10–2 • BGP Layer 2 VPNs (Detailed) www.juniper.net


In this lab part, you will load the VPN baseline configuration you saved in Lab 6. After loading the configuration, you will verify that the core network is operating as expected. You will review the CE instance configuration so you are familiar with the contents.

Step 1.1

Enter configuration mode and load the VPN baseline configuration by executing the load override jmv-RouterName-vpn-baseline command. Commit your configuration changes and exit to operational mode.




lab@mxA-1>

Step 1.2




Junos MPLS and VPNs

www.juniper.net BGP Layer 2 VPNs (Detailed) • Lab 10–3





Step 1.3

Enter configuration mode. Review and familiarize yourself with the CE instance configuration.





Junos MPLS and VPNs


Question: How many static routes are configured for this instance?


Part 2: Establishing a LDP Signaled LSP Between PE Routers

In this lab part, you will use LDP to signal your LSP to the remote PE router. You will begin by adding your core-facing interface to the LDP protocol. You will then verify reachability through the LSP to the remote CE router. Please refer to the lab diagram titled “Lab 10: Parts 1-2—BGP Layer 2 VPN” for the appropriate core-facing interfaces.

Step 2.1

Navigate to the [edit protocols ldp] hierarchy. Add your two core-facing interfaces, as well as your loopback interface. Commit your configuration changes and exit to operational mode.


[edit protocols ldp]lab@mxA-1# set interface ge-1/0/0.2xy

[edit protocols ldp]lab@mxA-1# set interface ge-1/0/1.2xy

[edit protocols ldp]lab@mxA-1# set interface lo0.0


lab@mxA-1>

Step 2.2

Verify that LDP is established and has valid neighbors using the following commands: show ldp session and show ldp neighbor.


Junos MPLS and VPNs


lab@mxA-1> show ldp neighbor Address Interface Label space ID Hold time172.22.210.2 ge-1/0/0.210 192.168.5.1:0 13172.22.211.2 ge-1/0/1.211 192.168.5.4:0 14

Question: Do you see neighborships established with your two peer provider (P) routers?

Answer: Yes, you should have an operational and open session to each of the directly connected P routers.

Step 2.3

Verify MPLS connectivity using the MPLS ping utility.

lab@mxA-1> ping mpls ldp 192.168.x.y !!!!!--- lsping statistics ---5 packets transmitted, 5 packets received, 0% packet loss

Question: Are your MPLS pings successful?

Answer: Yes, your pings should succeed. If they do not, check with the remote team and verify they have completed Step 2.3. Review your configuration and contact your instructor if you need assistance.


In this lab part, you will configure the PE to CE interface. You will add the correct VLAN tag and ensure that the proper encapsulation is configured. Later, you will add this interface to your BGP Layer 2 VPN instance. You will also reconfigure the CE to PE interface. Both the local CE interface and the remote CE interface must be on the same network. Please refer to the lab diagram titled “Lab 10: Parts 3-5—BGP Layer 2 VPN” for the remaining tasks in this lab.

Step 3.1

Navigate to the [edit interfaces] hierarchy. Configure the PE to CE interface properties outlined in the lab diagram. You will start with enabling vlan-tagging for the interface. You will configure the interface to handle vlan-ccc encapsulation. When you configure the unit, you will also have to specify the encapsulation for the logical interface also. Because we are configuring a Layer 2 VPN there will not be any Layer 3 information associated with this interface. Assign the correct vlan-id value and commit your changes.

Junos MPLS and VPNs




[edit interfaces]lab@mxA-1# set ge-1/0/4 encapsulation vlan-ccc

[edit interfaces]lab@mxA-1# set ge-1/0/4 unit 6x0 encapsulation vlan-ccc

[edit interfaces]lab@mxA-1# set ge-1/0/4 unit 6x0 vlan-id 6x0

[edit interfaces]lab@mxA-1# commit commit complete

Step 3.2

Delete the current CE interface (ge-1/1/4) configuration. Navigate to the [edit interfaces ge-1/1/4] hierarchy and configure this interface’s properties following the details provided in the network diagram. Note that both the local and remote CE router interfaces will be on the same Layer 3 network.

[edit interfaces]lab@mxA-1# delete ge-1/1/4

[edit interfaces]lab@mxA-1# edit ge-1/1/4

[edit interfaces ge-1/1/4]lab@mxA-1# set vlan-tagging

[edit interfaces ge-1/1/4]lab@mxA-1# set unit 6x0 vlan-id 6x0

[edit interfaces ge-1/1/4]lab@mxA-1# set unit 6x0 family inet address 10.0.x0.y/24

[edit interfaces ge-1/1/4]lab@mxA-1# commit commit complete

Junos MPLS and VPNs


Question: Why must both CE router interfaces be in the same network?

Answer: The reason both CE router interfaces must be in the same network is because you are configuring the PE router to pass the traffic based on the Layer 2 information. As far as the CE routers are concerned, they are directly connected.

Part 4: Configuring a BGP Layer 2 VPN Instance

In this lab part, you will configure a BGP Layer 2 VPN instance. You begin by enabling BGP to signal the Layer 2 NLRI. You will create your BGP Layer 2 VPN instance and assign a unique route distinguisher and a unique route target. You will include your CE-facing interface within this instance. In this lab you will be using the vrf-target option because of its simplicity. Please note that vrf-import and vrf-export policies would work also.

Step 4.1

Navigate to the [edit protocols bgp] hierarchy and enable Layer 2 VPN signaling. This action enables the PE router to signal and understand incoming Layer 2 NLRI information.

[edit interfaces ge-1/1/4]lab@mxA-1# top edit protocols bgp

[edit protocols bgp]lab@mxA-1# set group my-int-group family l2vpn signaling

Step 4.2

Navigate to the [edit routing-instances] hierarchy. Create a new instance called vpn-x. Configure the instance type as l2vpn.

[edit protocols bgp]lab@mxA-1# top edit routing-instances

[edit routing-instances]lab@mxA-1# set vpn-x instance-type l2vpn

Step 4.3

Navigate to the [edit routing-instances vpn-x] hierarchy. Create a route distinguisher using your local loopback address to uniquely identify routes advertised from this router. The format should resemble the following: 192.168.x.y:1.

[edit routing-instances]lab@mxA-1# edit vpn-x

[edit routing-instances vpn-1]lab@mxA-1# set route-distinguisher 192.168.x.y:1

Junos MPLS and VPNs


Step 4.4

Configure your route target. As mentioned earlier, you will be using the vrf-target option. Your target will contain the local autonomous system (AS) number and will be uniquely identified by using your pod value. The format for defining you vrf-target is: target:65512:x

[edit routing-instances vpn-1]lab@mxA-1# set vrf-target target:65512:x

Step 4.5

Include the CE-facing interface in your Layer 2 VPN instance.

[edit routing-instances vpn-1]lab@mxA-1# set interface ge-1/0/4.6x0

Step 4.6

Navigate to the [edit routing-instances vpn-x protocols l2vpn] hierarchy. Configure the protocol properties for the BGP Layer 2 VPN. You will be using the encapsulation type ethernet-vlan. You will configure your site name to reflect the name of your CE router (cex-y). Please refer to lab diagram to determine which site identifier you should use. Because we are only dealing with 2 sites, you will not need to configure the remote site ID. You must also indicate the interface that will be participating in your BGP Layer 2 VPN. Commit and exit to operational mode after you have completed your changes.

[edit routing-instances vpn-1]lab@mxA-1# edit protocols l2vpn

[edit routing-instances vpn-1 protocols l2vpn]lab@mxA-1# set encapsulation-type ethernet-vlan

[edit routing-instances vpn-1 protocols l2vpn]lab@mxA-1# set site cex-y site-identifier y

[edit routing-instances vpn-1 protocols l2vpn]lab@mxA-1# set site cex-y interface ge-1/0/4.6x0

[edit routing-instances vpn-1 protocols l2vpn]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Junos MPLS and VPNs


Question: With which remote site will your configuration automatically associate?

Answer: If your local site identifier is one, then your remote site identified for your first interface entry will default to two. If your local site identified is two, then your remote site identifier for your first interface entry will default to one.

Verify your Layer 2 VPN connection by issuing the show l2vpn connections command.

lab@mxA-1> show l2vpn connections Layer-2 VPN connections:

Legend for connection status (St) EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLSEM -- encapsulation mismatch WE -- interface and instance encaps not sameVC-Dn -- Virtual circuit down NP -- interface hardware not present CM -- control-word mismatch -> -- only outbound connection is upCN -- circuit not provisioned <- -- only inbound connection is upOR -- out of range Up -- operationalOL -- no outgoing label Dn -- down LD -- local site signaled down CF -- call admission control failure RD -- remote site signaled down SC -- local and remote site ID collisionLN -- local site not designated LM -- local site ID not minimum designatedRN -- remote site not designated RM -- remote site ID not minimum designatedXX -- unknown connection status IL -- no incoming labelMM -- MTU mismatch MI -- Mesh-Group ID not availbleBK -- Backup connection ST -- Standby connectionPF -- Profile parse failure PB -- Profile busyRS -- remote site standby SN -- Static Neighbor

Legend for interface status Up -- operational Dn -- down

Instance: vpn-1 Local site: ce1-1 (1) connection-site Type St Time last up # Up trans 2 rmt Up Oct 18 15:32:24 2010 1 Remote PE: 192.168.1.2, Negotiated control-word: Yes (Null) Incoming label: 800001, Outgoing label: 800000 Local interface: ge-1/0/4.610, Status: Up, Encapsulation: VLAN

Note


Junos MPLS and VPNs


Question: What is the status of your connection?

Answer: Your connection should show a status value of Up. If it does not, check with the remote team and ensure they have completed Step 4.6. If they have completed this step, then find the status code value in the legend and review your configuration. Contact your instructor for assistance, if needed.

Step 4.7

Verify reachability from your CE router to the remote CE router. You will ping the remote CE to PE interface five times, sourced from your local CE to PE interface using the ping 10.0.x0.y routing-instance cex-y count 5 command.

lab@mxA-1> ping 10.0.x0.y routing-instance cex-y count 5 PING 10.0.10.2 (10.0.10.2): 56 data bytes64 bytes from 10.0.10.2: icmp_seq=0 ttl=64 time=1.291 ms64 bytes from 10.0.10.2: icmp_seq=1 ttl=64 time=0.540 ms64 bytes from 10.0.10.2: icmp_seq=2 ttl=64 time=0.578 ms64 bytes from 10.0.10.2: icmp_seq=3 ttl=64 time=0.541 ms64 bytes from 10.0.10.2: icmp_seq=4 ttl=64 time=0.566 ms



Answer: Yes, your ping requests should complete. If they do not, review your configuration and work with the remote team to troubleshoot the problem. Request assistance from the instructor, if needed.


Junos MPLS and VPNs


Part 5: Configuring Routing Protocols on the CE Router

In this lab part, you will configure OSPF on your CE router. You will create a policy that will export your static routes to your OSPF neighbor. You will peer with the remote CE router across the BGP Layer 2 VPN you created in Part 4. You will configure the CE router to share the static routes that you have configured. You will verify that you are receiving the remote networks and verify reachability to the remote loopback using the ping utility.

Step 5.1

Enter configuration mode and navigate to the [edit policy-options] hierarchy. Create a policy named statics that will be used to redistribute your static routes into OSPF.





Step 5.2

Navigate to the [edit routing-instances cex-y protocols ospf] hierarchy. Configure your loopback and PE-facing interface under area 0.

[edit policy-options]lab@mxA-1# top edit routing-instances cex-y protocols ospf

[edit routing-instances ce1-1 protocols ospf]lab@mxA-1# set area 0 interface ge-1/1/4.6x0

[edit routing-instances ce1-1 protocols ospf]lab@mxA-1# set area 0 interface lo0.1

Step 5.3

Apply the policy statics you defined as an export policy to your OSPF protocol. This action will export your static routes to your peer. Commit and exit to operational mode.

[edit routing-instances ce1-1 protocols ospf]lab@mxA-1# set export statics

[edit routing-instances ce1-1 protocols ospf]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Junos MPLS and VPNs


Step 5.4

Verify that your neighborship has established for your CE router by including the instance cex-y option.

lab@mxA-1> show ospf neighbor instance cex-y Address Interface State ID Pri Dead10.0.10.2 ge-1/1/4.610 Full 192.168.11.2 128 33

Step 5.5

Review the routes being learned by OSPF and ensure you have the remote CE router’s static routes by issuing the show route protocol ospf table cex-y.inet.0 command.

lab@mxA-1> show route protocol ospf table cex-y.inet.0


172.10.4.0/24 *[OSPF/150] 00:05:33, metric 0, tag 0 > to 10.0.10.2 via ge-1/1/4.610172.10.5.0/24 *[OSPF/150] 00:05:33, metric 0, tag 0 > to 10.0.10.2 via ge-1/1/4.610172.10.6.0/24 *[OSPF/150] 00:05:33, metric 0, tag 0 > to 10.0.10.2 via ge-1/1/4.610172.10.7.0/24 *[OSPF/150] 00:05:33, metric 0, tag 0 > to 10.0.10.2 via ge-1/1/4.610192.168.11.2/32 *[OSPF/10] 00:05:33, metric 1 > to 10.0.10.2 via ge-1/1/4.610224.0.0.5/32 *[OSPF/10] 00:05:48, metric 1 MultiRecv

Question: Do you see all the remote CE router’s static routes?

Answer: Yes, you should see all the static routes from the remote CE network. If you do not, check with the remote team and ensure they have completed Step 5.2. Request assistance from the instructor, if needed.

Note


Junos MPLS and VPNs


Step 5.6

Verify you have reachability to the remote CE network by pinging the remote CE router’s loopback address five times, while sourcing the packets from your local CE router’s loopback address.



Question: Do your pings complete?

Answer: Yes, you should be able to ping the remote CE router’s loopback address. If you are not able to, please review your configuration and routes that you are receiving. You might also want to check with the remote team to ensure they are receiving your OSPF routes. Please request assistance from the instructor, if needed.


Junos MPLS and VPNs


www.juniper.net Circuit Cross Connect and LDP Layer 2 Circuits (Detailed) • Lab 11–110.a.10.3R1.9

Lab 11Circuit Cross Connect and LDP Layer 2 Circuits (Detailed)

Overview

In this lab, you will establish an LDP Layer 2 circuit using RSVP signaling between provider edge (PE) routers. Once the virtual LAN (VLAN)-based LDP Layer 2 circuit is operational, you will configure the customer edge (CE) routers to run one of several available routing protocols and advertise their static route and loopback address blocks. Because this is a Layer 2 circuit, the PE routers will not interact with the routing protocols used on the CE routers. After verifying the connection from CE to CE, you will delete the LDP Layer 2 circuit configuration and configure a circuit cross connect (CCC) connection. You will then verify the connection again from CE to CE.




• Configure an RSVP-signaled label-switched path (LSP) to the remote PE router.

• Create and establish an LDP Layer 2 circuit over the core network.

• Add OSPF to your CE network and create a neighborship between your local CE router and the remote CE router.

• Export your static routes into OSPF and share these routes with the remote CE network.

• Create and establish a CCC Layer 2 connection over the core network.

• Verify connectivity and behavior using operational mode commands including ping and commands used to examine routing tables.

Junos MPLS and VPNs

Lab 11–2 • Circuit Cross Connect and LDP Layer 2 Circuits (Detailed) www.juniper.net



Step 1.1





lab@mxA-1>

Step 1.2




Junos MPLS and VPNs

www.juniper.net Circuit Cross Connect and LDP Layer 2 Circuits (Detailed) • Lab 11–3





Step 1.3




Junos MPLS and VPNs




Part 2: Establishing an RSVP-Signaled LSP Between PE Routers

In this lab part, you will use RSVP to signal an LSP to the remote PE router through the core network. You will verify that the RSVP LSP is established and the RSVP route is installed in your routing table. You will configure an extended LDP session by adding your loopback interface to LDP protocol configuration, because an LDP Layer 2 circuit requires LDP signaling for exchanging virtual circuit (VC) labels between PE routers.

Step 2.1

Navigate to the [edit protocols mpls] hierarchy. Configure a label-switched-path called pey-to-pez-x. For example, if you are assigned router mxA-1, your peer router is mxA-2. The LSP should be named pe1-to-pe2-1. Your LSP should egress at your remote peer’s loopback address. Verify that the configuration looks correct. Commit and exit to operation mode when you are satisfied with the changes.



[edit protocols mpls]lab@mxA-1# show label-switched-path pe1-to-pe2-1 { to 192.168.1.2;}interface ge-1/0/0.210;interface ge-1/0/1.211;

Step 2.2

Navigate to the [edit protocols ldp] hierarchy and configure an extended LDP session by adding the loopback interface to the LDP protocol. As mentioned previously, this will allow LDP to exchange VC labels between the PE routers. Commit your configuration changes and exit to operational mode.

[edit protocols mpls]lab@mxA-1# top edit protocols ldp

[edit protocols ldp]lab@mxA-1# set interface lo0.0

Junos MPLS and VPNs



lab@mxA-1>

Step 2.3

Verify that the LSP has been established and is ready for use.

lab@mxA-1> show mpls lsp ingress Ingress LSP: 1 sessionsTo From State Rt P ActivePath LSPname192.168.1.2 192.168.1.1 Up 0 * pe1-to-pe2-1Total 1 displayed, Up 1, Down 0

Step 2.4

Verify that the inet.3 routing table has been created and contains the RSVP route to the remote PE router.




Question: Do you see the RSVP route to the remote PE router in your inet.3 routing table?

Answer: Yes, you should see the RSVP route in the inet.3 routing table now. If you do not, please review your configuration and verify the state of your MPLS LSP is Up.


In this lab part, you will configure the PE to CE interface. You will add the correct VLAN tag and ensure that the proper encapsulation is configured. Later, you will add this interface to your LDP Layer 2 circuit instance. You will also reconfigure the CE to PE interface because both the local CE interface and the remote CE interface must be on the same network. Please refer to the lab diagram titled “Lab 11: LDP Layer 2 Circuit” for interface properties.

Junos MPLS and VPNs


Step 3.1

Enter configuration mode and navigate to the [edit interfaces] hierarchy. Configure the PE to CE interface properties outlined in the lab diagram. You will start with enabling vlan-tagging for the interface. You will configure the interface to handle vlan-ccc encapsulation. When you configure the unit, you will also have to specify the encapsulation for the logical interface. Because you are configuring a Layer 2 VPN, no Layer 3 information is associated with this interface. Assign the correct vlan-id value and commit your changes.




[edit interfaces]lab@mxA-1# set ge-1/0/4 encapsulation vlan-ccc

[edit interfaces]lab@mxA-1# set ge-1/0/4 unit 6x0 encapsulation vlan-ccc

[edit interfaces]lab@mxA-1# set ge-1/0/4 unit 6x0 vlan-id 6x0

[edit interfaces]lab@mxA-1# commit commit complete

Step 3.2

Delete the current CE interface (ge-1/1/4) configuration. Navigate to the [edit interfaces ge-1/1/4] hierarchy and configure the interface properties following the details provided in the network diagram. Note that both the local and remote CE router interfaces will be on the same Layer 3 network. Commit your configuration changes.

[edit interfaces]lab@mxA-1# delete ge-1/1/4

[edit interfaces]lab@mxA-1# edit ge-1/1/4



[edit interfaces ge-1/1/4]lab@mxA-1# set unit 6x0 family inet address 10.0.x0.y/24

Junos MPLS and VPNs


[edit interfaces ge-1/1/4]lab@mxA-1# commit commit complete

Question: Why must both CE router interfaces be in the same network?

Answer: The reason both CE router interfaces must be in the same network is because you are configuring the PE router to pass the traffic based on the Layer 2 information. As far as the CE routers are concerned, they are directly connected.

Part 4: Configuring a LDP Layer 2 Circuit

In this lab part, you will configure an LDP Layer 2 circuit. You will create the circuit to the remote PE router’s loopback address and assign the correct CE-facing interface. You will assign a unique VC identifier. You will then verify that the circuit has been signaled and is functioning properly.

Step 4.1

Navigate to the [edit protocols l2circuit] hierarchy and specify the neighbor address for the circuit. Add the PE to CE interface that will be participating in this neighborship and assign this interface a VC identifier value of x to the interface. Review your configuration changes, commit, and exit to operational mode.

[edit interfaces ge-1/1/4]lab@mxA-1# top edit protocols l2circuit

[edit protocols l2circuit]lab@mxA-1# set neighbor 192.168.x.y interface ge-1/0/4.6x0 virtual-circuit-id x

[edit protocols l2circuit]lab@mxA-1# show neighbor 192.168.1.2 { interface ge-1/0/4.610 { virtual-circuit-id 1; }}

[edit protocols l2circuit]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Junos MPLS and VPNs


Step 4.2

Verify that the LDP Layer 2 circuit is up and functional by issuing the show l2circuits connections command.

lab@mxA-1> show l2circuit connections Layer-2 Circuit Connections:

Legend for connection status (St) EI -- encapsulation invalid NP -- interface h/w not present MM -- mtu mismatch Dn -- down EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down CM -- control-word mismatch Up -- operational VM -- vlan id mismatch CF -- Call admission control failureOL -- no outgoing label IB -- TDM incompatible bitrate NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration BK -- Backup Connection ST -- Standby ConnectionCB -- rcvd cell-bundle size bad SP -- Static PseudowireLD -- local site signaled down RS -- remote site standbyRD -- remote site signaled down XX -- unknown

Legend for interface status Up -- operational Dn -- down Neighbor: 192.168.1.2 Interface Type St Time last up # Up trans ge-1/0/4.610(vc 1) rmt Up Oct 21 15:39:50 2010 1 Remote PE: 192.168.1.2, Negotiated control-word: Yes (Null) Incoming label: 300224, Outgoing label: 301024 Negotiated PW status TLV: No Local interface: ge-1/0/4.610, Status: Up, Encapsulation: VLAN

Question: What is the status of your circuit?

Answer: The status should show that the circuit is Up. If your circuit is not Up, review your configuration and verify the remote team has completed Step 4.1. Request assistance from your instructor as needed.

Note


Junos MPLS and VPNs


Question: Can you tell from the output what your VC identifier is?

Answer: Yes, if your session is up and operational. You can see to the right of the interface, in brackets, that your VC value is displayed.

Step 4.3

Verify reachability from your CE router to the remote CE router. You will ping the remote CE to PE interface five times, sourced from your local CE to PE interface using the ping 10.0.x0.y routing-instance cex-y count 5 command.




Answer: Yes, Your ping requests should complete. If they do not, review your configuration and work with the remote team to troubleshoot the problem. Request assistance from the instructor, if needed.


Junos MPLS and VPNs


Part 5: Configuring Routing Protocols on the CE Router

In this lab part, you will configure OSPF on your CE router. You will create a policy that will export your static routes to your OSPF neighbor. You will peer with the remote CE router across the LDP Layer 2 circuit you created in Part 4. You will configure the CE router to share the static routes that you have configured. You will verify that you are receiving the remote networks and verify reachability to the remote loopback using the ping utility.

Step 5.1

Enter configuration mode and navigate to the [edit policy-options] hierarchy. Create a policy named statics that will be used to redistribute your static routes into OSPF.





Step 5.2

Navigate to the [edit routing-instances cex-y protocols ospf] hierarchy. Configure your loopback and PE-facing interface under area 0.

[edit policy-options]lab@mxA-1# top edit routing-instances cex-y protocols ospf

[edit routing-instances ce1-1 protocols ospf]lab@mxA-1# set area 0 interface ge-1/1/4.6x0

[edit routing-instances ce1-1 protocols ospf]lab@mxA-1# set area 0 interface lo0.1

Step 5.3

Apply the policy statics you defined as an export policy to your OSPF protocol. This change will export your static routes to your peer. Commit and exit to operational mode.

[edit routing-instances ce1-1 protocols ospf]lab@mxA-1# set export statics

[edit routing-instances ce1-1 protocols ospf]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Junos MPLS and VPNs


Step 5.4

Verify that your neighborship has established for your CE router by including the instance cex-y option.


Step 5.5

Review the routes being learned by OSPF and ensure that you have the remote CE router’s static routes by issuing the show route protocol ospf table cex-y.inet.0 command.

lab@mxA-1> show route protocol ospf table cex-y.inet.0


172.10.4.0/24 *[OSPF/150] 00:05:33, metric 0, tag 0 > to 10.0.10.2 via ge-1/1/4.610172.10.5.0/24 *[OSPF/150] 00:05:33, metric 0, tag 0 > to 10.0.10.2 via ge-1/1/4.610172.10.6.0/24 *[OSPF/150] 00:05:33, metric 0, tag 0 > to 10.0.10.2 via ge-1/1/4.610172.10.7.0/24 *[OSPF/150] 00:05:33, metric 0, tag 0 > to 10.0.10.2 via ge-1/1/4.610192.168.11.2/32 *[OSPF/10] 00:05:33, metric 1 > to 10.0.10.2 via ge-1/1/4.610224.0.0.5/32 *[OSPF/10] 00:05:48, metric 1 MultiRecv

Question: Do you see all the remote CE router’s static?

Answer: Yes, you should see all the static routes from the remote CE network. If you do not, check with the remote team and ensure they have completed Step 5.2. Request assistance from the instructor, if needed.

Note


Junos MPLS and VPNs


Step 5.6

Verify that you have reachability to the remote CE network by pinging the remote CE router’s loopback address five times, while sourcing the packets from your local CE router’s loopback address.



Question: Do your pings complete?

Answer: Yes, you should be able to ping the remote CE router’s loopback address. If you are not able to, please review your configuration and routes that you are receiving. You might also want to check with the remote team to ensure they are receiving your OSPF routes. Please request assistance from the instructor, if needed.


Part 6: Configuring a CCC Connection Between PE Routers

In this lab part, you will establish a point-to-point Layer 2 VPN using the Junos operating system’s CCC feature in support of a VLAN environment. MPLS-tagged VLAN frames will be transported between PE routers over an RSVP-signaled LSP. Once the Layer 2 CCC connection is established, you will verify that your CE routers can route using OSPF. Because this is a Layer 2 VPN, the PE routers will not interact with the routing protocols used on the CE routers. Please refer to the lab diagram titled “Lab 11: Circuit Cross Connect” for interface properties.

Step 6.1

Enter configuration mode. Delete your LDP Layer 2 circuit configuration and delete the ge-1/0/4 interface configuration. Commit your configuration changes.


[edit]

Junos MPLS and VPNs


lab@mxA-1# delete protocols l2circuit

[edit]lab@mxA-1# delete interfaces ge-1/0/4


Step 6.2

Navigate to the [edit interfaces ge-1/0/5] hierarchy. Configure the PE to CE interface properties outlined in the lab diagram. You will start with enabling vlan-tagging for the interface. You will configure the interface to handle vlan-ccc encapsulation. When you configure the unit, you will also have to specify the encapsulation for the logical interface. Because we are configuring a Layer 2 connection, no Layer 3 information is associated with this interface. Assign the correct vlan-tag value and commit your changes

[edit]lab@mxA-1# edit interfaces ge-1/0/5


[edit interfaces ge-1/0/5]lab@mxA-1# set encapsulation vlan-ccc

[edit interfaces ge-1/0/5]lab@mxA-1# set unit 6x0 encapsulation vlan-ccc


Step 6.3

Navigate to the top of the [edit] hierarchy and issue the command replace pattern ge-1/1/4 with ge-1/1/5. This action will change all references in the configuration of ge-1/1/4 to ge-1/1/5, which is the new CE interface being used in the lab diagram. Verify that the interface being applied for the CE routing instance has been changed. Remember to verify the change also applied to your CE router’s OSPF configuration. When you are satisfied with the change commit your configuration.

[edit interfaces ge-1/0/5]lab@mxA-1# top

[edit]lab@mxA-1# replace pattern ge-1/1/4 with ge-1/1/5

[edit]lab@mxA-1# show routing-instances cex-y instance-type virtual-router;interface ge-1/1/5.610;interface lo0.1;routing-options { static {

Junos MPLS and VPNs


route 172.10.0.0/24 reject; route 172.10.1.0/24 reject; route 172.10.2.0/24 reject; route 172.10.3.0/24 reject; } autonomous-system 65101;}protocols { ospf { export statics; area 0.0.0.0 { interface ge-1/1/5.610; interface lo0.1; } }}


Step 6.4

Navigate to the [edit protocols connections] hierarchy and configure a remote-interface-switch named vpn-x. Assign your PE interface used to connect to your CE router (ge-1/0/5.6x0) to the interface switch. For the interface you assign, you have to specify the transmit-lsp lsp-name and the receive-lsp lsp-name for the traffic to use to get to and from the remote end of the connection. You will assign the RSVP LSP that you configured in Part 2 as you transmit LSP and you will assign the LSP that the remote team created as you receive LSP. If you do not remember the names, you can view them in the output from the run show mpls lsp command. Commit your configuration changes and exit to operational mode.

[edit]lab@mxA-1# edit protocols connections

[edit protocols connections]lab@mxA-1# run show mpls lsp Ingress LSP: 1 sessionsTo From State Rt P ActivePath LSPname192.168.1.2 192.168.1.1 Up 0 * pe1-to-pe2-1Total 1 displayed, Up 1, Down 0



[edit protocols connections]lab@mxA-1# set remote-interface-switch vpn-x interface ge-1/0/5.6x0 transmit-lsp pey-to-pez-x

Junos MPLS and VPNs


[edit protocols connections]lab@mxA-1# set remote-interface-switch vpn-x interface ge-1/0/5.6x0 receive-lsp pez-to-pey-x

[edit protocols connections]lab@mxA-1# commit and-quit commit completeExiting configuration mode

lab@mxA-1>

Step 6.5

Verify that the CCC connection is up and ready to use by issuing the show connections command.

lab@mxA-1> show connections CCC and TCC connections [Link Monitoring On]Legend for status (St) Legend for connection typesUN -- uninitialized if-sw: interface switchingNP -- not present rmt-if: remote interface switchingWE -- wrong encapsulation lsp-sw: LSP switchingDS -- disabled tx-p2mp-sw: transmit P2MP switchingDn -- down rx-p2mp-sw: receive P2MP switching-> -- only outbound conn is up<- -- only inbound conn is up Legend for circuit typesUp -- operational intf -- interfaceRmtDn -- remote CCC down tlsp -- transmit LSPRestart -- restarting rlsp -- receive LSP

Connection/Circuit Type St Time last up # Up transvpn-1 rmt-if Up Oct 21 22:06:22 12 ge-1/0/5.610 intf Up pe1-to-pe2-1 tlsp Up pe2-to-pe1-1 rlsp Up

Question: What is the status of the CCC connection?

Answer: The status should be Up for the interface, transmit LSP or tlsp and the receive LSP or rlsp.

Note


Junos MPLS and VPNs


Step 6.6

Verify that you can ping five times through the CCC circuit you just configured.



Question: Do your ping packets complete?

Answer: Yes, your pings should complete at this time. If they do not, please check your configuration and ensure you are pinging the correct destination. Request assistance from your instructor if needed.

Step 6.7

Verify that your OSPF neighborship has established over the CCC circuit.


Question: What is the state of your OSPF adjacency?

Answer: The State should be Full at this time. You have established reachability with the ping command. Please request assistance from the instructor if needed.


www.juniper.net Virtual Private LAN Service (Detailed) • Lab 12–110.a.10.3R1.9

Lab 12Virtual Private LAN Service (Detailed)

Overview

In this lab, you will establish an LDP virtual private LAN service (VPLS) and a BGP VPLS between provider edge (PE) routers. You will also configure a virtual switch to act as the customer edge (CE) router. There will be redundant links between the PE and CE routers so you will be required to prevent any Layer 2 loops from forming.



• Load the virtual private network (VPN) baseline configuration for your router. This configuration includes your baseline core configuration including Open Shortest Path First (OSPF) and BGP. The baseline also contains a virtual router configuration that will be used to generate data traffic for this lab.

• Configure Layer 2 interfaces and apply them to a virtual switch that you will configure to act as the CE router.

• Configure LDP signaling to enable MPLS label-switched paths (LSPs) between PE routers.

• Configure an LDP VPLS.

• Configure a BGP VPLS.

• Configure redundant links between CE and PE routers and prevent Layer 2 loops from forming.

• Verify connectivity and behavior using operational mode commands including ping and commands used to examine routing tables, and PE to PE router BGP announcements.

Junos MPLS and VPNs

Lab 12–2 • Virtual Private LAN Service (Detailed) www.juniper.net



Step 1.1





Step 1.2

Verify that your OSPF and BGP neighbor relationships are established correctly.


lab@mxB-1> show bgp summary Groups: 1 Peers: 1 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0bgp.l3vpn.0 0 0 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...192.168.2.2 65512 264 259 0 1 1:52:47 Establ inet.0: 0/0/0/0 bgp.l3vpn.0: 0/0/0/0

Junos MPLS and VPNs

www.juniper.net Virtual Private LAN Service (Detailed) • Lab 12–3




Answer: Yes, your BGP neighbor relationship should be up and working. If it is not, please review your configuration and ensure the remote team has completed Step 1.1. Please request assistance from your instructor, if needed.

Step 1.3

Enter configuration mode. Review and familiarize yourself with the CE instance configuration.


[edit]lab@mxB-1# show routing-instances cex-y instance-type virtual-router;interface ge-1/1/4.620;interface lo0.1;routing-options { static { route 172.10.0.0/24 reject; route 172.10.1.0/24 reject; route 172.10.2.0/24 reject; route 172.10.3.0/24 reject; } autonomous-system 65201;}



Junos MPLS and VPNs




Part 2: Adjusting the Properties of the Virtual Router

In this lab part, you will rename the virtual router from the baseline lab. You will also change the IP address of the ge-1/1/4 interface as shown in the lab diagram. These changes will be made because a virtual switch will act as a the CE device in this lab, not the virtual router. The virtual router will be used to generate ping traffic for testing the VPLS.

Step 2.1

Enter configuration mode and navigate to the [edit interfaces] hierarchy. Configure the appropriate interface properties for the ge-1/1/4 interface as found on the lab diagram titled “Lab 12: Parts 1-6 - LDP VPLS”.




[edit interfaces]lab@mxB-1# set ge-1/1/4 vlan-tagging unit 6x0 vlan-id 6x0

[edit interfaces]lab@mxB-1# set ge-1/1/4 vlan-tagging unit 6x0 family inet address 10.0.x0.y/24

Step 2.2

Navigate to the [edit routing-instances] hierarchy and rename the virtual router routing instance to c-routerx-y. Commit your configuration so far.


[edit routing-instances]lab@mxB-1# rename cex-y to c-routerx-y

[edit routing-instances]lab@mxB-1# commit commit complete

Junos MPLS and VPNs


Part 3: Configuring a Virtual Switch Instance

In this lab part, you will configure a virtual switch that will act as a CE device for this lab. The virtual switch will be configured to have one interface that connects to the customer virtual router and two interfaces that connect to the PE router. Use the lab diagram to see the intended connectivity.

Step 3.1

Create a new virtual switch instance named ce-vsx-y.

[edit routing-instances]lab@mxB-1# set ce-vsx-y instance-type virtual-switch

Step 3.2

Navigate to the [edit interfaces] hierarchy and configure the three Layer 2 interfaces that will be used by the virtual switch. Make sure to specify an encapsulation of flexible-ethernet-services at the physical interface level and an encapsulation of vlan-bridge at the subinterface level.

[edit interfaces]lab@mxB-1# set ge-1/0/4 vlan-tagging encapsulation flexible-ethernet-services

[edit interfaces]lab@mxB-1# set ge-1/0/4 unit 6x0 encapsulation vlan-bridge vlan-id 6x0





Step 3.3

Navigate to the [edit routing-instances ce-vsx-y] and configure a bridge domain named vlan_6x0 using the appropriate virtual LAN (VLAN) ID. Add the three Layer 2 interfaces to the new bridge domain. Commit your configuration and exit to operational mode.

[edit interfaces]lab@mxB-1# top edit routing-instances ce-vsx-y

[edit routing-instances ce-vs2-1]lab@mxB-1# set bridge-domains vlan_6x0 vlan-id 6x0

[edit routing-instances ce-vs2-1]lab@mxB-1# set bridge-domains vlan_6x0 interface ge-1/0/4.6x0


Junos MPLS and VPNs




Step 3.4

Verify the status of the Layer 2 CE device using the show bridge domain command.

lab@mxB-1> show bridge domain

Routing instance Bridge domain VLAN ID Interfacesce-vs2-1 vlan_620 620 ge-1/0/4.620 ge-1/1/6.620 ge-1/1/7.620

Question: Have the correct three interfaces been applied to the correct routing instance and bridge domain?

Answer: The three Layer 2 interfaces should be applied to the CE virtual switch. If not, verify your configuration and check with your instructor if you need help.

Part 4: Enabling LDP Signaling in the Core

In this lab part, you will configure LDP as the signaling protocol for MPLS in the core. LDP will be used to both signal the MPLS LSPs between PE routers and also advertise the VPLS forwarding equivalency class (FEC) information between PE routers.

Step 4.1

Enter configuration mode and navigate to the [edit protocols ldp] hierarchy. Enable LDP on the core-facing interfaces as well as the loopback interface. You might need to refer to the lab diagram titled “Lab 1: Part 1—Static LSPs (Infrastructure)” to determine the names of the core-facing interfaces. Commit your configuration and exit to operational mode.


[edit]lab@mxB-1# edit protocols ldp

Junos MPLS and VPNs


[edit protocols ldp]lab@mxB-1# set interface ge-1/0/0.2xy

[edit protocols ldp]lab@mxB-1# set interface ge-1/0/1.2xy

[edit protocols ldp]lab@mxB-1# set interface lo0.0

[edit protocols ldp]lab@mxB-1# commit and-quit commit completeExiting configuration mode

Question: Can you think of a reason why you need to configure LDP to run on the loopback interface?

Answer: LDP must be configured on the loopback interface so that it can establish an extended LDP neighbor relationship with a remote PE router. LDP VPLS relies on these extended neighbor relationships to establish a VPLS.

Step 4.2

Use the show ldp neighbor command to determine the status of your neighbors.

lab@mxB-1> show ldp neighbor Address Interface Label space ID Hold time172.22.220.2 ge-1/0/0.220 192.168.5.1:0 10172.22.221.2 ge-1/0/1.221 192.168.5.4:0 11

Question: Has the PE router established relationships with the locally connected provider (P) routers?

Answer: Yes, the PE router should have a neighbor relationship with both of the directly connected P routers. If not, verify your configuration and check with your instructor if you need help.

Junos MPLS and VPNs


Step 4.3

Use the show ldp database command to determine whether an LSP has been established from your PE router to the remote PE router. Do not proceed until the LSP has been established to the remote PE router.

lab@mxB-1> show ldp database Input label database, 192.168.2.1:0--192.168.5.1:0 Label Prefix 302896 192.168.2.1/32 302864 192.168.2.2/32 3 192.168.5.1/32 299808 192.168.5.2/32 299856 192.168.5.3/32 299792 192.168.5.4/32 299824 192.168.5.5/32 299840 192.168.5.6/32

Output label database, 192.168.2.1:0--192.168.5.1:0 Label Prefix 3 192.168.2.1/32 299984 192.168.2.2/32 300000 192.168.5.1/32 300016 192.168.5.2/32 300032 192.168.5.3/32 299936 192.168.5.4/32 299952 192.168.5.5/32 299968 192.168.5.6/32

Input label database, 192.168.2.1:0--192.168.5.4:0 Label Prefix 301904 192.168.2.1/32 301872 192.168.2.2/32 299776 192.168.5.1/32 299792 192.168.5.2/32 299856 192.168.5.3/32 3 192.168.5.4/32 299808 192.168.5.5/32 299840 192.168.5.6/32

Output label database, 192.168.2.1:0--192.168.5.4:0 Label Prefix 3 192.168.2.1/32 299984 192.168.2.2/32 300000 192.168.5.1/32 300016 192.168.5.2/32 300032 192.168.5.3/32 299936 192.168.5.4/32 299952 192.168.5.5/32 299968 192.168.5.6/32

Junos MPLS and VPNs


Question: Has an LSP been established to the remote PE router?

Answer: To determine the answer, look at the input label database (received labels) from your LDP neighbors. If a label is associated with the remote PE router’s loopback interface then the LSP is established. If not, verify your configuration and check with your instructor if you need help.


Part 5: Configuring an LDP VPLS Instance

In this lab part, you will configure an LDP VPLS instance. You will include the CE router-facing interface within this instance.

Step 5.1

Enter configuration mode and navigate to the [edit interfaces] hierarchy. Configure ge-1/0/6 interface to be used as the CE router facing interface for the VPLS.



[edit interfaces]lab@mxB-1# set ge-1/0/6 vlan-tagging encapsulation vlan-vpls unit 6x0 vlan-id 6x0

[edit interfaces]lab@mxB-1# set ge-1/0/6 unit 6x0 encapsulation vlan-vpls

Step 5.2

Navigate to the [edit routing-instances] hierarchy. Create a new VPLS instance named vpn-x.


[edit routing-instances]lab@mxB-1# set vpn-x instance-type vpls

Junos MPLS and VPNs


Step 5.3

Navigate to the [edit routing-instances vpn-x] hierarchy. Add the ge-1/0/6 interface to the routing instance.

[edit routing-instances]lab@mxB-1# edit vpn-x


Step 5.4

Create an LDP VPLS using a VPLS ID of x00 and specify the remote PE router as the neighbor. Commit your configuration and exit to operational mode.

[edit routing-instances vpn-2]lab@mxB-1# set protocols vpls vpls-id x00 neighbor 192.168.x.y


Step 5.5

Check the status of the VPLS connection using the show vpls connections command.

lab@mxB-1> show vpls connections Layer-2 VPN connections:



Instance: vpn-2 VPLS-id: 200 Neighbor Type St Time last up # Up trans 192.168.2.2(vpls-id 200) rmt NP

Junos MPLS and VPNs


Question: Has a VPLS pseudowire been established to the remote PE router?

Answer: The output of the command should show that the VPLS is not in the up state.

Question: What does the legend suggest the current state might be? What is the solution to the problem?

Answer: The VPLS is in the NP state. According to the legend this state means that the interface hardware is not present. This absence generally equates to a missing tunnel services PIC. You simply must enable tunnel services on your PE router.

Step 5.6

Enter configuration mode and navigate to the [edit chassis]hierarchy. Enable tunnel services on FPC slot 1, PIC slot 0 at a bandwidth of 1 Gbps. Commit your configuration and exit to operational mode.




[edit chassis]lab@mxB-1# commit and-quit commit completeExiting configuration mode

Step 5.7

Check the status of the VPLS connection using the show vpls connections extensive command. Ensure that the remote group has completed the previous step of the lab.

lab@mxB-1> show vpls connections extensive Layer-2 VPN connections:

Junos MPLS and VPNs




Instance: vpn-2 VPLS-id: 200 Number of local interfaces: 1 Number of local interfaces up: 1 ge-1/0/6.620 vt-1/0/10.1050881 Intf - vpls vpn-2 neighbor 192.168.2.2 vpls-id 200 Neighbor Type St Time last up # Up trans 192.168.2.2(vpls-id 200) rmt Up Oct 21 12:05:17 2010 1 Remote PE: 192.168.2.2, Negotiated control-word: No Incoming label: 800001, Outgoing label: 800000 Negotiated PW status TLV: No Local interface: vt-1/0/10.1050881, Status: Up, Encapsulation: ETHERNET Description: Intf - vpls vpn-2 neighbor 192.168.2.2 vpls-id 200 Connection History: Oct 21 12:05:17 2010 status update timer Oct 21 12:05:17 2010 PE route changed Oct 21 12:05:17 2010 Out lbl Update 800000 Oct 21 12:05:17 2010 In lbl Update 800001 Oct 21 12:05:17 2010 loc intf up vt-1/0/10.1050881


Answer: The output of the command should show that the VPLS is now in the up state.

Junos MPLS and VPNs


Question: What transmit and receive labels have been reserved for the VPLS?

Answer: This answer will vary between students.

Question: What local interfaces are listed as participating in the VPLS?

Answer: The ge-1/0/6 interface and a randomly generated vt-1/0/10 interface should be listed.

Step 5.8

Verify that you have connectivity from the local customer router to the remote customer router through the VPLS by using the ping utility. You will ping the remote customer router’s ge-1/1/4 address. You will send five packets for this test. This task can be accomplished using the following command: ping 10.0.x0.y routing-instance c-routerx-y count 5.

lab@mxB-1> ping 10.0.x0.y routing-instance c-routerx-y count 5 PING 10.0.20.2 (10.0.20.2): 56 data bytes64 bytes from 10.0.20.2: icmp_seq=0 ttl=64 time=1.607 ms64 bytes from 10.0.20.2: icmp_seq=1 ttl=64 time=19.870 ms64 bytes from 10.0.20.2: icmp_seq=2 ttl=64 time=0.622 ms64 bytes from 10.0.20.2: icmp_seq=3 ttl=64 time=17.915 ms64 bytes from 10.0.20.2: icmp_seq=4 ttl=64 time=0.579 ms



Answer: Yes, they should all complete. If they do not, please review your configuration and request assistance from your instructor, if needed.

Junos MPLS and VPNs


Step 5.9

Use the show vpls statistics command to view details of traffic that has traversed the VPLS.

lab@mxB-1> show vpls statistics VPLS statistics:

Instance: vpn-2 Local interface: ge-1/0/6.620, Index: 85 Broadcast packets: 1 Broadcast bytes : 60 Multicast packets: 0 Multicast bytes : 0 Flooded packets : 0 Flooded bytes : 0 Unicast packets : 5 Unicast bytes : 510 Current MAC count: 1 (Limit 1024) Local interface: vt-1/0/10.1050881, Index: 87 Remote PE: 192.168.2.2 Broadcast packets: 0 Broadcast bytes : 0 Multicast packets: 0 Multicast bytes : 0 Flooded packets : 0 Flooded bytes : 0 Unicast packets : 6 Unicast bytes : 570 Current MAC count: 1

Question: How many broadcast packets have been received on the ge-1/0/6 interface? Can you think of a reason why the PE router has received a broadcast packet?

Answer: The number of broadcast packet will vary but at this point in the lab there should be at least one. An address resolution protocol (ARP) exchange was necessary for the local router to determine the media access control (MAC) address of the remote router. An ARP is sent as a broadcast.

Step 5.10

Use the show vpls mac-table command to determine whether the PE router has learned any MAC addresses. You might need to issue another ping from the local customer router to allow for the PE router to learn MAC addresses.

Junos MPLS and VPNs


lab@mxB-1> show vpls mac-table

MAC flags (S -static MAC, D -dynamic MAC, SE -Statistics enabled, NM -Non configured MAC)

Routing instance : vpn-2 Bridging domain : __vpn-2__, VLAN : NA MAC MAC Logical address flags interface 80:71:1f:c3:07:7c D ge-1/0/6.620 80:71:1f:c3:4c:7c D vt-1/0/10.1050881

Question: Of the MAC addresses that have been learned, which one is owned by the local customer router and which one is owned by the remote customer router?

Answer: The answer will vary, but the one associated with the vt-1/0/10 interface should be owned by the remote customer router. The MAC address associated with the ge-1/0/6 interface is owned by the local customer router.

Part 6: Using MSTP to Prevent a Layer 2 Loop in a VPLS

In this lab part, you will add an extra interface for redundancy between the PE and CE routers that will cause a Layer 2 loop to form. To ensure that only one interface is learning and forwarding at any one time, you will configure Multiple Spanning Tree Protocol (MSTP) between the PE and CE routers using a Layer 2 control instance on the PE router.

Step 6.1

Enter configuration mode and navigate to the [edit interfaces] hierarchy. Configure the ge-1/0/7 interface to be used as the CE router-facing interface for the VPLS. Remember that you have already added the peer interface to the CE router (ge-1/1/7).





Junos MPLS and VPNs


Step 6.2

Navigate to the [edit routing-instances] hierarchy. Add the ge-1/0/7 interface to the VPLS. Commit your configuration and exit to operational mode.


[edit routing-instances]lab@mxB-1# set vpn-x interface ge-1/0/7.6x0

[edit routing-instances]lab@mxB-1# commit and-quit commit completeExiting configuration mode

Step 6.3

Be aware that you have now created a Layer 2 loop between the PE and CE routers! Verify with the show vpls connections extensive command that the new interface has been added to the VPLS.




Instance: vpn-2 VPLS-id: 200 Number of local interfaces: 2 Number of local interfaces up: 2 ge-1/0/6.620 ge-1/0/7.620 vt-1/0/10.1050881 Intf - vpls vpn-2 neighbor 192.168.2.2 vpls-id 200 Neighbor Type St Time last up # Up trans 192.168.2.2(vpls-id 200) rmt Up Oct 21 12:05:17 2010 1

Junos MPLS and VPNs


Remote PE: 192.168.2.2, Negotiated control-word: No Incoming label: 800001, Outgoing label: 800000 Negotiated PW status TLV: No Local interface: vt-1/0/10.1050881, Status: Up, Encapsulation: ETHERNET Description: Intf - vpls vpn-2 neighbor 192.168.2.2 vpls-id 200 Connection History: Oct 21 12:05:17 2010 status update timer Oct 21 12:05:17 2010 PE route changed Oct 21 12:05:17 2010 Out lbl Update 800000 Oct 21 12:05:17 2010 In lbl Update 800001 Oct 21 12:05:17 2010 loc intf up vt-1/0/10.1050881

Question: Which interfaces are now listed as participating in the VPLS?

Answer: Interfaces ge-1/0/6, ge-1/0/7, and vt-1/0/10 should be listed as interfaces participating in the VPLS.

Step 6.4

Verify that a Layer 2 loop is in the network by issuing the command, ping 10.0.x0.255 routing-instance c-routerx-y count 5.

lab@mxB-1> ping 10.0.x0.255 routing-instance c-routerx-y count 5 PING 10.0.20.255 (10.0.20.255): 56 data bytes64 bytes from 10.0.20.1: icmp_seq=0 ttl=64 time=842.425 ms64 bytes from 10.0.20.1: icmp_seq=0 ttl=64 time=842.823 ms (DUP!)64 bytes from 10.0.20.1: icmp_seq=0 ttl=64 time=842.883 ms (DUP!)64 bytes from 10.0.20.1: icmp_seq=0 ttl=64 time=842.921 ms (DUP!)64 bytes from 10.0.20.1: icmp_seq=0 ttl=64 time=842.982 ms (DUP!)64 bytes from 10.0.20.1: icmp_seq=0 ttl=64 time=843.059 ms (DUP!)64 bytes from 10.0.20.1: icmp_seq=0 ttl=64 time=843.115 ms (DUP!)64 bytes from 10.0.20.1: icmp_seq=0 ttl=64 time=843.197 ms (DUP!)64 bytes from 10.0.20.1: icmp_seq=0 ttl=64 time=843.244 ms (DUP!)64 bytes from 10.0.20.1: icmp_seq=0 ttl=64 time=843.370 ms (DUP!)64 bytes from 10.0.20.1: icmp_seq=0 ttl=64 time=843.409 ms (DUP!)64 bytes from 10.0.20.1: icmp_seq=0 ttl=64 time=843.474 ms (DUP!)...64 bytes from 10.0.20.2: icmp_seq=2 ttl=64 time=2289.730 ms (DUP!)64 bytes from 10.0.20.2: icmp_seq=0 ttl=64 time=4351.733 ms (DUP!)64 bytes from 10.0.20.1: icmp_seq=4 ttl=64 time=838.432 ms

--- 10.0.20.255 ping statistics ---5 packets transmitted, 5 packets received, +1297 duplicates, 0% packet lossround-trip min/avg/max/stddev = 838.432/1782.169/4351.733/949.310 ms

Junos MPLS and VPNs


Question: Based on the results of the ping, does there appear to be a Layer 2 loop in the network?

Answer: The results of the ping should show that the customer router is receiving multiple, duplicate echo responses from the hosts on the broadcast segment, which would be a symptom of a Layer 2 loop.

Step 6.5

Enter configuration mode and navigate to the [edit routing-instance] hierarchy. Create a new Layer 2 control instance named vpn-x-l2control.



[edit routing-instances]lab@mxB-1# set vpn-x-l2control instance-type layer2-control

Step 6.6

In the vpn-x-l2control instance, configure MSTP to run on the ge-1/0/6 and ge-1/0/7 interfaces. Set the MSTP configuration name to vpn-x and the revision level to 1.

[edit routing-instances]lab@mxB-1# set vpn-x-l2control protocols mstp configuration-name vpn-x revision-level 1

[edit routing-instances]lab@mxB-1# set vpn-x-l2control protocols mstp interface ge-1/0/6

[edit routing-instances]lab@mxB-1# set vpn-x-l2control protocols mstp interface ge-1/0/7

Step 6.7

In the ce-vsx-y virtual switch instance, configure MSTP to run on the ge-1/1/6 and ge-1/1/7 interfaces. Set the MSTP configuration name to vpn-x and the revision level to 1. Commit your configuration and exit to operational mode.

[edit routing-instances]lab@mxB-1# set ce-vsx-y protocols mstp interface ge-1/1/6

[edit routing-instances]lab@mxB-1# set ce-vsx-y protocols mstp interface ge-1/1/7

[edit routing-instances]lab@mxB-1# set ce-vsx-y protocols mstp configuration-name vpn-x revision-level 1

Junos MPLS and VPNs



Step 6.8

Use the show spanning tree interface for both the virtual switch and the Layer 2 control instance to determine which interfaces are in the FWD (forwarding) state and which interfaces are in the BLK (blocking) state.

lab@mxB-1> show spanning-tree interface routing-instance ce-vsx-y

Spanning tree interface parameters for instance 0

Interface Port ID Designated Designated Port State Role port ID bridge ID Costge-1/1/6 128:57 128:47 32768.80711fc307d1 20000 FWD ROOT ge-1/1/7 128:58 128:48 32768.80711fc307d1 20000 BLK ALT

lab@mxB-1> show spanning-tree interface routing-instance vpn-x-l2control

Spanning tree interface parameters for instance 0

Interface Port ID Designated Designated Port State Role port ID bridge ID Costge-1/0/6 128:47 128:47 32768.80711fc307d1 20000 FWD DESG ge-1/0/7 128:48 128:48 32768.80711fc307d1 20000 FWD DESG

Question: Are there any interfaces currently in the blocking state?

Answer: The answer will vary by student. The interface will be chosen through MSTP normal behavior of building a loop-free spanning tree.

Question: Does a Layer 2 loop exist between the PE and CE routers?

Answer: At this point, there should be no Layer 2 loop between PE and CE routers because one interface exists in the blocking state.

Junos MPLS and VPNs


Step 6.9

Verify that a Layer 2 loop has been removed from the network by issuing the command, ping 10.0.x0.255 routing-instance c-routerx-y count 5.

lab@mxB-1> ping 10.0.20.255 routing-instance c-router2-1 count 5 PING 10.0.20.255 (10.0.20.255): 56 data bytes64 bytes from 10.0.20.2: icmp_seq=0 ttl=64 time=0.781 ms64 bytes from 10.0.20.2: icmp_seq=1 ttl=64 time=7.309 ms64 bytes from 10.0.20.2: icmp_seq=2 ttl=64 time=0.551 ms64 bytes from 10.0.20.2: icmp_seq=3 ttl=64 time=0.644 ms64 bytes from 10.0.20.2: icmp_seq=4 ttl=64 time=0.578 ms



Answer: The results of the ping should show that the customer router is no longer receiving multiple, duplicate echo responses from the hosts on the broadcast segment, which would be a symptom of a no Layer 2 loop.


Part 7: Adding a Subinterface to the Virtual Router

In this lab part, you will begin using the “Lab 12: Parts 7-9 - BGP VPLS” diagram. You will add a new subinterface to ge-1/1/4 interface as shown in the lab diagram. These changes will be made so the virtual router can be used to generate ping traffic for testing the BGP VPLS.

Step 7.1

Enter configuration mode and navigate to the [edit interfaces] hierarchy. Configure the appropriate interface properties for the ge-1/1/4 interface as found on the lab diagram titled “Lab 12: Parts 7-9 - BGP VPLS”.



Junos MPLS and VPNs


[edit interfaces]lab@mxB-1# set ge-1/1/4 unit 6x1 vlan-id 6x1

[edit interfaces]lab@mxB-1# set ge-1/1/4 unit 6x1 family inet address 10.0.x1.y/24

Step 7.2

Navigate to the [edit routing-instances] hierarchy and add the ge-1/1/4.6x1 interface to the virtual router. Commit your configuration so far.


[edit routing-instances]lab@mxB-1# set c-routerx-y interface ge-1/1/4.6x1

[edit routing-instances]lab@mxB-1# commit commit complete

Part 8: Configuring the Virtual Switch Instance

In this lab part, you will configure the virtual switch to have a another subinterface that connects to the customer virtual router and two interfaces that connect to the PE router. Use the lab diagram to see the intended connectivity.

Step 8.1

Navigate to the [edit interfaces] hierarchy and configure the three Layer 2 interfaces that will be used by the virtual switch. Make sure to specify an encapsulation of flexible-ethernet-services at the physical interface level and an encapsulation of vlan-bridge at the subinterface level.

[edit routing-instances]lab@mxB-1# top edit interfaces






Junos MPLS and VPNs


Step 8.2

Navigate to the [edit routing-instances ce-vsx-y] and configure a bridge domain named vlan_6x1 using the appropriate VLAN ID. Add the three Layer 2 interfaces to the new bridge domain. Commit your configuration and exit to operational mode.

[edit interfaces]lab@mxB-1# top edit routing-instances ce-vsx-y

[edit routing-instances ce-vs2-1]lab@mxB-1# set bridge-domains vlan_6x1 vlan-id 6x1



[edit routing-instances ce-vs2-1lab@mxB-1# set bridge-domains vlan_6x1 interface ge-1/1/9.6x1


Step 8.3

Verify the status of the Layer 2 CE device using the show bridge domain command.

lab@mxB-1> show bridge domain

Routing instance Bridge domain VLAN ID Interfacesce-vs2-1 vlan_620 620 ge-1/0/4.620 ge-1/1/6.620 ge-1/1/7.620ce-vs2-1 vlan_621 621 ge-1/0/4.621 ge-1/1/8.621 ge-1/1/9.621vpn-2 __vpn-2__ NA ge-1/0/6.620 ge-1/0/7.620 vt-1/0/10.1052416

Junos MPLS and VPNs


Question: Have the correct three interfaces been applied to the correct routing instance and bridge domain?

Answer: The three Layer 2 interfaces should be applied to the CE virtual switch. If not, verify your configuration and check with your instructor if you need help.

Part 9: Configuring a BGP VPLS with Redundant Links between CE and PE Routers

In this lab part, you will configure a BGP VPLS instance. You will include the ge-1/0/8 and ge-1/0/9 CE router-facing interfaces within this instance. To prevent a Layer 2 loop from forming, your will use the active-interface command.

Step 9.1

Enter into configuration mode and navigate to the [edit protocols bgp] hierarchy. Configure your PE router to PE router BGP session to support l2vpn signaling.

[edit]lab@mxB-1# edit protocols bgp

[edit protocols bgp]lab@mxB-1# set group my-int-group family l2vpn signaling

Step 9.2

Navigate to the [edit interfaces] hierarchy. Configure the ge-1/0/8 and ge-1/0/9 interfaces to be used as the CE router-facing interfaces for the VPLS.

[edit protocols bgp]lab@mxB-1# top edit interfaces





Junos MPLS and VPNs


Step 9.3

Navigate to the [edit routing-instances] hierarchy. Create a new VPLS instance named vpn-x1.


[edit routing-instances]lab@mxB-1# set vpn-x1 instance-type vpls

Step 9.4

Navigate to the [edit routing-instances vpn-x1] hierarchy. Add the ge-1/0/8 and ge-1/0/9 interfaces to the routing instance.

[edit routing-instances]lab@mxB-1# edit vpn-x1



Step 9.5

Configure a route target community of target:65512:x00 for the VPLS.

[edit routing-instances vpn-21]lab@mxB-1# set vrf-target target:65512:x00

Step 9.6

Create a BGP VPLS naming the site after your CE, ce-vsx-y, and specify a site ID that matches the y value of the CE router name. Commit your configuration and exit to operational mode.

[edit routing-instances vpn-21]lab@mxB-1# set protocols vpls site ce-vsx-y site-identifier y


Step 9.7

Verify that there is a Layer 2 loop in the network by issuing the command, ping 10.0.x1.255 routing-instance c-routerx-y count 5.

lab@mxB-1> ping 10.0.21.255 routing-instance c-router2-1 count 5 PING 10.0.21.255 (10.0.21.255): 56 data bytes64 bytes from 10.0.21.1: icmp_seq=0 ttl=64 time=1284.211 ms64 bytes from 10.0.21.1: icmp_seq=0 ttl=64 time=1284.590 ms (DUP!)64 bytes from 10.0.21.1: icmp_seq=0 ttl=64 time=1284.641 ms (DUP!)64 bytes from 10.0.21.1: icmp_seq=0 ttl=64 time=1284.830 ms (DUP!)64 bytes from 10.0.21.1: icmp_seq=0 ttl=64 time=1284.898 ms (DUP!)64 bytes from 10.0.21.1: icmp_seq=0 ttl=64 time=1285.086 ms (DUP!)

Junos MPLS and VPNs


64 bytes from 10.0.21.1: icmp_seq=0 ttl=64 time=1285.372 ms (DUP!)64 bytes from 10.0.21.1: icmp_seq=0 ttl=64 time=1294.265 ms (DUP!)...64 bytes from 10.0.21.1: icmp_seq=0 ttl=64 time=4394.511 ms (DUP!)64 bytes from 10.0.21.1: icmp_seq=0 ttl=64 time=4394.551 ms (DUP!)64 bytes from 10.0.21.1: icmp_seq=3 ttl=64 time=2291.676 ms (DUP!)64 bytes from 10.0.21.1: icmp_seq=4 ttl=64 time=1290.807 ms

--- 10.0.21.255 ping statistics ---5 packets transmitted, 5 packets received, +552 duplicates, 0% packet lossround-trip min/avg/max/stddev = 1284.211/2298.017/4394.551/961.959 ms


Answer: The results of the ping should show that the customer router is receiving multiple, duplicate echo responses from the hosts on the broadcast segment, which would be a symptom of a Layer 2 loop.

Step 9.8

Enter configuration and mode and navigate to the [edit routing-instances vpn-x1] hierarchy. To prevent that loop, configure the ge-1/0/8 interface as the active-interface for the site. Commit your configuration and exit to operational mode.

[edit routing-instances vpn-21]lab@mxB-1# set protocols vpls site ce-vsx-y interface ge-1/0/8.6x1

[edit routing-instances vpn-21]lab@mxB-1# set protocols vpls site ce-vsx-y interface ge-1/0/9.6x1

[edit routing-instances vpn-21]lab@mxB-1# set protocols vpls site ce-vsx-y active-interface primary ge-1/0/8.6x1


Junos MPLS and VPNs


Step 9.9

Check the status of the VPLS connection using the show vpls connections extensive command. Ensure that the remote group has completed the previous step of the lab.




Instance: vpn-21 Local site: ce-vs2-1 (1) Number of local interfaces: 2 Number of local interfaces up: 2 IRB interface present: no ge-1/0/8.621 ge-1/0/9.621 Interface flags: VC-Down vt-1/0/10.1052417 2 Intf - vpls vpn-21 local site 1 remote site 2 Label-base Offset Size Range Preference 800256 1 8 8 100 connection-site Type St Time last up # Up trans 2 rmt Up Nov 12 18:47:23 2010 1 Remote PE: 192.168.2.2, Negotiated control-word: No Incoming label: 800257, Outgoing label: 800256 Local interface: vt-1/0/10.1052417, Status: Up, Encapsulation: VPLS Description: Intf - vpls vpn-21 local site 1 remote site 2 Connection History: Nov 12 18:47:23 2010 status update timer Nov 12 18:47:23 2010 loc intf up vt-1/0/10.1052417 Nov 12 18:47:23 2010 PE route changed Nov 12 18:47:23 2010 Out lbl Update 800256 Nov 12 18:47:23 2010 In lbl Update 800257 Nov 12 18:47:23 2010 loc intf down ...

Junos MPLS and VPNs




Question: What local interfaces are listed as participating in the VPLS?

Answer: The ge-1/0/8 interface, the ge-1/0/9 interface, and a randomly generated vt-1/0/10 interface should be listed.

Question: Can you tell from the output of the command which CE router-facing interface is currently active?

Answer: The ge-1/0/9 is listed as having an interface status of VC-down. That listing means that the ge-1/0/9 interface is not being used for learning and forwarding. The ge-1/0/8 and vt-1/0/10 interfaces are the only interfaces being used for learning and forwarding.

Step 9.10

View the vpn-x1 routing table by using the show route table vpn-x1 extensive command. Analyze the route that was received from your remote neighbor.

lab@mxB-1> show route table vpn-x1 extensive

vpn-21.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)192.168.2.1:10:1:1/96 (1 entry, 1 announced)TSI:Page 0 idx 0 Type 1 val 292d540 *L2VPN Preference: 170/-101 Next hop type: Indirect Next-hop reference count: 2 Protocol next hop: 192.168.2.1 Indirect next hop: 0 - State: <Active Int Ext> Age: 22:02 Metric2: 1 Task: vpn-21-l2vpn

Junos MPLS and VPNs


Announcement bits (1): 1-BGP RT Background AS path: I Communities: Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100 Label-base: 800256, range: 8, status-vector: 0x3F

192.168.2.2:9:2:1/96 (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 192.168.2.2:9 Next hop type: Indirect Next-hop reference count: 5 Source: 192.168.2.2 Protocol next hop: 192.168.2.2 Indirect next hop: 2 no-forward State: <Secondary Active Int Ext> Local AS: 65512 Peer AS: 65512 Age: 3:49 Metric2: 1 Task: BGP_65512.192.168.2.2+60216 Announcement bits (1): 0-vpn-21-l2vpn AS path: I Communities: target:65512:200 Layer2-info: encaps:VPLS, control flags:, mtu: 0, site preference: 100 Import Accepted Label-base: 800256, range: 8 Localpref: 100 Router ID: 192.168.2.2 Primary Routing Table bgp.l2vpn.0 Indirect next hops: 1 Protocol next hop: 192.168.2.2 Metric: 1 Indirect next hop: 2 no-forward Indirect path forwarding next hops: 2 Next hop type: Router Next hop: 172.22.220.2 via ge-1/0/0.220 Next hop: 172.22.221.2 via ge-1/0/1.221 192.168.2.2/32 Originating RIB: inet.3 Metric: 1 Node path count: 1 Forwarding nexthops: 2 Nexthop: 172.22.220.2 via ge-1/0/0.220 Nexthop: 172.22.221.2 via ge-1/0/1.221

Question: What is the Site ID, Label Offset, Label Base, and Range of the label block advertised by your remote neighbor?

Answer: The answer will vary by student. In the example, the local PE router has automatically learned of a remote site (because this is BGP VPLS) with a site ID of 2, label offset of 1, label base of 800256, and a range of 8.

Junos MPLS and VPNs


Step 9.11

Verify that you have connectivity from the local customer router to the remote customer router through the VPLS by using the ping utility. You will ping the remote customer router’s ge-1/1/4 address. You will send five packets for this test. This task can be accomplished using the following command: ping 10.0.x1.y routing-instance c-routerx-y count 5.





Step 9.12






Junos MPLS and VPNs



Question: Which CE router-facing interface is being used for forwarding in the vpn-x1 routing instance?

Answer: The ge-1/0/8 interface should be the only PE router to CE router interface used for forwarding.

Step 9.13

Enter configuration mode and disable the ge-1/0/8 interface. Commit your configuration and exit to operational mode.


[edit]lab@mxB-1# set interfaces ge-1/0/8 disable


Step 9.14

Check the status of the VPLS connection using the show vpls connections extensive command.


Legend for connection status (St) EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLSEM -- encapsulation mismatch WE -- interface and instance encaps not sameVC-Dn -- Virtual circuit down NP -- interface hardware not present CM -- control-word mismatch -> -- only outbound connection is upCN -- circuit not provisioned <- -- only inbound connection is upOR -- out of range Up -- operationalOL -- no outgoing label Dn -- down LD -- local site signaled down CF -- call admission control failure RD -- remote site signaled down SC -- local and remote site ID collisionLN -- local site not designated LM -- local site ID not minimum designatedRN -- remote site not designated RM -- remote site ID not minimum designatedXX -- unknown connection status IL -- no incoming labelMM -- MTU mismatch MI -- Mesh-Group ID not availbleBK -- Backup connection ST -- Standby connection

Junos MPLS and VPNs


PF -- Profile parse failure PB -- Profile busyRS -- remote site standby SN -- Static Neighbor


Instance: vpn-21 Local site: ce-vs2-1 (1) Number of local interfaces: 2 Number of local interfaces up: 1 IRB interface present: no ge-1/0/8.621 Interface flags: VC-Down ge-1/0/9.621 vt-1/0/10.1052417 2 Intf - vpls vpn-21 local site 1 remote site 2 Label-base Offset Size Range Preference 800256 1 8 8 100 connection-site Type St Time last up # Up trans 2 rmt Up Nov 12 18:47:23 2010 1 Remote PE: 192.168.2.2, Negotiated control-word: No Incoming label: 800257, Outgoing label: 800256 Local interface: vt-1/0/10.1052417, Status: Up, Encapsulation: VPLS Description: Intf - vpls vpn-21 local site 1 remote site 2 Connection History: Nov 12 18:47:23 2010 status update timer Nov 12 18:47:23 2010 loc intf up vt-1/0/10.1052417 Nov 12 18:47:23 2010 PE route changed Nov 12 18:47:23 2010 Out lbl Update 800256 Nov 12 18:47:23 2010 In lbl Update 800257 Nov 12 18:47:23 2010 loc intf down ...

Question: Can you tell from the output of the command which interface is being used for learning and forwarding between the PE and CE routers?

Answer: The ge-1/0/8 interface is listed as having an interface status of VC-down. That listing means that the ge-1/0/8 interface is not being used for learning and forwarding. The ge-1/0/9 and vt-1/0/10 interfaces are currently being used for forwarding.

Step 9.15

Verify that you have connectivity from the local customer router to the remote customer router through the VPLS by using the ping utility. Ping the remote customer router’s ge-1/1/4 address. Send five packets for this test. This task can be accomplished using the following command: ping 10.0.x1.y routing-instance c-routerx-y count 5.

Junos MPLS and VPNs






Step 9.16





Question: Which CE router-facing interface is being used for forwarding?

Answer: The ge-1/0/9 interface should be the only PE router to CE router interface used for forwarding.


www.juniper.net Carrier-of-Carrier VPNs (Detailed) • Lab 13–110.a.10.3R1.9

Lab 13Carrier-of-Carrier VPNs (Detailed)

Overview

In this lab you, will establish a BGP virtual private LAN service (VPLS) between two provider edge (PE) routers that belong to different autonomous systems (ASs). Carrier-of-carrier virtual private networks (VPNs) option C will be used to provide the PE to PE VPLS signaling and forwarding plane. You must also configure a Layer 3 VPN from the provider PE routers to pass customer internal routes between ASs. You will also use labeled-unicast address family when passing routes between the provider PE router and the customer CE routers. Finally, you will configure the customer CE routers to pass any learned routes from the provider (remote customer site routes) to the customer PE router using the labeled-unicast address family.



• Load the VPN baseline configuration for your router. This configuration includes your baseline core configuration including OSPF and BGP. The baseline also contains a virtual router configuration that you will delete.

• Configure a virtual router to generate traffic from the subscriber sites.

• Configure a Layer 3 VPN between the provider PE routers and configure an multiprotocol EBGP session with the customer CE router using the labeled-unicast address family.

• Configure a bidirectional LSP between the provider PE routers and between the customer PE and CE.

• Configure an IBGP session between the customer CE and PE using the labeled-unicast address family.

• Configure a multihop EBGP session between the customer CE routers using the l2vpn address family.

• Configure a BGP VPLS to provide connectivity between the subscriber CE routers.

• Verify connectivity and behavior using operational mode commands including ping and commands used to examine routing tables, and PE-PE BGP announcements.

Junos MPLS and VPNs

Lab 13–2 • Carrier-of-Carrier VPNs (Detailed) www.juniper.net


In this lab part, you will load the VPN baseline configuration you saved in Lab 6. After loading the configuration, you will verify that the core network is operating as expected. You will also become familiar with the Lab 13 lab diagram.

Step 1.1

Enter configuration mode and load the VPN baseline configuration by executing the load override jmv-RouterName-vpn-baseline command. Commit your configuration changes.



[edit]lab@mxB-1# commit commit complete

Step 1.2

Delete any routing-instances, delete interface ge-1/1/4, and delete unit 1 of interface lo0. Commit your configuration and exit to operational mode.

[edit]lab@mxB-1# delete routing-instances

[edit]lab@mxB-1# delete interfaces ge-1/1/4

[edit]lab@mxB-1# delete interfaces lo0 unit 1


Step 1.3

Verify that your OSPF and BGP neighbor relationships are established correctly.


lab@mxB-1> show bgp summary Groups: 1 Peers: 1 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0bgp.l3vpn.0 0 0 0 0 0 0

Junos MPLS and VPNs

www.juniper.net Carrier-of-Carrier VPNs (Detailed) • Lab 13–3

Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...192.168.2.2 65512 264 259 0 1 1:52:47 Establ inet.0: 0/0/0/0 bgp.l3vpn.0: 0/0/0/0


Answer: Yes, your OSPF neighbors should be in a Full state. If they are not, please review your configuration and ensure that the remote team has completed Step 1.2. Please request assistance from your instructor, if needed.


Answer: Yes, your BGP neighbor relationship should be up and working. If it is not, please review your configuration and ensure the remote team has completed Step 1.2. Please request assistance from your instructor, if needed.

Step 1.4

Familiarize yourself with the Lab 13 network diagram. Notice that there is a provider AS, two customer ASs, and two subscriber CE routers.

Question: What are the names of the two provider PE routers?

Answer: The two provider PE routers are named p-pe1 and p-pe2.

Question: What are the names of the customer routers in AS 65x01?

Answer: The customer routers in AS 65x01 are named c-pe1 and c-ce1.

Junos MPLS and VPNs


Question: What are the names of the customer routers in AS 65x02?

Answer: The customer routers in AS 65x01 are named c-pe2 and c-ce2.

Question: What are the names of the two subscriber routers?

Answer: The two subscriber routers are named s-ce1 and s-ce2.

Part 2: Configuring the Subscriber CE Router Properties

In this lab part, you will create a virtual router type routing instance on your device. This virtual router will act as the subscriber CE router and will be used for testing connectivity between sites.

Step 2.1

Enter configuration mode and navigate to the [edit interfaces] hierarchy. Configure the ge-1/1/6 interface using the properties specified on the lab diagram.



[edit interfaces]lab@mxB-1# set ge-1/1/6 vlan-tagging unit 6x0 vlan-id 6x0 family inet address 10.0.51.y/24

Step 2.2

Navigate to the [edit routing-instances] hierarchy. Configure a virtual router routing-instance named s-cey.


[edit routing-instances]lab@mxB-1# set s-cey instance-type virtual-router

Step 2.3

Add the ge-1/1/6 interfaces to the s-cey routing instances. Commit your configuration and exit to operation mode.

Junos MPLS and VPNs


[edit routing-instances]lab@mxB-1# set s-cey interface ge-1/1/6.6x0


Step 2.4

Verify that the ge-1/1/6 interface is operational and configured with the correct properties by viewing the routing table of the s-cey virtual router.

lab@mxB-1> show route table s-cey

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


Question: Can the 10.0.51.0/24 subnet be found in the subscriber CE router’s routing table?

Answer: The direct route of 10.0.51.0/24 should be in the routing table. If not, check your configuration and make adjustments if needed.

Part 3: Enabling MPLS in the Provider Backbone

In this lab part, you will configure RSVP-signaled LSPs between the Provider PE routers.

Step 3.1

Enter configuration mode and navigate to the [edit protocols mpls] hierarchy. Configure an LSP named p-pey-to-p-pez from the local provider PE router to the remote provider PE router. Commit your configuration and exit to operational mode.


[edit]lab@mxB-1# set protocols mpls label-switched-path p-pey-to-p-pey to 192.168.x.y


Junos MPLS and VPNs


Step 3.2

Use the show mpls lsp command to determine whether the LSP has been established from your provider PE router to the remote provider PE router. Do not proceed until the LSP has been established to the remote PE router.

lab@mxB-1> show mpls lsp Ingress LSP: 1 sessionsTo From State Rt P ActivePath LSPname192.168.2.2 192.168.2.1 Up 0 * p-pe1-to-p-pe2Total 1 displayed, Up 1, Down 0

...

Question: Has an LSP been established to the remote PE router?

Answer: The LSP should be in the Up state. If not, verify your configuration and check with your instructor if you need help.


Part 4: Configuring a Layer 3 VPN on the Provider PE Routers

In this lab part, you will configure a Layer 3 VPN routing instance on the provider PE router. You will include the customer CE-facing interface within this instance. You will also configure an MP-EBGP session with the customer CE router using the labeled-unicast address family.

Step 4.1

Enter configuration mode and navigate to the [edit interfaces] hierarchy. Configure the ge-1/0/4 interface (with no VLAN tagging) to be used as the CE-facing interface for the Layer 3 VPN. Be sure to enable this interface for MPLS forwarding because it will be sending and receiving labeled packets.



[edit interfaces]lab@mxB-1# set ge-1/0/4 unit 0 family inet address 10.0.2y.1/24

[edit interfaces]lab@mxB-1# set ge-1/0/4 unit 0 family mpls

Junos MPLS and VPNs


Step 4.2

Navigate to the [edit routing-instances] hierarchy. Create a new Layer 3 VPN instance named vpn-to-extend-lsp.


[edit routing-instances]lab@mxB-1# set vpn-to-extend-lsp instance-type vrf

Step 4.3

Navigate to the [edit routing-instances vpn-to-extend-lsp] hierarchy. Add the ge-1/0/4 interface to the routing instance and specify a route target community of target:65512:x00.

[edit routing-instances]lab@mxB-1# edit vpn-to-extend-lsp

[edit routing-instances vpn-to-extend-lsp]lab@mxB-1# set interface ge-1/0/4.0

[edit routing-instances vpn-to-extend-lsp]lab@mxB-1# set vrf-target target:65512:x00

Step 4.4

Within the vpn-to-extend-lsp routing instance, configure an MP-EBGP session using the labeled-unicast address family between the provider PE router and your customer CE router. Remember that the session will not establish because you have not configured the customer CE router yet. Commit your configuration so far.

[edit routing-instances vpn-to-extend-lsp]lab@mxB-1# set protocols bgp group customer peer-as 65x0y

[edit routing-instances vpn-to-extend-lsp]lab@mxB-1# set protocols bgp group customer type external

[edit routing-instances vpn-to-extend-lsp]lab@mxB-1# set protocols bgp group customer neighbor 10.0.2y.2

[edit routing-instances vpn-to-extend-lsp]lab@mxB-1# set protocols bgp group customer family inet labeled-unicast

[edit routing-instances vpn-to-extend-lsp]lab@mxB-1# commit error: [ edit routing-instances vpn-to-extend-lsp ]Carrier's carrier - Interface ge-1/0/4.0 or keyword "all"must be enabled under [ edit protocols mpls ] sectionerror: configuration check-out failed

Junos MPLS and VPNs


Question: Did the configuration commit without any errors? If not, what errors were reported?

Answer: You will probably see an error like the one shown in the example, which tells you that when performing carrier’s carrier (labeled-unicast in a VRF), you must enable the MPLS protocol on the ge-1/0/4 interface.

Step 4.5

Navigate to the [edit protocols] hierarchy. Configure the ge-1/0/4 interface to run the MPLS protocol. Commit your configuration so far.

[edit routing-instances vpn-to-extend-lsp]lab@mxB-1# top edit protocols

[edit protocols]lab@mxB-1# set mpls interface ge-1/0/4.0

[edit protocols]lab@mxB-1# commit commit complete

Question: Did the configuration commit without any errors?

Answer: Yes, the configuration should commit without any error. If there are errors, check your configuration, make any changes and try to commit again.

Part 5: Configuring the Customer CE Logical System

In this lab part, you will use the logical system feature of the Junos OS to represent the customer CE router. You will configure the customer CE router to have an MP-IBGP session with the customer PE router and MP-EBGP session with the provider PE router using the labeled-unicast address family. You will also configure an MPLS LSP to the customer PE router using LDP.

Step 5.1

Navigate to the [edit logical-systems c-cey] hierarchy. Configure thege-1/1/4 and ge-1/0/5 interfaces (with no VLAN tagging). Be sure to enable these interfaces for MPLS forwarding because they will be sending and receiving labeled packets.

Junos MPLS and VPNs


[edit protocols]lab@mxB-1# top edit logical-systems c-cey

[edit logical-systems c-ce1]lab@mxB-1# set interfaces ge-1/1/4 unit 0 family inet address 10.0.2y.2/24

[edit logical-systems c-ce1]lab@mxB-1# set interfaces ge-1/1/4 unit 0 family mpls

[edit logical-systems c-ce1]lab@mxB-1# set interfaces ge-1/0/5 unit 0 family inet address 10.0.y0.1/24

[edit logical-systems c-ce1]lab@mxB-1# set interfaces ge-1/0/5 unit 0 family mpls

Step 5.2

Configure interface lo0.1 with the IP address listed on the lab diagram.

[edit logical-systems c-ce1]lab@mxB-1# set interfaces lo0 unit 1 family inet address 192.168.1x.y

Step 5.3

Navigate to the [edit logical-systems c-cey routing-options] hierarchy. Configure the AS number for the customer CE router.

[edit logical-systems c-ce1]lab@mxB-1# edit routing-options

[edit logical-systems c-ce1 routing-options]lab@mxB-1# set autonomous-system 65x0y

Step 5.4

Navigate to the [edit logical-systems c-cey protocols] hierarchy. Configure ge-1/0/4 and ge-1/0/5 to run the MPLS protocol.

[edit logical-systems c-ce1 routing-options]lab@mxB-1# up

[edit logical-systems c-ce1]lab@mxB-1# edit protocols

[edit logical-systems c-ce1 protocols]lab@mxB-1# set mpls interface ge-1/1/4.0

[edit logical-systems c-ce1 protocols]lab@mxB-1# set mpls interface ge-1/0/5.0

Step 5.5

Configure ge-1/0/5 to run the LDP protocol.

[edit logical-systems c-ce1 protocols]lab@mxB-1# set ldp interface ge-1/0/5.0

Junos MPLS and VPNs


Step 5.6

Configure OSPF (Area 0) on the lo0.1, ge-1/1/4 (passive), and ge-1/0/5 interfaces.

[edit logical-systems c-ce1 protocols]lab@mxB-1# set ospf area 0 interface lo0.1

[edit logical-systems c-ce1 protocols]lab@mxB-1# set ospf area 0 interface ge-1/1/4.0 passive

[edit logical-systems c-ce1 protocols]lab@mxB-1# set ospf area 0 interface ge-1/0/5.0

Step 5.7

Configure an MP-IBGP session using the labeled-unicast address family between the customer CE router and the customer PE router. Remember that the session will not establish because you have not configured the customer PE router yet.

[edit logical-systems c-ce1 protocols]lab@mxB-1# set bgp group int type internal local-address 192.168.1x.y

[edit logical-systems c-ce1 protocols]lab@mxB-1# set bgp group int type internal family inet labeled-unicast

[edit logical-systems c-ce1 protocols]lab@mxB-1# set bgp group int type internal neighbor 192.168.1x.y

Step 5.8

Configure an MP-EBGP session using the labeled-unicast address family between the customer CE router and the provider PE router.

[edit logical-systems c-ce1 protocols]lab@mxB-1# set bgp group ext type external peer-as 65512

[edit logical-systems c-ce1 protocols]lab@mxB-1# set bgp group ext family inet labeled-unicast

[edit logical-systems c-ce1 protocols]lab@mxB-1# set bgp group ext neighbor 10.0.2y.1

Step 5.9

Navigate to the [edit logical-systems c-cey policy-options] hierarchy. Create a policy named internals, which will be used to advertise all of the loopback addresses from the local customer AS.

[edit logical-systems c-ce1 protocols]lab@mxB-1# up

[edit logical-systems c-ce1]lab@mxB-1# edit policy-options

[edit logical-systems c-ce1 policy-options]lab@mxB-1# set policy-statement internals term 10 from route-filter 192.168.1x.y exact

Junos MPLS and VPNs


[edit logical-systems c-ce1 policy-options]lab@mxB-1# set policy-statement internals term 10 from route-filter 192.168.1x.y exact

[edit logical-systems c-ce1 policy-options]lab@mxB-1# set policy-statement internals term 10 then accept

Step 5.10

Navigate to the [edit logical-systems c-cey protocols] hierarchy. Apply the internals policy as an export policy to the provider PE neighbor. Commit your configuration and exit to operational mode.

[edit logical-systems c-ce1 policy-options]lab@mxB-1# up

[edit logical-systems c-ce1]lab@mxB-1# edit protocols

[edit logical-systems c-ce1 protocols]lab@mxB-1# set bgp group ext export internals

[edit logical-systems c-ce1 protocols]lab@mxB-1# commit and-quit commit completeExiting configuration mode

Step 5.11

Use the show mpls interface logical-system c-cey command to verify that MPLS has been enabled on the correct interfaces on the customer CE router.

lab@mxB-1> show mpls interface logical-system c-cey Interface State Administrative groupsge-1/0/5.0 Up <none>ge-1/1/4.0 Up <none>

Question: Do the ge-1/0/5 and ge-1/1/4 interfaces currently have MPLS enabled?

Answer: Both interfaces should be listed as Up in the output of the command. If not, please review your configuration and make any necessary changes. Please request assistance from your instructor, if needed.

Step 5.12

Use the show ldp interface logical-system c-cey command to verify that LDP has been enabled on the correct interfaces on the customer CE router.

lab@mxB-1> show ldp interface logical-system c-cey Interface Label space ID Nbr count Next helloge-1/0/5.0 192.168.12.1:0 0 3

Junos MPLS and VPNs


Question: Does the ge-1/0/5 interface currently have LDP enabled?

Answer: The interface should be listed as Up in the output of the command. If it is not, please review your configuration and make any necessary changes. Please request assistance from your instructor, if needed.

Step 5.13

Use the show ospf interface logical-system c-cey command to verify that OSPF has been enabled on the correct interfaces on the customer CE router.

lab@mxB-1> show ospf interface logical-system c-cey Interface State Area DR ID BDR ID Nbrsge-1/0/5.0 DR 0.0.0.0 192.168.12.1 0.0.0.0 0ge-1/1/4.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0lo0.1 DR 0.0.0.0 192.168.12.1 0.0.0.0 0

Question: Do the ge-1/0/5, ge-1/1/4, and lo0 interfaces currently have OSPF enabled?

Answer: All three interfaces should be listed in the output of the command. If not, please review your configuration and make any necessary changes. Please request assistance from your instructor, if needed.

Step 5.14

Use the show bgp summary logical-system c-cey command to verify that a BGP neighbor relationship has been established with the provider PE router.

lab@mxB-1> show bgp summary logical-system c-cey Groups: 2 Peers: 2 Down peers: 1Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 0 0 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...10.0.20.1 65512 194 197 0 0 1:26:59 Establ inet.0: 0/0/0/0192.168.12.3 10 0 0 0 0 1:27:03 Active

Junos MPLS and VPNs


Question: Is your BGP peering session with the provider PE router established?

Answer: Yes, your BGP neighbor relationship should be up and working. If it is not, please review your configuration and make any necessary changes. Please request assistance from your instructor, if needed.

Step 5.15

Use the show route advertising-protocol bgp 10.0.2y.1 logical-system c-cez command to verify that the customer CE router is advertising its loopback address to the provider PE router. Remember that it will not advertise the customer PE router’s loopback until the customer PE router is configured. You will configure the customer PE router in the next part of the lab.

lab@mxB-1> show route advertising-protocol bgp 10.0.2y.1 logical-system c-cez

inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path* 192.168.12.1/32 Self I

Question: Is the customer CE router’s loopback address being advertised to the provider PE router?

Answer: A route representing the customer CE router’s loopback address should show up in the output of the command. If it does not, please review your configuration and make any necessary changes. Please request assistance from your instructor, if needed.


Junos MPLS and VPNs


Part 6: Configuring the Customer PE Logical System

In this lab part, you will use the logical system feature of the Junos OS to represent the customer PE router. You will configure the customer PE router to have an MP-IBGP session with the customer CE router using the labeled-unicast address family. You will also configure an MPLS LSP to the customer CE router using LDP.

Step 6.1

Enter configuration mode and navigate to the [edit logical-systems c-pey] hierarchy. Configure the ge-1/1/5 interface (with no VLAN tagging). Be sure to enable this interface for MPLS forwarding because it will be sending and receiving labeled packets.

[edit]lab@mxB-1# edit logical-systems c-pey

[edit logical-systems c-pe1]lab@mxB-1# set interfaces ge-1/1/5 unit 0 family inet address 10.0.y0.2/24

[edit logical-systems c-pe1]lab@mxB-1# set interfaces ge-1/1/5 unit 0 family mpls

Step 6.2

Configure interface lo0.2 with the IP address listed on the lab diagram.

[edit logical-systems c-pe1]lab@mxB-1# set interfaces lo0 unit 2 family inet address 192.168.1x.y

Step 6.3

Navigate to the [edit logical-systems c-pey routing-options] hierarchy. Configure the AS number for the customer PE router.

[edit logical-systems c-pe1]lab@mxB-1# edit routing-options

[edit logical-systems c-pe1 routing-options]lab@mxB-1# set autonomous-system 65x0y

Step 6.4

Navigate to the [edit logical-systems c-pey protocols] hierarchy. Configure ge-1/1/5 to run the MPLS protocol.

[edit logical-systems c-pe1 routing-options]lab@mxB-1# up

[edit logical-systems c-pe1]lab@mxB-1# edit protocols

[edit logical-systems c-pe1 protocols]lab@mxB-1# set mpls interface ge-1/1/5.0

Junos MPLS and VPNs


Step 6.5

Configure ge-1/1/5 to run the LDP protocol.

[edit logical-systems c-pe1 protocols]lab@mxB-1# set ldp interface ge-1/1/5.0

Step 6.6

Configure OSPF (Area 0) on the lo0.2 and ge-1/1/5 interfaces.

[edit logical-systems c-pe1 protocols]lab@mxB-1# set ospf area 0 interface lo0.2

[edit logical-systems c-pe1 protocols]lab@mxB-1# set ospf area 0 interface ge-1/1/5.0

Step 6.7

Configure an MP-IBGP session using the labeled-unicast address family between the customer PE router and the customer CE router. Commit your configuration and exit to operational mode.

[edit logical-systems c-pe1 protocols]lab@mxB-1# set bgp group int type internal local-address 192.168.1x.y

[edit logical-systems c-pe1 protocols]lab@mxB-1# set bgp group int type internal family inet labeled-unicast

[edit logical-systems c-pe1 protocols]lab@mxB-1# set bgp group int type internal neighbor 192.168.1x.y

[edit logical-systems c-pe1 protocols]lab@mxB-1# commit and-quit commit completeExiting configuration mode

Step 6.8

Use the show mpls interface logical-system c-pey command to verify that MPLS has been enabled on the correct interfaces on the customer PE router.

lab@mxB-1> show mpls interface logical-system c-pey Interface State Administrative groupsge-1/1/5.0 Up <none>

Question: Does the ge-1/1/5 interface currently have MPLS enabled?

Answer: The interface should be listed as Up in the output of the command. If not, please review your configuration and make any necessary changes. Please request assistance from your instructor, if needed.

Junos MPLS and VPNs


Step 6.9

Use the show ospf neighbor logical-system c-pey command to verify that an OSPF adjacency exists with the customer CE router.

lab@mxB-1> show ospf neighbor logical-system c-pey Address Interface State ID Pri Dead10.0.50.1 ge-1/1/5.0 Full 192.168.12.1 128 33

Question: Is the ospf neighbor relationship with the customer CE in the Full state?

Answer: The neighbor relationship between the customer PE and CE should now be in the Full state. If not, please review your configuration and make any necessary changes. Please request assistance from your instructor, if needed.

Step 6.10

Use the show ldp database logical-system c-cey command to verify that LSPs have been created to and from the customer CE router.

lab@mxB-1> show ldp database logical-system c-pey Input label database, 192.168.12.3:0--192.168.12.1:0 Label Prefix 3 192.168.12.1/32 299792 192.168.12.3/32

Output label database, 192.168.12.3:0--192.168.12.1:0 Label Prefix 299776 192.168.12.1/32 3 192.168.12.3/32

Question: Are there LSPs established to and from the customer CE router?

Answer: Looking at the input label database, if you see the customer CE router’s loopback address associated with a label, then an LSP is up from the customer PE router to the customer CE router. Looking at the output label database, if you see the customer PE router’s loopback address associated with a label, then an LSP is up from the customer CE router to the customer PE router. If they are not up, please review your configuration and make any necessary changes. Please request assistance from your instructor, if needed.

Junos MPLS and VPNs


Step 6.11

Use the show bgp summary logical-system c-pey command to verify that a BGP neighbor relationship has been established with the customer CE router.

lab@mxB-1> show bgp summary logical-system c-pey Groups: 1 Peers: 1 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendinginet.0 2 2 0 0 0 0Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...192.168.12.1 65201 5 4 0 0 35 Establ inet.0: 2/2/2/0

Question: Is your BGP peering session with the provider CE router established?

Answer: Yes, your BGP neighbor relationship should be up and working. If it is not, please review your configuration and make any necessary changes. Please request assistance from your instructor, if needed.


Part 7: Placing IBGP Learned Routes in inet.3

In this lab part, you will analyze the BGP routes that have been learned by the customer PE router (originated in remote AS). You will ensure that these routes can be used for the BGP next-hop recursive lookup for Layer 2 VPN NLRI that will be advertised in the next part of the lab.

Step 7.1

Use the show route protocol bgp logical-system c-pey command to view the BGP routes that have been learned from the remote autonomous system.

lab@mxB-1> show route protocol bgp logical-system c-pey


10.0.21.0/24 *[BGP/170] 00:05:43, localpref 100, from 192.168.12.1 AS path: 65512 I > to 10.0.50.1 via ge-1/1/5.0, Push 299824192.168.12.2/32 *[BGP/170] 00:13:53, localpref 100, from 192.168.12.1 AS path: 65512 65202 I > to 10.0.50.1 via ge-1/1/5.0, Push 299808192.168.12.4/32 *[BGP/170] 00:05:43, localpref 100, from 192.168.12.1

Junos MPLS and VPNs


AS path: 65512 65202 I > to 10.0.50.1 via ge-1/1/5.0, Push 299824



Question: In which routing table are the received BGP routes currently being stored?

Answer: The routes are currently being stored in the inet.0 table.

Question: Does a BGP route exist in the inet.0 table that represents the loopback address of the remote customer PE router?

Answer: A BGP route representing the remote customer PE router should exist in the inet.0 table. If it does not, work with the remote group to determine whether they have applied the appropriate routing policy to the customer CE router. Make any necessary changes. Please request assistance from your instructor, if needed.

Question: In the next part of the lab, from the local customer PE router, you will establish a multihop Layer 2 VPN MP-BGP session with the remote customer PE router using loopback addresses for peering. What will be the BGP next hop advertised in any BGP update message received from the remote customer PE router?

Answer: The BGP next hop of any received BGP update messages from the remote customer PE router will be the loopback address of that same PE router.

Junos MPLS and VPNs


Question: For the BGP next hop of any MP-BGP VPN routes received from the remote customer PE router to be usable, where must the route to the next hop exist?

Answer: The route to the remote customer PE router’s loopback must exist in the inet.3 routing table. Any VPN NLRI (Layer 3 VPN and Layer 2 VPN) must use a route in inet.3 to resolve BGP next hops.

Question: You learned in the output of the command that the local customer PE router is placing the learned BGP routes in inet.0. What must you do to have it put the routes in inet.3 also?

Answer: To place the learned BGP routes in inet.3, you must configure the resolve-vpn option for the labeled-unicast address family.

Step 7.2

Enter configuration mode and navigate to the [edit logical-systems c-pey protocols] hierarchy. Configure the resolve-vpn option for the labeled-unicast address family. Commit your configuration and exit to operational mode.


[edit]lab@mxB-1# edit logical-systems c-pey protocols

[edit logical-systems c-pe1 protocols]lab@mxB-1# set bgp group int family inet labeled-unicast resolve-vpn

[edit logical-systems c-pe1 protocols]lab@mxB-1# commit and-quit commit completeExiting configuration mode

Junos MPLS and VPNs


Step 7.3

Use the show route protocol bgp logical-system c-pey command to view the BGP routes that have been learned from the remote AS.

lab@mxB-1> show route protocol bgp logical-system c-pey


10.0.21.0/24 *[BGP/170] 00:28:19, localpref 100, from 192.168.12.1 AS path: 65512 I > to 10.0.50.1 via ge-1/1/5.0, Push 299824192.168.12.2/32 *[BGP/170] 00:36:29, localpref 100, from 192.168.12.1 AS path: 65512 65202 I > to 10.0.50.1 via ge-1/1/5.0, Push 299808192.168.12.4/32 *[BGP/170] 00:28:19, localpref 100, from 192.168.12.1 AS path: 65512 65202 I > to 10.0.50.1 via ge-1/1/5.0, Push 299824


10.0.21.0/24 *[BGP/170] 00:01:37, localpref 100, from 192.168.12.1 AS path: 65512 I > to 10.0.50.1 via ge-1/1/5.0, Push 299824192.168.12.2/32 *[BGP/170] 00:01:37, localpref 100, from 192.168.12.1 AS path: 65512 65202 I > to 10.0.50.1 via ge-1/1/5.0, Push 299808192.168.12.4/32 *[BGP/170] 00:01:37, localpref 100, from 192.168.12.1 AS path: 65512 65202 I > to 10.0.50.1 via ge-1/1/5.0, Push 299824


Question: In which routing tables are the received BGP routes currently being stored?

Answer: The routes are currently being stored in both the inet.0 and the inet.3 table.


Junos MPLS and VPNs


Part 8: Configuring a BGP VPLS Between Customer PE Routers

In this lab part, you will create a BGP VPLS between PE routers in two different ASs. You will configure a multihop MP-EBGP session with the remote PE router using the l2vpn signaling address family.

Step 8.1

Enter configuration mode and navigate to the [edit chassis] hierarchy. Enable tunnel services on FPC 1PIC 0 at speed of 1 g.




Step 8.2

Navigate to the [edit logical-systems c-pey protocols] hierarchy. Configure a multihop EBGP session with the remote PE router using loopback addresses for peering and the l2vpn signaling address family.

[edit chassis]lab@mxB-1# top edit logical-systems c-pey protocols

[edit logical-systems c-pe1 protocols]lab@mxB-1# set bgp group ext type external multihop

[edit logical-systems c-pe1 protocols]lab@mxB-1# set bgp group ext local-address 192.168.1x.y peer-as 65x0y neighbor 192.168.1x.y

[edit logical-systems c-pe1 protocols]lab@mxB-1# set bgp group ext family l2vpn signaling

Step 8.3

Navigate to the [edit interfaces] hierarchy. Configure the ge-1/0/6 to allow for vlan-tagging and an encapsulation of vlan-vpls. Do not specify any logical interface properties at this hierarchy.

[edit logical-systems c-pe1 protocols]lab@mxB-1# top edit interfaces

[edit interfaces]lab@mxB-1# set ge-1/0/6 vlan-tagging

[edit interfaces]lab@mxB-1# set ge-1/0/6 encapsulation vlan-vpls

Junos MPLS and VPNs


Step 8.4

Navigate to the [edit logical-systems c-pey interfaces] hierarchy. Configure ge-1/0/6 unit 6x0 to be used as the subscriber CE router-facing interfaces for the VPLS.

[edit interfaces]lab@mxB-1# top edit logical-systems c-pey interfaces

[edit logical-systems c-pe1 interfaces]lab@mxB-1# set ge-1/0/6 unit 6x0 vlan-id 6x0

[edit logical-systems c-pe1 interfaces]lab@mxB-1# set ge-1/0/6 unit 6x0 encapsulation vlan-vpls

Step 8.5

Navigate to the [edit logical-systems c-pey routing-instances] hierarchy. Create a new VPLS instance called vpn-x.

[edit logical-systems c-pe1 interfaces]lab@mxB-1# up

[edit logical-systems c-pe1]lab@mxB-1# edit routing-instances

[edit logical-systems c-pe1 routing-instances]lab@mxB-1# set vpn-x instance-type vpls

Step 8.6

Navigate to the [edit logical-systems c-pey routing-instances vpn-x] hierarchy. Add the ge-1/0/6 interface to the routing instance.

[edit logical-systems c-pe1 routing-instances]lab@mxB-1# edit vpn-x

[edit logical-systems c-pe1 routing-instances vpn-2]lab@mxB-1# set interface ge-1/0/6.6x0

Step 8.7

Configure a route target community of target:65x01:x00 for the VPLS.

[edit logical-systems c-pe1 routing-instances vpn-2]lab@mxB-1# set vrf-target target:65x01:x00

Step 8.8

Configure a route distinguisher using the loopback of the customer PE router.

[edit logical-systems c-pe1 routing-instances vpn-2]lab@mxB-1# set route-distinguisher 192.168.1x.y:1

Junos MPLS and VPNs


Step 8.9

Create a BGP VPLS, naming the site after the subscriber CE router, s-cey, and specifying a site ID that matches the y value of the site name. Commit your configuration and exit to operational mode.

[edit logical-systems c-pe1 routing-instances vpn-2]lab@mxB-1# set protocols vpls site s-cey site-identifier y

[edit logical-systems c-pe1 routing-instances vpn-2]lab@mxB-1# commit and-quit commit completeExiting configuration mode

Step 8.10

Check the status of the VPLS connection using the show vpls connections extensive logical-systems c-pey command. Ensure that the remote group has completed the previous step of the lab.

lab@mxB-1> show vpls connections extensive logical-system c-pey Layer-2 VPN connections:



Instance: vpn-2 Local site: s-ce1 (1) Number of local interfaces: 1 Number of local interfaces up: 1 IRB interface present: no ge-1/0/6.620 vt-1/0/10.34603008 2 Intf - vpls vpn-2 local site 1 remote site 2 Label-base Offset Size Range Preference 800000 1 8 8 100 connection-site Type St Time last up # Up trans 2 rmt Up Oct 25 03:14:01 2010 1 Remote PE: 192.168.12.4, Negotiated control-word: No

Junos MPLS and VPNs


Incoming label: 800001, Outgoing label: 800000 Local interface: vt-1/0/10.34603008, Status: Up, Encapsulation: VPLS Description: Intf - vpls vpn-2 local site 1 remote site 2 Connection History: Oct 25 03:14:01 2010 status update timer Oct 25 03:14:01 2010 loc intf up vt-1/0/10.34603008 Oct 25 03:14:01 2010 PE route changed Oct 25 03:14:01 2010 Out lbl Update 800000 Oct 25 03:14:01 2010 In lbl Update 800001 Oct 25 03:14:01 2010 loc intf down

Question: Has a VPLS pseudowire been established to the remote customer PE router?


Step 8.11

Verify that you have connectivity from the local subscriber CE router to the remote subscriber CE router through the VPLS by using the ping utility. You will ping the remote subscriber CE router’s ge-1/1/6 address. Send 5 packets for this test. This task can be accomplished using the following command: ping 10.0.51.y routing-instance s-cey count 5.

lab@mxB-1> ping 10.0.51.y routing-instance s-cey count 5 PING 10.0.51.2 (10.0.51.2): 56 data bytes64 bytes from 10.0.51.2: icmp_seq=0 ttl=64 time=0.813 ms64 bytes from 10.0.51.2: icmp_seq=1 ttl=64 time=0.662 ms64 bytes from 10.0.51.2: icmp_seq=2 ttl=64 time=0.636 ms64 bytes from 10.0.51.2: icmp_seq=3 ttl=64 time=0.646 ms64 bytes from 10.0.51.2: icmp_seq=4 ttl=64 time=0.644 ms





Junos MPLS and VPNs

Appendix A: Lab Diagrams

Junos MPLS and VPNs

A–2 • Lab Diagrams www.juniper.net

Junos MPLS and VPNs

www.juniper.net Lab Diagrams • A–3

Junos MPLS and VPNs


jmv_10.a-r_lgd.pdf

Documents