N

LY

Junos MPLS and VPNs

SE

12.a

TE
R

AL

Detailed Lab GuideVolume 

IN

Worldwide Education Services

1194 North Mathilda Avenue

Sunnyvale, CA 94089
USA
408-745-2000
[Link]
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.
Junos MPLS and VPNs Detailed Lab Guide, Revision 12.a
Copyright 201 Juniper Networks, Inc. All rights reserved.
Printed in USA.
Revision History:
Revision [Link] 2010
Revision [Link] 2013

N
LY

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 12.3R2.5. Juniper Networks assumes no
responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary,
incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.

Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

SE

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

IN

TE
R

AL

The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an
agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and
agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper
Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should
consult the software license for further details.

Contents
Lab 1:

MPLS Fundamentals (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Part 1: Configuring Network Interfaces and Baseline Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Part 2: Configuring Customer Edge Router and Network Interfaces . . . . . . . . . . . . . . . . . . . . . . .1-11
Part 3: Configuring a Static LSP Through the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-19

Lab 2:

Label Distribution Protocols (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Lab 3:

N
LY

Part 1: Configuring Customer Edge Router and Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Part 2: Configuring RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-10
Part 3: Configuring a Explicit Route Object (ERO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-16
Part 4: Configuring LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-19
Part 5: Changing the Default Route Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-22

CSPF (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Lab 4:

SE

Part 1: Creating the Baseline Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

Part 2: Enabling the TED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
Part 3: Configuring RSVP-Signaled LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12
Part 4: Adding Administrative Groups to Core-Facing Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . .3-15
Part 5: Configuring LSPs to Take Gold, Silver, and Bronze Paths Using CSPF . . . . . . . . . . . . . . .3-18

Traffic Protection (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Lab 5:

AL

Part 1: Creating the Baseline Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Part 2: Redistributing Routes into BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5
Part 3: Creating an LSP to the Remote PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8
Part 4: Configuring a Secondary Path for Added Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11
Part 5: Configuring Secondary Standby Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-15
Part 6: Examining a Secondary/Secondary Protected LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-23
Part 7: Examining a Fast-Reroute Protected LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-28
Part 8: Examining Link and Node-Link Protected RSVP LSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-32
Part 9: Configuring LDP Link Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-37

Fate Sharing (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

TE
R

Part 1: Creating the Baseline Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

Part 2: Creating an LSP to the Remote PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
Part 3: Configuring Fate Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11
Part 4: Configuring SRLGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14
Part 5: Configuring Extended Admin Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-19

IN

Lab 6:

Miscellaneous MPLS Features (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Part 1: Configuring the Baseline Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2

Part 2: Configuring a RSVP LSP to Install a Route in the inet.0 Table . . . . . . . . . . . . . . . . . . . . 6-7
Part 3: Configuring MPLS Traffic Engineering to Install an inet.0 Route . . . . . . . . . . . . . . . . .6-11
Part 4: Using Policy to Control LSP Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-14
Part 5: Using LSP Metric to Control LSP Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-22
Part 6: Configuring Your Router to Not Decrement the TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-25
Part 7: Configuring Your Router to Signal Explicit Null . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-27
Part 8: Configuring Your Router to Automatically Adjust the RSVP Reservation Based on Observed
Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-28
Part 9: Using MPLS Ping to Verify LSP Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-30

Contents iii

Lab 7:

L3VPN Static and BGP Routing (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Part 1: Creating the Baseline SP Network and Enabling PE for Layer 3 VPN Signaling . . . . . . . . .7-2
Part 2: Establishing an RSVP Signaled LSP Between PE Routers . . . . . . . . . . . . . . . . . . . . . . . . 7-10
Part 3: Verify CE Router Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
Part 4: Configuring the PE to CE Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14
Part 5: Configuring a Layer 3 VPN Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15
Part 6: Configuring Static Routing Between the PE and CE Routers . . . . . . . . . . . . . . . . . . . . . . 7-17
Part 7: Configuring BGP Routing Between the PE and CE Routers . . . . . . . . . . . . . . . . . . . . . . . 7-23

Lab 8:

Route Reflection and Internet Access (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Lab 9:

N
LY

Part 1: Creating the Baseline SP Network and Enabling PE for Layer 3 VPN Signaling . . . . . . . . .8-2
Part 2: Verifying CE Router Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9
Part 3: Configuring the PE to CE Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14
Part 4: Configuring Two Layer 3 VPN Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16
Part 5: Configuring BGP Routing Between the PE and CE Routers . . . . . . . . . . . . . . . . . . . . . . . 8-19
Part 6: Implementing Route Target Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-31
Part 7: Configuring Internet Access Using a Non-VRF Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 8-37

GRE Tunnel Integration (Detailed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

IN

TE
R

AL

SE

Part 1: Creating the Baseline SP Network and Enabling PE for Layer 3 VPN Signaling . . . . . . . . .9-2
Part 2: Verifying CE Router Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9
Part 3: Configuring the PE to CE Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12
Part 4: Configuring a Layer 3 VPN Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
Part 5: Configuring OSPF Routing Between the PE and CE Routers . . . . . . . . . . . . . . . . . . . . . . 9-15
Part 6: Establishing a GRE Tunnel Between PE Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-20
Part 7: Creating and Adding a Static Route to inet.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-21
Part 8: Redistributing BGP Routes into OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-26

iv Contents

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

Objectives

N
LY

Through demonstrations and hands-on labs, students will gain experience in configuring and
monitoring the Junos OS and in device operations. This course uses Juniper Networks MX Series
3D Universal Edge Routers for the hands-on component, but the lab environment does not
preclude the course from being applicable to other Juniper hardware platforms running the
Junos OS. This course is based on the Junos OS Release 12.3R2.5.

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.

SE

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.

AL

Explain the behavior of inter-area traffic engineered LSPs

IN

TE
R

[Link]

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.

Describe the behavior of fate sharing.

Describe how SRLG changes the CSPF algorithm when computing the path of a
secondary LSP.

Explain how extended admin groups can be used to influence path selection.

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.
Course Overview v

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.

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 multi-access 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.

AL

SE

N
LY

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

IN

TE
R

vi Course Overview

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

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.

Configure BGP and LDP VPLS.

Troubleshoot VPLS.

Describe the Junos OS support for carrier of carriers.

Describe the Junos OS support for interprovider VPNs.

N
LY

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

IN

TE
R

AL

SE

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

[Link]

Course Overview vii

Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: MPLS Fundamentals
MPLS Fundamentals Lab
Chapter 3: Label Distribution Protocols
Label Distribution Protocols Lab

N
LY

Chapter 4: Constrained Shortest Path First

CSPF Lab

Day 2
Chapter 5: Traffic Protection and LSP Optimization
Chapter 6: Fate Sharing
Fate Sharing Lab
Miscellaneous MPLS Features

SE

Chapter 7:

Traffic Protection Lab

Miscellaneous MPLS Features Lab

Chapter 8: VPN Review
Chapter 9: Layer 3 VPNs

Day 3

Chapter 10: Basic Layer 3 VPN Configuration

AL

Layer 3 VPN with Static and BGP Routing Lab

Chapter 11: Troubleshooting Layer 3 VPNs
Chapter 12: Layer 3 VPN Scaling and Internet Access

Route Reflection and Internet Access Lab

TE
R

Chapter 13: Layer 3 VPNsAdvanced Topics

GRE Tunnel Integration Lab

Day 4

Chapter 14: BGP Layer 2 VPNs

IN

BGP Layer 2 VPNs Lab

Chapter 15: Layer 2 VPN Scaling and CoS

Chapter 16: LDP Layer 2 Circuits
Circuit Cross-Connect and LDP Layer 2 Circuits Lab
Chapter 17: Virtual Private LAN Service

viii Course Agenda

[Link]

Day 5
Chapter 18: VPLS Configuration
VPLS Lab
Chapter 19: Interprovider VPNs
Carrier-of-Carriers VPNs Lab
Appendix A: Multicast VPNs

IN

TE
R

AL

SE

N
LY

MVPN Lab

[Link]

Course Agenda 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.
Description

Usage Example

Franklin Gothic

Normal text.

Most of what you read in the Lab Guide

and Student Guide.

Courier New

Console text:

N
LY

Style

Screen captures

commit complete

Noncommand-related
syntax

Exiting configuration mode

Menu names
Text field entry

SE

Input Text Versus Output Text

Select File > Open, and then click

[Link] in the
Filename text box.

GUI text elements:

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

Description

Usage Example

Normal CLI

No distinguishing variant.

Physical interface:fxp0,
Enabled

Text that you must enter.

CLI Input

AL

Normal GUI

TE
R

GUI Input

View configuration history by clicking

Configuration > History.
lab@San_Jose> show route
Select File > Save, and type
[Link] in the Filename field.

IN

Defined and Undefined Syntax Variables

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

Description

Usage Example

CLI Variable

Text where variable value is

already assigned.

policy my-peers

GUI Variable

Click my-peers in the dialog.

CLI Undefined

GUI Undefined

x Document Conventions

Text where the variables value

is the users discretion and text
where the variables 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.
[Link]

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:
[Link]

About This Publication

N
LY

The Junos MPLS and VPNs Detailed Lab Guide was developed and tested using software Release
12.3R2.5. Previous and later versions of software might behave differently so you should always
consult the documentation and release notes for the version of code you are running before
reporting errors.
This document is written and maintained by the Juniper Networks Education Services development
team. Please send questions and suggestions for improvement to training@[Link].

Technical Publications

You can print technical manuals and release notes directly from the Internet in a variety of formats:
Go to [Link]

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.

SE

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

Juniper Networks Support

IN

TE
R

AL

For technical support, contact Juniper Networks at [Link] or

at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).

[Link]

Additional Information xi

N
LY
O
SE
U
AL
N
TE
R
IN
xii Additional Information

[Link]

Lab

N
LY

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

SE

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.

IN

TE
R

AL

[Link]

MPLS Fundamentals (Detailed) Lab 11

Junos MPLS and VPNs

Part 1: Configuring Network Interfaces and Baseline Protocols

In this lab part, you will be using the lab diagram for part 1. 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 [Link]. Once you have completed this, you will set
up a internal BGP (IBGP) peering with the remote teams router.
Note

N
LY

The instructor will tell you the nature of your

access and will provide you with the
necessary details to access your assigned
device.
Step 1.1

Ensure that you know to which device you are assigned. Check with your instructor if
necessary.

SE

Step 1.2

Consult the management network diagram, provided by your instructor, to determine

your devices management address.

AL

Question: What is the management address

assigned to your station?

IN

TE
R

Answer: The answer varies. The sample hostname

and IP address used in the output examples in this
lab are for mxA-1, which uses [Link] as its
management IP address. The actual management
subnet varies between delivery environments.

Lab 12 MPLS Fundamentals (Detailed)

[Link]

Junos MPLS and VPNs

Step 1.3

N
LY

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.

SE

Step 1.4

Log in as user lab with the password supplied by your instructor. Enter
configuration mode and load the reset configuration file
jmv/[Link] and commit.
mxA-1 (ttyp0)

AL

login: lab
Password:

TE
R

--- JUNOS 12.3R2.5 built 2013-03-22 [Link] UTC

lab@mxA-1> configure
Entering configuration mode
[edit]
lab@mxB-1# load override jmv/[Link]
load complete

IN

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

Step 1.5
Navigate to the [edit interfaces] hierarchy level. 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!

[Link]

MPLS Fundamentals (Detailed) Lab 13

Junos MPLS and VPNs

[edit]
lab@mxB-1# edit interfaces
[edit interfaces]
lab@mxB-1# set ge-1/0/0 vlan-tagging
[edit interfaces]
lab@mxB-1# set ge-1/0/0 unit unit vlan-id vlan-id

[edit interfaces]
lab@mxB-1# set ge-1/0/1 vlan-tagging
[edit interfaces]
lab@mxB-1# set ge-1/0/1 unit unit vlan-id vlan-id

N
LY

[edit interfaces]
lab@mxB-1# set ge-1/0/0 unit unit family inet address address/24

[edit interfaces]
lab@mxB-1# set ge-1/0/1 unit unit family inet address address/24

SE

[edit interfaces]
lab@mxB-1# set lo0 unit 0 family inet address address/32

[edit interfaces]
lab@mxB-1#

Step 1.6

AL

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.

IN

TE
R

[edit interfaces]
lab@mxB-1# show
ge-1/0/0 {
vlan-tagging;
unit 220 {
vlan-id 220;
family inet {
address [Link]/24;
}
}
}
ge-1/0/1 {
vlan-tagging;
unit 221 {
vlan-id 221;
family inet {
address [Link]/24;
}
}
}
fxp0 {
description "MGMT INTERFACE - DO NOT DELETE";
Lab 14 MPLS Fundamentals (Detailed)

[Link]

Junos MPLS and VPNs

unit 0 {
family inet {
address [Link]/27;
}
}

N
LY

}
lo0 {
unit 0 {
family inet {
address [Link]/32;
}
}
}

[edit interfaces]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

SE

Step 1.7

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

IN

TE
R

AL

lab@mxB-1> show interfaces terse

Interface
Admin Link Proto
Local
lc-0/0/0
up
up
lc-0/0/0.32769
up
up
vpls
pfe-0/0/0
up
up
pfe-0/0/0.16383
up
up
inet
inet6
pfh-0/0/0
up
up
pfh-0/0/0.16383
up
up
inet
xe-0/0/0
up
up
xe-0/0/1
up
down
xe-0/0/2
up
down
xe-0/0/3
up
down
ge-1/0/0
up
up
ge-1/0/0.220
up
up
inet
[Link]/24
multiservice
ge-1/0/0.32767
up
up
multiservice
ge-1/0/1
up
up
ge-1/0/1.221
up
up
inet
[Link]/24
multiservice
ge-1/0/1.32767
up
up
multiservice
ge-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
ge-1/0/9
up
up
ge-1/1/0
up
up
[Link]

MPLS Fundamentals (Detailed) Lab 15

ge-1/1/1
ge-1/1/2
ge-1/1/3
ge-1/1/4
ge-1/1/5
ge-1/1/6
ge-1/1/7
ge-1/1/8
ge-1/1/9
cbp0
demux0
dsc
em0
em0.0

up
up
up
up
up
up
up
up
up
up
up
up
up
up

down
up
up
up
up
up
up
up
up
up
up
up
up
up
inet

tnp

[Link]/8
[Link]/2
[Link]/2
fe80::200:ff:fe00:4/64
fec0::a:0:0:4/64
0x4

inet

[Link]/27

SE

inet
inet
inet

[Link]
[Link]

down
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up

--> 0/0
--> 0/0

TE
R

AL

up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up
up

inet6
em1
fxp0
fxp0.0
gre
ipip
irb
lo0
lo0.0
lo0.16384
lo0.16385
lsi
me0
me0.0
mtun
pimd
pime
pip0
pp0
tap

N
LY

Junos MPLS and VPNs

IN

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.8
Issue the show route command to view the current route entries.

Lab 16 MPLS Fundamentals (Detailed)

[Link]

Junos MPLS and VPNs

lab@mxB-1> show route

[Link]/32
[Link]/24
[Link]/32
[Link]/24
[Link]/32
[Link]/32

*[Direct/0] [Link]
> via fxp0.0
*[Local/0] [Link]
Local via fxp0.0
*[Direct/0] [Link]
> via ge-1/0/0.220
*[Local/0] [Link]
Local via ge-1/0/0.220
*[Direct/0] [Link]
> via ge-1/0/1.221
*[Local/0] [Link]
Local via ge-1/0/1.221
*[Direct/0] [Link]
> via lo0.0

[Link]/27

N
LY

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

SE

Question: Does the routing table display an entry for

all local interface addresses and directly connected
networks?

AL

Answer: The answer should be yes. If necessary, you

can refer back to the network diagram and compare
it with the displayed route entries.

TE
R

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.

IN

Step 1.9

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

hierarchy level. Configure the core facing interfaces in area [Link]. Remember to
add the loopback interface.

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit protocols ospf
[edit protocols ospf]
lab@mxB-1# set area 0 interface ge-1/0/[Link]
[Link]

MPLS Fundamentals (Detailed) Lab 17

Junos MPLS and VPNs

[edit protocols ospf]

lab@mxB-1# set area 0 interface ge-1/0/[Link]
[edit protocols ospf]
lab@mxB-1# set area 0 interface lo0
[edit protocols ospf]
lab@mxB-1#

Step 1.10

N
LY

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

lab@mxB-1> show ospf neighbor

Address
Interface
[Link]
ge-1/0/0.220
[Link]
ge-1/0/1.221

[edit protocols ospf]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

ID
[Link]
[Link]

SE

State
Full
Full

Pri
128
128

Dead
34
35

AL

Question: Which neighbor state is shown for the

listed interfaces?

IN

TE
R

Answer: The neighbor state for the ge-1/0/0 and

ge-1/0/1 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.
Note

Before proceeding, ensure that the remote

student team in your pod finishes the
previous steps.

Step 1.11

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

lab@mxB-1> ping address rapid count 10

PING [Link] ([Link]): 56 data bytes
!!!!!!!!!!
--- [Link] ping statistics --10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.524/0.716/1.372/0.303 ms

Lab 18 MPLS Fundamentals (Detailed)

[Link]

Junos MPLS and VPNs

lab@mxB-1> ping address rapid count 10

PING [Link] ([Link]): 56 data bytes
!!!!!!!!!!
--- [Link] ping statistics --10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.528/0.576/0.872/0.100 ms

N
LY

lab@mxB-1> ping address rapid count 10

PING [Link] ([Link]): 56 data bytes
!!!!!!!!!!
--- [Link] ping statistics --10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.523/0.572/0.882/0.104 ms

Question: Are the ping tests successful?

SE

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

AL

lab@mxB-1> configure
Entering configuration mode

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

Step 1.13

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

TE
R

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 teams PE router. Refer to the network diagram for this lab as necessary.

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

IN

[edit protocols bgp]

lab@mxB-1# set group my-int-group type internal

[edit protocols bgp]

lab@mxB-1# set group my-int-group local-address local-loopback-address
[edit protocols bgp]
lab@mxB-1# set group my-int-group neighbor remote-loopback-address
[edit protocols bgp]
lab@mxB-1# commit
commit complete
[Link]

MPLS Fundamentals (Detailed) Lab 19

Junos MPLS and VPNs

[edit protocols bgp]

lab@mxB-1#

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

N
LY

[edit protocols bgp]

lab@mxB-1# run show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table
Tot Paths Act Paths Suppressed
History Damp State
Pending
inet.0
0
0
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
[Link]
65512
2
3
0
0
2 0/
0/0/0
0/0/0/0

SE

Question: How many BGP neighbors does your

router currently list?

AL

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.

TE
R

Question: Does your session show an Active

state?

IN

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.

Lab 110 MPLS Fundamentals (Detailed)

[Link]

Junos MPLS and VPNs

Part 2: Configuring Customer Edge Router and Network Interfaces

In this lab part, you will reference the lab diagram for parts 2 and 3. 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.

N
LY

Step 2.1

Refer to the lab diagram to ensure you navigate to the correct virtual router name.
Navigate to the [edit routing-instances instance-name] 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 protocols bgp]

SE

lab@mxB-1# top edit routing-instances instance-name

[edit routing-instances ceB-1]
lab@mxB-1# set instance-type virtual-router

[edit routing-instances ceB-1]

lab@mxB-1# set interface ge-1/1/4

Step 2.2

AL

[edit routing-instances ceB-1]

lab@mxB-1# set interface lo0.1

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

IN

TE
R

[edit routing-instances ceB-1]

lab@mxB-1# show
instance-type virtual-router;
interface ge-1/1/4.0; ## 'ge-1/1/4.0' is not defined
interface 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.

[Link]

MPLS Fundamentals (Detailed) Lab 111

Junos MPLS and VPNs

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 ceB-1]
lab@mxB-1# top edit interfaces

N
LY

[edit interfaces]
lab@mxB-1# set ge-1/0/4 unit 0 family inet address address/24
[edit interfaces]
lab@mxB-1# set ge-1/1/4 unit 0 family inet address address/24

[edit interfaces]
lab@mxB-1# set lo0 unit 1 family inet address address

SE

[edit interfaces]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 2.4

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

AL

lab@mxB-1> ping address routing-instance instance-name count 1

PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=64 time=2.006 ms

IN

TE
R

--- [Link] ping statistics --1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.006/2.006/2.006/0.000 ms
Note

Use Ctrl + c to stop a continuous ping

operation.

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 the network diagram
for appropriate peer autonomous system numbers.

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit protocols bgp
Lab 112 MPLS Fundamentals (Detailed)

[Link]

Junos MPLS and VPNs

[edit protocols bgp]

lab@mxB-1# set group my-ext-group type external
[edit protocols bgp]
lab@mxB-1# set group my-ext-group peer-as peer-as
[edit protocols bgp]
lab@mxB-1# set group my-ext-group neighbor address

N
LY

[edit protocols bgp]

lab@mxB-1# show group my-ext-group
type external;
peer-as 65201;
neighbor [Link];

Question: Do you have to configure the group type

as external?

SE

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

AL

Navigate to the [edit routing-instances instance-name] 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 verify that the neighbor relationship is established
before moving on to the next step.

TE
R

[edit protocols bgp]

lab@mxB-1# top edit routing-instances instance-name
[edit routing-instances ceB-1]
lab@mxB-1# set routing-options autonomous-system as-number

IN

[edit routing-instances ceB-1]

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

[edit routing-instances ceB-1 protocols bgp]

lab@mxB-1# set group my-ext-group peer-as 65512
[edit routing-instances ceB-1 protocols bgp]
lab@mxB-1# set group my-ext-group neighbor address
[edit routing-instances ceB-1 protocols bgp]
[Link]

MPLS Fundamentals (Detailed) Lab 113

Junos MPLS and VPNs

lab@mxB-1# commit
commit complete

N
LY

[edit routing-instances ceB-1 protocols bgp]

lab@mxB-1# run show bgp summary
Groups: 3 Peers: 3 Down peers: 0
Table
Tot Paths Act Paths Suppressed
History Damp State
Pending
inet.0
1
1
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
[Link]
65512
8
7
0
0
2:12 Establ
[Link].0: 1/1/1/0
[Link]
65201
6
8
0
0
2:12 Establ
inet.0: 0/0/0/0
[Link]
65512
84
83
0
0
36:23 Establ
inet.0: 1/1/1/0

SE

Question: Is your EBGP peering established

between your PE and CE routers?

AL

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
[Link].0, followed by the route
information.

TE
R

Question: Are you sending any routes from your CE

router?

IN

Answer: No, at this time there should not be any

routes being sent from the CE router.

Step 2.7

Navigate to the [edit policy-options] hierarchy and configure a policy

named ce-export-loopback. Allow your CE routers 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 routing-instances ceB-1 protocols bgp]

lab@mxB-1# top edit policy-options
[edit policy-options]
lab@mxB-1# set policy-statement ce-export-loopback term 1 from protocol direct
Lab 114 MPLS Fundamentals (Detailed)

[Link]

Junos MPLS and VPNs

[edit policy-options]
lab@mxB-1# set policy-statement ce-export-loopback term 1 from route-filter
ce-loopback-address exact
[edit policy-options]
lab@mxB-1# set policy-statement ce-export-loopback term 1 then accept
[edit policy-options]
lab@mxB-1# top edit routing-instances instance-name

N
LY

[edit routing-instances ceB-1]

lab@mxB-1# set protocols bgp group my-ext-group export ce-export-loopback

[edit routing-instances ceB-1]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

SE

Step 2.8

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@mxB-1> show route advertising-protocol bgp local-pe-ge-1/0/4-address

AL

[Link].0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/32
Self
I
lab@mxB-1> show route advertising-protocol bgp remote-pe-loopback-address

IN

TE
R

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/32
[Link]
100
65201 I

Note

Before proceeding, ensure that the remote

student team in your pod finishes the
previous steps.

Step 2.9

Verify that you are receiving the remote CE loopback from your IBGP neighbor. The
total destination routes may differ in your outputs.
lab@mxB-1> show route receive-protocol bgp remote-pe-loopback-address
inet.0: 37 destinations, 37 routes (36 active, 0 holddown, 1 hidden)

[Link]

MPLS Fundamentals (Detailed) Lab 115

Junos MPLS and VPNs

[Link].0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

lab@mxB-1>

Question: Where is the route the remote peer is

advertising to us?

N
LY

Answer: It is being received but is stored as a

hidden route, which indicates you might have a
problem.
Step 2.10

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

lab@mxB-1> show route hidden extensive

TE
R

AL

SE

inet.0: 37 destinations, 37 routes (36 active, 0 holddown, 1 hidden)

[Link]/32 (1 entry, 0 announced)
BGP
Preference: 170/-101
Next hop type: Unusable
Address: 0x24cf8a8
Next-hop reference count: 1
State: <Hidden Int Ext>
Local AS: 65512 Peer AS: 65512
Age: 1:09
Validation State: unverified
Task: BGP_65512.[Link]+52758
AS path: 65202 I
Accepted
Localpref: 100
Router ID: [Link]
Indirect next hops: 1
Protocol next hop: [Link]
Indirect next hop: 0 - INH Session ID: 0x0

IN

Question: Why is the protocol (BGP) next hop for the

route? Which router in the topology owns that
address?

Answer: The answer will vary by team. In the

example the protocol next hop is [Link]. This
address is owned by the remote CE.

Lab 116 MPLS Fundamentals (Detailed)

[Link]

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 can not determine the
physical next hop needed to install this route.

N
LY

Question: How do you fix this problem and get the

route to be a usable route?

SE

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

AL

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.

TE
R

lab@mxB-1> configure
Entering configuration mode

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

IN

[edit policy-options]
lab@mxB-1# set policy-statement nhs term 1 from protocol bgp
[edit policy-options]
lab@mxB-1# set policy-statement nhs term 1 then next-hop self
[edit policy-options]
lab@mxB-1# set policy-statement nhs term 1 then accept
[edit policy-options]
lab@mxB-1# top edit protocols bgp group my-int-group

[edit protocols bgp group my-int-group]

lab@mxB-1# set export nhs
[Link]

MPLS Fundamentals (Detailed) Lab 117

Junos MPLS and VPNs

[edit protocols bgp group my-int-group]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>
Note

N
LY

Before proceeding, ensure that the remote

student team in your pod finishes the
previous steps.
Step 2.12

Verify that the route to the remote CE routers loopback address is now usable and
installed in the routing table.
lab@mxB-1> show route receive-protocol bgp remote-pe-loopback-address

SE

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/32
[Link]
100
65202 I

[Link].0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

AL

Question: Do you see the route now?

TE
R

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.

IN

Step 2.13

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

lab@mxB-1> show route receive-protocol bgp local-pe-ge-1/0/4-address

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)
[Link].0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/32
[Link]
65512 65202 I
lab@mxB-1> show route table [Link].0
[Link].0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
Lab 118 MPLS Fundamentals (Detailed)

[Link]

Junos MPLS and VPNs

[Link]/24

*[Direct/0] [Link]
> via ge-1/1/4.0
*[Local/0] [Link]
Local via ge-1/1/4.0
*[Direct/0] [Link]
> via lo0.1
*[BGP/170] [Link], localpref 100
AS path: 65512 65202 I, validation-state: unverified
> to [Link] via ge-1/1/4.0

[Link]/32
[Link]/32
[Link]/32

N
LY

Question: Is the route present in your CE routing

table?

SE

Answer: Yes, you should now see the route in your

routing instance table.

Do not proceed until the remote team finishes Part 2.

STOP

Part 3: Configuring a Static LSP Through the Core

AL

In this lab part, you will reference the lab diagram for parts 2 and 3. 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

TE
R

Enter into configuration mode and navigate to the [edit interfaces]

hierarchy. Configure the core facing interface to allow MPLS traffic.

lab@mxB-1> configure
Entering configuration mode

IN

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

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.

[Link]

MPLS Fundamentals (Detailed) Lab 119

Junos MPLS and VPNs

[edit interfaces]
lab@mxB-1# top edit protocols mpls
[edit protocols mpls]
lab@mxB-1# set interface all
[edit protocols mpls]
lab@mxB-1# set interface fxp0 disable
[edit protocols mpls]
lab@mxB-1#

N
LY

Step 3.3

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

SE

[edit protocols mpls]

lab@mxB-1# run show route table mpls.0

[edit protocols mpls]

lab@mxB-1# commit
commit complete

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

+ = Active Route, - = Last Active, * = Both
*[MPLS/0] [Link],
Receive
*[MPLS/0] [Link],
Receive
*[MPLS/0] [Link],
Receive
*[MPLS/0] [Link],
Receive

metric 1

metric 1

AL

1
2

metric 1

13

metric 1

IN

TE
R

Question: What are the routes that you see?

Answer: You should see the four 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, Label 2 is the IPv6 explicit null label, and
Label 13 is the GAL indicator.

Step 3.4
Review the interfaces that are participating in MPLS to ensure that we have the
proper configuration by executing the run show mpls interface command.
[edit protocols mpls]
lab@mxB-1# run show mpls interface
Lab 120 MPLS Fundamentals (Detailed)

[Link]

Junos MPLS and VPNs

Interface
ge-1/0/0.220

State
Up

Administrative groups (x: extended)

<none>

Question: What interface do you see?

N
LY

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.
Step 3.5

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

[edit protocols mpls]

lab@mxB-1# set static-label-switched-path my-static-lsp ingress to
remote-pe-loopback-address

SE

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

AL

[edit protocols mpls]

lab@mxB-1# edit static-label-switched-path my-static-lsp ingress

[edit protocols mpls static-label-switched-path my-static-lsp ingress]

lab@mxB-1# set next-hop next-hop-address

TE
R

[edit protocols mpls static-label-switched-path my-static-lsp ingress]

lab@mxB-1# set push label

IN

[edit protocols mpls static-label-switched-path my-static-lsp ingress]

lab@mxB-1# show
next-hop [Link];
to [Link];
push 1000201;
[edit protocols mpls static-label-switched-path my-static-lsp ingress]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 3.7
Issue the show mpls static-lsp ingress command to view the current
status of the recently configured LSP.
[Link]

MPLS Fundamentals (Detailed) Lab 121

Junos MPLS and VPNs

lab@mxB-1> show mpls static-lsp ingress

Ingress LSPs:
LSPname
To
my-static-lsp
[Link]
Total 1, displayed 1, Up 1, Down 0

State
Up

Question: What is the state of the static LSP?

Step 3.8

N
LY

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

lab@mxB-1> show route remote-ce-loopback-address

Review the route being used for the remote CE routers loopback by issuing the
show route remote-ce-loopback-address command.

*[BGP/170] [Link], localpref 100, from [Link]

AS path: 65202 I, validation-state: unverified
> to [Link] via ge-1/0/0.220, Push 1000201

[Link]/32

SE

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

*[BGP/170] [Link], localpref 100

AS path: 65512 65202 I, validation-state: unverified
> to [Link] via ge-1/1/4.0

[Link]/32

AL

[Link].0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

IN

TE
R

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
1000201 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 122 MPLS Fundamentals (Detailed)

[Link]

Junos MPLS and VPNs

lab@mxB-1> show mpls static-lsp statistics ingress

Ingress LSPs:
LSPname
To
State
my-static-lsp
[Link]
Up
Total 1, displayed 1, Up 1, Down 0

Packets
0

Bytes
0

Step 3.10
Test the LSP by using the ping utility from the virtual router by executing the ping
remote-ce-loopback source local-ce-loopback count 10 rapid
routing-instance instance-name command.

N
LY

lab@mxB-1> ping remote-ce-loopback source local-ce-loopback count 10 rapid

routing-instance instance-name

PING [Link] ([Link]): 56 data bytes

!!!!!!!!!!
--- [Link] ping statistics --10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.562/0.596/0.838/0.081 ms

Step 3.11

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

Packets
10

Bytes
840

SE

lab@mxB-1> show mpls static-lsp statistics ingress

Ingress LSPs:
LSPname
To
State
my-static-lsp
[Link]
Up
Total 1, displayed 1, Up 1, Down 0

TE
R

AL

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.

IN

Step 3.12

Log out of your assigned device using the exit command.

lab@mxB-1> exit
mxB-1 (ttyu0)
login:

STOP

[Link]

Tell your instructor that you have completed this lab.

MPLS Fundamentals (Detailed) Lab 123

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 124 MPLS Fundamentals (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

MPLS Fundamentals (Detailed) Lab 125

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 126 MPLS Fundamentals (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

MPLS Fundamentals (Detailed) Lab 127

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 128 MPLS Fundamentals (Detailed)

[Link]

Lab

N
LY

Label Distribution Protocols (Detailed)

Overview

This lab demonstrates configuration and monitoring of Resource Reservation Protocol

(RSVP) and Label Distribution (LDP) signaled 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.

SE

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

IN

TE
R

AL

[Link]

Label Distribution Protocols (Detailed) Lab 21

Junos MPLS and VPNs

Part 1: Configuring Customer Edge Router and Network Interfaces

Note

N
LY

In this lab part, you will configure the virtual router representing the customer edge
(CE) router. You will load a configuration that will automatically configure the
interfaces and networks needed to establish an external BGP (EBGP) peering
between your customer edge router and your provider edge (PE) router. The loaded
configuration will configure your virtual router and all interfaces for both routers and
also configure the EBGP peering session between the two routers. You will then
configure your CE router to advertise the loopback address from your CE device to
your PE router. Your PE router will share these routes with your internal BGP (IBGP)
peer.

The instructor will tell you the nature of your

access and will provide you with the
necessary details to access your assigned
device.

SE

Step 1.1

Ensure that you know to which device you are assigned. Check with your instructor if
necessary.

Step 1.2

AL

Consult the management network diagram, provided by your instructor, to determine

your devices management address.

Question: What is the management address

assigned to your station?

IN

TE
R

Answer: The answer varies. The sample hostname

and IP address used in the output examples in this
lab are for mxB-1, which uses [Link] as its
management IP address. The actual management
subnet varies between delivery environments.

Lab 22 Label Distribution Protocols (Detailed)

[Link]

Junos MPLS and VPNs

Step 1.3

N
LY

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
mxB-1 using the Secure CRT program.

SE

Step 1.4

Log in as user lab with the password supplied by your instructor. Enter
configuration mode and load the reset configuration file
jmv/[Link] and commit.
mxB-1 (ttyp0)

AL

login: lab
Password:

TE
R

--- JUNOS 12.3R2.5 built 2013-03-22 [Link] UTC

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# load override jmv/[Link]
load complete

IN

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

Step 1.5
Verify that your Open Shortest Path First (OSPF) neighbor relationships are up and
operational.
[edit]
lab@mxB-1# run show ospf neighbor

[Link]

Label Distribution Protocols (Detailed) Lab 23

Junos MPLS and VPNs

Address
[Link]
[Link]

Interface
ge-1/0/0.220
ge-1/0/1.221

State
Full
Full

ID
[Link]
[Link]

Pri
128
128

Dead
32
31

Question: What is the state of your PE routers OSPF

neighbors?

N
LY

Answer: After a short time, the OSPF neighbors

should attain the Full state.
Step 1.6

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

[edit]
lab@mxB-1# run ping local-pe-address routing-instance instance-name count 1
PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=64 time=0.722 ms

SE

--- [Link] ping statistics --1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.722/0.722/0.722/0.000 ms

AL

Question: Was the attempt to ping successful?

Answer: The ping should be successful.

Step 1.7

TE
R

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

IN

[edit]
lab@mxB-1# run show bgp summary
Groups: 3 Peers: 3 Down peers: 0
Table
Tot Paths Act Paths Suppressed
History Damp State
Pending
inet.0
0
0
0
0
0
0
Peer
AS
InPkt
OutPkt
OutQ
Flaps Last Up/Dwn
State|#Active/Received/Accepted/Damped...
[Link]
65512
24
23
0
0
9:17 Est
abl
[Link].0: 0/0/0/0
[Link]
65201
23
25
0
0
9:17 Est
abl
inet.0: 0/0/0/0
[Link]
65512
24
23
0
0
9:22 Establ
inet.0: 0/0/0/0

Lab 24 Label Distribution Protocols (Detailed)

[Link]

Junos MPLS and VPNs

Question: Are all of the BGP sessions in the

Established state?

Answer: All of the BGP sessions should be in the

Established state.
Step 1.8

N
LY

Use the run show route advertising-protocol bgp command to

determine which routes that your CE router is advertising to your PE router.
[edit]
lab@mxB-1# run show route advertising-protocol bgp local-pe-ge-1/0/4-address

SE

Question: How many routes are being advertised

from your CE router to your PE router?

Answer: There are no routes currently being

advertised. You will configure your CE router to
advertise its loopback address in the next step.
Step 1.9

AL

Navigate to the [edit policy-options] hierarchy and configure a policy

named vr-export-loopback. Configure the policy to advertise your CE routers
loopback address.

TE
R

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

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

IN

[edit policy-options]
lab@mxB-1# set policy-statement vr-export-loopback term 1 from route-filter
local-ce-loopback-address exact
[edit policy-options]
lab@mxB-1# set policy-statement vr-export-loopback term 1 then accept

Step 1.10

Navigate to the [edit routing-instance instance-name] hierarchy and

apply the 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@mxB-1# top edit routing-instances instance-name

[Link]

Label Distribution Protocols (Detailed) Lab 25

Junos MPLS and VPNs

[edit routing-instances ce1-1]

lab@mxB-1# set protocols bgp group my-ext-group export vr-export-loopback
[edit routing-instances ce1-1]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 1.11

N
LY

Verify that you are advertising your CE routers loopback address to your EBGP peer.
lab@mxB-1> show route advertising-protocol bgp local-pe-ge-1/0/4-address

[Link].0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/32
Self

SE

Question: Are any routes being advertised from your

CE router to your PE router?

Answer: The CE router is advertising a route that

represents its loopback address.

AL

Step 1.12

Verify the advertisement of the CE routers loopback route from the local PE router to
the remote IBGP peer.

lab@mxB-1> show route advertising-protocol bgp remote-pe-loopback-address

TE
R

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/32
[Link]
100
65201 I

IN

Question: What route is being advertised from your

PE router to the remote PE router? Why is it being
advertised?

Answer: The local PE router is advertising the local

CE routers loopback to the remote PE. The local PE
is automatically advertising this route to its IBGP
peers due to BGPs default rules of route
advertisement.

Lab 26 Label Distribution Protocols (Detailed)

[Link]

Junos MPLS and VPNs

Note

Before proceeding, ensure that the remote

student team in your pod finishes the
previous steps.
Step 1.13
Verify that the local PE is receiving the remote CE routers loopback from the remote
PE neighbor.

N
LY

lab@mxB-1> show route receive-protocol bgp remote-pe-loopback-address

inet.0: 37 destinations, 37 routes (36 active, 0 holddown, 1 hidden)

[Link].0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

SE

Question: Is the local PE router installing any routes

from the remote PE into the routing table?

Answer: No routes from the remote PE are being

installed in the routing tables.

AL

Question: Do you notice anything interesting about

the output of the command?

TE
R

Answer: There are hidden routes being received but

not installed in the routing table.

Step 1.14

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

lab@mxB-1> show route hidden extensive

IN

inet.0: 37 destinations, 37 routes (36 active, 0 holddown, 1 hidden)

[Link]/32 (1 entry, 0 announced)
BGP
Preference: 170/-101
Next hop type: Unusable
Address: 0x24cf8a8
Next-hop reference count: 1
State: <Hidden Int Ext>
Local AS: 65512 Peer AS: 65512
Age: 4:07
Validation State: unverified
Task: BGP_65512.[Link]+179
AS path: 65202 I
Accepted
[Link]

Label Distribution Protocols (Detailed) Lab 27

Junos MPLS and VPNs

Localpref: 100
Router ID: [Link]
Indirect next hops: 1
Protocol next hop: [Link]
Indirect next hop: 0 - INH Session ID: 0x0
[Link].0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

N
LY

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.

SE

Question: How do we fix this problem and get the

route to be a usable route?

Step 1.15

AL

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.

TE
R

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.

IN

lab@mxB-1> configure
Entering configuration mode

[edit]
lab@mxB-1# edit policy-options
[edit policy-options]
lab@mxB-1# set policy-statement nhs term 1 from protocol bgp
[edit policy-options]
lab@mxB-1# set policy-statement nhs term 1 then next-hop self
[edit policy-options]
lab@mxB-1# set policy-statement nhs term 1 then accept
Lab 28 Label Distribution Protocols (Detailed)

[Link]

Junos MPLS and VPNs

Step 1.16
Apply the new 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@mxB-1# top edit protocols bgp group my-int-group
[edit protocols bgp group my-int-group]
lab@mxB-1# set export nhs

N
LY

[edit protocols bgp group my-int-group]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

lab@mxB-1>
Note

SE

Before proceeding, ensure that the remote

student team in your pod finishes the
previous steps.

Step 1.17

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

AL

lab@mxB-1> show route receive-protocol bgp remote-pe-loopback-address

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/32
[Link]
100
65202 I

IN

TE
R

[Link].0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

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.18
Verify you are receiving and installing the route to the remote CE router in your
virtual router.
[Link]

Label Distribution Protocols (Detailed) Lab 29

Junos MPLS and VPNs

lab@mxB-1> show route remote-ce-loopback-address

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
[Link]/32

*[BGP/170] [Link], localpref 100, from [Link]

AS path: 65202 I, validation-state: unverified
> to [Link] via ge-1/0/0.220
to [Link] via ge-1/0/1.221

[Link]/32

N
LY

[Link].0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

*[BGP/170] [Link], localpref 100

AS path: 65512 65202 I, validation-state: unverified
> to [Link] via ge-1/1/4.0

SE

Question: Is the route present in your CE routers

routing table?

Answer: Yes, you should now see the route in your

routing instance table.

Part 2: Configuring RSVP

AL

Do not proceed until the remote team finishes Part 1.

STOP

IN

Step 2.1

TE
R

In this lab part, 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.
Enter into configuration mode and navigate to the [edit interfaces]
hierarchy. Configure the core facing interfaces to allow multiprotocol label switching
(MPLS) traffic.

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit interfaces
[edit interfaces]
lab@mxB-1# set ge-1/0/0 unit unit family mpls
[edit interfaces]
lab@mxB-1# set ge-1/0/1 unit unit family mpls
Lab 210 Label Distribution Protocols (Detailed)

[Link]

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@mxB-1# top edit protocols mpls

[edit protocols mpls]

lab@mxB-1# set interface fxp0 disable

Step 2.3

N
LY

[edit protocols mpls]

lab@mxB-1# set interface all

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.

SE

[edit protocols mpls]

lab@mxB-1# commit
commit complete

[edit protocols mpls]

lab@mxB-1# run show mpls interface
Interface
State
Administrative groups (x: extended)
ge-1/0/0.220
Up
<none>
ge-1/0/1.221
Up
<none>

Step 2.4

AL

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.

TE
R

[edit protocols mpls]

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

IN

[edit protocols rsvp]

lab@mxB-1# set interface ge-1/0/[Link]
[edit protocols rsvp]
lab@mxB-1# show
interface ge-1/0/0.220;
interface ge-1/0/1.221;
[edit protocols rsvp]
lab@mxB-1# commit
commit complete

[Link]

Label Distribution Protocols (Detailed) Lab 211

Junos MPLS and VPNs

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.

N
LY

Step 2.5

[edit protocols rsvp]

lab@mxB-1# top edit protocols mpls

[edit protocols mpls]

lab@mxB-1# set no-cspf

SE

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
localPE-to-remotePE-pod. For example, if you are assigned router mxB-1,
your peer router is mxB-2 and your pod is B. The LSP for mxB-1 should be named
pe1-to-pe2-B. Your LSP should egress at your remote peers loopback address.
Verify that the configuration looks correct. Commit and exit to operation mode when
you are satisfied with the changes.

AL

[edit protocols mpls]

lab@mxB-1# set label-switched-path localPE-to-remotePE-pod to
remote-PE-loopback-address

IN

TE
R

[edit protocols mpls]

lab@mxB-1# show
no-cspf;
label-switched-path pe1-to-pe2-B {
to [Link];
}
interface all;
interface fxp0.0 {
disable;
}
[edit protocols mpls]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

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

Lab 212 Label Distribution Protocols (Detailed)

[Link]

Junos MPLS and VPNs

lab@mxB-1> show mpls lsp

Ingress LSP: 1 sessions
To
From
State Rt P
[Link]
[Link]
Up
0 *
Total 1 displayed, Up 1, Down 0
Egress LSP: 1 sessions
To
From
State
[Link]
[Link]
Up
Total 1 displayed, Up 1, Down 0

ActivePath

LSPname
pe1-to-pe2-B

Rt Style Labelin Labelout LSPname

0 1 FF
3
- pe2-to-pe1-2

N
LY

Transit LSP: 0 sessions

Total 0 displayed, Up 0, Down 0

Question: How many LSPs are reflected in the

output and what are the terminating points?

AL

SE

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.

IN

TE
R

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@mxB-1> show mpls lsp ingress extensive

Ingress LSP: 1 sessions
[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2-B
ActivePath: (primary)
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
[Link]

Label Distribution Protocols (Detailed) Lab 213

Junos MPLS and VPNs

N
LY

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):
[Link] [Link] [Link] [Link]
4 May 9 [Link].819 Selected as active path
3 May 9 [Link].819 Record Route: [Link] [Link] [Link]
[Link]
2 May 9 [Link].819 Up
1 May 9 [Link].757 Originate Call
Created: Thu May 9 [Link] 2013
Total 1 displayed, Up 1, Down 0

SE

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
lab diagram you can determine the exact path the
LSP is using.
Step 2.8

AL

Verify traffic that is destined to the remote CE routers loopback will use the LSP by
issuing the show route remote-CE-loopback-address command.

lab@mxB-1> show route remote-CE-loopback-address

TE
R

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
[Link]/32
pe1-to-pe2-B

*[BGP/170] [Link], localpref 100, from [Link]

AS path: 65202 I, validation-state: unverified
> to [Link] via ge-1/0/0.220, label-switched-path

IN

[Link].0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
[Link]/32

*[BGP/170] [Link], localpref 100

AS path: 65512 65202 I, validation-state: unverified
> to [Link] via ge-1/1/4.0

Lab 214 Label Distribution Protocols (Detailed)

[Link]

Junos MPLS and VPNs

Question: Will traffic destined for the remote CE get

forwarded using the LSP?

Answer: The route to the remote CE routers

loopback address is associated with an LSP,
therefore all packets destined to that address
should be forwarded using the LSP.

N
LY

Step 2.9

Verify the remote CE routers loopback is reachable from your local CE router by
sending five Internet Control Message Protocol (ICMP) packets. Make sure to source
the ICMP packets from the local CE routers loopback address.

SE

lab@mxB-1> ping remote-ce-loopback-address source local-ce-loopback-address

routing-instance instance-name count 5
PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=59 time=0.869 ms
64 bytes from [Link]: icmp_seq=1 ttl=59 time=0.787 ms
64 bytes from [Link]: icmp_seq=2 ttl=59 time=0.701 ms
64 bytes from [Link]: icmp_seq=3 ttl=59 time=0.688 ms
64 bytes from [Link]: icmp_seq=4 ttl=59 time=0.755 ms

AL

--- [Link] ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.688/0.760/0.869/0.065 ms

TE
R

Question: Were the pings successful?

Answer: All five pings should be successful.

Step 2.10

Verify the ICMP packets traversed the LSP by displaying the traffic statistics for the
LSP.

IN

lab@mxB-1> show mpls lsp statistics ingress

Ingress LSP: 1 sessions
To
From
State
Packets
[Link]
[Link]
Up
5
Total 1 displayed, Up 1, Down 0

[Link]

Bytes LSPname
420 pe1-to-pe2-B

Label Distribution Protocols (Detailed) Lab 215

Junos MPLS and VPNs

Question: How many packets have been forwarded

over the LSP?

N
LY

Answer: The example shows that five packets have

been forwarded over the LSP. If the other team has
also performed the ping test, you may see that 10
packets have traversed the LSP.

Do not proceed until the remote team finishes Part 2.

STOP

Part 3: Configuring a Explicit Route Object (ERO)

SE

In this lab part, 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 local PE
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 onlyyou might choose to engineer your LSP path differently.

AL

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.

TE
R

lab@mxB-1> configure
Entering configuration mode

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

IN

[edit protocols mpls]

lab@mxB-1# set path my-ERO p4-address strict
[edit protocols mpls]
lab@mxB-1# set path my-ERO p3-address loose
[edit protocols mpls]
lab@mxB-1# show
no-cspf;
label-switched-path pe1-to-pe2-B {
to [Link];
}
path my-ERO {
[Link] strict;
Lab 216 Label Distribution Protocols (Detailed)

[Link]

Junos MPLS and VPNs

[Link] loose;

}
interface all;
interface fxp0.0 {
disable;
}

[edit protocols mpls]

lab@mxB-1

Step 3.2

O
SE

[edit protocols mpls]

lab@mxB-1# set label-switched-path ?
Possible completions:
<path_name>
Name of path
pe1-to-pe2-B
Name of path

N
LY

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@mxB-1# set label-switched-path lsp-name primary my-ERO

TE
R

AL

[edit protocols mpls]

lab@mxB-1# show
no-cspf;
label-switched-path pe1-to-pe2-B {
to [Link];
primary my-ERO;
}
path my-ERO {
[Link] strict;
[Link] loose;
}
interface all;
interface fxp0.0 {
disable;
}

IN

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 3.3
Verify the status of your LSP using the show mpls lsp ingress command.
lab@mxB-1> show mpls lsp ingress
Ingress LSP: 1 sessions
[Link]

Label Distribution Protocols (Detailed) Lab 217

Junos MPLS and VPNs

To
From
State Rt P
[Link]
[Link]
Up
0 *
Total 1 displayed, Up 1, Down 0

ActivePath
my-ERO

LSPname
pe1-to-pe2-B

Question: What is the state of your LSP?

N
LY

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?

SE

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.

AL

lab@mxB-1> show mpls lsp ingress detail

Ingress LSP: 1 sessions

IN

TE
R

[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2-B
ActivePath: my-ERO (primary)
LSPtype: Static Configured, Penultimate hop popping
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):
[Link] [Link] [Link] [Link] [Link]
Total 1 displayed, Up 1, Down 0

Lab 218 Label Distribution Protocols (Detailed)

[Link]

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.

N
LY

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

lab@mxB-1> configure
Entering configuration mode

Step 4.2

AL

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

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

SE

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

TE
R

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@mxB-1# edit protocols ldp

IN

[edit protocols ldp]

lab@mxB-1# set interface all
[edit protocols ldp]
lab@mxB-1# set interface fxp0 disable
[edit protocols ldp]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

[Link]

Label Distribution Protocols (Detailed) Lab 219

Junos MPLS and VPNs

Step 4.3
Verify the proper interfaces are participating in LDP by issuing the command show
ldp interface.
lab@mxB-1> show ldp interface
Interface
Label space ID
lo0.0
[Link]:0
ge-1/0/0.220
[Link]:0
ge-1/0/1.221
[Link]:0

Nbr count
0
1
1

Next hello
0
2
1

N
LY

Question: Do you see the correct interfaces?

SE

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.
Hold time
20
20

AL

lab@mxB-1> show ldp session

Address
State
Connection
[Link]
Operational Open
[Link]
Operational Open

Adv. Mode
DU
DU

Question: What is the status of the connection?

IN

Step 4.5

TE
R

Answer: The connection should display as Open for

each session.

Verify traffic that is destined to the remote CE routers loopback will use the LSP by
issuing the show route remote-ce-loopback-address command.

lab@mxB-1> show route remote-ce-loopback-address

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
[Link]/32

*[BGP/170] [Link], localpref 100, from [Link]

AS path: 65202 I, validation-state: unverified
> to [Link] via ge-1/0/0.220, Push 300080
to [Link] via ge-1/0/1.221, Push 300096

[Link].0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
Lab 220 Label Distribution Protocols (Detailed)

[Link]

Junos MPLS and VPNs

[Link]/32

*[BGP/170] [Link], localpref 100

AS path: 65512 65202 I, validation-state: unverified
> to [Link] via ge-1/1/4.0

Question: Will traffic destined for the remote CE get

forwarded using an LSP?

N
LY

Answer: The route to the remote CE routers

loopback address is associated with an MPLS label
push operation, therefore all packets destined to
that address should be forwarded using an LSP.
Step 4.6

Verify the remote CE routers loopback is reachable from your local CE router by
sending five ICMP packets.

AL

SE

lab@mxB-1> ping remote-ce-loopback-address source local-ce-loopback-address

routing-instance instance-name count 5
PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=59 time=0.768 ms
64 bytes from [Link]: icmp_seq=1 ttl=59 time=0.784 ms
64 bytes from [Link]: icmp_seq=2 ttl=59 time=0.778 ms
64 bytes from [Link]: icmp_seq=3 ttl=59 time=0.734 ms
64 bytes from [Link]: icmp_seq=4 ttl=59 time=0.693 ms

--- [Link] ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.693/0.751/0.784/0.034 ms

TE
R

Question: Were the pings successful?

Answer: All five pings should be successful.

IN

Step 4.7

Verify these ICMP packets traversed the LSP by displaying the traffic statistics for
the LSP.

lab@mxB-1> show ldp traffic-statistics

INET FEC Statistics:
FEC
[Link]/32
[Link]/32
[Link]/32
[Link]

Type
Transit
Ingress
Transit
Ingress
Transit

Packets
0
5
0
0
0

Bytes
0
420
0
0
0

Shared
No
No
No
No
No

Label Distribution Protocols (Detailed) Lab 221

Junos MPLS and VPNs

Ingress
Transit
Ingress
Transit
Ingress
Transit
Ingress
Transit
Ingress

[Link]/32
[Link]/32
[Link]/32
[Link]/32

0
0
0
0
0
0
0
0
0

0
0
0
0
0
0
0
0
0

No
No
No
No
No
No
No
No
No

N
LY

Question: Did the ICMP packet traverse the LDP

LSPs?

SE

Answer: The ICMP packet should have traversed the

LDP LSPs. If your pings do not succeed or you see
no LDP packet statistics, 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.

Do not proceed until the remote team finishes Part 4

AL

STOP

Part 5: Changing the Default Route Preference

Step 5.1

TE
R

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 manipulate the LSP that is chosen as the next hop.
Enter into configuration mode and re-activate the RSVP protocol. Commit the
configuration changes.

IN

lab@mxB-1> configure
Entering configuration mode

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

Lab 222 Label Distribution Protocols (Detailed)

[Link]

Junos MPLS and VPNs

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@mxB-1# run show route remote-ce-loopback-address
inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

pe1-to-pe2-B

*[BGP/170] [Link], localpref 100, from [Link]

AS path: 65202 I, validation-state: unverified
> to [Link] via ge-1/0/1.221, label-switched-path

N
LY

[Link]/32

*[BGP/170] [Link], localpref 100

AS path: 65512 65202 I, validation-state: unverified
> to [Link] via ge-1/1/4.0

SE

[Link]/32

[Link].0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

AL

Question: What protocol is being used to carry the

traffic to remote CE router?

IN

TE
R

Answer: If you look carefully you will notice that the

next hop is via the RSVP-signaled LSP. This
indicates that RSVP is the preferred route and will
be used for traffic destined to the CE network.
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 remote-pe-loopback-address command.
[edit]
lab@mxB-1# run show route table inet.3 remote-pe-loopback-address
inet.3: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
[Link]

Label Distribution Protocols (Detailed) Lab 223

Junos MPLS and VPNs

[Link]/32
pe1-to-pe2-B

*[RSVP/7/1] [Link], metric 4

> to [Link] via ge-1/0/1.221, label-switched-path
[LDP/9] [Link], metric 1
to [Link] via ge-1/0/0.220, Push 300080
> to [Link] via ge-1/0/1.221, Push 300096

N
LY

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

SE

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.
Commit your changes and return to operational mode.

lab@mxB-1>

Step 5.5

AL

lab@mxB-1# commit and-quit

commit complete
Exiting configuration mode

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

After the commit has finished, review the route to the remote PE router in the
inet.3 routing table to ensure LDP will be used for traffic to the CE network.

TE
R

lab@mxB-1> show route remote-pe-loopback-address table inet.3

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

IN

[Link]/32

pe1-to-pe2-B

*[LDP/6] [Link], metric 1

> to [Link] via ge-1/0/0.220, Push 300080
to [Link] via ge-1/0/1.221, Push 300096
[RSVP/7/1] [Link], metric 4
> to [Link] via ge-1/0/1.221, label-switched-path

Lab 224 Label Distribution Protocols (Detailed)

[Link]

Junos MPLS and VPNs

Question: What protocol is now the more preferred

protocol for traffic destined to the remote PE ?

Answer: The LDP protocol and routes should be

more preferred now.
Step 5.6

lab@mxB-1> show route remote-CE-loopback-address

N
LY

View the route to the remote CE to determine which type of LSP will be used to
forward traffic to the remote CE.

*[BGP/170] [Link], localpref 100, from [Link]

AS path: 65202 I, validation-state: unverified
> to [Link] via ge-1/0/0.220, Push 300080
to [Link] via ge-1/0/1.221, Push 300096

SE

[Link]/32

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

*[BGP/170] [Link], localpref 100

AS path: 65512 65202 I, validation-state: unverified
> to [Link] via ge-1/1/4.0

AL

[Link]/32

[Link].0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

IN

TE
R

Question: What type of LSP will be used to reach the

remote CE from the local PE?

[Link]

Answer: An LDP LSP will be used to reach the

remote CE.

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, which allows you to
alter the preference on a more granular
level than LDP.

Label Distribution Protocols (Detailed) Lab 225

Junos MPLS and VPNs

Step 5.7
Log out of your assigned device using the exit command.
lab@mxB-1> exit
mxB-1 (ttyu0)
login:

Tell your instructor that you have completed this lab.

IN

TE
R

AL

SE

N
LY

STOP

Lab 226 Label Distribution Protocols (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

Label Distribution Protocols (Detailed) Lab 227

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 228 Label Distribution Protocols (Detailed)

[Link]

Lab

N
LY

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

SE

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.
By completing this lab, you will perform the following tasks:
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).

IN

TE
R

AL

[Link]

CSPF (Detailed) Lab 31

Junos MPLS and VPNs

Part 1: Creating the Baseline Network

In this lab part, you will create the baseline network for the lab. You will load a
baseline configuration which will configure your routers interfaces, Open Shortest
Path First (OSPF) topology, and the Internal Border Gateway Protocol (IBGP) peering
session between the two PE routers. You will then enable RSVP and MPLS on the
core-facing interfaces.
Note

N
LY

The instructor will tell you the nature of your

access and will provide you with the
necessary details to access your assigned
device.
Step 1.1

Ensure that you know to which device you are assigned. Check with your instructor if
necessary.

SE

Step 1.2

Consult the management network diagram, provided by your instructor, to determine

your devices management address.

AL

Question: What is the management address

assigned to your station?

IN

TE
R

Answer: The answer varies. The sample hostname

and IP address used in the output examples in this
lab are for mxB-1, which uses [Link] as its
management IP address. The actual management
subnet varies between delivery environments.

Lab 32 CSPF (Detailed)

[Link]

Junos MPLS and VPNs

Step 1.3

N
LY

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
mxB-1 using the Secure CRT program.

SE

Step 1.4

login: lab
Password:

AL

mxB-1 (ttyp0)

Log in as user lab with the password supplied by your instructor. Enter
configuration mode and load the reset configuration file
jmv/[Link]. Commit the configuration and return to operational
mode.

TE
R

--- JUNOS 12.3R2.5 built 2013-03-22 [Link] UTC

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# load override jmv/[Link]
load complete

IN

[edit]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 1.5
Verify that your Open Shortest Path First (OSPF) neighbor relationships are up and
operational.

[Link]

CSPF (Detailed) Lab 33

Junos MPLS and VPNs

lab@mxB-1> show ospf neighbor

Address
Interface
[Link]
ge-1/0/0.220
[Link]
ge-1/0/1.221

State
Full
Full

ID
[Link]
[Link]

Pri
128
128

Dead
34
39

Question: What is the state of your PE routers OSPF

neighbors?

N
LY

Answer: After a short time, the OSPF neighbors

should attain the Full state.
Step 1.6

Verify that your PE router has established an IBGP neighbor relationship with the
remote PE router.

IN

TE
R

AL

SE

lab@mxB-1> show bgp neighbor

Peer: [Link]+179 AS 65512 Local: [Link]+58282 AS 65512
Type: Internal
State: Established
Flags: <Sync>
Last State: OpenConfirm
Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress Refresh>
Local Address: [Link] Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: [Link]
Local ID: [Link]
Active Holdtime: 90
Keepalive Interval: 30
Group index: 0
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)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
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 19
Sent 8
Checked 31
Input messages: Total 9219
Updates 4
Refreshes 0
Octets 175246
Output messages: Total 9218
Updates 2
Refreshes 0
Octets 175250
Output Queue[0]: 0

Lab 34 CSPF (Detailed)

[Link]

Junos MPLS and VPNs

Question: Is the neighbor relationship in the

established state with the remote PE router?

N
LY

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

Enter into configuration mode and navigate to the [edit interfaces]

hierarchy. Configure the core facing interfaces to allow multiprotocol label switching
(MPLS) traffic.

lab@mxB-1> configure
Entering configuration mode

SE

[edit]
lab@mxB-1# edit interfaces

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

AL

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

Step 1.8

[edit interfaces]
lab@mxB-1#

TE
R

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@mxB-1# top edit protocols mpls

IN

[edit protocols mpls]

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

Step 1.9

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@mxB-1# commit
commit complete
[Link]

CSPF (Detailed) Lab 35

Junos MPLS and VPNs

[edit protocols mpls]

lab@mxB-1# run show mpls interface
Interface
State
Administrative groups (x: extended)
ge-1/0/0.220
Up
<none>
ge-1/0/1.221
Up
<none>

Step 1.10

N
LY

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@mxB-1# top edit protocols rsvp

[edit protocols rsvp]

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

AL

[edit protocols rsvp]

lab@mxB-1# commit and quit
commit complete

SE

[edit protocols rsvp]

lab@mxB-1# show
interface ge-1/0/0.220;
interface ge-1/0/1.221;

Note

TE
R

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.

IN

Step 1.11

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 groups (x: extended)
ge-1/0/0.220
Up
<none>
ge-1/0/1.221
Up
<none>

Lab 36 CSPF (Detailed)

[Link]

Junos MPLS and VPNs

lab@mxB-1> show rsvp interface

RSVP interface: 2 active
Active SubscrInterface
State resv
iption
ge-1/0/0.220Up
0
100%
ge-1/0/1.221Up
0
100%

Static
BW
1000Mbps
1000Mbps

Available
BW
1000Mbps
1000Mbps

Reserved
BW
0bps
0bps

Highwater
mark
0bps
0bps

N
LY

Question: Can your core-facing interfaces now

support the transmission of MPLS packets?

Answer: The outputs of the two commands show

that the two interfaces can now support the
forwarding of MPLS packets.

Part 2: Enabling the TED

SE

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.

Adv Rtr
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]

IN

TE
R

Area [Link]
Type
ID
Router *[Link]
Router
[Link]
Router
[Link]
Router
[Link]
Router
[Link]
Router
[Link]
Router
[Link]
Router
[Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]

AL

lab@mxB-1> show ospf database

[Link]

Seq
0x8000007a
0x800000af
0x800000b6
0x800000af
0x800000b2
0x800000b4
0x800000ae
0x800000b1
0x800000ac
0x800000ad
0x800000ac
0x800000ac
0x800000ac
0x800000ad
0x800000ad
0x80000054
0x80000054
0x800000ae
0x800000ae
0x80000001
0x800000ae
0x800000ad

Age
1851
906
127
1469
2267
2900
1468
1770
1969
758
2754
2520
1897
124
270
2127
2043
1410
1020
457
627
969

Opt
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22

Cksum Len
0x26a4 60
0x5634 60
0xe735 96
0x2771 72
0x37c6 96
0xb15b 96
0x1679 72
0x1927 108
0xd3d8 32
0xced7 32
0xf3ad 32
0xfaa2 32
0xc1df 32
0xacf6 32
0xbbdf 32
0x876f 32
0x8867 32
0xd2c2 32
0xd3ba 32
0xb49d 28
0x5b45 28
0x613e 28

CSPF (Detailed) Lab 37

Junos MPLS and VPNs

0x800000ad
0x800000ae
0x800000ad
0x800000ad
0x80000001
0x800000ad
0x800000ad
0x800000ad
0x80000054
0x800000ad
0x800000ad
0x80000001
0x800000ad
0x800000ac
0x800000ad
0x800000ad
0x800000ad
0x800000ac
0x80000054
0x800000ac
0x800000ac
0x800000ad
0x800000ac
0x800000ad

981
329
1040
2145
457
1627
469
553
2472
611
645
457
1127
2969
1838
1615
183
2895
2627
2469
2695
1186
2325
1395

0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22

0x6538
0x6733
0x6d2c
0x7126
0x65cf
0x8f19
0x7d24
0x950a
0x5e7d
0x8517
0x5f37
0x8da4
0xfca8
0x6b2e
0x274
0xd0d3
0xe8b9
0x9505
0x5282
0xd96
0x4158
0x871b
0x6d27
0xef8a

28
28
28
28
124
124
124
124
124
124
124
124
124
124
124
124
124
124
124
124
124
124
124
124

N
LY

[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]

[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]

SE

OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea
OpaqArea

AL

Question: What types of LSAs are being flooded in

the OSPF domain?

Answer: You should see Router, Network, and

OpaqArea LSAs.

TE
R

Question: Is your router generating an OpaqArea

LSA?

IN

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 LSAs
to build a TED.

Lab 38 CSPF (Detailed)

[Link]

Junos MPLS and VPNs

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?

N
LY

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

SE

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

lab@mxB-1> configure
Entering configuration mode

AL

[edit protocols ospf]

lab@mxB-1# set traffic-engineering

TE
R

[edit protocols ospf]

lab@mxB-1# commit and-quit
commit complete
lab@mxB-1>

Step 2.4

IN

Issue the show ospf database command and determine if you router is now
generating OpaqArea LSA s.

lab@mxB-1> show ospf database

Area [Link]
Type
ID
Router *[Link]
Router
[Link]
Router
[Link]
Router
[Link]
Router
[Link]
Router
[Link]
Router
[Link]
Router
[Link]
[Link]

Adv Rtr
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]

Seq
0x8000007a
0x800000af
0x800000b6
0x800000af
0x800000b2
0x800000b5
0x800000ae
0x800000b1

Age
2171
1226
447
1789
2587
220
1788
2090

Opt
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22

Cksum Len
0x26a4 60
0x5634 60
0xe735 96
0x2771 72
0x37c6 96
0xaf5c 96
0x1679 72
0x1927 108

CSPF (Detailed) Lab 39

Junos MPLS and VPNs

0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22
0x22

0xd3d8
0xced7
0xf1ae
0xfaa2
0xc1df
0xacf6
0xbbdf
0x876f
0x8867
0xd2c2
0xd3ba
0xb0a3
0xb49d
0x5b45
0x613e
0x6538
0x6733
0x6d2c
0x7126
0x733
0x65cf
0x8f19
0x7d24
0x950a
0x5e7d
0x8517
0x5f37
0x2f08
0x8da4
0xfca8
0x692f
0x274
0xd0d3
0xe8b9
0x9306
0x5282
0xd96
0x3f59
0x871b
0x6d27
0xef8a

32
32
32
32
32
32
32
32
32
32
32
28
28
28
28
28
28
28
28
124
124
124
124
124
124
124
124
124
124
124
124
124
124
124
124
124
124
124
124
124
124

N
LY

SE

AL

TE
R

2289
1078
74
2840
2217
444
590
2447
2363
1730
1340
71
777
947
1289
1301
649
1360
2465
71
777
1947
789
873
2792
931
965
71
777
1447
289
2158
1935
503
215
2947
2789
15
1506
2645
1715

0x800000ac
0x800000ad
0x800000ad
0x800000ac
0x800000ac
0x800000ad
0x800000ad
0x80000054
0x80000054
0x800000ae
0x800000ae
0x80000001
0x80000001
0x800000ae
0x800000ad
0x800000ad
0x800000ae
0x800000ad
0x800000ad
0x80000001
0x80000001
0x800000ad
0x800000ad
0x800000ad
0x80000054
0x800000ad
0x800000ad
0x80000001
0x80000001
0x800000ad
0x800000ad
0x800000ad
0x800000ad
0x800000ad
0x800000ad
0x80000054
0x800000ac
0x800000ad
0x800000ad
0x800000ac
0x800000ad

[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]

Network [Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
Network [Link]
OpaqArea*[Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea*[Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea*[Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]
OpaqArea [Link]

IN

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.
Step 2.5
Issue the show ted database command to determine if your router is using the
OpaqArea LSAs to build a TED database.
Lab 310 CSPF (Detailed)

[Link]

Junos MPLS and VPNs

IN

TE
R

AL

SE

N
LY

lab@mxB-1> show ted database

TED database: 0 ISIS nodes 19 INET nodes
ID
Type Age(s) LnkIn LnkOut Protocol
[Link]-1
Net
237
2
2 OSPF([Link])
To: [Link], Local: [Link], Remote: [Link]
Local interface index: 0, Remote interface index: 0
To: [Link], Local: [Link], Remote: [Link]
Local interface index: 0, Remote interface index: 0
ID
Type Age(s) LnkIn LnkOut Protocol
[Link]-1
Net
237
2
2 OSPF([Link])
To: [Link], Local: [Link], Remote: [Link]
Local interface index: 0, Remote interface index: 0
To: [Link], Local: [Link], Remote: [Link]
Local interface index: 0, Remote interface index: 0
ID
Type Age(s) LnkIn LnkOut Protocol
[Link]-1
Net
237
2
2 OSPF([Link])
To: [Link], Local: [Link], Remote: [Link]
Local interface index: 0, Remote interface index: 0
To: [Link], Local: [Link], Remote: [Link]
Local interface index: 0, Remote interface index: 0
ID
Type Age(s) LnkIn LnkOut Protocol
[Link]-1
Net
237
2
2 OSPF([Link])
To: [Link], Local: [Link], Remote: [Link]
Local interface index: 0, Remote interface index: 0
To: [Link], Local: [Link], Remote: [Link]
Local interface index: 0, Remote interface index: 0
ID
Type Age(s) LnkIn LnkOut Protocol
[Link]-1
Net
237
2
2 OSPF([Link])
To: [Link], Local: [Link], Remote: [Link]
Local interface index: 0, Remote interface index: 0
To: [Link], Local: [Link], Remote: [Link]
Local interface index: 0, Remote interface index: 0
ID
Type Age(s) LnkIn LnkOut Protocol
...

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

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 local-pe-loopback-address
TED database: 0 ISIS nodes 19 INET nodes
NodeID: [Link]
Type: Rtr, Age: 328 secs, LinkIn: 2, LinkOut: 2
Protocol: OSPF([Link])
To: [Link]-1, Local: [Link], Remote: [Link]
[Link]

CSPF (Detailed) Lab 311

Junos MPLS and VPNs

1000Mbps
1000Mbps

1000Mbps
1000Mbps

1000Mbps
1000Mbps

1000Mbps
1000Mbps

AL

SE

N
LY

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]
[4] 1000Mbps
[5] 1000Mbps
[6] 1000Mbps
[7]
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 1000Mbps
[1] 1000Mbps
[2] 1000Mbps
[3]
[4] 1000Mbps
[5] 1000Mbps
[6] 1000Mbps
[7]
To: [Link]-1, Local: [Link], Remote: [Link]
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]
[4] 1000Mbps
[5] 1000Mbps
[6] 1000Mbps
[7]
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 1000Mbps
[1] 1000Mbps
[2] 1000Mbps
[3]
[4] 1000Mbps
[5] 1000Mbps
[6] 1000Mbps
[7]

TE
R

Question: Have any colors been assigned to your PE

routers core-facing interfaces?

IN

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 no colors (administrative groups)
assigned.

STOP

Do not proceed until the remote team finishes Part 2.

Part 3: Configuring RSVP-Signaled LSPs

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

Lab 312 CSPF (Detailed)

[Link]

Junos MPLS and VPNs

Step 3.1
Enter configuration mode and navigate to the [edit protocols mpls]
hierarchy. Configure an RSVP-signaled LSP named
lsp-gold-localPE-to-remotePE-pod. For example, if you are assigned
router mxB-1, your peer router is mxB-2 and your pod is B. The LSP for mxB-1 should
be named lsp-gold-pe1-to-pe2-B. Your LSP should egress at your remote
peers loopback address. Create and a use a path called path1 to 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 path1 [Link] loose

N
LY

lab@mxB-1> configure
Entering configuration mode

SE

[edit protocols mpls]

lab@mxB-1# set label-switched-path lsp-gold-localPE-to-remotePE-pod to
remote-pe-loopback-address

[edit protocols mpls]

lab@mxB-1# set label-switched-path lsp-gold-localPE-to-remotePE-pod primary
path1

Step 3.2

AL

[edit protocols mpls]

lab@mxB-1#

TE
R

Configure an RSVP-signaled LSP named

lsp-silver-localPE-to-remotePE-pod. For example, if you are assigned
router mxB-1, your peer router is mxB-2 and your pod is B. The LSP for mxB-1 should
be named lsp-silver-pe1-to-pe2-B. Your LSP should egress at your remote
peers loopback address. Use the path called path1 to ensure that this LSP
traverses P2 as a loose hop.

[edit protocols mpls]

lab@mxB-1# set label-switched-path lsp-silver-localPE-to-remotePE-pod to
remote-pe-loopback-address

IN

[edit protocols mpls]

lab@mxB-1# set label-switched-path lsp-silver-localPE-to-remotePE-pod primary
path1

Step 3.3

Configure an RSVP-signaled LSP named

lsp-bronze-localPE-to-remotePE-pod. For example, if you are assigned
router mxB-1, your peer router is mxB-2 and your pod is B. The LSP for mxB-1 should
be named lsp-bronze-pe1-to-pe2-B. Your LSP should egress at your remote
peers loopback address. Use the path called path1 to ensure that this LSP
traverses P2 as a loose hop. Commit your configuration and exit to operational
mode.
[Link]

CSPF (Detailed) Lab 313

Junos MPLS and VPNs

[edit protocols mpls]

lab@mxB-1# set label-switched-path lsp-bronze-localPE-to-remotePE-pod to
remote-pe-loopback-address

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

Step 3.4

N
LY

[edit protocols mpls]

lab@mxB-1# set label-switched-path lsp-bronze-localPE-to-remotePE-pod primary
path1

lab@mxB-1> show rsvp session extensive ingress

Ingress RSVP: 3 sessions

Using the show rsvp session extensive ingress command, verify that
the new LSPs are up and are currently traversing P2.

TE
R

AL

SE

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: lsp-gold-pe1-to-pe2-B, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 300288
Resv style: 1 FF, Label in: -, Label out: 300288
Time left:
-, Since: Mon May 13 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 47889 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/0.220) 6 pkts
RESV rcvfrom: [Link] (ge-1/0/0.220) 5 pkts
Explct route: [Link] [Link] [Link] [Link]
Record route: <self> [Link] [Link] [Link] [Link]

IN

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: lsp-bronze-pe1-to-pe2-B, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 300304
Resv style: 1 FF, Label in: -, Label out: 300304
Time left:
-, Since: Mon May 13 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 47890 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/0.220) 3 pkts
RESV rcvfrom: [Link] (ge-1/0/0.220) 3 pkts
Explct route: [Link] [Link] [Link] [Link]
Record route: <self> [Link] [Link] [Link] [Link]
Lab 314 CSPF (Detailed)

[Link]

Junos MPLS and VPNs

N
LY

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: lsp-silver-pe1-to-pe2-B, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 300320
Resv style: 1 FF, Label in: -, Label out: 300320
Time left:
-, Since: Mon May 13 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 47891 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/0.220) 3 pkts
RESV rcvfrom: [Link] (ge-1/0/0.220) 3 pkts
Explct route: [Link] [Link] [Link] [Link]
Record route: <self> [Link] [Link] [Link] [Link]
Total 3 displayed, Up 3, Down 0

SE

Question: Are all three LSPs up?

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

IN

TE
R

AL

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

CSPF (Detailed) Lab 315

Junos MPLS and VPNs

lab@mxB-1> configure
Entering configuration mode
[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.

N
LY

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

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

Step 4.4

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

SE

Apply the administrative groups (as listed in the lab diagram) to the core-facing
interfaces. Commit your configuration and exit to operational mode.

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

AL

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

TE
R

[edit protocols]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

IN

Step 4.5

Use the show mpls interface command to verify that the correct
administrative groups have been applied to your interfaces.

lab@mxB-1> show mpls interface

Interface
State
Administrative groups
ge-1/0/0.220
Up
bronze
silver
ge-1/0/1.221
Up
gold

Lab 316 CSPF (Detailed)

[Link]

Junos MPLS and VPNs

Question: What administrative group have been

applied to the interfaces?

Answer: On your PE routers, the ge-1/0/0 interface

should be listed as silver and bronze. The ge-1/0/1
interface should be listed as gold.

N
LY

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

IN

TE
R

AL

SE

lab@mxB-1> show ted database local-pe-loopback-address extensive

TED database: 0 ISIS nodes 19 INET nodes
NodeID: [Link]
Type: Rtr, Age: 74 secs, LinkIn: 2, LinkOut: 2
Protocol: OSPF([Link])
To: [Link]-1, Local: [Link], Remote: [Link]
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):
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: [Link]-1, Local: [Link], Remote: [Link]
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

[Link]

CSPF (Detailed) Lab 317

Junos MPLS and VPNs

Question: Is your router advertising the correct color

settings to other routers in the network?

N
LY

Answer: In the TED, the ge-1/0/0 interface should

be listed as silver and bronze. The
ge-1/0/1 interface should be listed as gold.

Do not proceed until the remote team finishes Part 4.

STOP

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

SE

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

AL

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.
lab@mxB-1> configure
Entering configuration mode

TE
R

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

[edit protocols mpls]

lab@mxB-1# set label-switched-path lsp-gold-localPE-to-remotePE-pod primary
path1 admin-group include-any gold

IN

[edit protocols mpls]

lab@mxB-1#

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-localPE-to-remotePE-pod primary
path1 admin-group include-any silver

Lab 318 CSPF (Detailed)

[Link]

Junos MPLS and VPNs

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.

IN

TE
R

AL

SE

[edit protocols mpls]

lab@mxB-1# show
admin-groups {
gold 1;
silver 2;
bronze 3;
}
label-switched-path lsp-gold-pe1-to-pe2-B {
to [Link];
primary path1 {
admin-group include-any gold;
}
}
label-switched-path lsp-silver-pe1-to-pe2-B {
to [Link];
primary path1 {
admin-group include-any silver;
}
}
label-switched-path lsp-bronze-pe1-to-pe2-B {
to [Link];
primary path1 {
admin-group include-any bronze;
}
}
path path1 {
[Link] loose;
}
interface ge-1/0/0.220 {
admin-group [ silver bronze ];
}
interface ge-1/0/1.221 {
admin-group gold;
}

N
LY

[edit protocols mpls]

lab@mxB-1# set label-switched-path lsp-bronze-localPE-to-remotePE-pod primary
path1 admin-group include-any bronze

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

Step 5.4
Use the show rsvp session ingress detail command to verify that each
LSP is traversing the correct, colored path as well as passing through P2.
lab@mxB-1> show rsvp session ingress detail
Ingress RSVP: 3 sessions
[Link]

CSPF (Detailed) Lab 319

Junos MPLS and VPNs

N
LY

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: lsp-gold-pe1-to-pe2-B, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 300240
Resv style: 1 FF, Label in: -, Label out: 300240
Time left:
-, Since: Mon May 13 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 2 receiver 47889 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/1.221) 4 pkts
RESV rcvfrom: [Link] (ge-1/0/1.221) 4 pkts
Explct route: [Link] [Link] [Link] [Link]
[Link]
[Link]
Record route: <self> [Link] [Link] [Link] [Link]
[Link] [Link]

IN

TE
R

AL

SE

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: lsp-bronze-pe1-to-pe2-B, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 300400
Resv style: 1 FF, Label in: -, Label out: 300400
Time left:
-, Since: Mon May 13 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 2 receiver 47890 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/0.220) 4 pkts
RESV rcvfrom: [Link] (ge-1/0/0.220) 4 pkts
Explct route: [Link] [Link] [Link] [Link]
[Link]
[Link]
Record route: <self> [Link] [Link] [Link] [Link]
[Link] [Link]
[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: lsp-silver-pe1-to-pe2-B, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 300416
Resv style: 1 FF, Label in: -, Label out: 300416
Time left:
-, Since: Mon May 13 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 2 receiver 47891 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Lab 320 CSPF (Detailed)

[Link]

Junos MPLS and VPNs

Path MTU: received 1500

PATH sentto: [Link] (ge-1/0/0.220) 4 pkts
RESV rcvfrom: [Link] (ge-1/0/0.220) 4 pkts
Explct route: [Link] [Link] [Link] [Link]
[Link]
[Link]
Record route: <self> [Link] [Link] [Link] [Link]
[Link] [Link]
Total 3 displayed, Up 3, Down 0

N
LY

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.

SE

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.

TE
R

AL

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.

Step 5.5

Log out of your assigned device using the exit command.

IN

lab@mxB-1> exit
mxB-1 (ttyu0)
login:

STOP

[Link]

Tell your instructor that you have completed this lab.

CSPF (Detailed) Lab 321

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 322 CSPF (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

CSPF (Detailed) Lab 323

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 324 CSPF (Detailed)

[Link]

Lab

N
LY

Traffic Protection (Detailed)

Overview

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

SE

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.
By completing this lab, you will perform the following tasks:
Load a baseline network.

Define an Resource Reservation Protocol (RSVP) signaled 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.

AL

Add link protection to an LSP.

IN

TE
R

[Link]

Traffic Protection (Detailed) Lab 41

Junos MPLS and VPNs

Part 1: Creating the Baseline Network

In this lab part, you will create the baseline network for the lab. You will load a
baseline configuration which will configure your routers interfaces, Open Shortest
Path First (OSPF) topology, and the Internal Border Gateway Protocol (IBGP) peering
session between the two PE routers. The configuration will also enable RSVP and
MPLS on the core-facing interfaces. Please refer to the lab diagram titled Traffic
Protection Lab.

N
LY

Note

The instructor will tell you the nature of your

access and will provide you with the
necessary details to access your assigned
device.

Step 1.1

SE

Ensure that you know to which device you are assigned. Check with your instructor if
necessary.
Step 1.2

Consult the management network diagram, provided by your instructor, to determine

your devices management address.

AL

Question: What is the management address

assigned to your station?

IN

TE
R

Answer: The answer varies. The sample hostname

and IP address used in the output examples in this
lab are for mxB-1, which uses [Link] as its
management IP address. The actual management
subnet varies between delivery environments.

Lab 42 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

Step 1.3

N
LY

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
mxB-1 using the Secure CRT program.

SE

Step 1.4

login: lab
Password:

AL

mxB-1 (ttyp0)

Log in as user lab with the password supplied by your instructor. Enter
configuration mode and load the reset configuration file
jmv/[Link]. Commit the configuration and return to operational
mode.

TE
R

--- JUNOS 12.3R2.5 built 2013-03-22 [Link] UTC

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# load override jmv/[Link]
load complete

IN

[edit]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 1.5
Verify that your Open Shortest Path First (OSPF) neighbor relationships are up and
operational.

[Link]

Traffic Protection (Detailed) Lab 43

Junos MPLS and VPNs

lab@mxB-1> show ospf neighbor

Address
Interface
[Link]
ge-1/0/0.220
[Link]
ge-1/0/1.221

State
Full
Full

ID
[Link]
[Link]

Pri
128
128

Dead
34
39

Question: What is the state of your PE routers OSPF

neighbors?

N
LY

Answer: After a short time, the OSPF neighbors

should attain the Full state.
Step 1.6

Verify that your PE router has established an IBGP neighbor relationship with the
remote PE router.

IN

TE
R

AL

SE

lab@mxB-1> show bgp neighbor

Peer: [Link]+179 AS 65512 Local: [Link]+58282 AS 65512
Type: Internal
State: Established
Flags: <Sync>
Last State: OpenConfirm
Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress Refresh>
Local Address: [Link] Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: [Link]
Local ID: [Link]
Active Holdtime: 90
Keepalive Interval: 30
Group index: 0
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)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
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 19
Sent 8
Checked 31
Input messages: Total 9219
Updates 4
Refreshes 0
Octets 175246
Output messages: Total 9218
Updates 2
Refreshes 0
Octets 175250
Output Queue[0]: 0

Lab 44 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

Question: Is the neighbor relationship in the

established state with the remote PE router?

N
LY

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

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

Static
BW
1000Mbps
1000Mbps

lab@mxB-1> show rsvp interface

RSVP interface: 2 active
Active SubscrInterface
State resv
iption
ge-1/0/0.220Up
0
100%
ge-1/0/1.221Up
0
100%

SE

lab@mxB-1> show mpls interface

Interface
State
Administrative groups (x: extended)
ge-1/0/0.220
Up
<none>
ge-1/0/1.221
Up
<none>

Available
BW
1000Mbps
1000Mbps

Reserved
BW
0bps
0bps

Highwater
mark
0bps
0bps

TE
R

AL

Question: Can your core-facing interfaces now

support the transmission of MPLS packets?

Answer: The outputs of the two commands show

that the two interfaces can now support the
forwarding of MPLS packets.

IN

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.
lab@mxB-1> configure
Entering configuration mode
[Link]

Traffic Protection (Detailed) Lab 45

Junos MPLS and VPNs

[edit]
lab@mxB-1# edit routing-options
[edit routing-options]
lab@mxB-1# set static route route/24 reject

N
LY

[edit routing-options]
lab@mxB-1# show
static {
route [Link]/24 reject;
}
autonomous-system 65512;
[edit routing-options]
lab@mxB-1#

Step 2.2

SE

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

Navigate to the [edit policy-options] hierarchy and configure a routing

policy called statics to redistribute the static route into BGP.

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

[edit policy-options]
lab@mxB-1

Step 2.3

AL

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

TE
R

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@mxB-1# top edit protocols bgp

IN

[edit protocols bgp]

lab@mxB-1# set group my-int-group export statics
[edit protocols bgp]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 2.4
Using the show route advertising-protocol bgp command, verify that
you are sending a route to your remote PE neighbor.

Lab 46 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

lab@mxB-1> show route advertising-protocol bgp remote-pe-loopback-address

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

N
LY

Question: Is your router advertising the route to the

remote PE router?

Answer: Your router should be advertising the route

to the remote PE router.
Step 2.5

Using the show route receive-protocol bgp command, verify that you are
receiving a route from your remote PE neighbor.
lab@mxB-1> show route receive-protocol bgp remote-pe-loopback-address

SE

inet.0: 45 destinations, 45 routes (45 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
[Link]
100
I

[Link].0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

AL

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

IN

TE
R

Question: Is your router receiving the route from the

remote PE router?

STOP

[Link]

Answer: Your router should be receiving the route

from the remote PE router.

Do not proceed until the remote team finishes Part 2.

Traffic Protection (Detailed) Lab 47

Junos MPLS and VPNs

Part 3: Creating an LSP to the Remote PE

In this lab part, you will create an RSVP-signaled LSP from your PE to the remote PE.
The second router along the path of the LSP must be either P1 (for ingress router
PE1) or P3 (for ingress router PE2). You will specify a strict hop of the provider
routers connecting interface. Refer to the lab diagram titled Traffic Protection Lab
to determine the path of your LSP.
Step 3.1

Ingress PE

Strict Hop

Loose Hop

[Link]

[Link]

mxA-2

[Link]

[Link]

mxB-1

[Link]

[Link]

mxB-2

[Link]

[Link]

mxC-1

[Link]

mxC-2

[Link]

mxD-1

[Link]

[Link]

mxD-2

[Link]

[Link]

SE

mxA-1

N
LY

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:

[Link]

AL

[Link]

lab@mxB-1> configure
Entering configuration mode

TE
R

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

[edit protocols mpls]

lab@mxB-1# set path strict-first-hop address strict
[edit protocols mpls]
lab@mxB-1# set path strict-first-hop address loose

IN

[edit protocols mpls]

lab@mxB-1#

Step 3.2

Configure an LSP named localPE-to-remotePE-pod to the remote PE with a

primary path using the path you created in the previous step. For example, if you are
assigned router mxB-1, your peer router is mxB-2 and your pod is B. The LSP for
mxB-1 should be named pe1-to-pe2-B. Your LSP should egress at your remote
peers loopback address. Modify the LSP with the no-cspf command. Commit your
configuration and exit configuration mode and verify that your LSP is up.

Lab 48 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

[edit protocols mpls]

lab@mxB-1# set label-switched-path localPE-to-remotePE-pod to
remote-pe-loopback-address primary strict-first-hop
[edit]
lab@mxB-1# set label-switched-path localPE-to-remotePE-pod no-cspf
[edit protocols mpls]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

N
LY

lab@mxB-1>

Step 3.3

lab@mxB-1> show rsvp session ingress detail

Ingress RSVP: 1 sessions

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

IN

TE
R

AL

SE

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: pe1-to-pe2-B, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 300448
Resv style: 1 FF, Label in: -, Label out: 300448
Time left:
-, Since: Wed May 15 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 47894 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/0.220) 3 pkts
RESV rcvfrom: [Link] (ge-1/0/0.220) 3 pkts
Explct route: [Link] [Link]
Record route: <self> [Link] [Link] [Link] [Link]
[Link]
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.
[Link]

Traffic Protection (Detailed) Lab 49

Junos MPLS and VPNs

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.
lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# set interfaces ge-1/0/0 disable

N
LY

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

Verify the status of the LSP.

SE

[edit]
lab@mxB-1 run show rsvp session ingress detail
Ingress RSVP: 1 sessions

Step 3.5

IN

TE
R

AL

[Link]
From: [Link], LSPstate: Dn, ActiveRoute: 0
LSPname: pe1-to-pe2-B, 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: Wed May 15 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 47894 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 0
PATH sentto: [bad strict route]
Explct route: [Link] [Link]
Record route: <self> ...incomplete
Total 1 displayed, Up 0, Down 1

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 (strict
hop) is repaired. The LSP will be unusable during
that time because no traffic protection mechanisms
are enabled.
Lab 410 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

Step 3.6
Enable the interface on your PE router that is being used by the primary path of the
LSP. Commit your configuration.
[edit]
lab@mxB-1# delete interfaces ge-1/0/0 disable
[edit]
lab@mxB-1# commit
commit complete

N
LY

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

SE

[edit]
lab@mxB-1# run show rsvp session ingress
Ingress RSVP: 1 sessions
To
From
State
Rt Style Labelin Labelout LSPname
[Link]
[Link]
Up
0 1 FF
300464 pe1-to-pe2-B
Total 1 displayed, Up 1, Down 0

Question: What happens to the status of the LSP

when the interface is enabled?

AL

Answer: The LSP will go to an up state.

Part 4: Configuring a Secondary Path for Added Protection

TE
R

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

Step 4.1

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.

IN

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

[edit protocols mpls]

lab@mxB-1#

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

Traffic Protection (Detailed) Lab 411

Junos MPLS and VPNs

[edit protocols mpls]

lab@mxB-1# set label-switched-path localPE-to-remotePE-pod secondary any-path
[edit protocols mpls]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 4.3
lab@mxB-1> show rsvp session ingress detail
Ingress RSVP: 1 sessions

N
LY

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

AL

SE

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: pe1-to-pe2-B, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 300464
Resv style: 1 FF, Label in: -, Label out: 300464
Time left:
-, Since: Wed May 15 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 47894 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/0.220) 12 pkts
RESV rcvfrom: [Link] (ge-1/0/0.220) 12 pkts
Explct route: [Link] [Link]
Record route: <self> [Link] [Link] [Link] [Link]
[Link]
Total 1 displayed, Up 1, Down 0

TE
R

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

or why not?

IN

Answer: The secondary should not be up. Without

the standby option configured, the secondary will
remain down until the primary has failed.

Step 4.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.
lab@mxB-1> configure
Entering configuration mode
[edit]
Lab 412 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

lab@mxB-1# set interfaces ge-1/0/0 disable

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

Step 4.5
[edit]
lab@mxB-1# run show rsvp session ingress extensive
Ingress RSVP: 2 sessions

N
LY

Verify the status of the LSP.

AL

SE

[Link]
From: [Link], LSPstate: Dn, ActiveRoute: 0
LSPname: pe1-to-pe2-B, 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: Wed May 15 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 47894 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 0
PATH sentto: [bad strict route]
Explct route: [Link] [Link]
Record route: <self> ...incomplete

IN

TE
R

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: pe1-to-pe2-B, LSPpath: Secondary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 300288
Resv style: 1 FF, Label in: -, Label out: 300288
Time left:
-, Since: Wed May 15 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 2 receiver 47895 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/1.221) 3 pkts
RESV rcvfrom: [Link] (ge-1/0/1.221) 3 pkts
Record route: <self> [Link] [Link] [Link] [Link]
Total 2 displayed, Up 1, Down 1

[Link]

Traffic Protection (Detailed) Lab 413

Junos MPLS and VPNs

Question: What happens to the status of the LSP

while the interface is disabled?

N
LY

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

SE

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.

lab@mxB-1>

Step 4.7

AL

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

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

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

TE
R

lab@mxB-1> show mpls lsp extensive

Ingress LSP: 1 sessions

IN

[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2-B
ActivePath: any-path (secondary)
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Time remaining before reverting: 58
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):
[Link] [Link] [Link] [Link] [Link]
17 May 15 [Link].678 Record Route: [Link] [Link] [Link]
[Link] [Link]
16 May 15 [Link].678 Up
15 May 15 [Link].064 Explicit Route: bad strict route[5 times]
Lab 414 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

AL

SE

N
LY

14 May 15 [Link].404 Deselected as active

13 May 15 [Link].398 No Route toward dest
12 May 15 [Link].397 [Link]: Down
11 May 15 [Link].923 Selected as active path
10 May 15 [Link].921 Record Route: [Link] [Link] [Link]
[Link] [Link]
9 May 15 [Link].921 Up
8 May 15 [Link].178 Explicit Route: bad strict route[5 times]
7 May 15 [Link].626 Deselected as active
6 May 15 [Link].625 No Route toward dest
5 May 15 [Link].625 [Link]: Down
4 May 15 [Link].222 Selected as active path
3 May 15 [Link].221 Record Route: [Link] [Link] [Link]
[Link] [Link]
2 May 15 [Link].221 Up
1 May 15 [Link].172 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):
[Link] [Link] [Link] [Link]
4 May 15 [Link].464 Selected as active path
3 May 15 [Link].464 Record Route: [Link] [Link] [Link]
[Link]
2 May 15 [Link].464 Up
1 May 15 [Link].401 Originate Call
Created: Wed May 15 [Link] 2013
Total 1 displayed, Up 1, Down 0
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

IN

TE
R

Transit LSP: 0 sessions

Total 0 displayed, Up 0, 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 58 seconds or so before traffic will be
moved over to the primary path. This delay is a
safeguard against a flapping interface.

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

Traffic Protection (Detailed) Lab 415

Junos MPLS and VPNs

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.
lab@mxB-1> configure
Entering configuration mode

N
LY

[edit]
lab@mxB-1# edit protocols mpls
[edit protocols mpls]
lab@mxB-1# set label-switched-path localPE-to-remotePE-pod secondary any-path
standby

SE

lab@mxB-1>

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

Step 5.2

Use the show mpls lsp ingress extensive command to verify that the new
LSP is up using the primary path. Also, verify that the secondary path is up in a
standby state.

AL

lab@mxB-1> show mpls lsp ingress extensive

Ingress LSP: 1 sessions

IN

TE
R

[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2-B
ActivePath: strict-first-hop (primary)
LSPtype: Static Configured, Penultimate hop popping
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):
[Link] [Link] [Link] [Link] [Link]
18 May 15 [Link].378 Selected as active path: due to 'primary'
17 May 15 [Link].678 Record Route: [Link] [Link] [Link]
[Link] [Link]
16 May 15 [Link].678 Up
15 May 15 [Link].064 Explicit Route: bad strict route[5 times]
14 May 15 [Link].404 Deselected as active
13 May 15 [Link].398 No Route toward dest
12 May 15 [Link].397 [Link]: Down
11 May 15 [Link].923 Selected as active path
10 May 15 [Link].921 Record Route: [Link] [Link] [Link]
[Link] [Link]
9 May 15 [Link].921 Up
Lab 416 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

SE

N
LY

8 May 15 [Link].178 Explicit Route: bad strict route[5 times]

7 May 15 [Link].626 Deselected as active
6 May 15 [Link].625 No Route toward dest
5 May 15 [Link].625 [Link]: Down
4 May 15 [Link].222 Selected as active path
3 May 15 [Link].221 Record Route: [Link] [Link] [Link]
[Link] [Link]
2 May 15 [Link].221 Up
1 May 15 [Link].172 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):
[Link] [Link] [Link] [Link]
9 May 15 [Link].332 Record Route: [Link] [Link] [Link]
[Link]
8 May 15 [Link].332 Up
7 May 15 [Link].293 Originate Call
6 May 15 [Link].853 Clear Call
5 May 15 [Link].378 Deselected as active: due to 'primary'
4 May 15 [Link].464 Selected as active path
3 May 15 [Link].464 Record Route: [Link] [Link] [Link]
[Link]
2 May 15 [Link].464 Up
1 May 15 [Link].401 Originate Call
Created: Wed May 15 [Link] 2013
Total 1 displayed, Up 1, Down 0

IN

TE
R

AL

Question: Is the primary path up? Secondary?

Answer: Yes, the primary and secondary path

should be up.
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.

[Link]

Traffic Protection (Detailed) Lab 417

Junos MPLS and VPNs

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# set interfaces ge-1/0/0 disable

[edit]
lab@mxB-1#

Step 5.4

N
LY

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

[edit]
lab@mxB-1# run show mpls lsp ingress extensive
Ingress LSP: 1 sessions

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

IN

TE
R

AL

SE

[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2-B
ActivePath: any-path (secondary)
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Primary
strict-first-hop State: Dn
Priorities: 7 0
SmartOptimizeTimer: 180
22 May 15 [Link].699 Explicit Route: bad strict route[3 times]
21 May 15 [Link].737 Deselected as active
20 May 15 [Link].736 No Route toward dest
19 May 15 [Link].735 [Link]: Down
18 May 15 [Link].378 Selected as active path: due to 'primary'
17 May 15 [Link].678 Record Route: [Link] [Link] [Link]
[Link] [Link]
16 May 15 [Link].678 Up
15 May 15 [Link].064 Explicit Route: bad strict route[5 times]
14 May 15 [Link].404 Deselected as active
13 May 15 [Link].398 No Route toward dest
12 May 15 [Link].397 [Link]: Down
11 May 15 [Link].923 Selected as active path
10 May 15 [Link].921 Record Route: [Link] [Link] [Link]
[Link] [Link]
9 May 15 [Link].921 Up
8 May 15 [Link].178 Explicit Route: bad strict route[5 times]
7 May 15 [Link].626 Deselected as active
6 May 15 [Link].625 No Route toward dest
5 May 15 [Link].625 [Link]: Down
4 May 15 [Link].222 Selected as active path
3 May 15 [Link].221 Record Route: [Link] [Link] [Link]
[Link] [Link]
2 May 15 [Link].221 Up
1 May 15 [Link].172 Originate Call
Lab 418 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

N
LY

*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):
[Link] [Link] [Link] [Link]
10 May 15 [Link].737 Selected as active path
9 May 15 [Link].332 Record Route: [Link] [Link] [Link]
[Link]
8 May 15 [Link].332 Up
7 May 15 [Link].293 Originate Call
6 May 15 [Link].853 Clear Call
5 May 15 [Link].378 Deselected as active: due to 'primary'
4 May 15 [Link].464 Selected as active path
3 May 15 [Link].464 Record Route: [Link] [Link] [Link]
[Link]
2 May 15 [Link].464 Up
1 May 15 [Link].401 Originate Call
Created: Wed May 15 [Link] 2013
Total 1 displayed, Up 1, Down 0

SE

Question: What happens to the status of the LSP

while the interface is disabled?

TE
R

AL

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.

IN

Step 5.5

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@mxB-1# delete interfaces ge-1/0/0 disable

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

[Link]

Traffic Protection (Detailed) Lab 419

Junos MPLS and VPNs

Step 5.6
Use the show mpls lsp ingress extensive command to verify the status of
the LSP.
lab@mxB-1> show mpls lsp ingress extensive
Ingress LSP: 1 sessions

IN

TE
R

AL

SE

N
LY

[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2-B
ActivePath: any-path (secondary)
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Time remaining before reverting: 56
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):
[Link] [Link] [Link] [Link] [Link]
24 May 15 [Link].488 Record Route: [Link] [Link] [Link]
[Link] [Link]
23 May 15 [Link].488 Up
22 May 15 [Link].650 Explicit Route: bad strict route[5 times]
21 May 15 [Link].737 Deselected as active
20 May 15 [Link].736 No Route toward dest
19 May 15 [Link].735 [Link]: Down
18 May 15 [Link].378 Selected as active path: due to 'primary'
17 May 15 [Link].678 Record Route: [Link] [Link] [Link]
[Link] [Link]
16 May 15 [Link].678 Up
15 May 15 [Link].064 Explicit Route: bad strict route[5 times]
14 May 15 [Link].404 Deselected as active
13 May 15 [Link].398 No Route toward dest
12 May 15 [Link].397 [Link]: Down
11 May 15 [Link].923 Selected as active path
10 May 15 [Link].921 Record Route: [Link] [Link] [Link]
[Link] [Link]
9 May 15 [Link].921 Up
8 May 15 [Link].178 Explicit Route: bad strict route[5 times]
7 May 15 [Link].626 Deselected as active
6 May 15 [Link].625 No Route toward dest
5 May 15 [Link].625 [Link]: Down
4 May 15 [Link].222 Selected as active path
3 May 15 [Link].221 Record Route: [Link] [Link] [Link]
[Link] [Link]
2 May 15 [Link].221 Up
1 May 15 [Link].172 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):
[Link] [Link] [Link] [Link]
10 May 15 [Link].737 Selected as active path
Lab 420 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

N
LY

9 May 15 [Link].332 Record Route: [Link] [Link] [Link]

[Link]
8 May 15 [Link].332 Up
7 May 15 [Link].293 Originate Call
6 May 15 [Link].853 Clear Call
5 May 15 [Link].378 Deselected as active: due to 'primary'
4 May 15 [Link].464 Selected as active path
3 May 15 [Link].464 Record Route: [Link] [Link] [Link]
[Link]
2 May 15 [Link].464 Up
1 May 15 [Link].401 Originate Call
Created: Wed May 15 [Link] 2013
Total 1 displayed, Up 1, Down 0

Question: What path is being used by the LSP

immediately after enabling the interface? Why?

SE

Answer: The secondary path is still being used by

the LSP. The output of the command shows that it
will be about 56 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

AL

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.

IN

TE
R

lab@mxB-1> show route forwarding-table destination remote-static-route

Routing table: [Link]
Internet:
Destination
Type RtRef Next hop
Type Index NhRef Netif
[Link]/24
user
0
indr 1048575
2
[Link]
Push 300496
535 1 ge-1/0/0.220

[Link]

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.

Traffic Protection (Detailed) Lab 421

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?

N
LY

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

SE

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@mxB-1# edit policy-options

lab@mxB-1> configure
Entering configuration mode

AL

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

Step 5.9

TE
R

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@mxB-1# top edit routing-options

IN

[edit routing-options]
lab@mxB-1# set forwarding-table export load-balance
[edit routing-options]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

Step 5.10
View the forwarding table to see the next hop of the BGP route being advertised by
the remote PE router.
lab@mxB-1> show route forwarding-table destination remote-static-route
Routing table: [Link]
Lab 422 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

Internet:
Destination
[Link]/24

Type RtRef Next hop

user
0

0.220
1.221

[Link]

Type Index NhRef Netif

indr 1048575
2
ulst 1048576
2
Push 300496
535
1 ge-1/0/

[Link]

Push 300304

536

1 ge-1/0/

N
LY

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.

SE

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

AL

Enter configuration mode navigate to the [edit protocols mpls] hierarchy.

Delete the LSP from the previous sections of the lab.
lab@mxB-1> configure
Entering configuration mode

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

TE
R

[edit protocols mpls]

lab@mxB-1# delete label-switched-path localPE-to-remotePE-pod

IN

Step 6.2

Create a no-cspf LSP named localPE-to-remotePE-pod to the remote PE.

For example, if you are assigned router mxB-1, your peer router is mxB-2 and your
pod is B. The LSP for mxB-1 should be named pe1-to-pe2-B. Your LSP should
egress at your remote peers loopback address. The LSP should have 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@mxB-1# set label-switched-path localPE-to-remotePE-pod to
remote-pe-loopback-address no-cspf
[edit protocols mpls]
lab@mxB-1# set label-switched-path localPE-to-remotePE-pod secondary
strict-first-hop
[Link]

Traffic Protection (Detailed) Lab 423

Junos MPLS and VPNs

[edit protocols mpls]

lab@mxB-1# set label-switched-path localPE-to-remotePE-pod secondary any-path
[edit protocols mpls]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 6.3

lab@mxB-1> show mpls lsp ingress extensive

Ingress LSP: 1 sessions

N
LY

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

IN

TE
R

AL

SE

[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2-B
ActivePath: strict-first-hop (secondary)
LSPtype: Static Configured, Penultimate hop popping
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):
[Link] [Link] [Link] [Link] [Link]
4 May 15 [Link].127 Selected as active path
3 May 15 [Link].127 Record Route: [Link] [Link] [Link]
[Link] [Link]
2 May 15 [Link].127 Up
1 May 15 [Link].077 Originate Call
Secondary any-path
State: Dn
Priorities: 7 0
SmartOptimizeTimer: 180
4 May 15 [Link].052 Clear Call
3 May 15 [Link].126 Record Route: [Link] [Link] [Link]
[Link]
2 May 15 [Link].126 Up
1 May 15 [Link].078 Originate Call
Created: Wed May 15 [Link] 2013
Total 1 displayed, Up 1, Down 0

Lab 424 Traffic Protection (Detailed)

[Link]

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.

N
LY

Step 6.4

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# set interfaces ge-1/0/0 disable

SE

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

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

[edit]
lab@mxB-1#

Step 6.5

AL

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

[edit]
lab@mxB-1# run show mpls lsp ingress extensive
Ingress LSP: 1 sessions

IN

TE
R

[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2-B
ActivePath: any-path (secondary)
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Secondary strict-first-hop State: Dn
Priorities: 7 0
SmartOptimizeTimer: 180
9 May 15 [Link].877 Clear Call
8 May 15 [Link].083 Explicit Route: bad strict route[4 times]
7 May 15 [Link].413 Deselected as active
6 May 15 [Link].411 No Route toward dest
5 May 15 [Link].410 [Link]: Down
4 May 15 [Link].127 Selected as active path
3 May 15 [Link].127 Record Route: [Link] [Link] [Link]
[Link] [Link]
2 May 15 [Link].127 Up
1 May 15 [Link].077 Originate Call
[Link]

Traffic Protection (Detailed) Lab 425

Junos MPLS and VPNs

N
LY

*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):
[Link] [Link] [Link] [Link]
8 May 15 [Link].415 Selected as active path
7 May 15 [Link].414 Record Route: [Link] [Link] [Link]
[Link]
6 May 15 [Link].414 Up
5 May 15 [Link].412 Originate Call
4 May 15 [Link].052 Clear Call
3 May 15 [Link].126 Record Route: [Link] [Link] [Link]
[Link]
2 May 15 [Link].126 Up
1 May 15 [Link].078 Originate Call
Created: Wed May 15 [Link] 2013
Total 1 displayed, Up 1, Down 0

SE

Question: What happens to the status of the LSP

while the interface is disabled?

AL

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

TE
R

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

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

IN

[edit]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 6.7
Use the show mpls lsp ingress extensive command to verify the status of
the LSP.
lab@mxB-1> show mpls lsp ingress extensive
Ingress LSP: 1 sessions

Lab 426 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

IN

TE
R

AL

SE

N
LY

[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2-B
ActivePath: any-path (secondary)
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
Secondary strict-first-hop State: Dn
Priorities: 7 0
SmartOptimizeTimer: 180
9 May 15 [Link].877 Clear Call
8 May 15 [Link].083 Explicit Route: bad strict route[4 times]
7 May 15 [Link].413 Deselected as active
6 May 15 [Link].411 No Route toward dest
5 May 15 [Link].410 [Link]: Down
4 May 15 [Link].127 Selected as active path
3 May 15 [Link].127 Record Route: [Link] [Link] [Link]
[Link] [Link]
2 May 15 [Link].127 Up
1 May 15 [Link].077 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):
[Link] [Link] [Link] [Link]
8 May 15 [Link].415 Selected as active path
7 May 15 [Link].414 Record Route: [Link] [Link] [Link]
[Link]
6 May 15 [Link].414 Up
5 May 15 [Link].412 Originate Call
4 May 15 [Link].052 Clear Call
3 May 15 [Link].126 Record Route: [Link] [Link] [Link]
[Link]
2 May 15 [Link].126 Up
1 May 15 [Link].078 Originate Call
Created: Wed May 15 [Link] 2013
Total 1 displayed, Up 1, Down 0

[Link]

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.

Traffic Protection (Detailed) Lab 427

Junos MPLS and VPNs

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
Enter configuration mode navigate to the [edit protocols mpls] hierarchy.
Delete the LSP from the previous sections of the lab.
lab@mxB-1> configure
Entering configuration mode

N
LY

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

[edit protocols mpls]

lab@mxB-1# delete label-switched-path localPE-to-remotePE-pod

[edit protocols mpls]

lab@mxB-1#

Step 7.2

SE

Create an no-cspf LSP named localPE-to-remotePE-pod to the remote PE.

For example, if you are assigned router mxB-1, your peer router is mxB-2 and your
pod is B. The LSP for mxB-1 should be named pe1-to-pe2-B. Your LSP should
egress at your remote peers loopback address. The LSP should have fast-reroute
enabled. The LSP should have a primary path using the strict-first-hop path.
Commit your configuration and exit to operational mode.

AL

[edit protocols mpls]

lab@mxB-1# set label-switched-path localPE-to-remotePE-pod to
remote-pe-loopback-address no-cspf

[edit protocols mpls]

lab@mxB-1# set label-switched-path localPE-to-remotePE-pod fast-reroute

TE
R

[edit protocols mpls]

lab@mxB-1# set label-switched-path localPE-to-remotePE-pod primary
strict-first-hop

IN

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

Step 7.3

Use the show rsvp session ingress detail command to verify the status
of the LSP.
lab@mxB-1> show rsvp session ingress detail
Ingress RSVP: 1 sessions
[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: pe1-to-pe2-B, LSPpath: Primary
LSPtype: Static Configured
Lab 428 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

SE

N
LY

Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 300560
Resv style: 1 FF, Label in: -, Label out: 300560
Time left:
-, Since: Thu May 16 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 8 receiver 47898 protocol 0
FastReroute desired
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/0.220) 7 pkts
RESV rcvfrom: [Link] (ge-1/0/0.220) 7 pkts
Explct route: [Link] [Link]
Record route: <self> [Link] [Link] [Link] [Link]
[Link]
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: [Link] (ge-1/0/1.221) 4 pkts
Detour RESV rcvfrom: [Link] (ge-1/0/1.221) 2 pkts
Detour Explct route: [Link] [Link] [Link] [Link]
Detour Record route: <self> [Link] [Link] [Link]
[Link]
Detour Label out: 300400
Total 1 displayed, Up 1, Down 0

AL

Question: Has the PE router signaled to the

downstream routers that fast-reroute is desired?

IN

TE
R

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.

Step 7.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.
lab@mxB-1> configure
Entering configuration mode
[Link]

Traffic Protection (Detailed) Lab 429

Junos MPLS and VPNs

[edit]
lab@mxB-1# set interfaces ge-1/0/0 disable
[edit]
lab@mxB-1# commit
commit complete
[edit]

Step 7.5

[edit]
lab@mxB-1# run show mpls lsp ingress extensive
Ingress LSP: 1 sessions

N
LY

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

IN

TE
R

AL

SE

[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: pe1-to-pe2-B
ActivePath: strict-first-hop (primary)
FastReroute desired
LSPtype: Static Configured, Penultimate hop popping
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):
[Link] [Link] [Link] [Link]
21 May 16 [Link].275 Tunnel local repaired[4 times]
20 May 16 [Link].300 Record Route: [Link] [Link] [Link]
[Link]
19 May 16 [Link].300 [Link]: Tunnel local repaired
18 May 16 [Link].299 [Link]: Down
17 May 16 [Link].106 Fast-reroute Detour Up
16 May 16 [Link].141 Record Route: [Link](flag=9)
[Link](flag=9) [Link](flag=9) [Link](flag=1) [Link]
15 May 16 [Link].135 Record Route: [Link] [Link](flag=9)
[Link](flag=9) [Link](flag=1) [Link]
14 May 16 [Link].119 Record Route: [Link] [Link]
[Link](flag=9) [Link](flag=1) [Link]
13 May 16 [Link].104 Record Route: [Link] [Link]
[Link](flag=9) [Link] [Link]
12 May 16 [Link].140 Record Route: [Link] [Link] [Link]
[Link] [Link]
11 May 16 [Link].139 Up
10 May 16 [Link].089 Originate Call
9 May 16 [Link].087 Clear Call
8 May 16 [Link].084 Fast-reroute Detour Up
7 May 16 [Link].104 Record Route: [Link](flag=9)
[Link](flag=9) [Link] [Link](flag=1) [Link]
6 May 16 [Link].100 Record Route: [Link] [Link](flag=9)
[Link] [Link] [Link]
Lab 430 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

5 May 16 [Link].136 Selected as active path

4 May 16 [Link].135 Record Route: [Link] [Link] [Link]
[Link] [Link]
3 May 16 [Link].135 Up
2 May 16 [Link].069 Originate Call
1 May 16 [Link].069 CSPF: computation result accepted [Link]
[Link] [Link] [Link] [Link]
Created: Wed May 15 [Link] 2013
Total 1 displayed, Up 1, Down 0

N
LY

Question: What happens to the status of the LSP

while the interface is disabled?

Answer: The LSP remains up but the fast-reroute

detour path is used.
Step 7.6

SE

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.

Step 7.7

lab@mxB-1>

AL

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

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

TE
R

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

lab@mxB-1> show rsvp session ingress detail

Ingress RSVP: 1 sessions

IN

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: pe1-to-pe2-B, 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: Thu May 16 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 8 receiver 47898 protocol 0
FastReroute desired
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 0
[Link]

Traffic Protection (Detailed) Lab 431

Junos MPLS and VPNs

N
LY

PATH sentto: [bad strict route]

Explct route: [Link] [Link]
Record route: <self> ...incomplete
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: [Link] (ge-1/0/1.221) 14 pkts
Detour RESV rcvfrom: [Link] (ge-1/0/1.221) 8 pkts
Detour Explct route: [Link] [Link] [Link] [Link]
Detour Record route: <self> [Link] [Link] [Link]
[Link]
Detour Label out: 300400
Total 1 displayed, Up 1, Down 0

Question: Which path is used by the LSP

immediately after enabling the interface? Why?

SE

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 RSVP LSPs

AL

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

Enter configuration mode navigate to the [edit protocols mpls] hierarchy.

Delete the LSP from the previous sections of the lab.

TE
R

lab@mxB-1> configure
Entering configuration mode

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

IN

[edit protocols mpls]

lab@mxB-1# delete label-switched-path localPE-to-remotePE-pod

Step 8.2

Create an no-cspf LSP named localPE-to-remotePE-pod 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@mxB-1# set label-switched-path localPE-to-remotePE-pod to remote-pe-address
no-cspf

Lab 432 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

[edit protocols mpls]

lab@mxB-1# set label-switched-path localPE-to-remotePE-pod primary
strict-first-hop
[edit protocols mpls]
lab@mxB-1# set label-switched-path localPE-to-remotePE-pod node-link-protection

Step 8.3

N
LY

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.

SE

[edit protocols mpls]

lab@mxB-1# top edit protocols rsvp

Navigate to the [edit protocols rsvp] hierarchy and configure the

ge-1/0/[Link] interface to allow link protection capabilities. Commit your
configuration and exit to operational mode.

Step 8.4

AL

[edit protocols rsvp]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

[edit protocols rsvp]

lab@mxB-1# set interface ge-1/0/[Link] link-protection

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

TE
R

lab@mxB-1> show rsvp session ingress detail

Ingress RSVP: 2 sessions

IN

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: pe1-to-pe2-B, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 300592
Resv style: 1 SE, Label in: -, Label out: 300592
Time left:
-, Since: Thu May 16 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 47899 protocol 0
Node/Link protection desired
Type: Protection down
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/0.220) 3 pkts
[Link]

Traffic Protection (Detailed) Lab 433

Junos MPLS and VPNs

AL

SE

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: Bypass->[Link]->[Link]
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: Thu May 16 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 47900 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: [Link] (ge-1/0/1.221) 3 pkts
RESV rcvfrom: [Link] (ge-1/0/1.221) 3 pkts
Explct route: [Link]
Record route: <self> [Link]
Total 2 displayed, Up 2, Down 0

N
LY

RESV rcvfrom: [Link] (ge-1/0/0.220) 3 pkts

Explct route: [Link] [Link]
Record route: <self> [Link] (node-id) [Link] [Link] (node-id)
[Link]
[Link] (node-id) [Link] [Link] (node-id) [Link]
[Link] (node-id)
[Link]

Question: Is the bypass LSP up?

Answer: Yes, the bypass LSP should be up.

IN

TE
R

Question: Does the bypass LSP provide protection

for the failure of the P router that is directly
connected to your PE router 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.
lab@mxB-1> configure
Entering configuration mode

Lab 434 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

[edit]
lab@mxB-1# edit protocols mpls
[edit protocols mpls]
lab@mxB-1# set label-switched-path localPE-to-remotePE-pod link-protection

Step 8.6

IN

TE
R

AL

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

SE

[edit protocols mpls]

lab@mxB-1# show
label-switched-path pe1-to-pe2-B {
to [Link];
no-cspf;
link-protection;
primary strict-first-hop;
}
path strict-first-hop {
[Link] strict;
[Link] loose;
}
path any-path;
interface ge-1/0/0.220;
interface ge-1/0/1.221;
interface lo0.0;

N
LY

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

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

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

lab@mxB-1> show rsvp session detail

Ingress RSVP: 2 sessions
[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: pe1-to-pe2-B, LSPpath: Primary
LSPtype: Static Configured
[Link]

Traffic Protection (Detailed) Lab 435

Junos MPLS and VPNs

N
LY

Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 300736
Resv style: 1 SE, Label in: -, Label out: 300736
Time left:
-, Since: Thu May 16 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 33664 protocol 0
Link protection desired
Type: Protection down
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/0.220) 3 pkts
RESV rcvfrom: [Link] (ge-1/0/0.220) 3 pkts
Explct route: [Link] [Link]
Record route: <self> [Link] (node-id) [Link] [Link] (node-id)
[Link]
[Link] (node-id) [Link] [Link] (node-id) [Link]
[Link] (node-id)
[Link]

TE
R

AL

SE

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: Bypass->[Link]
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 300672
Resv style: 1 SE, Label in: -, Label out: 300672
Time left:
-, Since: Thu May 16 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 33665 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: [Link] (ge-1/0/1.221) 2 pkts
RESV rcvfrom: [Link] (ge-1/0/1.221) 2 pkts
Explct route: [Link] [Link]
Record route: <self> [Link] [Link]
Total 2 displayed, Up 2, Down 0

IN

Egress RSVP: 0 sessions

Total 0 displayed, Up 0, Down 0
Transit RSVP: 0 sessions
Total 0 displayed, Up 0, Down 0

Question: Is the bypass LSP up?

Answer: Yes, the bypass LSP should be up.

Lab 436 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

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)

N
LY

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.

Part 9: Configuring LDP Link Protection

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

SE

Step 9.1

lab@mxB-1> configure
Entering configuration mode

AL

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

Enter configuration mode navigate to the [edit protocols mpls] hierarchy.

Delete the LSP from the previous sections of the lab.

[edit protocols mpls]

lab@mxB-1# delete label-switched-path localPE-to-remotePE-pod

TE
R

[edit protocols mpls]

lab@mxB-1#

Step 9.2

Navigate to the [edit protocols ldp] and enable LDP on every interface.

IN

[edit protocols mpls]

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

[edit protocols ldp]

lab@mxB-1# commit
commit complete
[edit protocols ldp]
lab@mxB-1#

[Link]

Traffic Protection (Detailed) Lab 437

Junos MPLS and VPNs

Step 9.3
Use the show ldp interfaces command to determine if LDP has been
enabled.
[edit protocols ldp]
lab@mxB-1# run show ldp interface
Interface
Label space ID
lo0.0
[Link]:0
ge-1/0/0.220
[Link]:0
ge-1/0/1.221
[Link]:0

Nbr count
0
1
1

Next hello
0
0
2

N
LY

Question: Does your router have any LDP

neighbors? What interfaces?

Answer: Your PE router should have a single

neighbor on each of the two core facing interfaces.
Step 9.4

[edit protocols ldp]

lab@mxB-1# run show route 193.168/16

SE

Use the show route 193.168/16 command to view the routes to the loopback
address of all routers in the topology.

inet.0: 35 destinations, 35 routes (35 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

TE
R

[Link]/32

AL

[Link]/32

*[Direct/0] [Link]
> via lo0.0
*[OSPF/10] [Link], metric 4
> to [Link] via ge-1/0/0.220
to [Link] via ge-1/0/1.221
*[OSPF/10] [Link], metric 1
> to [Link] via ge-1/0/0.220
*[OSPF/10] [Link], metric 2
> to [Link] via ge-1/0/0.220
*[OSPF/10] [Link], metric 3
> to [Link] via ge-1/0/0.220
*[OSPF/10] [Link], metric 1
> to [Link] via ge-1/0/1.221
*[OSPF/10] [Link], metric 2
> to [Link] via ge-1/0/1.221
*[OSPF/10] [Link], metric 3
> to [Link] via ge-1/0/1.221

[Link]/32

[Link]/32
[Link]/32

IN

[Link]/32
[Link]/32
[Link]/32

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

+ = Active Route, - = Last Active, * = Both
[Link]/32
[Link]/32

*[LDP/9] [Link],
to [Link]
> to [Link]
*[LDP/9] [Link],

Lab 438 Traffic Protection (Detailed)

metric 1
via ge-1/0/0.220, Push 300704
via ge-1/0/1.221, Push 300592
metric 1
[Link]

Junos MPLS and VPNs

[Link]/32
[Link]/32
[Link]/32
[Link]/32
[Link]/32

> to [Link]
*[LDP/9] [Link],
> to [Link]
*[LDP/9] [Link],
> to [Link]
*[LDP/9] [Link],
> to [Link]
*[LDP/9] [Link],
> to [Link]
*[LDP/9] [Link],
> to [Link]

via ge-1/0/0.220
metric 1
via ge-1/0/0.220,
metric 1
via ge-1/0/0.220,
metric 1
via ge-1/0/1.221
metric 1
via ge-1/0/1.221,
metric 1
via ge-1/0/1.221,

Push 299952
Push 299968

Push 299984
Push 300000

N
LY

Question: Do you notice anything similar about the

OSPF learned routes and the LDP learned routes?

Answer: For every OSPF learned route in inet.0

there is an equivalent LDP route in inet.3. Both sets
of routes are also using the exact same next hops.

SE

Question: How many next hops are associated with

each route?

AL

Answer: The route to each P router should have one

next hop. The route to each PE router should have 2
next hops.
Step 9.5

Navigate to the [edit protocols ospf] hierarchy. On the ge-1/0/[Link]

interface, apply link protection. Commit your configuration.

TE
R

[edit protocols ldp]

lab@mxB-1# top edit protocols ospf
[edit protocols ospf]
lab@mxB-1# set area 0 interface ge-1/0/[Link] link-protection

IN

[edit protocols ospf]

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

Step 9.6
Use the show route 193.168/16 command to view the routes to the loopback
address of all routers in the topology.
[edit protocols ospf]
lab@mxB-1# run show route 193.168/16

[Link]

Traffic Protection (Detailed) Lab 439

Junos MPLS and VPNs

[Link]/32
[Link]/32
[Link]/32
[Link]/32
[Link]/32
[Link]/32

[Link]/32

*[Direct/0] [Link]
> via lo0.0
*[OSPF/10] [Link], metric 4
to [Link] via ge-1/0/0.220
> to [Link] via ge-1/0/1.221
*[OSPF/10] [Link], metric 1
> to [Link] via ge-1/0/0.220
to [Link] via ge-1/0/1.221
*[OSPF/10] [Link], metric 2
> to [Link] via ge-1/0/0.220
to [Link] via ge-1/0/1.221
*[OSPF/10] [Link], metric 3
> to [Link] via ge-1/0/0.220
to [Link] via ge-1/0/1.221
*[OSPF/10] [Link], metric 1
> to [Link] via ge-1/0/1.221
*[OSPF/10] [Link], metric 2
> to [Link] via ge-1/0/1.221
*[OSPF/10] [Link], metric 3
> to [Link] via ge-1/0/1.221

SE

[Link]/32

N
LY

inet.0: 35 destinations, 35 routes (35 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

[Link]/32

TE
R

[Link]/32
[Link]/32

IN

[Link]/32
[Link]/32

metric 1
via ge-1/0/0.220,
via ge-1/0/1.221,
metric 1
via ge-1/0/0.220
via ge-1/0/1.221,
metric 1
via ge-1/0/0.220,
via ge-1/0/1.221,
metric 1
via ge-1/0/0.220,
via ge-1/0/1.221,
metric 1
via ge-1/0/1.221
metric 1
via ge-1/0/1.221,
metric 1
via ge-1/0/1.221,

AL

[Link]/32

*[LDP/9] [Link],
> to [Link]
to [Link]
*[LDP/9] [Link],
> to [Link]
to [Link]
*[LDP/9] [Link],
> to [Link]
to [Link]
*[LDP/9] [Link],
> to [Link]
to [Link]
*[LDP/9] [Link],
> to [Link]
*[LDP/9] [Link],
> to [Link]
*[LDP/9] [Link],
> to [Link]

[Link]/32

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

+ = Active Route, - = Last Active, * = Both
Push 300704
Push 300592
Push 300032
Push 299952
Push 300016
Push 299968
Push 300048

Push 299984
Push 300000

Question: How did the routing tables change by

adding link protection to the OSPF interface?

Answer: For all routes that use the protected

interface as a next hop, a second next hop has
been added to the routing table.
Lab 440 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

Question: Why did the next hops change for the LDP
routes when link protection was only configured
under OSPF?

Answer: LDP uses the routes learned by the internal

gateway protocol (IGP) to determine its best path to
each destination that it learns in the network.

N
LY

Question: For the LDP routes, what type of LSP is

being used to protect the interface?

Answer: The routing table shows that it will be an

LDP LSP that will provide the protection if the
protected interface fails.
Step 9.7

[edit protocols ospf]

lab@mxB-1# top edit protocols mpls

SE

Navigate to the [edit protocols mpls] hierarchy. Configure a path called

avoid-top that ensure that an LSP will not traverse the ge-1/0/0 interface.

Step 9.8

AL

[edit protocols mpls]

lab@mxB-1# set path avoid-top address strict

Configure a no-cspf RSVP LSP called protect that terminates on the P router
attached to your ge-1/0/0 interface. Apply the avoid-top path to the LSP. Also,
ensure that it can be used as a backup path for both OSPF routes and LDP routes by
configuring backup and ldp-tunneling.

TE
R

[edit protocols mpls]

lab@mxB-1# set label-switched-path protect to p-router-address
[edit protocols mpls]
lab@mxB-1# set label-switched-path protect no-cspf

IN

[edit protocols mpls]

lab@mxB-1# set label-switched-path protect primary avoid-top

[edit protocols mpls]

lab@mxB-1# set label-switched-path protect backup
[edit protocols mpls]
lab@mxB-1# set label-switched-path protect ldp-tunneling

[Link]

Traffic Protection (Detailed) Lab 441

Junos MPLS and VPNs

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 9.9
Issue the show mpls lsp command to verify the status of the RSVP LSP.

LSPname
protect

Egress LSP: 0 sessions

Total 0 displayed, Up 0, Down 0

ActivePath
avoid-top

N
LY

lab@mxB-1> show mpls lsp

Ingress LSP: 1 sessions
To
From
State Rt P
[Link]
[Link]
Up
0 *
Total 1 displayed, Up 1, Down 0

Transit LSP: 0 sessions

Total 0 displayed, Up 0, Down 0

SE

Question: Is the RSVP LSP in the up state?

Answer: The RSVP LSP should be in the up state.

Step 9.10

AL

Use the show route 193.168/16 command to view the routes to the loopback
address of all routers in the topology.

lab@mxB-1> show route 193.168/16

TE
R

inet.0: 35 destinations, 35 routes (35 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
[Link]/32
[Link]/32

IN

[Link]/32
protect
[Link]/32
protect
[Link]/32
protect

*[Direct/0] [Link]
> via lo0.0
*[OSPF/10] [Link], metric 4
to [Link] via ge-1/0/0.220
> to [Link] via ge-1/0/1.221
*[OSPF/10] [Link], metric 1
> to [Link] via ge-1/0/0.220
to [Link] via ge-1/0/1.221, label-switched-path
*[OSPF/10] [Link], metric 2
> to [Link] via ge-1/0/0.220
to [Link] via ge-1/0/1.221, label-switched-path
*[OSPF/10] [Link], metric 3
> to [Link] via ge-1/0/0.220
to [Link] via ge-1/0/1.221, label-switched-path

Lab 442 Traffic Protection (Detailed)

[Link]

Junos MPLS and VPNs

[Link]/32
[Link]/32
[Link]/32

*[OSPF/10] [Link], metric 1

> to [Link] via ge-1/0/1.221
*[OSPF/10] [Link], metric 2
> to [Link] via ge-1/0/1.221
*[OSPF/10] [Link], metric 3
> to [Link] via ge-1/0/1.221

inet.3: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

protect
[Link]/32
protect
[Link]/32
[Link]/32

N
LY

*[LDP/9] [Link], metric 1

> to [Link] via ge-1/0/0.220, Push 299952
to [Link] via ge-1/0/1.221, label-switched-path
*[LDP/9] [Link], metric 1
> to [Link] via ge-1/0/0.220, Push 299968
to [Link] via ge-1/0/1.221, label-switched-path
*[LDP/9] [Link],
> to [Link]
*[LDP/9] [Link],
> to [Link]
*[LDP/9] [Link],
> to [Link]

IN

TE
R

[Link]/32

protect
[Link]/32

[LDP/9] [Link], metric 1

> to [Link] via ge-1/0/0.220
to [Link] via ge-1/0/1.221, label-switched-path

SE

protect

[Link]/32

*[LDP/9] [Link], metric 1

> to [Link] via ge-1/0/0.220, Push 300704
to [Link] via ge-1/0/1.221, Push 300592
*[RSVP/7/1] [Link], metric 1
> to [Link] via ge-1/0/1.221, label-switched-path

metric 1
via ge-1/0/1.221
metric 1
via ge-1/0/1.221, Push 299984
metric 1
via ge-1/0/1.221, Push 300000

AL

[Link]/32

Question: How did the routing tables change by

adding the RSVP LSP?

Answer: For most routes that use the protected

interface as the primary next hop, the LSP has been
added as a second next hop.
Question: Did the next hops for route to the remote
PE change? Why?

Answer: The next hops associated with the route to

the remote PE did not change because OSPF was
able to calculate two equal cost paths to the remote
PE. When there are more than one equal cost
paths, link protection is not necessary.
[Link]

Traffic Protection (Detailed) Lab 443

Junos MPLS and VPNs

Question: For the LDP routes, what type of LSP is

being used to protect the interface?

Answer: The routing table shows that it will be an

RSVP LSP that will provide the protection if the
protected interface fails.
Step 9.11
Log out of your assigned device using the exit command.

N
LY

lab@mxB-1> exit
mxB-1 (ttyu0)

login:

Tell your instructor that you have completed this lab.

IN

TE
R

AL

SE

STOP

Lab 444 Traffic Protection (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

Traffic Protection (Detailed) Lab 445

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 446 Traffic Protection (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

Traffic Protection (Detailed) Lab 447

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 448 Traffic Protection (Detailed)

[Link]

Lab

N
LY

Fate Sharing (Detailed)

Overview

SE

In this lab, you will load a baseline multiprotocol label switching (MPLS) network. You will
analyze the default fate sharing behavior of your Juniper router. You will then configure
fate sharing so that you can avoid a single point of failure between the primary and
secondary paths of an MPLS label switched path (LSP). Next, you will enable Shared Risk
Link Group (SRLG) values in the network such the IGP can help improve the Junos
operating systems default fate sharing behavior. Finally, you will repurpose a set of SRLG
values for use as extended admin groups.

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.
By completing this lab, you will perform the following tasks:
Load a baseline network.

Define an Resource Reservation Protocol (RSVP) signaled LSP to the remote

provider edge (PE) router.
Add primary/secondary path protection to an LSP.
Analyze the default fate sharing behavior of you Juniper routers.

TE
R

AL

Modify the fate sharing behavior of you Juniper router.

Enable and analyze the use of SRLG values.

Enable extended admin groups to be used for signaling MPLS LSPs.

IN

[Link]

Fate Sharing (Detailed) Lab 51

Junos MPLS and VPNs

Part 1: Creating the Baseline Network

Note

N
LY

In this lab part, you will create the baseline network for the lab. You will load a
baseline configuration which will configure your routers interfaces, six logical
systems that represent the core network (p1, p2, p3, p4, pe2, and VS), and the
Open Shortest Path First (OSPF) topology. Since the core network is already
configured for you, you will only be responsible for configure pe1 (the default logical
system). The loaded configuration will also enable RSVP and MPLS on the
core-facing interfaces of the pe1 router.

The instructor will tell you the nature of your

access and will provide you with the
necessary details to access your assigned
device.
Step 1.1

SE

Ensure that you know to which device you are assigned. Check with your instructor if
necessary.
Step 1.2

Consult the management network diagram, provided by your instructor, to determine

your devices management address.

AL

Question: What is the management address

assigned to your station?

IN

TE
R

Answer: The answer varies. The sample hostname

and IP address used in the output examples in this
lab are for mxB-1, which uses [Link] as its
management IP address. The actual management
subnet varies between delivery environments.

Lab 52 Fate Sharing (Detailed)

[Link]

Junos MPLS and VPNs

Step 1.3

N
LY

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
mxB-1 using the Secure CRT program.

SE

Step 1.4

login: lab
Password:

AL

mxB-1 (ttyp0)

Log in as user lab with the password supplied by your instructor. Enter
configuration mode and load the reset configuration file
jmv/[Link]. Commit the configuration and return to operational
mode.

TE
R

--- JUNOS 12.3R2.5 built 2013-03-22 [Link] UTC

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# load override jmv/[Link]
load complete

IN

[edit]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 1.5
Verify that your Open Shortest Path First (OSPF) neighbor relationships are up and
operational.

[Link]

Fate Sharing (Detailed) Lab 53

Junos MPLS and VPNs

lab@mxB-1> show ospf neighbor

Address
Interface
[Link]
ge-1/0/5.100
[Link]
ge-1/0/5.200
[Link]
ge-1/0/6.100

State
Full
Full
Full

ID
[Link]
[Link]
[Link]

Pri
128
128
128

Dead
36
35
33

N
LY

Question: What is the state of your PE routers OSPF

neighbors?

Answer: After a short time, the OSPF neighbors

should attain the Full state.
Step 1.6

Use the show route command to verify that your PE router has learned routes to
the loopback address of all of the core routers in the network.
lab@mxB-1> show route 193.168/16

[Link]/32
[Link]/32
[Link]/32

TE
R

[Link]/32

AL

[Link]/32

*[Direct/0] 4d [Link]
> via lo0.0
*[OSPF/10] [Link], metric 1
> to [Link] via ge-1/0/6.100
*[OSPF/10] [Link], metric 1
> to [Link] via ge-1/0/5.100
*[OSPF/10] [Link], metric 1
> to [Link] via ge-1/0/5.200
*[OSPF/10] [Link], metric 2
> to [Link] via ge-1/0/6.100
*[OSPF/10] [Link], metric 2
to [Link] via ge-1/0/5.100
> to [Link] via ge-1/0/5.200

[Link]/32

SE

inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

IN

Question: Has your PE router learned a route to

each of the core routers loopback addresses?

Lab 54 Fate Sharing (Detailed)

Answer: Yes, your router should have learned a

route for every router in the network from the OSPF
protocol.

[Link]

Junos MPLS and VPNs

Question: From your pe1s perspective what is the

best path to take to get to pe2? Describe that path.

N
LY

Answer: The output of the command shows that

there are two equal cost paths to get to pe2
([Link]). The best path from pe1 to pe2
would be across the pe1-p2-pe2 links or the
pe1-p3-pe2 links. Both paths traverse a common
Ethernet switch.
Step 1.7

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

Static
BW
1000Mbps
1000Mbps
1000Mbps

AL

lab@mxB-1> show rsvp interface

RSVP interface: 3 active
Active SubscrInterface
State resv
iption
ge-1/0/5.100Up
0
100%
ge-1/0/5.200Up
0
100%
ge-1/0/6.100Up
0
100%

SE

lab@mxB-1> show mpls interface

Interface
State
Administrative groups (x: extended)
ge-1/0/5.100
Up
<none>
ge-1/0/5.200
Up
<none>
ge-1/0/6.100
Up
<none>

Available
BW
1000Mbps
1000Mbps
1000Mbps

Reserved
BW
0bps
0bps
0bps

Highwater
mark
0bps
0bps
0bps

Answer: The outputs of the two commands show

that the two interfaces can now support the
forwarding of MPLS packets.

IN

TE
R

Question: Can your core-facing interfaces now

support the transmission of MPLS packets?

[Link]

Fate Sharing (Detailed) Lab 55

Junos MPLS and VPNs

Part 2: Creating an LSP to the Remote PE

In this lab part, you will create an RSVP-signaled LSP from pe1 to pe2. You will
create two empty paths (no EROs or admin groups) called path1 and path2. You
will apply path1 as the primary path of your LSP and path2 as the secondary path
of your LSP while ensuring that the secondary LSP is in standby mode.
Step 2.1
Enter configuration mode and navigate to the [edit protocols mpls]
hierarchy. Create two empty paths called path1 and path2.

N
LY

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit protocols mpls

[edit protocols mpls]

lab@mxB-1# set path path1

SE

[edit protocols mpls]

lab@mxB-1# set path path2
[edit protocols mpls]
lab@mxB-1#

Step 2.2

AL

Configure an LSP named lsp1 from pe1 to pe2 with a primary path of path1 and a
secondary path of path2. Ensure the secondary path is on standby. Your LSP
should egress at pe2s loopback address.

[edit protocols mpls]

lab@mxB-1# set label-switched-path lsp1 to [Link]

TE
R

[edit protocols mpls]

lab@mxB-1# set label-switched-path lsp1 primary path1
[edit protocols mpls]
lab@mxB-1# set label-switched-path lsp1 secondary path2 standby

IN

Step 2.3

Enable traceoptions for MPLS by configuring a file name [Link] and

specify the flags of cspf, cspf-link, and cspf-node. Commit your
configuration and exit to operational mode.

[edit protocols mpls]

lab@mxB-1# set traceoptions file [Link]
[edit protocols mpls]
lab@mxB-1# set traceoptions flag cspf
[edit protocols mpls]
lab@mxB-1# set traceoptions flag cspf-link

Lab 56 Fate Sharing (Detailed)

[Link]

Junos MPLS and VPNs

[edit protocols mpls]

lab@mxB-1# set traceoptions flag cspf-node
[edit protocols mpls]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 2.4

lab@mxB-1> show rsvp session ingress detail

Ingress RSVP: 2 sessions

N
LY

Issue the show rsvp session ingress detail command to verify that the
new LSPs are up and also determine the path that they are taking.

AL

SE

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: lsp1, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 299776
Resv style: 1 FF, Label in: -, Label out: 299776
Time left:
-, Since: Mon Jun 3 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 18433 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/5.100) 10 pkts
RESV rcvfrom: [Link] (ge-1/0/5.100) 9 pkts
Explct route: [Link] [Link]
Record route: <self> [Link] [Link]

IN

TE
R

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: lsp1, LSPpath: Secondary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 299776
Resv style: 1 FF, Label in: -, Label out: 299776
Time left:
-, Since: Mon Jun 3 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 2 receiver 18434 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/5.200) 9 pkts
RESV rcvfrom: [Link] (ge-1/0/5.200) 8 pkts
Explct route: [Link] [Link]
Record route: <self> [Link] [Link]
Total 2 displayed, Up 2, Down 0

[Link]

Fate Sharing (Detailed) Lab 57

Junos MPLS and VPNs

Question: Are the new LSPs up?

Answer: Yes, the LSPs should be up.

N
LY

Question: What path are the LSPs taking through

the network?

Answer: The answer will vary by student. In the

example the primary LSP is traversing the
pe1-p2-pe2 links while the secondary LSP is
traversing the pe1-p3-pe2 links.

SE

Question: Do the two LSPs have a potential single

point of failure?

Answer: The LSPs both traverse the single Ethernet

switch. This causes a single point of failure between
the two LSPs.

AL

Question: Why do you think that the primary and

secondary LSPs do not take the exact same path?

IN

TE
R

Answer: The reason the LSPs do not traverse the

exact same path is because of the Junos OSs
default fate sharing behavior. Prior to running the
CSPF algorithm for the secondary LSP, the Junos OS
will add 8000000 to the CSPF metric of the links
traversed by the primary LSP.
Question: Why does the secondary path not take
the pe1-p1-p4-pe2 links?

Answer: The reason the secondary path does not

traverse the pe1-p1-p4-pe2 link is because the
router has determined that it is not the shortest
cost path to get to the pe2 router. That path has a
cost of 3 while one of the other paths only has a
cost of 2.
Lab 58 Fate Sharing (Detailed)

[Link]

Junos MPLS and VPNs

Step 2.5
Issue the clear log [Link] command to empty the contents of the
log file.
lab@mxB-1> clear log [Link]

Step 2.6
Clear the MPLS LSP and determine the path of the resignaled primary and
secondary LSPs.
Step 2.7

N
LY

lab@mxB-1> clear mpls lsp

lab@mxB-1> show rsvp session ingress detail

Ingress RSVP: 2 sessions

Issue the show rsvp session ingress detail command to verify that the
new LSPs are up and also determine the path that they are taking. It might take 30
seconds for the secondary to get to the up state.

TE
R

AL

SE

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: lsp1, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 299792
Resv style: 1 FF, Label in: -, Label out: 299792
Time left:
-, Since: Mon Jun 3 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 3 receiver 18433 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/5.100) 4 pkts
RESV rcvfrom: [Link] (ge-1/0/5.100) 4 pkts
Explct route: [Link] [Link]
Record route: <self> [Link] [Link]

IN

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: lsp1, LSPpath: Secondary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 299792
Resv style: 1 FF, Label in: -, Label out: 299792
Time left:
-, Since: Mon Jun 3 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 4 receiver 18434 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/5.200) 3 pkts
RESV rcvfrom: [Link] (ge-1/0/5.200) 3 pkts

[Link]

Fate Sharing (Detailed) Lab 59

Junos MPLS and VPNs

Explct route: [Link] [Link]

Record route: <self> [Link] [Link]
Total 2 displayed, Up 2, Down 0

Question: Are the new LSPs up?

Answer: Yes, the LSPs should be up.

N
LY

Question: What path are the LSPs taking through

the network?

Answer: The answer will vary by student. In the

example the primary LSP is traversing the
pe1-p2-pe2 links while the secondary LSP is
traversing the pe1-p3-pe2 links.

SE

Step 2.8

View the [Link] file to view the CSPF calculation of the secondary LSP.

IN

TE
R

AL

lab@mxB-1> show log [Link] | find secondary

Jun 3 [Link].857429 CSPF adding path lsp1(secondary path2) to CSPF queue 0
Jun 3 [Link].857511 CSPF creating CSPF job
Jun 3 [Link].857631
Jun 3 [Link].857662 CSPF for path lsp1(secondary path2), begin at
0000.0000.0000.00 , starting
Jun 3 [Link].857699 path SRLG: Unknown-0x3e8 Unknown-0x64
Jun 3 [Link].857745 bandwidth: CT0=0bps ; setup priority: 0; random
Jun 3 [Link].857785 CSPF credibility 0
Jun 3 [Link].857808 CSPF final destination [Link]
Jun 3 [Link].857844 CSPF starting from 0000.0000.0000.00 ([Link]) to
[Link], hoplimit 254
Jun 3 [Link].857867 constraint avoid primary path
...
Jun 3 [Link].858809
Link [Link]->[Link](0000.0000.0000.00/
[Link], Link IDs 0->0) metric 0 color 0x00000000 bw 0bps
Jun 3 [Link].858839 Reverse Link for
[Link]([Link]:0)->[Link]([Link]:0) is
[Link]([Link]:0)->[Link]([Link]:0)
Jun 3 [Link].858860 no constraints to check
Jun 3 [Link].858883 Link overlap with primary path, adding cost 8000000
...

Lab 510 Fate Sharing (Detailed)

[Link]

Junos MPLS and VPNs

Question: Can you tell from the log file as to why the
primary and secondary LSPs do not take the exact
same path?

N
LY

Answer: The reason the LSPs do not traverse the

exact same path is because of the Junos OSs
default fate sharing behavior. As shown in the log
output, prior to running the CSPF algorithm for the
secondary LSP, the Junos OS adds 8000000 to the
CSPF metric of the links traversed by the primary
LSP.

Part 3: Configuring Fate Sharing

SE

In this lab part, you will configure fate sharing so that the ingress router can attempt
to avoid the single point of failure (the Ethernet switch) when signaling the
secondary LSP.
Step 3.1

AL

Enter configuration mode and navigate to the [edit routing-options]

hierarchy. Configure a fate sharing group called switch. Configure fate sharing for
that group such that a cost of 20000 will be added to all links associated with the
Ethernet switch (in the event that the primary traverses the switch) prior to
calculating the path of the secondary LSP. Commit your configuration and exit to
operational mode.

lab@mxB-1> configure
Entering configuration mode

TE
R

[edit]
lab@mxB-1# edit routing-options
[edit routing-options]
lab@mxB-1# set fate-sharing group switch cost 20000

IN

[edit routing-options]
lab@mxB-1# set fate-sharing group switch from [Link]

[edit routing-options]
lab@mxB-1# set fate-sharing group switch from [Link]

[edit routing-options]
lab@mxB-1# set fate-sharing group switch from [Link]
[edit routing-options]
lab@mxB-1# set fate-sharing group switch from [Link]
[edit routing-options]
lab@mxB-1# commit and-quit
[Link]

Fate Sharing (Detailed) Lab 511

Junos MPLS and VPNs

commit complete
Exiting configuration mode
lab@mxB-1>

Step 3.2
Issue the clear log [Link] command to empty the contents of the
log file.
lab@mxB-1> clear log [Link]

Step 3.3

N
LY

Clear the MPLS LSP and determine the path of the resignaled primary and
secondary LSPs.
lab@mxB-1> clear mpls lsp

Step 3.4

Issue the show rsvp session ingress detail command to verify that the
new LSPs are up and also determine the path that they are taking. It may take 30
seconds for the secondary to get to the up state.

SE

lab@mxB-1> show rsvp session ingress detail

Ingress RSVP: 2 sessions

IN

TE
R

AL

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: lsp1, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 299808
Resv style: 1 FF, Label in: -, Label out: 299808
Time left:
-, Since: Mon Jun 3 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 5 receiver 18433 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/5.100) 3 pkts
RESV rcvfrom: [Link] (ge-1/0/5.100) 3 pkts
Explct route: [Link] [Link]
Record route: <self> [Link] [Link]
[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: lsp1, LSPpath: Secondary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 299776
Resv style: 1 FF, Label in: -, Label out: 299776
Time left:
-, Since: Mon Jun 3 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 6 receiver 18434 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Lab 512 Fate Sharing (Detailed)

[Link]

Junos MPLS and VPNs

Path MTU: received 1500

PATH sentto: [Link] (ge-1/0/6.100) 3 pkts
RESV rcvfrom: [Link] (ge-1/0/6.100) 3 pkts
Explct route: [Link] [Link] [Link]
Record route: <self> [Link] [Link] [Link]
Total 2 displayed, Up 2, Down 0

Question: Are the new LSPs up?

N
LY

Answer: Yes, the LSPs should be up.

Question: What path are the LSPs taking through

the network?

SE

Answer: The answer will vary by student. In the

example the primary LSP is traversing the
pe1-p2-pe2 links while the secondary LSP is
traversing the pe1-p1-p4-pe2 links.

AL

Question: Has the single point of failure (Ethernet

switch) been avoided by the secondary path of the
LSP?

TE
R

Step 3.5

Answer: The single point of failure has been

avoided.

View the [Link] file to view the CSPF calculation of the secondary LSP.

IN

lab@mxB-1> show log [Link] | find secondary

Jun 3 [Link].133225 CSPF adding path lsp1(secondary path2) to CSPF queue 0
Jun 3 [Link].133301 CSPF creating CSPF job
Jun 3 [Link].133410
Jun 3 [Link].133441 CSPF for path lsp1(secondary path2), begin at
0000.0000.0000.00 , starting
Jun 3 [Link].133472 CSPF adding fate-sharing group "switch"
Jun 3 [Link].133501 path SRLG: Unknown-0x3e8 Unknown-0x64
Jun 3 [Link].133545 bandwidth: CT0=0bps ; setup priority: 0; random
Jun 3 [Link].133585 CSPF credibility 0
Jun 3 [Link].133607 CSPF final destination [Link]
Jun 3 [Link].133644 CSPF starting from 0000.0000.0000.00 ([Link]) to
[Link], hoplimit 254
Jun 3 [Link].133703 constraint avoid primary path
...
[Link]

Fate Sharing (Detailed) Lab 513

Junos MPLS and VPNs

Jun 3 [Link].133906 fate-sharing "switch" detected while passing

"[Link]-1", adding cost 20000
Jun 3 [Link].133929 Effective link metric 20001
...
Jun 3 [Link].134090 fate-sharing "switch" detected while passing
"[Link]-1", adding cost 20000
Jun 3 [Link].134112 Effective link metric 20001
Jun 3 [Link].134170
Link [Link]->[Link](0000.0000.0000.00/
[Link], Link IDs 0->0) metric 1 color 0x00000000 bw 1000Mbps

N
LY

Question: During the CSPF calculation of the

secondary path, what is the CSPF metric being used
for the pe1-p2 link as well as the pe1-p3 link?

Answer: The ingress router is adding 20000 to both

links so the metric is 20001 for each link.

SE

Part 4: Configuring SRLGs

In this lab part, you will configure an SRLG so that the ingress router can attempt to
avoid the single point of failure (the Ethernet switch) when signaling the secondary
LSP. Use the diagram labeled Fate Sharing Lab - Part 4 for this part of the lab.
Step 4.1

AL

Enter configuration mode and navigate to the [edit routing-options]

hierarchy. Delete the entire configuration hierarchy at that level.

lab@mxB-1> configure
Entering configuration mode

TE
R

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

IN

[edit routing-options]
lab@mxB-1# delete
Delete everything under this level? [yes,no] (no) yes
[edit routing-options]
lab@mxB-1#

Step 4.2

Configure an SRLG called switch1. This SRLG should have a SRLG value of 1003
and an SRLG cost of 20000.
[edit routing-options]
lab@mxB-1# set srlg switch1 srlg-value 1003
[edit routing-options]
lab@mxB-1# set srlg switch1 srlg-cost 20000
Lab 514 Fate Sharing (Detailed)

[Link]

Junos MPLS and VPNs

Step 4.3
Navigate to the [edit protocols mpls] hierarchy. Apply the switch1 SRLG
to the two ge-1/0/5 subinterfaces that attach to the Ethernet switch. Commit your
configuration and exit to operational mode.
[edit routing-options]
lab@mxB-1# top edit protocols mpls

[edit protocols mpls]

lab@mxB-1# set interface ge-1/0/5.200 srlg switch1

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

N
LY

[edit protocols mpls]

lab@mxB-1# set interface ge-1/0/5.100 srlg switch1

lab@mxB-1>

SE

Step 4.4

Issue the clear log [Link] command to empty the contents of the
log file.

lab@mxB-1> clear log [Link]

Step 4.5

AL

Clear the MPLS LSP and determine the path of the resignaled primary and
secondary LSPs.
Step 4.6

lab@mxB-1> clear mpls lsp

TE
R

Issue the show rsvp session ingress detail command to verify that the
new LSPs are up and also determine the path that they are taking. It may take 30
seconds for the secondary to get to the up state.

lab@mxB-1> show rsvp session ingress detail

Ingress RSVP: 2 sessions

IN

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: lsp1, LSPpath: Primary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 299824
Resv style: 1 FF, Label in: -, Label out: 299824
Time left:
-, Since: Mon Jun 3 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 5 receiver 18435 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/5.200) 3 pkts
[Link]

Fate Sharing (Detailed) Lab 515

Junos MPLS and VPNs

RESV rcvfrom: [Link] (ge-1/0/5.200) 3 pkts

Explct route: [Link] [Link]
Record route: <self> [Link] [Link]

SE

N
LY

[Link]
From: [Link], LSPstate: Up, ActiveRoute: 0
LSPname: lsp1, LSPpath: Secondary
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: Recovery label received: -, Recovery label sent: 299808
Resv style: 1 FF, Label in: -, Label out: 299808
Time left:
-, Since: Mon Jun 3 [Link] 2013
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 6 receiver 18436 protocol 0
PATH rcvfrom: localclient
Adspec: sent MTU 1500
Path MTU: received 1500
PATH sentto: [Link] (ge-1/0/6.100) 1 pkts
RESV rcvfrom: [Link] (ge-1/0/6.100) 1 pkts
Explct route: [Link] [Link] [Link]
Record route: <self> [Link] [Link] [Link]
Total 2 displayed, Up 2, Down 0

Question: Are the new LSPs up?

Answer: Yes, the LSPs should be up.

AL

Question: What path are the LSPs taking through

the network?

TE
R

Answer: The answer will vary by student. In the

example the primary LSP is traversing the
pe1-p3-pe2 links while the secondary LSP is
traversing the pe1-p1-p4-pe2 links.

IN

Question: Has the single point of failure (Ethernet

switch) been avoided by the secondary path of the
LSP?

Answer: The single point of failure has been

avoided.
Step 4.7
View the [Link] file to view the CSPF calculation of the secondary LSP.
Lab 516 Fate Sharing (Detailed)

[Link]

Junos MPLS and VPNs

IN

TE
R

AL

SE

N
LY

lab@mxB-1> show log [Link] | find secondary

Jun 3 [Link].198619 CSPF adding path lsp1(secondary path2) to CSPF queue 0
Jun 3 [Link].198705 CSPF creating CSPF job
Jun 3 [Link].198816
Jun 3 [Link].198846 CSPF for path lsp1(secondary path2), begin at
0000.0000.0000.00 , starting
Jun 3 [Link].198883 path SRLG: switch1 Unknown-0x65
Jun 3 [Link].198929 bandwidth: CT0=0bps ; setup priority: 0; random
Jun 3 [Link].198969 CSPF credibility 0
Jun 3 [Link].198992 CSPF final destination [Link]
Jun 3 [Link].199028 CSPF starting from 0000.0000.0000.00 ([Link]) to
[Link], hoplimit 254
Jun 3 [Link].199088 constraint avoid primary path
Jun 3 [Link].199114
Node 0000.0000.0000.00 ([Link]) metric 0, hops
0, avail 32000 32000 32000 32000
Jun 3 [Link].199158
Link [Link]->[Link](0000.0000.0000.00/
[Link], Link IDs 0->0) metric 1 color 0x00000000 bw 1000Mbps
Jun 3 [Link].199192 Reverse Link for
[Link]([Link]:0)->[Link]([Link]:0) is
[Link]([Link]:0)->[Link]([Link]:0)
Jun 3 [Link].199220 link's interface switch capability descriptor #1
Jun 3 [Link].199243
encoding: Packet, switching: Packet
Jun 3 [Link].199264 link passes constraints
Jun 3 [Link].199288 Effective link metric with SRLG: 20001
Jun 3 [Link].199326
Link [Link]->[Link](0000.0000.0000.00/
[Link], Link IDs 0->0) metric 1 color 0x00000000 bw 1000Mbps
Jun 3 [Link].199358 Reverse Link for
[Link]([Link]:0)->[Link]([Link]:0) is
[Link]([Link]:0)->[Link]([Link]:0)
Jun 3 [Link].199382 link's interface switch capability descriptor #1
Jun 3 [Link].199404
encoding: Packet, switching: Packet
Jun 3 [Link].199424 link passes constraints
Jun 3 [Link].199446 Effective link metric with SRLG: 20001
...

Question: During the CSPF calculation of the

secondary path, what is the CSPF metric being used
for the pe1-p2 link as well as the pe1-p3 link?

Answer: The ingress router is adding 20000 to both

links so the metric is 20001 for each link.

Step 4.8
Issue to the show mpls lsp extensive command to determine the SRLGs that
each path is currently traversing.
lab@mxB-1> show mpls lsp extensive
Ingress LSP: 1 sessions
[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: lsp1
[Link]

Fate Sharing (Detailed) Lab 517

Junos MPLS and VPNs

N
LY

ActivePath: path1 (primary)

LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary
path1
State: Up
Priorities: 7 0
SmartOptimizeTimer: 180
SRLG: switch1 Unknown-0x65
...
Standby
path2
State: Up
Priorities: 7 0
SmartOptimizeTimer: 180
SRLG: Unknown-0x66
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
...

SE

Question: What SRLGs are the primary path

traversing?

Answer: The answer will vary by student but the

output shows that the SRLG is currently traversing
the switch1 SRLG as well as an unknown SRLG with
a value of 0x65 (SRLG value 101).

AL

Question: What SRLGs are the secondary path

traversing?

TE
R

Answer: The answer will vary by student but the

output shows that the SRLG is currently traversing
an unknown SRLG with a value of 0x66 (SRLG value
102).

IN

Question: What could explain the reason why your

are seeing unknown SRLG values?

Answer: An unknown SRLG value occurs when a

different router in the network is advertising that an
interface is assigned an SRLG value but you have
not locally configured an entry in the name-to-value
table (under routing-options) for that SRLG
value.

Lab 518 Fate Sharing (Detailed)

[Link]

Junos MPLS and VPNs

Part 5: Configuring Extended Admin Groups

In this lab part, you will repurpose 100 SRLG values so that they can be used as
extended admin groups. You will then configure an LSP that will traverse links that
have been colored with extended admin groups.
Step 5.1
Enter configuration mode and navigate to the [edit routing-options]
hierarchy. Configure the extended admin group range to be from 100 to 900.

N
LY

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit routing-options

[edit routing-options]
lab@mxB-1# set admin-groups-extended-range minimum 100 maximum 900

SE

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

Step 5.2

Configure 3 extended admin group called gold (value 100), silver (value 101),
and bronze (value 102).
[edit routing-options]
lab@mxB-1# set admin-groups-extended gold group-value 100

AL

[edit routing-options]
lab@mxB-1# set admin-groups-extended silver group-value 101

TE
R

Step 5.3

[edit routing-options]
lab@mxB-1# set admin-groups-extended bronze group-value 102

Navigate to the [edit protocols mpls] hierarchy and apply (color) the
appropriate extended groups to your core facing interfaces.

[edit routing-options]
lab@mxB-1# top edit protocols mpls

IN

[edit protocols mpls]

lab@mxB-1# set interface ge-1/0/5.100 admin-group-extended gold
[edit protocols mpls]
lab@mxB-1# set interface ge-1/0/5.200 admin-group-extended silver

[edit protocols mpls]

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

[Link]

Fate Sharing (Detailed) Lab 519

Junos MPLS and VPNs

Step 5.4
Navigate to the [edit protocols mpls label-switched-path
lsp-bronze] and configure an MPLS LSP named lsp-bronze. Ensure that it
uses path1 as its primary path and that the LSP will only traverse links that are
colored with the bronze extended admin group. The LSP should egress at the pe2
router. Commit your configuration and exit to operational mode.

[edit protocols mpls label-switched-path lsp-bronze]

lab@mxB-1# set to [Link]

N
LY

[edit protocols mpls]

lab@mxB-1# edit label-switched-path lsp-bronze

[edit protocols mpls label-switched-path lsp-bronze]

lab@mxB-1# set primary path1 admin-group-extended include-all bronze

[edit protocols mpls label-switched-path lsp-bronze]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

SE

lab@mxB-1>

Step 5.5

Issue the show mpls interface command to verify that the extended admin
groups have been applied properly to the pe1 routers interfaces.

AL

lab@mxB-1> show mpls interface

Interface
State
Administrative groups (x: extended)
ge-1/0/5.100
Up
<none>gold(x)
ge-1/0/5.200
Up
<none>silver(x)
ge-1/0/6.100
Up
<none>bronze(x)

TE
R

Question: Have the extended admin group been

applied correctly to the pe1 routers interfaces?

IN

Answer: All interfaces should now show the

appropriate extended admin groups.

Step 5.6

Issue to the show mpls lsp extensive name lsp-bronze command to

determine the SRLGs that each path is currently traversing.

lab@mxB-1> show mpls lsp extensive name lsp-bronze

Ingress LSP: 2 sessions
[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: lsp-bronze
ActivePath: path1 (primary)
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
Lab 520 Fate Sharing (Detailed)

[Link]

Junos MPLS and VPNs

Transit LSP: 0 sessions

Total 0 displayed, Up 0, Down 0

SE

Egress LSP: 0 sessions

Total 0 displayed, Up 0, Down 0

N
LY

Encoding type: Packet, Switching type: Packet, GPID: IPv4

*Primary
path1
State: Up
Priorities: 7 0
SmartOptimizeTimer: 180
Extended Admin Group Include All: bronze
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3)
[Link] S [Link] S [Link] S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt
20=Node-ID):
[Link] [Link] [Link]
6 Jun 3 [Link].462 Selected as active path
5 Jun 3 [Link].459 Record Route: [Link] [Link] [Link]
4 Jun 3 [Link].459 Up
3 Jun 3 [Link].435 Originate Call
2 Jun 3 [Link].435 CSPF: computation result accepted [Link] [Link]
[Link]
1 Jun 3 [Link].000 CSPF failed: no route toward [Link][40 times]
Created: Mon Jun 3 [Link] 2013
Total 1 displayed, Up 1, Down 0

AL

Question: What path is the lsp-bronze LSP taking to

reach the pe2 router

TE
R

Step 5.7

Answer: The LSP should traverse the pe1-p1-p4-pe2

path.

Log out of your assigned device using the exit command.

lab@mxB-1> exit

IN

mxB-1 (ttyu0)
login:

STOP

[Link]

Tell your instructor that you have completed this lab.

Fate Sharing (Detailed) Lab 521

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 522 Fate Sharing (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

Fate Sharing (Detailed) Lab 523

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 524 Fate Sharing (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

Fate Sharing (Detailed) Lab 525

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 526 Fate Sharing (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

Fate Sharing (Detailed) Lab 527

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 528 Fate Sharing (Detailed)

[Link]

Lab

N
LY

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

SE

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

TE
R

AL

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.

IN

[Link]

Miscellaneous MPLS Features (Detailed) Lab 61

Junos MPLS and VPNs

Part 1: Configuring the Baseline Network

In this lab part, you will load a configuration that will automatically configure the
interfaces and networks needed to establish an internal BGP (IBGP) peering
between your provider edge (PE) router and the remote PE router. The loaded
configuration will also enable RSVP and MPLS on the core-facing interfaces. After
loading the configuration, you will configure an LSP to traverse the network to
terminate at the remote provider edge (PE) router.

N
LY

Note

The instructor will tell you the nature of your

access and will provide you with the
necessary details to access your assigned
device.

Step 1.1

SE

Ensure that you know to which device you are assigned. Check with your instructor if
necessary.
Step 1.2

Consult the management network diagram, provided by your instructor, to determine

your devices management address.

AL

Question: What is the management address

assigned to your station?

IN

TE
R

Answer: The answer varies. The sample hostname

and IP address used in the output examples in this
lab are for mxB-1, which uses [Link] as its
management IP address. The actual management
subnet varies between delivery environments.

Lab 62 Miscellaneous MPLS Features (Detailed)

[Link]

Junos MPLS and VPNs

Step 1.3

N
LY

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
mxB-1 using the Secure CRT program.

SE

Step 1.4

login: lab
Password:

AL

mxB-1 (ttyp0)

Log in as user lab with the password supplied by your instructor. Enter
configuration mode and load the reset configuration file
jmv/[Link]. Commit the configuration and return to operational
mode.

TE
R

--- JUNOS 12.3R2.5 built 2013-03-22 [Link] UTC

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# load override jmv/[Link]
load complete

IN

[edit]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 1.5
Verify that your Open Shortest Path First (OSPF) neighbor relationships are up and
operational.

[Link]

Miscellaneous MPLS Features (Detailed) Lab 63

Junos MPLS and VPNs

lab@mxB-1> show ospf neighbor

Address
Interface
[Link]
ge-1/0/0.220
[Link]
ge-1/0/1.221

State
Full
Full

ID
[Link]
[Link]

Pri
128
128

Dead
34
39

Question: What is the state of your PE routers OSPF

neighbors?

N
LY

Answer: After a short time, the OSPF neighbors

should attain the Full state.
Step 1.6

Verify that your PE router has established an IBGP neighbor relationship with the
remote PE router.

IN

TE
R

AL

SE

lab@mxB-1> show bgp neighbor

Peer: [Link]+53868 AS 65512 Local: [Link]+179 AS 65512
Type: Internal
State: Established
Flags: <Sync>
Last State: OpenConfirm
Last Event: RecvKeepAlive
Last Error: Cease
Options: <Preference LocalAddress Refresh>
Local Address: [Link] Holdtime: 90 Preference: 170
Number of flaps: 2
Last flap event: Stop
Error: 'Hold Timer Expired Error' Sent: 1 Recv: 0
Error: 'Cease' Sent: 2 Recv: 0
Peer ID: [Link]
Local ID: [Link]
Active Holdtime: 90
Keepalive Interval: 30
Group index: 0
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)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
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:
1
Received prefixes:
1
Accepted prefixes:
1
Suppressed due to damping:
0
Advertised prefixes:
0

Lab 64 Miscellaneous MPLS Features (Detailed)

[Link]

Junos MPLS and VPNs

Last traffic (seconds): Received 6

Sent 6
Input messages: Total 4
Updates 2
Output messages: Total 3
Updates 0
Output Queue[0]: 0

Checked 6
Refreshes 0
Refreshes 0

Octets 149
Octets 120

N
LY

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

SE

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 groups (x: extended)
ge-1/0/0.220
Up
<none>
ge-1/0/1.221
Up
<none>

IN

TE
R

AL

lab@mxB-1> show rsvp interface

RSVP interface: 2 active
Active SubscrInterface
State resv
iption
ge-1/0/0.220Up
0
100%
ge-1/0/1.221Up
0
100%

Static
BW
1000Mbps
1000Mbps

Available
BW
1000Mbps
1000Mbps

Reserved
BW
0bps
0bps

Highwater
mark
0bps
0bps

Question: Can your core-facing interfaces now

support the transmission of MPLS packets?

Answer: The outputs of the two commands show

that the two interfaces can now support the
forwarding of MPLS packets.

Step 1.8
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
localPE-to-remotePE-pod. For example, if you are assigned router mxB-1,
your peer router is mxB-2 and your pod is B. The LSP for mxB-1 should be named
pe1-to-pe2-B. 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.
[Link]

Miscellaneous MPLS Features (Detailed) Lab 65

Junos MPLS and VPNs

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit protocols mpls
[edit protocols mpls]
lab@mxB-1# set label-switched-path localPE-to-remotePE-pod to
remote-pe-loopback-address

N
LY

[edit protocols mpls]

lab@mxB-1# show
label-switched-path pe1-to-pe2-B {
to [Link];
}
interface ge-1/0/0.220;
interface ge-1/0/1.221;
interface lo0.0;

SE

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 1.9

AL

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

lab@mxB-1> show mpls lsp

Ingress LSP: 1 sessions
To
From
State Rt P
[Link]
[Link]
Up
0 *
Total 1 displayed, Up 1, Down 0

TE
R

Egress LSP: 1 sessions

To
From
State
[Link]
[Link]
Up
Total 1 displayed, Up 1, Down 0

ActivePath

LSPname
pe1-to-pe2-B

Rt Style Labelin Labelout LSPname

0 1 FF
3
- pe2-to-pe1-B

IN

Transit LSP: 0 sessions

Total 0 displayed, Up 0, Down 0

Lab 66 Miscellaneous MPLS Features (Detailed)

[Link]

Junos MPLS and VPNs

Question: How many LSPs are reflected in the

output and what are the terminating points?

N
LY

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.

Do not proceed until the remote team finishes Part 1.

SE

STOP

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

Step 2.1

AL

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
teams route as a destination that will use the established LSP for all traffic to the
new network.

TE
R

Enter configuration mode and navigate to the [edit protocols ospf area
[Link]] 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.

IN

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit protocols ospf area 0
[edit protocols ospf area [Link]]
lab@mxB-1# set interface ge-1/0/4 passive
[edit protocols ospf area [Link]]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>
[Link]

Miscellaneous MPLS Features (Detailed) Lab 67

Junos MPLS and VPNs

Step 2.2
Use the show ospf interface command to verify the new interface is
participating in your OSPF network.
lab@mxB-1> show ospf interface
Interface
State
Area
ge-1/0/0.230
BDR
[Link]
ge-1/0/1.231
BDR
[Link]
ge-1/0/4.0
DRother [Link]
lo0.0
DR
[Link]

DR ID
[Link]
[Link]
[Link]
[Link]

BDR ID
[Link]
[Link]
[Link]
[Link]

Nbrs
1
1
0
0

N
LY

Question: Does the ge-1/0/4 interface appear as

an OSPF interface in the output of the command?

Step 2.3

SE

Answer: The interface should appear as an OSPF

interface.

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 remote
network as an OSPF route.

lab@mxB-1> show route remote-network/24

*[OSPF/10] [Link], metric 5

> to [Link] via ge-1/0/0.220
to [Link] via ge-1/0/1.221

[Link]/24

AL

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

TE
R

Question: Do you have the remote network in your

routing table?

IN

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.4
Enter into configuration mode and navigate to the [edit protocols mpls
label-switched-path localPE-to-remotePE-pod] hierarchy. Using the
install statement, add the remote network to your inet.3 routing table.
Commit your changes.
lab@mxB-1> configure
Entering configuration mode
Lab 68 Miscellaneous MPLS Features (Detailed)

[Link]

Junos MPLS and VPNs

[edit]
lab@mxB-1# edit protocols mpls label-switched-path localPE-to-remotePE-pod
[edit protocols mpls label-switched-path pe1-to-pe2-B]
lab@mxB-1# set install remote-network/24
[edit protocols mpls label-switched-path pe1-to-pe2-B]
lab@mxB-1# commit
commit complete

N
LY

[edit protocols mpls label-switched-path pe1-to-pe2-B]

lab@mxB-1#

Step 2.5

Verify that the route has been added to the inet.3 routing table and points to the
correct LSP.

[edit protocols mpls label-switched-path pe1-to-pe2-B]

lab@mxB-1# run show route table inet.3

pe1-to-pe2-B

pe1-to-pe2-B
[Link]/32

*[RSVP/7/1] [Link], metric 4

> to [Link] via ge-1/0/0.220, label-switched-path
*[RSVP/7/1] [Link], metric 4
> to [Link] via ge-1/0/0.220, label-switched-path

AL

[Link]/24

SE

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

+ = Active Route, - = Last Active, * = Both

TE
R

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.

IN

Step 2.6

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 BGP next hop and internal IPv4 traffic will only
use the next hop found in the inet.0 routing table.

[edit protocols mpls label-switched-path pe1-to-pe2-B]

lab@mxB-1# run show route remote-network/24
inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

[Link]

Miscellaneous MPLS Features (Detailed) Lab 69

Junos MPLS and VPNs

[Link]/24

*[OSPF/10] [Link], metric 5

> to [Link] via ge-1/0/0.220
to [Link] via ge-1/0/1.221

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

+ = Active Route, - = Last Active, * = Both
[Link]/24
pe1-to-pe2-B

*[RSVP/7/1] [Link], metric 4

> to [Link] via ge-1/0/0.220, label-switched-path

N
LY

Question: Is your internal traffic going to use the

OSPF route or the RSVP route?

SE

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

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 your configuration,

AL

[edit protocols mpls label-switched-path pe1-to-pe2-B]

lab@mxB-1# set install remote-network/24 active

TE
R

[edit protocols mpls label-switched-path pe1-to-pe2-B]

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

Step 2.8

Verify that you can now see the RSVP route in your inet.0 routing table.

IN

[edit protocols mpls label-switched-path pe1-to-pe2-B]

lab@mxB-1 run show route remote-network/24
inet.0: 37 destinations, 38 routes (37 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
[Link]/24
pe1-to-pe2-B

*[RSVP/7/1] [Link], metric 4

> to [Link] via ge-1/0/0.220, label-switched-path
[OSPF/10] [Link], metric 5
> to [Link] via ge-1/0/0.220
to [Link] via ge-1/0/1.221

Lab 610 Miscellaneous MPLS Features (Detailed)

[Link]

Junos MPLS and VPNs

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.

N
LY

Question: Which route will be used when resolving

internal traffic?

Answer: Internal traffic will use the RSVP route to

resolve next hops.

SE

Question: Which route will be used when resolving

external traffic (BGP) next hops?

AL

Answer: External traffic will use the RSVP route.

Part 3: Configuring MPLS Traffic Engineering to Install an inet.0 Route

TE
R

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.

Step 3.1

IN

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.

[edit protocols mpls label-switched-path pe1-to-pe2-B]

lab@mxB-1 show
to [Link];
install [Link]/24 active;
[edit protocols mpls label-switched-path pe1-to-pe2-B]
lab@mxB-1# delete install remote-network/24 active
[edit protocols mpls label-switched-path pe1-to-pe2-B]
lab@mxB-1# show
to [Link];
install [Link]/24;
[Link]

Miscellaneous MPLS Features (Detailed) Lab 611

Junos MPLS and VPNs

[edit protocols mpls label-switched-path pe1-to-pe2-B]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 3.2
Verify that you no longer have the RSVP route in your inet.0 routing table.

N
LY

lab@mxB-1> show route remote-network/24

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
*[OSPF/10] [Link], metric 5
> to [Link] via ge-1/0/0.220
to [Link] via ge-1/0/1.221

[Link]/24

[Link]/24

*[RSVP/7/1] [Link], metric 4

> to [Link] via ge-1/0/1.221, label-switched-path

pe1-to-pe2-B

SE

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

+ = Active Route, - = Last Active, * = Both

AL

Question: Which protocol is being used in the

inet.0 routing table?

IN

Step 3.3

TE
R

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.

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.

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit protocols mpls
[edit protocols mpls]
lab@mxB-1# set traffic-engineering ?
Possible completions:
Lab 612 Miscellaneous MPLS Features (Detailed)

[Link]

Junos MPLS and VPNs

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@mxB-1# set traffic-engineering bgp-igp

N
LY

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 3.4

lab@mxB-1> show route remote-network/24

Verify that your inet.0 route table contains the RSVP route to the remote network
specified to use the LSP.

Step 3.5

pe1-to-pe2-B

*[RSVP/7/1] [Link], metric 4

> to [Link] via ge-1/0/0.220, label-switched-path
[OSPF/10] [Link], metric 5
> to [Link] via ge-1/0/0.220
to [Link] via ge-1/0/1.221

AL

[Link]/24

SE

inet.0: 37 destinations, 39 routes (37 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

Using the traceroute utility verify that internal traffic will use the LSP when sending
traffic to the remote network (use the address on the remote PE routers ge-1/0/4
interface as a destination).

IN

TE
R

lab@mxB-1> traceroute remote-ge-1/0/4-address

traceroute to [Link] ([Link]), 30 hops max, 40
1 [Link] ([Link]) 2.693 ms 0.617 ms
MPLS Label=300928 CoS=0 TTL=1 S=1
2 [Link] ([Link]) 0.571 ms 0.595 ms
MPLS Label=300816 CoS=0 TTL=1 S=1
3 [Link] ([Link]) 0.605 ms 0.609 ms
MPLS Label=300848 CoS=0 TTL=1 S=1
4 [Link] ([Link]) 0.650 ms 0.568 ms 0.540

byte packets
0.547 ms
0.573 ms
0.579 ms
ms

Question: Does your traceroute complete?

Answer: Yes, your should see the traceroute

responses from all routers along the path.

[Link]

Miscellaneous MPLS Features (Detailed) Lab 613

Junos MPLS and VPNs

Question: Do you see MPLS label values associated

with the traceroute responses?

Part 4: Using Policy to Control LSP Selection

N
LY

Answer: Yes, you should see MPLS label values. If

you do not, please review your configuration and
request assistance from your instructor as needed.

In this lab part, you will use policy to control which LSP certain traffic traverses. You
will begin by disabling 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 routesreceived
from your neighbordown separate LSPs.

SE

Step 4.1

lab@mxB-1> configure
Entering configuration mode

Enter into configuration mode and begin by removing the ge-1/0/4 interface that we
added to OSPF area 0 in Part 2. You only need to remove this interface from your
OSPF configuration.

AL

[edit]
lab@mxB-1# delete protocols ospf area 0 interface ge-1/0/4

Step 4.2

Navigate to the [edit protocols mpls] hierarchy and delete the existing label
switched path and traffic engineering configuration.

TE
R

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

[edit protocols mpls]

lab@mxB-1# delete label-switched-path localPE-to-remotePE-pod

IN

[edit protocols mpls]

lab@mxB-1# delete traffic-engineering
[edit protocols mpls]
lab@mxB-1#

Step 4.3
Create two paths named one and two. Specify the different loose hops that each
LSP path should signal along. Path one should traverse the top of the network using
the P1, P2, and P3 routers. Path two should traverse the bottom using P4, P5, and
P6 routers.

Lab 614 Miscellaneous MPLS Features (Detailed)

[Link]

Junos MPLS and VPNs

[edit protocols mpls]

lab@mxB-1# set path one p-router-address loose
[edit protocols mpls]
lab@mxB-1# set path one p-router-address loose
[edit protocols mpls]
lab@mxB-1# set path one p-router-address loose

[edit protocols mpls]

lab@mxB-1# set path two p-router-address loose

SE
U

Step 4.4

AL

[edit protocols mpls]

lab@mxB-1# show
path one {
[Link] loose;
[Link] loose;
[Link] loose;
}
path two {
[Link] loose;
[Link] loose;
[Link] loose;
}
interface ge-1/0/0.220;
interface ge-1/0/1.221;
interface lo0.0;

[edit protocols mpls]

lab@mxB-1# set path two p-router-address loose

N
LY

[edit protocols mpls]

lab@mxB-1# set path two p-router-address loose

TE
R

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 routers loopback. Before committing your
configuration changes, review the changes. After you are satisfied with the changes
commit and exit to operational mode.

IN

[edit protocols mpls]

lab@mxB-1# set label-switched-path lsp-1 to remote-pe-loopback-address primary
one
[edit protocols mpls]
lab@mxB-1# set label-switched-path lsp-2 to remote-pe-loopback-address primary
two
[edit protocols mpls]
lab@mxB-1# show
label-switched-path lsp-1 {
to [Link];
primary one;
}
[Link]

Miscellaneous MPLS Features (Detailed) Lab 615

Junos MPLS and VPNs

N
LY

label-switched-path lsp-2 {
to [Link];
primary two;
}
path one {
[Link] loose;
[Link] loose;
[Link] loose;
}
path two {
[Link] loose;
[Link] loose;
[Link] loose;
}
interface ge-1/0/0.220;
interface ge-1/0/1.221;
interface lo0.0;

SE

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 4.5

AL

Using the show mpls lsp extensive ingress command, verify that your
LSPs are established and traversing the core network as expected based on your
explicit paths.
lab@mxB-1> show mpls lsp extensive ingress
Ingress LSP: 2 sessions

IN

TE
R

[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: lsp-1
ActivePath: one (primary)
LSPtype: Static Configured, Penultimate hop popping
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)
[Link] S [Link] S [Link] S [Link] S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt
20=Node-ID):
[Link] [Link] [Link] [Link]
5 May 20 [Link].179 Selected as active path
4 May 20 [Link].177 Record Route: [Link] [Link] [Link]
[Link]
3 May 20 [Link].177 Up
2 May 20 [Link].132 Originate Call
1 May 20 [Link].132 CSPF: computation result accepted [Link]
[Link] [Link] [Link]
Created: Mon May 20 [Link] 2013
Lab 616 Miscellaneous MPLS Features (Detailed)

[Link]

Junos MPLS and VPNs

SE

N
LY

[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: lsp-2
ActivePath: two (primary)
LSPtype: Static Configured, Penultimate hop popping
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)
[Link] S [Link] S [Link] S [Link] S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt
20=Node-ID):
[Link] [Link] [Link] [Link]
5 May 20 [Link].285 Selected as active path
4 May 20 [Link].284 Record Route: [Link] [Link] [Link]
[Link]
3 May 20 [Link].284 Up
2 May 20 [Link].134 Originate Call
1 May 20 [Link].134 CSPF: computation result accepted [Link]
[Link] [Link] [Link]
Created: Mon May 20 [Link] 2013
Total 2 displayed, Up 2, Down 0

AL

Question: Are your LSPs in an Up state?

IN

TE
R

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.6
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.
lab@mxB-1> configure
Entering configuration mode
[Link]

Miscellaneous MPLS Features (Detailed) Lab 617

Junos MPLS and VPNs

[edit]
lab@mxB-1# edit routing-options
[edit routing-options]
lab@mxB-1# set static route route/24 receive
[edit routing-options]
lab@mxB-1# set static route route/24 receive

N
LY

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

Step 4.7

Navigate to the [edit policy-options policy-statement

export-static] hierarchy. Create a policy named export-static that will
export these routes to your internal BGP (IBGP) peer.

[edit routing-options]
lab@mxB-1# top edit policy-options policy-statement export-static

SE

[edit policy-options policy-statement export-static]

lab@mxB-1# set from protocol static

[edit policy-options policy-statement export-static]

lab@mxB-1# set then accept

AL

[edit policy-options policy-statement export-static]

lab@mxB-1# show
from protocol static;
then accept;

[edit policy-options policy-statement export-static]

lab@mxB-1#

TE
R

Step 4.8

Apply the new policy as an export policy to your IBGP group. Commit your
configuration changes and exit to operational mode.

[edit policy-options policy-statement export-static]

lab@mxB-1# top edit protocols bgp group my-int-group

IN

[edit protocols bgp group my-int-group]

lab@mxB-1# set export export-static
[edit protocols bgp group my-int-group]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 4.9
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.
Lab 618 Miscellaneous MPLS Features (Detailed)

[Link]

Junos MPLS and VPNs

lab@mxB-1> show route advertising-protocol bgp remote-pe-loopback-address

inet.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden)
Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
Self
100
I
* [Link]/24
Self
100
I
lab@mxB-1> show route receive-protocol bgp remote-pe-loopback-address

N
LY

inet.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
[Link]
100
I
* [Link]/24
[Link]
100
I
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
mpls.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

lab@mxB-1> show route protocol bgp

AL

[Link]/24

*[BGP/170] [Link], localpref 100, from [Link]

AS path: I, validation-state: unverified
to [Link] via ge-1/0/0.220, label-switched-path
> to [Link] via ge-1/0/1.221, label-switched-path
*[BGP/170] [Link], localpref 100, from [Link]
AS path: I, validation-state: unverified
to [Link] via ge-1/0/0.220, label-switched-path
> to [Link] via ge-1/0/1.221, label-switched-path

[Link]/24

SE

inet.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

lsp-1
lsp-2

IN

TE
R

...

lsp-1
lsp-2

Question: To which LSPs do the routes you received

from your neighbor point 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.10

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.
lab@mxB-1> configure
Entering configuration mode
[Link]

Miscellaneous MPLS Features (Detailed) Lab 619

Junos MPLS and VPNs

[edit]
lab@mxB-1# edit policy-options policy-statement lsp-policy
[edit policy-options policy-statement lsp-policy]
lab@mxB-1# set term lsp-1 from protocol bgp
[edit policy-options policy-statement lsp-policy]
lab@mxB-1# set term lsp-1 from route-filter first-received-route/24 exact

[edit policy-options policy-statement lsp-policy]

lab@mxB-1# set term lsp-1 then accept

[edit policy-options policy-statement lsp-policy]

lab@mxB-1# set term lsp-2 from protocol bgp

N
LY

[edit policy-options policy-statement lsp-policy]

lab@mxB-1# set term lsp-1 then install-nexthop lsp lsp-1

[edit policy-options policy-statement lsp-policy]

lab@mxB-1# set term lsp-2 from route-filter second-received-route/24 exact

SE

[edit policy-options policy-statement lsp-policy]

lab@mxB-1# set term lsp-2 then install-nexthop lsp lsp-2

[edit policy-options policy-statement lsp-policy]

lab@mxB-1# set term lsp-2 then accept

IN

TE
R

AL

[edit policy-options policy-statement lsp-policy]

lab@mxB-1# show
term lsp-1 {
from {
protocol bgp;
route-filter [Link]/24 exact;
}
then {
install-nexthop lsp lsp-1;
accept;
}
}
term lsp-2 {
from {
protocol bgp;
route-filter [Link]/24 exact;
}
then {
install-nexthop lsp lsp-2;
accept;
}
}

Step 4.11
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.
Lab 620 Miscellaneous MPLS Features (Detailed)

[Link]

Junos MPLS and VPNs

[edit policy-options policy-statement lsp-policy]

lab@mxB-1# top edit routing-options
[edit routing-options]
lab@mxB-1# set forwarding-table export lsp-policy
[edit routing-options]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

N
LY

lab@mxB-1>

Step 4.12

Verify that the next hop for each of the remote BGP routes point to the correct LSP as
defined in your policy.

lab@mxB-1> show route protocol bgp

inet.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

[Link]/24

*[BGP/170] [Link], localpref 100, from [Link]

AS path: I, validation-state: unverified
to [Link] via ge-1/0/0.220, label-switched-path lsp-1
*[BGP/170] [Link], localpref 100, from [Link]
AS path: I, validation-state: unverified
to [Link] via ge-1/0/1.221, label-switched-path lsp-2

SE

[Link]/24

AL

...

IN

TE
R

Question: Do you see the correct LSP selected as

the next hop for each of your BGP routes?

STOP

[Link]

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.

Do not proceed until the remote team finishes Part 4.

Miscellaneous MPLS Features (Detailed) Lab 621

Junos MPLS and VPNs

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.

N
LY

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.

lab@mxB-1> configure
Entering configuration mode

[edit]
lab@mxB-1# delete policy-options policy-statement lsp-policy

SE

[edit]
lab@mxB-1# delete routing-options forwarding-table export

Step 5.2

AL

[edit]
lab@mxB-1

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

Use the show route protocol bgp command to review the current status of
your BGP routes received from your peer.

TE
R

[edit]
lab@mxB-1# run show route protocol bgp
inet.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

IN

[Link]/24

[Link]/24

...

*[BGP/170] [Link], localpref 100, from [Link]

AS path: I, validation-state: unverified
to [Link] via ge-1/0/0.220, label-switched-path
> to [Link] via ge-1/0/1.221, label-switched-path
*[BGP/170] [Link], localpref 100, from [Link]
AS path: I, validation-state: unverified
to [Link] via ge-1/0/0.220, label-switched-path
> to [Link] via ge-1/0/1.221, label-switched-path

Lab 622 Miscellaneous MPLS Features (Detailed)

lsp-1
lsp-2
lsp-1
lsp-2

[Link]

Junos MPLS and VPNs

Question: How many next hops are associated with

each of the BGP routes? Why?

Answer: Both BGP routes are associated with two

next hops. This usually means that there are two
equal cost paths to the advertised BGP next hop.

N
LY

Step 5.3
Review the RSVP routes in inet.3 to determine what metric is being calculated by 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

[edit]
lab@mxB-1# run show route table inet.3

[Link]/32

SE

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

+ = Active Route, - = Last Active, * = Both
*[RSVP/7/1] [Link], metric 4
to [Link] via ge-1/0/0.220, label-switched-path lsp-1
> to [Link] via ge-1/0/1.221, label-switched-path lsp-2

AL

Question: Why do you see both LSPs as available

next hops?

IN

TE
R

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

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.
[edit]
lab@mxB-1# edit protocols mpls

[Link]

Miscellaneous MPLS Features (Detailed) Lab 623

Junos MPLS and VPNs

[edit protocols mpls]

lab@mxB-1# set label-switched-path lsp-2 metric 8
[edit protocols mpls]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 5.5

N
LY

Use the show route protocol bgp command to review the BGP routes for
changes.
lab@mxB-1> show route protocol bgp

[Link]/24

...

*[BGP/170] [Link], localpref 100, from [Link]

AS path: I, validation-state: unverified
> to [Link] via ge-1/0/0.220, label-switched-path lsp-1
*[BGP/170] [Link], localpref 100, from [Link]
AS path: I, validation-state: unverified
> to [Link] via ge-1/0/0.220, label-switched-path lsp-1

SE

[Link]/24

inet.0: 40 destinations, 40 routes (40 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

AL

Question: What changes do you see in the routing

table?

Step 5.6

TE
R

Answer: The two next hops for the BGP routes are
no longer available because they are no longer
equal cost paths.

View the inet.3 table to verify the metric change is reflected by the RSVP routes.

IN

lab@mxB-1> show route table inet.3

[Link]/32

*[RSVP/7/1] [Link], metric 4

> to [Link] via ge-1/0/0.230, label-switched-path lsp-1
[RSVP/7/1] [Link], metric 8
> to [Link] via ge-1/0/1.231, label-switched-path lsp-2

Lab 624 Miscellaneous MPLS Features (Detailed)

[Link]

Junos MPLS and VPNs

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.

N
LY

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

lab@mxB-1> configure
Entering configuration mode

SE

Enter into configuration mode and navigate to the [edit protocols mpls]
hierarchy. Enable traffic-engineering bgp-igp. This will allow you to
traceroute over the MPLS LSPs 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 teams loopback
address.

AL

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

[edit protocols mpls]

lab@mxB-1# set traffic-engineering bgp-igp

TE
R

[edit protocols mpls]

lab@mxB-1# commit and quit
commit complete
Exiting configuration mode
lab@mxB-1>

IN

Step 6.2

Verify the default behavior by using the traceroute utility. You can now traceroute to
the remote teams loopback address.

lab@mxB-1> traceroute remote-pe-loopback-address

traceroute to [Link] ([Link]), 30 hops max, 40 byte packets
1 [Link] ([Link]) 0.766 ms 0.624 ms 0.541 ms
MPLS Label=299904 CoS=0 TTL=1 S=1
2 [Link] ([Link]) 0.574 ms 0.569 ms 0.558 ms
MPLS Label=299904 CoS=0 TTL=1 S=1
3 [Link] ([Link]) 0.598 ms 0.642 ms 0.583 ms
MPLS Label=299904 CoS=0 TTL=1 S=1
4 [Link] ([Link]) 0.680 ms 0.540 ms 0.545 ms
[Link]

Miscellaneous MPLS Features (Detailed) Lab 625

Junos MPLS and VPNs

Question: How many devices respond to the

traceroute request?

Answer: You should see four responses. One for

each device, including the destination PE device.
Step 6.3

N
LY

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.

lab@mxB-1> configure
Entering configuration mode

SE

[edit]
lab@mxB-1# edit protocols mpls
[edit protocols mpls]
lab@mxB-1# set no-decrement-ttl

Step 6.4

AL

lab@mxB-1>

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

Use the traceroute utility again to view the change in behavior.

TE
R

lab@mxB-1> traceroute remote-pe-loopback-address

traceroute to [Link] ([Link]), 30 hops max, 40 byte packets
1 [Link] ([Link]) 0.866 ms 0.573 ms 0.542 ms

IN

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.

Lab 626 Miscellaneous MPLS Features (Detailed)

[Link]

Junos MPLS and VPNs

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

Rt Style Labelin Labelout LSPname

0 1 FF
3
- lsp-1
0 1 FF
3
- lsp-2

lab@mxB-1> show mpls lsp egress

Egress LSP: 2 sessions
To
From
State
[Link]
[Link]
Up
[Link]
[Link]
Up
Total 2 displayed, Up 2, Down 0

N
LY

Use the show mpls lsp egress command to 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.

Step 7.2

SE

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

AL

lab@mxB-1> configure
Entering configuration mode

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

TE
R

[edit protocols mpls]

lab@mxB-1# set explicit-null

IN

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 7.3

Use the show mpls lsp egress command to 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@mxB-1> show mpls lsp egress
Egress LSP: 2 sessions
To
From
State
[Link]
[Link]
Up
[Link]
[Link]
Up
[Link]

Rt Style Labelin Labelout LSPname

0 1 FF
0
- lsp-1
0 1 FF
0
- lsp-2
Miscellaneous MPLS Features (Detailed) Lab 627

Junos MPLS and VPNs

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.

N
LY

Part 8: Configuring Your Router to Automatically Adjust the RSVP Reservation Based on
Observed Bandwidth

SE

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

AL

lab@mxB-1> configure
Entering configuration mode

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@mxB-1# edit protocols mpls statistics

TE
R

[edit protocols mpls statistics]

lab@mxB-1# set file auto-stats
[edit protocols mpls statistics]
lab@mxB-1# set auto-bandwidth
[edit protocols mpls statistics]
lab@mxB-1#

IN

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@mxB-1# up
[edit protocols mpls]
lab@mxB-1# set label-switched-path lsp-1 auto-bandwidth

Lab 628 Miscellaneous MPLS Features (Detailed)

[Link]

Junos MPLS and VPNs

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-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.

N
LY

lab@mxB-1> show mpls lsp ingress name lsp-1 extensive

Ingress LSP: 2 sessions

IN

TE
R

AL

SE

[Link]
From: [Link], State: Up, ActiveRoute: 0, LSPname: lsp-1
ActivePath: one (primary)
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
Autobandwidth
AdjustTimer: 86400 secs
Max AvgBW util: 0bps, Bandwidth Adjustment in 86382 second(s).
Overflow limit: 0, Overflow sample count: 0
Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: 0bps
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)
[Link] S [Link] S [Link] S [Link] S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt
20=Node-ID):
[Link] [Link] [Link] [Link]
5 May 20 [Link].200 Selected as active path
4 May 20 [Link].199 Record Route: [Link] [Link] [Link]
[Link]
3 May 20 [Link].198 Up
2 May 20 [Link].155 Originate Call
1 May 20 [Link].155 CSPF: computation result accepted [Link]
[Link] [Link] [Link]
Created: Mon May 20 [Link] 2013
Total 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
86382 seconds.
[Link]

Miscellaneous MPLS Features (Detailed) Lab 629

Junos MPLS and VPNs

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.

Question: Do the pings complete?

N
LY

lab@mxB-1> ping mpls rsvp lsp-1

!!!!!
--- lsping statistics --5 packets transmitted, 5 packets received, 0% packet loss

SE

Answer: Yes, your pings should complete at this

point. If they do not check with the remote team and
ensure they have the [Link]/32 address
assigned to their loopback. If you need assistance,
consult with your instructor.
Step 9.2

login:

Tell your instructor that you have completed this lab.

IN

STOP

TE
R

mxB-1 (ttyu0)

lab@mxB-1> exit

AL

Log out of your assigned device using the exit command.

Lab 630 Miscellaneous MPLS Features (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

Miscellaneous MPLS Features (Detailed) Lab 631

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 632 Miscellaneous MPLS Features (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

Miscellaneous MPLS Features (Detailed) Lab 633

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 634 Miscellaneous MPLS Features (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

Miscellaneous MPLS Features (Detailed) Lab 635

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 636 Miscellaneous MPLS Features (Detailed)

[Link]

Lab

N
LY

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

SE

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.
By completing this lab, you will perform the following tasks:
Load the a baseline configuration for your router. This configuration includes
your baseline core configuration including OSPF and BGP. The baseline also
contains a logical 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.

AL

Configure static routing between your PE and CE router and share your static
PE routes through the Layer 3 VPN using MP-BGP.

IN

TE
R

[Link]

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.

L3VPN Static and BGP Routing (Detailed) Lab 71

Junos MPLS and VPNs

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 a
baseline configuration 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.
Note

N
LY

The instructor will tell you the nature of your

access and will provide you with the
necessary details to access your assigned
device.
Step 1.1

Ensure that you know to which device you are assigned. Check with your instructor if
necessary.
Step 1.2

SE

Consult the management network diagram, provided by your instructor, to determine

your devices management address.

Question: What is the management address

assigned to your station?

IN

TE
R

AL

Answer: The answer varies. The sample hostname

and IP address used in the output examples in this
lab are for mxB-1, which uses [Link] as its
management IP address. The actual management
subnet varies between delivery environments.

Lab 72 L3VPN Static and BGP Routing (Detailed)

[Link]

Junos MPLS and VPNs

Step 1.3

N
LY

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
mxB-1 using the Secure CRT program.

SE

Step 1.4

Log in as user lab with the password supplied by your instructor. Enter
configuration mode and load the reset configuration file
jmv/[Link] and commit.
mxB-1 (ttyp0)

AL

login: lab
Password:

TE
R

--- JUNOS 12.3R2.5 built 2013-03-22 [Link] UTC

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# load override jmv/[Link]
load complete

IN

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

Step 1.5
Navigate to the [edit protocols] hierarchy. Issue the show command and
analyze the protocols that have been preconfigured for you.
[edit]
lab@mxB-1# edit protocols

[Link]

L3VPN Static and BGP Routing (Detailed) Lab 73

Junos MPLS and VPNs

N
LY

[edit protocols]
lab@mxB-1# show
bgp {
group my-int-group {
type internal;
local-address [Link];
neighbor [Link];
}
}
ospf {
area [Link] {
interface ge-1/0/0.220;
interface ge-1/0/1.221;
interface lo0.0;
}
}

[edit protocols]
lab@mxB-1#

SE

Question: Which protocols have been preconfigured

for you?

Answer: OSPF and BGP have been preconfigured.

AL

Question: In its current state, will your router be

able to build a traffic engineering database (TED)?

IN

TE
R

Answer: Your router will not be able to build a TED

because traffic-engineering has not been
enabled for OSPF.
Question: What is the name of the preconfigured
BGP peer group? Which router in the network is
configured as a member of the group?

Answer: The configured peer group is called

my-int-group. The group is configured to
establish an IBGP session with the remote PE.
Step 1.6
Exit to operational mode and verify your Open Shortest Path First (OSPF) neighbor
relationships are up and operational.
Lab 74 L3VPN Static and BGP Routing (Detailed)

[Link]

Junos MPLS and VPNs

[edit protocols]
lab@mxB-1# exit configuration-mode
Exiting configuration mode
lab@mxB-1> show ospf neighbor
Address
Interface
[Link]
ge-1/0/0.220
[Link]
ge-1/0/1.221

State
Full
Full

ID
[Link]
[Link]

Pri
128
128

Dead
34
39

N
LY

Question: What is the state of your PE routers OSPF

neighbors?

Answer: After a short time, the OSPF neighbors

should attain the Full state.
Step 1.7

SE

Verify that your PE router has established an IBGP neighbor relationship with the
remote PE router.

IN

TE
R

AL

lab@mxB-1> show bgp neighbor

Peer: [Link]+179 AS 65512 Local: [Link]+58282 AS 65512
Type: Internal
State: Established
Flags: <Sync>
Last State: OpenConfirm
Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress Refresh>
Local Address: [Link] Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: [Link]
Local ID: [Link]
Active Holdtime: 90
Keepalive Interval: 30
Group index: 0
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)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
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 19
Sent 8
Checked 31
Input messages: Total 9219
Updates 4
Refreshes 0
Octets 175246
[Link]

L3VPN Static and BGP Routing (Detailed) Lab 75

Junos MPLS and VPNs

Output messages: Total 9218

Output Queue[0]: 0

Updates 2

Refreshes 0

Octets 175250

Question: Is the neighbor relationship in the

established state with the remote PE router?

N
LY

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.

SE

Question: What address family has been negotiated

for the BGP session? What type of routes can be
advertised between the two PE routers?

AL

Answer: The PE routers have negotiated the

advertisement of inet-unicast routes. That
means that only IPv4 unicast routes can be
advertised between the two neighbors.
Step 1.8

TE
R

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 and enable family mpls on both of the
core-facing interfaces.
lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit interfaces

IN

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

Step 1.9
Navigate to the [edit protocols] hierarchy and configure the MPLS protocol
on the core-facing interfaces.
Lab 76 L3VPN Static and BGP Routing (Detailed)

[Link]

Junos MPLS and VPNs

[edit interfaces]
lab@mxB-1# top edit protocols
[edit protocols]
lab@mxB-1# set mpls interface ge-1/0/[Link]
[edit protocols]
lab@mxB-1# set mpls interface ge-1/0/[Link]

Step 1.10

N
LY

[edit protocols]
lab@mxB-1#

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

Step 1.11

Configure the RSVP protocol on the core-facing interfaces.

SE

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.

Step 1.12

AL

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

To allow the exchange of Layer 3 VPN routes, enable the inet-vpn unicast network
layer reachability information (NLRI) for your PE routers BGP session with the
remote PE router. Make sure to also enable the exchange of standard unicast IP
version 4 (IPv4) routes as well.

TE
R

[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

IN

Step 1.13

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 routers 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 local-pe-loopback-address

[Link]

L3VPN Static and BGP Routing (Detailed) Lab 77

Junos MPLS and VPNs

[edit routing-options]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

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

Available
BW
1000Mbps
1000Mbps

Reserved
BW
0bps
0bps

Static
BW
1000Mbps
1000Mbps

SE

lab@mxB-1> show rsvp interface

RSVP interface: 2 active
Active SubscrInterface
State resv
iption
ge-1/0/0.220Up
0
100%
ge-1/0/1.221Up
0
100%

N
LY

lab@mxB-1> show mpls interface

Interface
State
Administrative groups (x: extended)
ge-1/0/0.220
Up
<none>
ge-1/0/1.221
Up
<none>

Highwater
mark
0bps
0bps

Question: Can your core-facing interfaces now

support the transmission of MPLS packets?

Step 1.15

AL

Answer: The outputs of the two commands show

that the two interfaces can now support the
forwarding of MPLS packets.

TE
R

Verify the state of your PE routers BGP neighbor relationship with the remote PE
router.

IN

lab@mxB-1> show bgp neighbor remote-pe-loopback-address

Peer: [Link]+52281 AS 65512 Local: [Link]+179 AS 65512
Type: Internal
State: Established
Flags: <Sync>
Last State: OpenConfirm
Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress AddressFamily Rib-group Refresh>
Address families configured: inet-unicast inet-vpn-unicast
Local Address: [Link] Holdtime: 90 Preference: 170
Number of flaps: 1
Last flap event: RecvNotify
Error: 'Cease' Sent: 0 Recv: 1
Peer ID: [Link]
Local ID: [Link]
Active Holdtime: 90
Keepalive Interval: 30
Group index: 0
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
Lab 78 L3VPN Static and BGP Routing (Detailed)

[Link]

Junos MPLS and VPNs

AL

SE

N
LY

Peer supports Refresh capability (2)

Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
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 inet-vpn-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
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 15
Sent 15
Checked 15
Input messages: Total 4
Updates 2
Refreshes 0
Octets 139
Output messages: Total 3
Updates 0
Refreshes 0
Octets 158
Output Queue[0]: 0
Output Queue[1]: 0

IN

TE
R

Question: Is the neighbor relationship in the

established state with the remote PE?

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

L3VPN Static and BGP Routing (Detailed) Lab 79

Junos MPLS and VPNs

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

N
LY

Enter configuration mode and navigate to the [edit protocols mpls]

hierarchy and configure a label-switched-path called
localPE-to-remotePE-pod. For example, if you are assigned router mxB-1,
your peer router is mxB-2 and your pod is B. The LSP for mxB-1 should be named
pe1-to-pe2-B. 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.
lab@mxB-1> configure
Entering configuration mode

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

AL

[edit protocols mpls]

lab@mxB-1# show
label-switched-path pe1-to-pe2-B {
to [Link];
}
interface ge-1/0/0.220;
interface ge-1/0/1.221;

SE

[edit protocols mpls]

lab@mxB-1# set label-switched-path localPE-to-remotePE-pod to
remote-pe-loopback-address

TE
R

[edit protocols mpls]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

IN

Step 2.2

Use the show mpls lsp command to verify that the RSVP LSP you just configured
is up and functional. Ensure that you have bidirectional LSPs before proceeding.

lab@mxB-1> show mpls lsp

Ingress LSP: 1 sessions
To
From
State Rt P
[Link]
[Link]
Up
0 *
Total 1 displayed, Up 1, Down 0
Egress LSP: 1 sessions
To
From
State
[Link]
[Link]
Up
Total 1 displayed, Up 1, Down 0
Lab 710 L3VPN Static and BGP Routing (Detailed)

ActivePath

LSPname
pe1-to-pe2-B

Rt Style Labelin Labelout LSPname

0 1 FF
3
- pe2-to-pe1-B

[Link]

Junos MPLS and VPNs

Transit LSP: 0 sessions

Total 0 displayed, Up 0, Down 0

Question: Are bidirectional LSPs established

between your PE router and the remote PE router?

N
LY

Answer: Your PE router should now be the ingress

and egress LSR for LSPs established with the
remote PE. You may need to wait some time before
the remote team has configured it LSP.
Step 2.3

Use the show route table inet.3 command to review the inet.3 routing table
and verify that the RSVP route is present and ready to use.
lab@mxB-1> show route table inet.3

pe1-to-pe2-B

*[RSVP/7/1] [Link], metric 4

> to [Link] via ge-1/0/1.221, label-switched-path

[Link]/32

SE

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

+ = Active Route, - = Last Active, * = Both

TE
R

AL

Question: Is the appropriate RSVP route to the

remote PE router 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 teams PE router.

Step 2.4

Verify MPLS connectivity using the MPLS ping utility.

IN

lab@mxB-1> ping mpls rsvp localPE-to-remotePE-pod

!!!!!
--- 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.
[Link]

L3VPN Static and BGP Routing (Detailed) Lab 711

Junos MPLS and VPNs

Part 3: Verify CE Router Configuration

In this lab part you will view the configuration for CE router (logical system) that was
preconfigured as part of the loaded starting configuration in Part 1 of this lab.
Step 3.1
Use the set cli logical-system command to place the CLI in the context of
the CE router logical system.

lab@mxB-1:ceB-1>

Step 3.2

N
LY

lab@mxB-1> set cli logical-system local-ce-hostname

Logical system: ceB-1

IN

TE
R

AL

SE

lab@mxB-1:ceB-1> show configuration

interfaces {
ge-1/1/4 {
unit 620 {
vlan-id 620;
family inet {
address [Link]/24;
}
}
}
lo0 {
unit 1 {
family inet {
address [Link]/32;
}
}
}
}
policy-options {
policy-statement exp-policy {
term 10 {
from protocol static;
then accept;
}
term 20 {
from protocol direct;
then accept;
}
}
}

Issue the show configuration command to view the configuration of the CE

router.

Lab 712 L3VPN Static and BGP Routing (Detailed)

[Link]

Junos MPLS and VPNs

routing-options {
static {
route [Link]/24 reject;
route [Link]/24 reject;
route [Link]/24 reject;
route [Link]/24 reject;
}
autonomous-system 65201;
}

N
LY

Question: What interfaces have been configured on

the CE router? According to the lab diagram, do they
have the appropriate IP addressing?

SE

Answer: The CE router should have both the

loopback and ge-1/1/4 interface configured with
the appropriate addressing according to the lab
diagram.

AL

Question: What is configured under the

routing-options hierarchy? According to the
lab diagram, are these setting appropriate?

IN

TE
R

Answer: Four static routes (next hop of reject) and

the CE routers autonomous system should be
configured under routing-options hierarchy.
These settings are appropriate.
Question: What is configured under the
policy-options hierarchy? What does this
policy do?

Answer: A policy called exp-policy is configured

under policy-options hierarchy. If applied as
an export policy, this policy will redistribute active
direct and static routes into the protocol to which it
is applied. It is currently not applied to any protocol
in the configuration.

Step 3.3
Use the ping utility to attempt to ping the local PE routers ge-1/0/4 interface.

[Link]

L3VPN Static and BGP Routing (Detailed) Lab 713

Junos MPLS and VPNs

lab@mxB-1:ceB-1> ping local-pe-address count 1

PING [Link] ([Link]): 56 data bytes
--- [Link] ping statistics --1 packets transmitted, 0 packets received, 100% packet loss

Question: Does your ping succeed? Why?

N
LY

Answer: The pings do not succeed because the PE

routers ge-1/0/4 interface has not been
configured at this point in the lab.

Part 4: Configuring the PE to CE Interface

SE

Do not proceed until the remote team finishes Part 3.

STOP

In this lab part, you will configure the PE to CE interface. You will verify reachability
using the ping utility.
Step 4.1

AL

Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).

Step 4.2

TE
R

lab@mxB-1>

lab@mxB-1:ceB-1> clear cli logical-system

Cleared default logical system

Enter configuration mode and navigate to the [edit interfaces] hierarchy.

Configure the appropriate ge-1/0/4 interface properties found on the network
diagram. Commit your changes and exit to operational mode to verify reachability to
the CE interface.

IN

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit interfaces

[edit interfaces]
lab@mxB-1# set ge-1/0/4 vlan-tagging unit unit vlan-id vlan-id family inet
address address/24

Lab 714 L3VPN Static and BGP Routing (Detailed)

[Link]

Junos MPLS and VPNs

[edit interfaces]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 4.3
Verify connectivity to the CE device using the ping utility with a count value of 3.

N
LY

lab@mxB-1> ping local-ce-address count 3

PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=64 time=2.048 ms
64 bytes from [Link]: icmp_seq=1 ttl=64 time=0.595 ms
64 bytes from [Link]: icmp_seq=2 ttl=64 time=0.609 ms

--- [Link] ping statistics --3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.595/1.084/2.048/0.682 ms

SE

Question: Does your ping complete?

AL

Answer: Yes, your ping should complete. If it does

not, please review your configuration and ask your
instructor for assistance, if needed.

Part 5: Configuring a Layer 3 VPN Instance

TE
R

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.

IN

Step 5.1

Enter into configuration mode and navigate to the

[edit routing-instances] hierarchy. Create a new VPN routing and
forwarding (VRF) instance named vpn-pod.. For example, if you are assigned router
mxB-1, your pod is B. The routing instance for mxB-1 should be named vpn-B.

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit routing-instances

[edit routing-instances]
lab@mxB-1# set vpn-pod instance-type vrf

[Link]

L3VPN Static and BGP Routing (Detailed) Lab 715

Junos MPLS and VPNs

[edit routing-instances]
lab@mxB-1#

Step 5.2
Navigate to the [edit routing-instances vpn-pod] hierarchy. Create a
route distinguisher using your local loopback address to uniquely identify routes
advertised from this router. The format should look like this:
loopback-address:1.

[edit routing-instances vpn-B]

lab@mxB-1# set route-distinguisher loopback-address:1
[edit routing-instances vpn-B]
lab@mxB-1#

Step 5.3

N
LY

[edit routing-instances]
lab@mxB-1# edit vpn-pod

Target Community

Pod

SE

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. Use the following
table to determine the format of your vrf-target.

AL

target:65512:1

target:65512:2

target:65512:3

target:65512:4

Step 5.4

TE
R

[edit routing-instances vpn-B]

lab@mxB-1# set vrf-target target-community

Include the CE facing interface in your VRF instance.

IN

[edit routing-instances vpn-B]

lab@mxB-1# set interface ge-1/0/[Link]

Step 5.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-B]

lab@mxB-1# show
instance-type vrf;
interface ge-1/0/4.620;
route-distinguisher [Link]:1;
vrf-target target:65512:2;
Lab 716 L3VPN Static and BGP Routing (Detailed)

[Link]

Junos MPLS and VPNs

[edit routing-instances vpn-B]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 5.6

lab@mxB-1> show route table [Link].0

N
LY

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
show route table [Link].0 command.

[Link]/24
[Link]/32

*[Direct/0] [Link]
> via ge-1/0/4.620
*[Local/0] [Link]
Local via ge-1/0/4.620

[Link].0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

SE

Question: Do you see your local and direct routes?

AL

Answer: You should see a /32 local route for the

ge-1/0/4 interface and a /24 direct route for the
network attached to that interface. If you do not see
these routes, please review your configuration and
ask your instructor for assistance, if needed.

Do not proceed until the remote team finishes Part 5.

TE
R

STOP

IN

Part 6: 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 6.1
Use the set cli logical-system command to place the CLI in the context of
the CE router logical system.
[Link]

L3VPN Static and BGP Routing (Detailed) Lab 717

Junos MPLS and VPNs

lab@mxB-1> set cli logical-system local-ce-hostname

Logical system: ceB-1
lab@mxB-1:ceB-1>

Step 6.2
Enter configuration mode and navigate to the [edit routing-options]
hierarchy. Configure a static default route that points to the PE interface address as
the next hop.

N
LY

lab@mxB-1:ceB-1> configure
Entering configuration mode
[edit]
lab@mxB-1:ceB-1# edit routing-options

[edit routing-options]
lab@mxB-1:ceB-1# set static route 0/0 next-hop local-pe-address

SE

[edit routing-options]
lab@mxB-1:ceB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1:ceB-1>

Step 6.3

AL

Issue the show route command that the default route now exists in the CE
routers routing table.
lab@mxB-1:ceB-1> show route

*[Static/5] [Link]
> to [Link] via ge-1/1/4.620
*[Direct/0] [Link]
> via ge-1/1/4.620
*[Local/0] [Link]
Local via ge-1/1/4.620
*[Static/5] [Link]
Reject
*[Static/5] [Link]
Reject
*[Static/5] [Link]
Reject
*[Static/5] [Link]
Reject
*[Direct/0] [Link]
> via lo0.1

TE
R

[Link]/0

inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

[Link]/24
[Link]/32

IN

[Link]/24
[Link]/24
[Link]/24
[Link]/24

[Link]/32

Lab 718 L3VPN Static and BGP Routing (Detailed)

[Link]

Junos MPLS and VPNs

Question: Is the default route active in the CE

routers routing table?

Answer: The default route should be active in the

routing table. If you do not see the route, please
review your configuration ensuring that you chose
the correct next hop address value. Ask your
instructor for assistance, if needed.

N
LY

Step 6.4

Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).
lab@mxB-1:ceB-1> clear cli logical-system
Cleared default logical system

lab@mxB-1>

Step 6.5

AL

lab@mxB-1> configure
Entering configuration mode

SE

Enter configuration mode and navigate to the [edit routing-instances

vpn-pod 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 routers ge-1/1/4 interface address.

[edit]
lab@mxB-1# edit routing-instances vpn-pod routing-options

TE
R

[edit routing-instances vpn-B routing-options]

lab@mxB-1# set static route network/24 next-hop ce-address
[edit routing-instances vpn-B routing-options]
lab@mxB-1# set static route network/24 next-hop ce-address

IN

[edit routing-instances vpn-B routing-options]

lab@mxB-1# set static route network/24 next-hop ce-address
[edit routing-instances vpn-B routing-options]
lab@mxB-1# set static route network/24 next-hop ce-address
[edit routing-instances vpn-B routing-options]
lab@mxB-1# set static route ce-loopback-address next-hop ce-address
[edit routing-instances vpn-B routing-options]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>
[Link]

L3VPN Static and BGP Routing (Detailed) Lab 719

Junos MPLS and VPNs

Step 6.6
Verify that you are advertising your routes to the remote PE router.
lab@mxB-1> show route advertising-protocol bgp remote-pe-loopback-address

N
LY

[Link].0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
Self
100
I
* [Link]/24
Self
100
I
* [Link]/24
Self
100
I
* [Link]/24
Self
100
I
* [Link]/24
Self
100
I
* [Link]/32
Self
100
I

Question: What routes are being advertised to the

remote PE router?

SE

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.

AL

Step 6.7

Verify that you are receiving routes from the remote PE router.
lab@mxB-1> show route receive-protocol bgp remote-pe-address

inet.0: 33 destinations, 33 routes (33 active, 0 holddown, 0 hidden)

TE
R

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

IN

[Link].0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
[Link]
100
I
* [Link]/24
[Link]
100
I
* [Link]/24
[Link]
100
I
* [Link]/24
[Link]
100
I
* [Link]/24
[Link]
100
I
* [Link]/32
[Link]
100
I
mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
Prefix
Nexthop
MED
Lclpref
AS path
[Link]:1:[Link]/24
*
[Link]
100
I
[Link]:1:[Link]/24
*
[Link]
100
I
Lab 720 L3VPN Static and BGP Routing (Detailed)

[Link]

Junos MPLS and VPNs

*
*
*
*

[Link]:1:[Link]/24
[Link]
[Link]:1:[Link]/24
[Link]
[Link]:1:[Link]/24
[Link]
[Link]:1:[Link]/32
[Link]

100

100

100

100

N
LY

Question: What routes are you receiving from the

remote PE router?

SE

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 the lab
up to this point. Please request assistance from
your instructor, if needed.

Step 6.8

Review the routes that are installed in your VRF table.

AL

lab@mxB-1> show route table [Link].0

[Link].0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

TE
R

[Link]/32

*[Direct/0] [Link]
> via ge-1/0/4.620
*[Local/0] [Link]
Local via ge-1/0/4.620
*[BGP/170] [Link], localpref 100, from [Link]
AS path: I, validation-state: unverified
> to [Link] via ge-1/0/1.221, label-switched-path

[Link]/24

[Link]/24

IN

pe1-to-pe2-B
[Link]/24
pe1-to-pe2-B
[Link]/24
pe1-to-pe2-B
[Link]/24
pe1-to-pe2-B

[Link]

*[BGP/170] [Link], localpref 100, from [Link]

AS path: I, validation-state: unverified
> to [Link] via ge-1/0/1.221, label-switched-path
*[BGP/170] [Link], localpref 100, from [Link]
AS path: I, validation-state: unverified
> to [Link] via ge-1/0/1.221, label-switched-path
*[BGP/170] [Link], localpref 100, from [Link]
AS path: I, validation-state: unverified
> to [Link] via ge-1/0/1.221, label-switched-path

L3VPN Static and BGP Routing (Detailed) Lab 721

Junos MPLS and VPNs

[Link]/24

*[BGP/170] [Link], localpref 100, from [Link]

AS path: I, validation-state: unverified
> to [Link] via ge-1/0/1.221, label-switched-path

pe1-to-pe2-B
[Link]/24

*[Static/5] [Link]
> to [Link] via ge-1/0/4.620
*[Static/5] [Link]
> to [Link] via ge-1/0/4.620
*[Static/5] [Link]
> to [Link] via ge-1/0/4.620
*[Static/5] [Link]
> to [Link] via ge-1/0/4.620
*[Static/5] [Link]
> to [Link] via ge-1/0/4.620
*[BGP/170] [Link], localpref 100, from [Link]
AS path: I, validation-state: unverified
> to [Link] via ge-1/0/1.221, label-switched-path

[Link]/24
[Link]/24
[Link]/24

N
LY

[Link]/32
[Link]/32

pe1-to-pe2-B

SE

Question: Do you see all the remote PE routes?

Answer: Yes, you should see all the remote

PE routes.
Step 6.9

AL

Use the set cli logical-system command to place the CLI in the context of
the CE router logical system.

TE
R

lab@mxB-1:ceB-1>

lab@mxB-1> set cli logical-system local-ce-hostname

Logical system: ceB-1

IN

Step 6.10

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 CEs loopback address. You will send five packets for this
test. This can be accomplished using the following command: ping
remote-ce-loopback source local-ce-loopback count 5

lab@mxB-1:ceB-1> ping remote-ce-loopback source local-ce-loopback count 5

PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=59 time=6.485 ms
64 bytes from [Link]: icmp_seq=1 ttl=59 time=0.800 ms
64 bytes from [Link]: icmp_seq=2 ttl=59 time=0.834 ms
64 bytes from [Link]: icmp_seq=3 ttl=59 time=0.782 ms
64 bytes from [Link]: icmp_seq=4 ttl=59 time=0.786 ms
--- [Link] ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.782/1.937/6.485/2.274 ms
Lab 722 L3VPN Static and BGP Routing (Detailed)

[Link]

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.

N
LY

Do not proceed until the remote team finishes Part 6.

STOP

Part 7: Configuring BGP Routing Between the PE and CE Routers

SE

In this lab part, you will configure BGP routing to pass routes from your CE 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 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.

Note

Step 7.1

AL

Prior to starting this part of the lab, your CLI

should be set in the context of the CE
logical system.

TE
R

Enter into configuration mode and navigate to the [edit protocols bgp]
hierarchy. Create an external group called my-ext-group and specify the local
PEs ge-1/0/4 interfaces as the neighbor address. You must also define your
peer-as (AS 65512). Apply the policy exp-policy that you analyzed earlier in
the lab as an export policy to your EBGP group. Review your BGP configuration
before proceeding.

IN

lab@mxB-1:ceB-1> configure
Entering configuration mode
[edit]
lab@mxB-1:ceB-1# edit protocols bgp

[edit protocols bgp]

lab@mxB-1:ceB-1# set group my-ext-group type external
[edit protocols bgp]
lab@mxB-1:ceB-1# set group my-ext-group neighbor local-pe-address
[edit protocols bgp]
lab@mxB-1:ceB-1# set group my-ext-group peer-as 65512
[Link]

L3VPN Static and BGP Routing (Detailed) Lab 723

Junos MPLS and VPNs

[edit protocols bgp]

lab@mxB-1:ceB-1# set group my-ext-group export exp-policy

N
LY

[edit protocols bgp]

lab@mxB-1:ceB-1# show
group my-ext-group {
type external;
export exp-policy;
peer-as 65512;
neighbor [Link];
}
[edit protocols bgp]

Step 7.2

SE

[edit protocols bgp]

lab@mxB-1:ceB-1# top edit routing-options

Navigate to the [edit routing-options] hierarchy. Remove the static default

route that you created earlier. Commit and exit to operational mode before
proceeding.

lab@mxB-1:ceB-1>

Step 7.3

AL

[edit routing-options]
lab@mxB-1:ceB-1# commit and-quit
commit complete
Exiting configuration mode

[edit routing-options]
lab@mxB-1:ceB-1# delete static route 0/0

TE
R

Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).

lab@mxB-1:ceB-1> clear cli logical-system

Cleared default logical system
lab@mxB-1>

IN

Step 7.4

Enter into configuration mode and navigate to the [edit routing-instances

vpn-pod routing-options] hierarchy. Delete all static routes that have been
applied to the VRF instance.

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit routing-instances vpn-pod routing-options
[edit routing-instances vpn-B routing-options]
lab@mxB-1# delete static
Lab 724 L3VPN Static and BGP Routing (Detailed)

[Link]

Junos MPLS and VPNs

[edit routing-instances vpn-B routing-options]

lab@mxB-1#

Step 7.5
Navigate to the [edit routing-instances vpn-pod protocols bgp]
hierarchy. Create an external group called my-ext-group and specify the local CE
routers ge-1/1/4 address for the neighbor address. You must also define your
peer-as (the local CE routers AS number). Review your configuration, Commit,
and exit to operational mode before moving on to the next step.

[edit routing-instances vpn-B protocols bgp]

lab@mxB-1# set group my-ext-group type external

N
LY

[edit routing-instances vpn-B routing-options]

lab@mxB-1# top edit routing-instances vpn-pod protocols bgp

[edit routing-instances vpn-B protocols bgp]

lab@mxB-1# set group my-ext-group neighbor local-ce-address

SE

[edit routing-instances vpn-B protocols bgp]

lab@mxB-1# set group my-ext-group peer-as local-ce-as-number

AL

[edit routing-instances vpn-B protocols bgp]

lab@mxB-1# show
group my-ext-group {
type external;
peer-as 65201;
neighbor [Link];
}

TE
R

lab@mxB-1>

[edit routing-instances vpn-B protocols bgp]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

Step 7.6

Verify on the PE that you are receiving the advertised BGP routes from your
CE router.

IN

lab@mxB-1> show route receive-protocol bgp local-ce-address

inet.0: 33 destinations, 33 routes (33 active, 0 holddown, 0 hidden)

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)
Prefix
Nexthop
MED
Lclpref
AS path
[Link]/24
[Link]
65201 I
* [Link]/24
[Link]
65201 I
* [Link]/24
[Link]
65201 I

[Link]

L3VPN Static and BGP Routing (Detailed) Lab 725

Junos MPLS and VPNs

* [Link]/24
* [Link]/24
* [Link]/32

[Link]
[Link]
[Link]

65201 I
65201 I
65201 I

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

bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

N
LY

Question: Do you see the static routes that you

exported with the policy you applied to the CE
routers BGP instance?

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 [Link] you do not, please review your
configuration and request assistance from your
instructor, if needed.

SE

Step 7.7

Verify that your PE router is advertising your VPN routes to the remote PE router.

lab@mxB-1> show route advertising-protocol bgp remote-pe-loopback-address

TE
R

AL

[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
Self
100
I
* [Link]/24
Self
100
65201 I
* [Link]/24
Self
100
65201 I
* [Link]/24
Self
100
65201 I
* [Link]/24
Self
100
65201 I
* [Link]/32
Self
100
65201 I

IN

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 7.8
Verify that you are receiving the VPN routes being advertised from the remote
PE router.

Lab 726 L3VPN Static and BGP Routing (Detailed)

[Link]

Junos MPLS and VPNs

lab@mxB-1> show route receive-protocol bgp remote-pe-loopback-address

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

N
LY

[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
[Link]
100
I
* [Link]/24
[Link]
100
I
* [Link]/24
[Link]
100
I
* [Link]/24
[Link]
100
I
* [Link]/24
[Link]
100
I
* [Link]/32
[Link]
100
I
mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)

AL

SE

bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
[Link]:1:[Link]/24
*
[Link]
100
I
[Link]:1:[Link]/24
*
[Link]
100
I
[Link]:1:[Link]/24
*
[Link]
100
I
[Link]:1:[Link]/24
*
[Link]
100
I
[Link]:1:[Link]/24
*
[Link]
100
I
[Link]:1:[Link]/32
*
[Link]
100
I

IN

TE
R

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 up through Step 7.6. Please request
assistance from your instructor, if needed.

Step 7.9
Use the set cli logical-system command to place the CLI in the context of
the CE router logical system.

[Link]

L3VPN Static and BGP Routing (Detailed) Lab 727

Junos MPLS and VPNs

lab@mxB-1> set cli logical-system local-ce-hostname

Logical system: ceB-1
lab@mxB-1:ceB-1>

Step 7.10
Review the BGP routes you are receiving on your CE router.
lab@mxB-1:ceB-1> show route receive-protocol bgp local-pe-address

N
LY

inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
[Link]
65512 I

Question: Are you receiving all the remote network

routes from your PE router?

Answer: No, you are not receiving all of these

routes.

SE

Question: What additional steps must you take to

determine why the routes are not being received at
your CE router?

TE
R

Step 7.11

AL

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.

Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).

IN

lab@mxB-1:ceB-1> clear cli logical-system

Cleared default logical system
lab@mxB-1>

Step 7.12

Verify that your PE router is advertising these routes to your CE router.

lab@mxB-1> show route advertising-protocol bgp local-ce-address
[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)
Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
Self
I

Lab 728 L3VPN Static and BGP Routing (Detailed)

[Link]

Junos MPLS and VPNs

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

N
LY

lab@mxB-1> show route remote-ce-network/24 extensive

IN

TE
R

AL

SE

[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)

[Link]/24 (1 entry, 1 announced)
TSI:
KRT in-kernel [Link]/24 -> {indirect(1048575)}
*BGP
Preference: 170/-101
Route Distinguisher: [Link]:1
Next hop type: Indirect
Address: 0x27c8c3c
Next-hop reference count: 18
Source: [Link]
Next hop type: Router, Next hop index: 643
Next hop: [Link] via ge-1/0/0.220 weight 0x1, selected
Label-switched-path pe1-to-pe2-B
Label operation: Push 299904, Push 300080(top)
Label TTL action: prop-ttl, prop-ttl(top)
Session Id: 0x108
Protocol next hop: [Link]
Push 299904
Indirect next hop: 2868000 1048575 INH Session ID: 0x113
State: <Secondary Active Int Ext ProtectionCand>
Local AS: 65512 Peer AS: 65512
Age: 26
Metric2: 4
Validation State: unverified
Task: BGP_65512.[Link]+179
Announcement bits (1): 1-KRT
AS path: 65201 I
Communities: target:65512:2
Import Accepted
VPN Label: 299904
Localpref: 100
Router ID: [Link]
Primary Routing Table bgp.l3vpn.0
Indirect next hops: 1
Protocol next hop: [Link] Metric: 4
Push 299904
Indirect next hop: 2868000 1048575 INH Session ID: 0x113
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: [Link] via ge-1/0/0.220 weight 0x1
Session Id: 0x108
[Link]/32 Originating RIB: inet.3
[Link]

L3VPN Static and BGP Routing (Detailed) Lab 729

Junos MPLS and VPNs

Metric: 4
Node path count: 1
Forwarding nexthops: 1
Nexthop: [Link] via ge-1/0/0.220
bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

IN

TE
R

AL

SE

N
LY

[Link]:1:[Link]/24 (1 entry, 0 announced)

*BGP
Preference: 170/-101
Route Distinguisher: [Link]:1
Next hop type: Indirect
Address: 0x27c8c3c
Next-hop reference count: 18
Source: [Link]
Next hop type: Router, Next hop index: 643
Next hop: [Link] via ge-1/0/0.220 weight 0x1, selected
Label-switched-path pe1-to-pe2-B
Label operation: Push 299904, Push 300080(top)
Label TTL action: prop-ttl, prop-ttl(top)
Session Id: 0x108
Protocol next hop: [Link]
Push 299904
Indirect next hop: 2868000 1048575 INH Session ID: 0x113
State: <Active Int Ext ProtectionCand>
Local AS: 65512 Peer AS: 65512
Age: 26
Metric2: 4
Validation State: unverified
Task: BGP_65512.[Link]+179
AS path: 65201 I
Communities: target:65512:2
Import Accepted
VPN Label: 299904
Localpref: 100
Router ID: [Link]
Secondary Tables: [Link].0
Indirect next hops: 1
Protocol next hop: [Link] Metric: 4
Push 299904
Indirect next hop: 2868000 1048575 INH Session ID: 0x113
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: [Link] via ge-1/0/0.220 weight 0x1
Session Id: 0x108
[Link]/32 Originating RIB: inet.3
Metric: 4
Node path count: 1
Forwarding nexthops: 1
Nexthop: [Link] via ge-1/0/0.220

Question: What is the AS path of this route?

Answer: The answer will vary. In this example from

mxB-1, the AS path is 65201 I.

Lab 730 L3VPN Static and BGP Routing (Detailed)

[Link]

Junos MPLS and VPNs

Question: What is the AS of your CE router?

Answer: The answer will vary. In this example from

mxB-1, the AS of the CE router is 65201.

N
LY

Question: Will the PE router advertise routes to an

EBGP peer when the peers 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 7.14

lab@mxB-1> configure
Entering configuration mode

SE

Enter into configuration mode and navigate to the [edit routing-instances

vpn-pod 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@mxB-1# edit routing-instances vpn-pod protocols bgp

AL

[edit routing-instances vpn-B protocols bgp]

lab@mxB-1# set group my-ext-group as-override

TE
R

[edit routing-instances vpn-B protocols bgp]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

IN

Step 7.15

Use the set cli logical-system command to place the CLI in the context of
the CE router logical system.

lab@mxB-1> set cli logical-system local-ce-hostname

Logical system: ceB-1
lab@mxB-1:ceB-1>

Step 7.16
Verify that your CE router is now receiving the routes from your PE router after the
change.
lab@mxB-1:ceB-1> show route receive-protocol bgp local-pe-address
inet.0: 13 destinations, 18 routes (13 active, 0 holddown, 5 hidden)
[Link]

L3VPN Static and BGP Routing (Detailed) Lab 731

Junos MPLS and VPNs

*
*
*
*
*
*

Prefix
[Link]/24
[Link]/24
[Link]/24
[Link]/24
[Link]/24
[Link]/32

Nexthop
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]

MED

Lclpref

AS path
65512 I
65512 65512
65512 65512
65512 65512
65512 65512
65512 65512

I
I
I
I
I

N
LY

Question: Do you now see the routes being sent

from the remote team in your CE routers 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.

SE

Step 7.17

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 routers loopback address while sourcing the
packets from your local CE routers loopback address. You will send five packets for
this test. This task can be accomplished using the following command: ping
remote-ce-loopback source local-ce-loopback count 5 .

TE
R

AL

lab@mxB-1:ceB-1> ping remote-ce-loopback source local-ce-loopback count 5

PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=59 time=0.792 ms
64 bytes from [Link]: icmp_seq=1 ttl=59 time=0.753 ms
64 bytes from [Link]: icmp_seq=2 ttl=59 time=0.772 ms
64 bytes from [Link]: icmp_seq=3 ttl=59 time=0.773 ms
64 bytes from [Link]: icmp_seq=4 ttl=59 time=0.800 ms
--- [Link] ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.753/0.778/0.800/0.017 ms

IN

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.

Step 7.18
Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).
Lab 732 L3VPN Static and BGP Routing (Detailed)

[Link]

Junos MPLS and VPNs

lab@mxB-1:ceB-1> clear cli logical-system

Cleared default logical system
lab@mxB-1>

Step 7.19
Log out of your assigned device using the exit command.
lab@mxB-1> exit

N
LY

mxB-1 (ttyu0)
login:

Tell your instructor that you have completed this lab.

IN

TE
R

AL

SE

STOP

[Link]

L3VPN Static and BGP Routing (Detailed) Lab 733

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 734 L3VPN Static and BGP Routing (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

L3VPN Static and BGP Routing (Detailed) Lab 735

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 736 L3VPN Static and BGP Routing (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

L3VPN Static and BGP Routing (Detailed) Lab 737

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 738 L3VPN Static and BGP Routing (Detailed)

[Link]

Lab

N
LY

Route 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 configure an internal
BGP (IBGP) session 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.

SE

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.

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

Load the a baseline configuration for your router. This configuration includes
your baseline core OSPF configuration. The baseline also contains two logical
router configurations that will act as your CE routers for this lab.

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

IN

TE
R

AL

[Link]

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.

Route Reflection and Internet Access (Detailed) Lab 81

Junos MPLS and VPNs

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 a
baseline OSPF configuration and then enable Label Distribution Protocol (LDP) and
multiprotocol label switching (MPLS) on the core-facing interfaces, configure a
MP-BGP peering session with the route reflector, and configure a route-distinguisher
ID.
Note

N
LY

The instructor will tell you the nature of your

access and will provide you with the
necessary details to access your assigned
device.
Step 1.1

Ensure that you know to which device you are assigned. Check with your instructor if
necessary.

SE

Step 1.2

Consult the management network diagram, provided by your instructor, to determine

your devices management address.

AL

Question: What is the management address

assigned to your station?

IN

TE
R

Answer: The answer varies. The sample hostname

and IP address used in the output examples in this
lab are for mxB-1, which uses [Link] as its
management IP address. The actual management
subnet varies between delivery environments.

Lab 82 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

Step 1.3

N
LY

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
mxB-1 using the Secure CRT program.

SE

Step 1.4

Log in as user lab with the password supplied by your instructor. Enter
configuration mode and load the reset configuration file
jmv/[Link] and commit.
mxB-1 (ttyp0)

AL

login: lab
Password:

TE
R

--- JUNOS 12.3R2.5 built 2013-03-22 [Link] UTC

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# load override jmv/[Link]
load complete

IN

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

Step 1.5
Navigate to the [edit protocols] hierarchy. Issue the show command and
analyze the protocols that have been preconfigured for you.
[edit]
lab@mxB-1# edit protocols

[Link]

Route Reflection and Internet Access (Detailed) Lab 83

Junos MPLS and VPNs

[edit protocols]
lab@mxB-1# show
ospf {
area [Link] {
interface ge-1/0/0.220;
interface ge-1/0/1.221;
interface lo0.0;
}
}

N
LY

[edit protocols]
lab@mxB-1#

Question: Which protocols have been preconfigured

for you?

Answer: OSPF has been preconfigured.

SE

Step 1.6

State
Full
Full

AL

[edit protocols]
lab@mxB-1# run show ospf neighbor
Address
Interface
[Link]
ge-1/0/0.220
[Link]
ge-1/0/1.221

Verify that your Open Shortest Path First (OSPF) neighbor relationships are up and
operational.

ID
[Link]
[Link]

Pri
128
128

Dead
34
39

TE
R

Question: What is the state of your PE routers OSPF

neighbors?

Answer: After a short time, the OSPF neighbors

should attain the Full state.

IN

Step 1.7

Navigate to the [edit protocols bgp] hierarchy. Configure a IBGP peer group
called my-int-group. Use your routers loopback address as the source address
of all IBGP packets. Finally, configure your router to peer with the P2 router, which is
the acting route reflector for the core network.

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

Lab 84 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

[edit protocols bgp]

lab@mxB-1# set group my-int-group local-address local-pe-loopback-address
[edit protocols bgp]
lab@mxB-1# set group my-int-group neighbor [Link]

Step 1.8

N
LY

To allow for the exchange of Layer 3 VPN routes, enable the inet-vpn unicast
network layer reachability information (NLRI) for your PE routers BGP session with
the P2 router. Make sure to also enable the exchange of standard unicast IP version
4 (IPv4) routes as well. Commit your configuration and exit to operation mode.
[edit protocols bgp]
lab@mxB-1# set group my-int-group family inet unicast

lab@mxB-1>

Step 1.9

SE

[edit protocols bgp]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

[edit protocols bgp]

lab@mxB-1# set group my-int-group family inet-vpn unicast

AL

Verify that your PE router has established an IBGP neighbor relationship with the P2
router.

IN

TE
R

lab@mxB-1> show bgp neighbor

Peer: [Link]+50974 AS 65512 Local: [Link]+179 AS 65512
Type: Internal
State: Established
Flags: <ImportEval Sync>
Last State: OpenConfirm
Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress AddressFamily Rib-group Refresh>
Address families configured: inet-unicast inet-vpn-unicast
Local Address: [Link] Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: [Link]
Local ID: [Link]
Active Holdtime: 90
Keepalive Interval: 30
Group index: 0
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)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
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 inet-vpn-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
[Link]

Route Reflection and Internet Access (Detailed) Lab 85

Checked 36
Refreshes 0
Refreshes 0

Octets 166
Octets 177

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
Active prefixes:
0
Received prefixes:
0
Accepted prefixes:
0
Suppressed due to damping:
0
Last traffic (seconds): Received 12
Sent 6
Input messages: Total 5
Updates 2
Output messages: Total 4
Updates 0
Output Queue[0]: 0
Output Queue[1]: 0

N
LY

Junos MPLS and VPNs

SE

Question: Is the neighbor relationship in the

established state with the P2 router?

AL

Answer: The P2 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.

TE
R

Question: What NLRI type has been negotiated

between your PE router and the P2 router?

IN

Answer: Using the show bgp neighbor

command, you should see that the NLRI for this
session should be inet-unicast and
inet-vpn-unicast.

Step 1.10

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 and enable family mpls on both of the
core-facing interfaces.
lab@mxB-1> configure
Entering configuration mode

Lab 86 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

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

N
LY

Step 1.11

[edit interfaces]
lab@mxB-1# top edit protocols
[edit protocols]
lab@mxB-1# set mpls interface ge-1/0/[Link]

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

SE

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

[edit protocols]
lab@mxB-1#

Step 1.12

AL

Configure the LDP protocol on the core-facing interfaces as well as the loopback
interface.

[edit protocols]
lab@mxB-1# set ldp interface ge-1/0/[Link]

TE
R

[edit protocols]
lab@mxB-1# set ldp interface ge-1/0/[Link]
[edit protocols]
lab@mxB-1# set ldp interface lo0.0

IN

Step 1.13

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 routers 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 local-pe-loopback-address
[edit routing-options]
lab@mxB-1# commit and-quit
[Link]

Route Reflection and Internet Access (Detailed) Lab 87

Junos MPLS and VPNs

commit complete
Exiting configuration mode
lab@mxB-1>

Step 1.14
Use the show mpls interface command to verify that MPLS is configured
correctly on the core-facing interfaces.

N
LY

lab@mxB-1> show mpls interface

Interface
State
Administrative groups (x: extended)
ge-1/0/0.220
Up
<none>
ge-1/0/1.221
Up
<none>

Question: Can your core-facing interfaces now

support the transmission of MPLS packets?

SE

Answer: The output of the command shows that the

two interfaces can now support the forwarding of
MPLS packets.
Step 1.15

Verify that your router has established LDP neighbor relationships with the
neighboring P routers.

AL

lab@mxB-1> show ldp neighbor

Address
Interface
[Link]
ge-1/0/0.220
[Link]
ge-1/0/1.221

TE
R

lab@mxB-1> show ldp session

Address
State
[Link]
Operational
[Link]
Operational

Label space ID
[Link]:0
[Link]:0

Connection
Open
Open

Hold time
23
23

Hold time
13
10
Adv. Mode
DU
DU

IN

Question: What is the state of your PE routers

relationship with the neighboring P routers?

Answer: The neighboring P routers should be in the

Operational state with your PE router.

Step 1.16
Verify that the inet.3 routing table contains an LDP route to the remote PE router.
lab@mxB-1> show route table inet.3
inet.3: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
Lab 88 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

*[LDP/9] [Link],
> to [Link]
to [Link]
*[LDP/9] [Link],
> to [Link]
*[LDP/9] [Link],
> to [Link]
*[LDP/9] [Link],
> to [Link]
*[LDP/9] [Link],
> to [Link]
*[LDP/9] [Link],
> to [Link]
*[LDP/9] [Link],
> to [Link]

[Link]/32
[Link]/32
[Link]/32
[Link]/32
[Link]/32
[Link]/32

metric 1
via ge-1/0/1.221,
via ge-1/0/0.220,
metric 1
via ge-1/0/0.220
metric 1
via ge-1/0/0.220,
metric 1
via ge-1/0/0.220,
metric 1
via ge-1/0/1.221
metric 1
via ge-1/0/1.221,
metric 1
via ge-1/0/1.221,

Push 300064
Push 300096

Push 299840
Push 299824

Push 299776

N
LY

[Link]/32

Push 299792

Question: Do you see the LDP route to the remote

PE router in your inet.3 routing table?

SE

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.

Do not proceed until the remote team finishes Part 1.

AL

STOP

Part 2: Verifying CE Router Configuration

TE
R

In this lab part, you will view the configuration for the two CE routers (logical
systems) that were preconfigured as part of the loaded starting configuration in
Part 1 of this lab.

Step 2.1

Use the set cli logical-system command to place the CLI in the context of
the lower CE router logical system (based on the location on diagram).

IN

lab@mxB-1> set cli logical-system lower-ce-hostname

Logical system: ceB-1
lab@mxB-1:ceB-1>

Step 2.2
Issue the show configuration command to view the configuration of the CE
router.
lab@mxB-1:ceB-1> show configuration
interfaces {
ge-1/1/4 {
unit 620 {
[Link]

Route Reflection and Internet Access (Detailed) Lab 89

Junos MPLS and VPNs

SE

TE
R

lab@mxB-1:ceB-1>

AL

}
policy-options {
policy-statement exp-policy {
term 10 {
from protocol static;
then accept;
}
term 20 {
from protocol direct;
then accept;
}
}
}
routing-options {
static {
route [Link]/24 reject;
route [Link]/24 reject;
route [Link]/24 reject;
route [Link]/24 reject;
}
autonomous-system 65201;
}

}
lo0 {
unit 1 {
family inet {
address [Link]/32;
}
}
}

N
LY

vlan-id 620;
family inet {
address [Link]/24;
}

IN

Question: What interfaces have been configured on

the CE router? According to the lab diagram, do they
have the appropriate IP addressing?

Answer: The CE router should have both the

loopback and ge-1/1/4 interface configured with
the appropriate addressing according to the lab
diagram.

Lab 810 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

Question: What is configured under the

routing-options hierarchy? According to the
lab diagram, are these setting appropriate?

N
LY

Answer: Four static routes (next hop of reject) and

the CE routers autonomous system should be
configured under routing-options hierarchy.
These settings are appropriate.

Question: What is configured under the

policy-options hierarchy? What does this
policy do?

SE

Answer: A policy called exp-policy is configured

under policy-options hierarchy. If applied as
an export policy, this policy will redistribute active
direct and static routes into the protocol to which it
is applied. It is currently not applied to any protocol
in the configuration.
Step 2.3

AL

Use the ping utility to attempt to ping the local PE routers ge-1/0/4 interface.

lab@mxB-1:ceB-1> ping local-pe-address count 1

PING [Link] ([Link]): 56 data bytes

IN

TE
R

--- [Link] ping statistics --1 packets transmitted, 0 packets received, 100% packet loss

Question: Does your ping succeed? Why?

Answer: The pings do not succeed because the PE

routers ge-1/0/4 interface has not been
configured at this point in the lab.

Step 2.4
Use the set cli logical-system command to place the CLI in the context of
the upper CE router logical system (based on the location on diagram).
lab@mxB-1:ceB-1> set cli logical-system upper-ce-hostname
Logical system: ceB-3
lab@mxB-1:ceB-3>
[Link]

Route Reflection and Internet Access (Detailed) Lab 811

Junos MPLS and VPNs

Step 2.5

IN

TE
R

AL

SE

lab@mxB-1:ceB-3> show configuration

interfaces {
ge-1/1/5 {
unit 621 {
vlan-id 621;
family inet {
address [Link]/24;
}
}
}
lo0 {
unit 2 {
family inet {
address [Link]/32;
}
}
}
}
policy-options {
policy-statement exp-policy {
term 10 {
from protocol static;
then accept;
}
term 20 {
from protocol direct;
then accept;
}
}
}
routing-options {
static {
route [Link]/24 reject;
route [Link]/24 reject;
route [Link]/24 reject;
route [Link]/24 reject;
}
autonomous-system 65202;
}

N
LY

Issue the show configuration command to view the configuration of the CE

router.

lab@mxB-1:ceB-3>

Lab 812 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

Question: What interfaces have been configured on

the CE router? According to the lab diagram, do they
have the appropriate IP addressing?

N
LY

Answer: The CE router should have both the

loopback and ge-1/1/5 interface configured with
the appropriate addressing according to the lab
diagram.

Question: What is configured under the

routing-options hierarchy? According to the
lab diagram, are these setting appropriate?

SE

Answer: Four static routes (next hop of reject) and

the CE routers autonomous system should be
configured under routing-options hierarchy.
These settings are appropriate.

AL

Question: What is configured under the

policy-options hierarchy? What does this
policy do?

TE
R

Answer: A policy called exp-policy is configured

under policy-options hierarchy. If applied as
an export policy, this policy will redistribute active
direct and static routes into the protocol to which it
is applied. It is currently not applied to any protocol
in the configuration.

IN

Step 2.6

Use the ping utility to attempt to ping the local PE routers ge-1/0/5 interface.

lab@mxB-1:ceB-3> ping local-pe-address count 1

PING [Link] ([Link]): 56 data bytes
--- [Link] ping statistics --1 packets transmitted, 0 packets received, 100% packet loss

[Link]

Route Reflection and Internet Access (Detailed) Lab 813

Junos MPLS and VPNs

Question: Does your ping succeed? Why?

Answer: The pings do not succeed because the PE

routers ge-1/0/5 interface has not been
configured at this point in the lab.

N
LY

Part 3: Configuring the PE to CE Interfaces

In this lab part, you will configure both of the PE to CE [Link] will verify
reachability using the ping utility.
Step 3.1

SE

lab@mxB-1:ceB-3> clear cli logical-system

Cleared default logical system

Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).

lab@mxB-1>

Step 3.2

AL

Enter into configuration mode and navigate to the [edit interfaces]

hierarchy. Configure the appropriate interface properties on your PE routers that can
be found on the lab diagram. 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.

lab@mxB-1> configure
Entering configuration mode

TE
R

[edit]
lab@mxB-1# edit interfaces

[edit interfaces]
lab@mxB-1# set ge-1/0/4 vlan-tagging unit unit vlan-id vlan-id

IN

[edit interfaces]
lab@mxB-1# set ge-1/0/4 unit unit family inet address address/24
[edit interfaces]
lab@mxB-1# set ge-1/0/5 vlan-tagging unit unit vlan-id vlan-id
[edit interfaces]
lab@mxB-1# set ge-1/0/5 unit unit family inet address address/24

Lab 814 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

[edit interfaces]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 3.3
Verify reachability to both CE routers by pinging their interfaces five times.

time=7.201
time=0.598
time=0.550
time=0.576
time=0.558

ms
ms
ms
ms
ms

N
LY

lab@mxB-1> ping lower-ce-address count 5

PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=64
64 bytes from [Link]: icmp_seq=1 ttl=64
64 bytes from [Link]: icmp_seq=2 ttl=64
64 bytes from [Link]: icmp_seq=3 ttl=64
64 bytes from [Link]: icmp_seq=4 ttl=64

--- [Link] ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.550/1.897/7.201/2.652 ms

SE

lab@mxB-1> ping upper-ce-address count 5

PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=64
64 bytes from [Link]: icmp_seq=1 ttl=64
64 bytes from [Link]: icmp_seq=2 ttl=64
64 bytes from [Link]: icmp_seq=3 ttl=64
64 bytes from [Link]: icmp_seq=4 ttl=64

AL

time=6.616 ms
time=4.930 ms
time=3.992 ms
time=7.623 ms
time=12.433 ms

--- [Link] ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.992/7.119/12.433/2.943 ms

IN

TE
R

Question: Do the pings complete?

[Link]

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.

Route Reflection and Internet Access (Detailed) Lab 815

Junos MPLS and VPNs

Part 4: Configuring Two Layer 3 VPN Instances

N
LY

In this lab part, you will configure two Layer 3 VPN instances. You will create a VPN
named vpn-lower, which will connect the lower CE routers (see diagram) of the
two sites. For example, if you are controlling mxB-1 or mxB-2 (pod B), you will create
a VPN that connects ceB-1 to ceB-2. You will then create a VPN named vpn-upper,
which will connect the upper CE routers. 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. Use the following table as your guide for configuring your target communities in
this part of the lab.

Lower Target

Upper Target

target:65512:101

target:65512:102

target:65512:201

target:65512:301

target:65512:302

target:65512:401

target:65512:402

Pod

SE

target:65512:202

Step 4.1

AL

Enter into configuration mode and navigate to the [edit routing-instances

vpn-lower] hierarchy. Configure the routing instance specifying a routing
instance type of vrf.
lab@mxB-1> configure
Entering configuration mode

TE
R

[edit]
lab@mxB-1# edit routing-instances vpn-lower
[edit routing-instances vpn-lower]
lab@mxB-1# set instance-type vrf
[edit routing-instances vpn-lower]
lab@mxB-1#

IN

Step 4.2

Configure your route target for the lower VPN. As mentioned previously, you will be
using the vrf-target option. See the table at the beginning of this part of the lab
to determine the appropriate target community value.

[edit routing-instances vpn-lower]

lab@mxB-1# set vrf-target lower-target-value
Step 4.3
Configure the vrf-table-label behavior for this VRF instance.
[edit routing-instances vpn-lower]
lab@mxB-1# set vrf-table-label
Lab 816 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

Step 4.4
Add the appropriate subinterface of ge-1/0/4 to the routing instance. Review your
configuration changes and commit when you are satisfied with the changes.
[edit routing-instances vpn-lower]
lab@mxB-1# set interface ge-1/0/[Link]

N
LY

[edit routing-instances vpn-lower]

lab@mxB-1# show
instance-type vrf;
interface ge-1/0/4.620;
vrf-target target:65512:201;
vrf-table-label;
[edit routing-instances vpn-lower]
lab@mxB-1# commit
commit complete

Step 4.5

[edit routing-instances]
lab@mxB-1# edit vpn-upper

[edit routing-instances vpn-lower]

lab@mxB-1# up

SE

Navigate to the [edit routing-instances vpn-upper] hierarchy.

Configure the routing instance specifying a routing instance type of vrf.

AL

[edit routing-instances vpn-upper]

lab@mxB-1# set instance-type vrf

Step 4.6

[edit routing-instances vpn-upper]

lab@mxB-1#

TE
R

Configure your route target for the upper VPN using the vrf-target option. See
the table at the beginning of this part of the lab to determine the appropriate target
community value.

[edit routing-instances vpn-upper]

lab@mxB-1# set vrf-target upper-target-value

IN

Step 4.7

Add the appropriate subinterface of ge-1/0/5 to the routing instance. Review your
configuration changes and when satisfied, commit and exit to operational mode.

[edit routing-instances vpn-upper]

lab@mxB-1# set interface ge-1/0/[Link]
[edit routing-instances vpn-upper]
lab@mxB-1# show
instance-type vrf;
interface ge-1/0/5.621;
vrf-target target:65512:202;
[Link]

Route Reflection and Internet Access (Detailed) Lab 817

Junos MPLS and VPNs

[edit routing-instances vpn-upper]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 4.8
Use the show route command to verify that both VRF tables are created and
contain the local network routes.

N
LY

lab@mxB-1> show route table vpn-lower

[Link]/32

*[Direct/0] [Link]
> via ge-1/0/4.620
*[Local/0] [Link]
Local via ge-1/0/4.620

lab@mxB-1> show route table vpn-upper

SE

[Link]/24

[Link].0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

[Link].0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

AL

[Link]/32

*[Direct/0] [Link]
> via ge-1/0/5.621
*[Local/0] [Link]
Local via ge-1/0/5.621

[Link]/24

TE
R

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.

IN

Step 4.9

Issue the show route advertising-protocol bgp extensive command to

view that routes that are being advertised to the route reflector.

lab@mxB-1> show route advertising-protocol bgp [Link] extensive

[Link].0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
* [Link]/24 (1 entry, 1 announced)
BGP group my-int-group type Internal
Route Distinguisher: [Link]:12
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
Lab 818 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

AS path: [65512] I
Communities: target:65512:201
[Link].0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

N
LY

* [Link]/24 (1 entry, 1 announced)

BGP group my-int-group type Internal
Route Distinguisher: [Link]:13
BGP label allocation failure: Need a nexthop address on LAN
Nexthop: Not advertised
Flags: Nexthop Change
Localpref: 100
AS path: [65512] I
Communities: target:65512:202

SE

Question: Do you notice any differences in the

routes in the vpn-lower and vpn-upper tables?
Why?

STOP

TE
R

AL

Answer: The route in the vpn-upper table is not

being advertised because the PE has not learned
any route from the attached CE. By default, a
Juniper router maps and allocates VPN labels to a
next hop. Without a learned next-hop, a label
cannot be allocated. The route in the vpn-lower
table is being advertised since you configured
vrf-table-label causing the router to allocate
VPN labels on a per table basis (there is no longer a
need to pre-determine the next hop before label
allocation).

Do not proceed until the remote team finishes Part 6.

IN

Part 5: Configuring BGP Routing Between the PE and CE Routers

[Link]

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.

Route Reflection and Internet Access (Detailed) Lab 819

Junos MPLS and VPNs

Step 5.1
Enter into configuration mode and navigate to the [edit routing-instances
vpn-lower protocols bgp] hierarchy. Create an external group called
my-ext-group-lower and specify your locally attached CE routers 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, commit, and exit to
operation mode before moving on to the next step.

N
LY

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit routing-instances vpn-lower protocols bgp

[edit routing-instances vpn-lower protocols bgp]

lab@mxB-1# set group my-ext-group-lower type external

[edit routing-instances vpn-lower protocols bgp]

lab@mxB-1# set group my-ext-group-lower neighbor lower-ce-address

SE

[edit routing-instances vpn-lower protocols bgp]

lab@mxB-1# set group my-ext-group-lower peer-as lower-ce-as-number

[edit routing-instances vpn-lower protocols bgp]

lab@mxB-1# set group my-ext-group-lower as-override

TE
R

AL

[edit routing-instances vpn-lower protocols bgp]

lab@mxB-1# show
group my-ext-group-lower {
type external;
peer-as 65201;
as-override;
neighbor [Link];
}
[edit routing-instances vpn-lower protocols bgp]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

IN

lab@mxB-1>

Step 5.2

Use the set cli logical-system command to place the CLI in the context of
the lower CE router logical system (based on the location on diagram).

lab@mxB-1> set cli logical-system lower-ce-hostname

Logical system: ceB-1
lab@mxB-1:ceB-1>

Lab 820 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

Step 5.3
Enter configuration mode and navigate to the [edit protocols bgp]
hierarchy. Create an external group called my-ext-group and specify your local
PE routers neighbor address. You must also define your peer-as. Apply the policy
exp-policy that you viewed earlier in the lab as an export policy to your EBGP
group. Review your configuration, commit, and exit to operational mode.
lab@mxB-1:ceB-1> configure
Entering configuration mode

N
LY

[edit]
lab@mxB-1:ceB-1# edit protocols bgp

[edit protocols bgp]

lab@mxB-1:ceB-1# set group my-ext-group type external

[edit protocols bgp]

lab@mxB-1:ceB-1# set group my-ext-group neighbor local-pe-address

SE

[edit protocols bgp]

lab@mxB-1:ceB-1# set group my-ext-group peer-as 65512

AL

[edit protocols bgp]

lab@mxB-1:ceB-1# show
group my-ext-group {
type external;
export exp-policy;
peer-as 65512;
neighbor [Link];
}

[edit protocols bgp]

lab@mxB-1:ceB-1# set group my-ext-group export exp-policy

TE
R

[edit protocols bgp]

lab@mxB-1:ceB-1# commit and-quit
commit complete
Exiting configuration mode

IN

lab@mxB-1:ceB-1>

Note

Check with the team configuring the

remote CE router and ensure that they have
completed Step 5.3 before proceeding to
the next step.

Step 5.4
Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).

[Link]

Route Reflection and Internet Access (Detailed) Lab 821

Junos MPLS and VPNs

lab@mxB-1:ceB-1> clear cli logical-system

Cleared default logical system
lab@mxB-1>

Step 5.5
Use the show route receive-protocol bgp command to verify that you are
receiving the static routes from the lower CE router at your PE router.
lab@mxB-1> show route receive-protocol bgp lower-ce-address

N
LY

inet.0: 33 destinations, 33 routes (33 active, 0 holddown, 0 hidden)

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

SE

[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
[Link]/24
[Link]
65201 I
* [Link]/24
[Link]
65201 I
* [Link]/24
[Link]
65201 I
* [Link]/24
[Link]
65201 I
* [Link]/24
[Link]
65201 I
* [Link]/32
[Link]
65201 I
[Link].0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)

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

AL

bgp.l3vpn.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

TE
R

Question: Has your PE router received the BGP

routes that represent that static routes that were
redistributed by the local, lower CE router?

Answer: Your PE router should be receiving the

routes from the local, lower CE router.

IN

Step 5.6

Issue the show route advertising-protocol bgp [Link]

command to verify that you are sending the routes learned from the local lower CE
router to the remote team through the route reflector.

lab@mxB-1> show route advertising-protocol bgp [Link]

[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)
Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
Self
100
I
* [Link]/24
Self
100
65201 I
* [Link]/24
Self
100
65201 I
* [Link]/24
Self
100
65201 I
* [Link]/24
Self
100
65201 I
Lab 822 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

* [Link]/32

Self

100

65201 I

[Link].0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
Not advertised
100
I

N
LY

Question: Is your PE router sending the BGP routes

that represent that static routes that were
redistributed by the local, lower CE router?

Answer: Your PE router should be sending the

routes to the route reflector.
Step 5.7

SE

Issue the show route receive-protocol bgp [Link] command to

verify that you are also receiving the remote, lower CE routers static routes at your
PE router from the route reflector.
lab@mxB-1> show route receive-protocol bgp [Link]
inet.0: 33 destinations, 33 routes (33 active, 0 holddown, 0 hidden)

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

Question: Is your PE router receiving the BGP routes

that represent that static routes that were
redistributed by the remote, lower CE router?

IN

TE
R

AL

[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
[Link]
100
I
* [Link]/24
[Link]
100
65201 I
* [Link]/24
[Link]
100
65201 I
* [Link]/24
[Link]
100
65201 I
* [Link]/24
[Link]
100
65201 I
* [Link]/32
[Link]
100
65201 I
...

Answer: Your PE router should be receiving the

routes from the route reflector.
Step 5.8
Issue the show route advertising-protocol bgp local-ce-address
command to verify that you are sending the routes learned from the remote, lower
CE router to the local, lower CE router.
[Link]

Route Reflection and Internet Access (Detailed) Lab 823

Junos MPLS and VPNs

lab@mxB-1> show route advertising-protocol bgp lower-ce-address

N
LY

[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
Self
I
* [Link]/24
[Link]
65512 I
* [Link]/24
[Link]
65512 I
* [Link]/24
[Link]
65512 I
* [Link]/24
[Link]
65512 I
* [Link]/24
Self
65512 I
* [Link]/24
Self
65512 I
* [Link]/24
Self
65512 I
* [Link]/24
Self
65512 I
* [Link]/32
[Link]
65512 I
* [Link]/32
Self
65512 I

SE

Question: Is your PE router sending the BGP routes

from the remote, lower CE router to the local, lower
CE router?

Answer: Your PE router should be sending the

routes to the local, lower CE router.
Step 5.9

AL

Use the set cli logical-system command to place the CLI in the context of
the lower CE router logical system (based on the location on diagram).

lab@mxB-1:ceB-1>

TE
R

Step 5.10

lab@mxB-1> set cli logical-system lower-ce-hostname

Logical system: ceB-1

Verify reachability to the remote CE router by pinging the loopback address five
times. This task can be accomplished by issuing the ping
remote-ce-loopback source local-ce-loopback count 5 command.

IN

lab@mxB-1:ceB-1> ping remote-ce-loopback source local-ce-loopback count 5

PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=59 time=0.853 ms
64 bytes from [Link]: icmp_seq=1 ttl=59 time=0.844 ms
64 bytes from [Link]: icmp_seq=2 ttl=59 time=0.734 ms
64 bytes from [Link]: icmp_seq=3 ttl=59 time=0.802 ms
64 bytes from [Link]: icmp_seq=4 ttl=59 time=0.766 ms
--- [Link] ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.734/0.800/0.853/0.045 ms

Lab 824 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

Question: Did the ping test complete?

Answer: Yes, your pings should complete.

Note

N
LY

If you are not receiving or sending any of

the routes from the previous steps, please
review your configuration and work with the
remote team for your pod. Request
assistance from the instructor as needed.
Step 5.11

SE

lab@mxB-1:ceB-1> clear cli logical-system

Cleared default logical system

Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).

lab@mxB-1>

Step 5.12

AL

Enter into configuration mode and navigate to the [edit routing-instances

vpn-upper protocols bgp] hierarchy. Create an external group named
my-ext-group-upper 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, commit your configuration, and exit to operational mode
before proceeding to the next step.

TE
R

lab@mxB-1> configure
Entering configuration mode

[edit]
lab@mxB-1# edit routing-instances vpn-upper protocols bgp

IN

[edit routing-instances vpn-upper protocols bgp]

lab@mxB-1# set group my-ext-group-upper type external
[edit routing-instances vpn-upper protocols bgp]
lab@mxB-1# set group my-ext-group-upper neighbor upper-ce-address
[edit routing-instances vpn-upper protocols bgp]
lab@mxB-1# set group my-ext-group-upper peer-as upper-ce-as-number
[edit routing-instances vpn-upper protocols bgp]
lab@mxB-1# set group my-ext-group-upper as-override
[edit routing-instances vpn-upper protocols bgp]
lab@mxB-1# show
group my-ext-group-upper {
[Link]

Route Reflection and Internet Access (Detailed) Lab 825

Junos MPLS and VPNs

type external;
peer-as 65202;
as-override;
neighbor [Link];

[edit routing-instances vpn-upper protocols bgp]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

N
LY

lab@mxB-1>

Step 5.13

lab@mxB-1> set cli logical-system upper-ce-router

Logical system: ceB-3
lab@mxB-1:ceB-3>

SE

Step 5.14

Use the set cli logical-system command to place the CLI in the context of
the upper CE router logical system (based on the location on diagram).

Enter configuration mode and navigate to the [edit protocols bgp]

hierarchy. 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 viewed earlier in this lab as an export policy to your EBGP
group. Review your configuration, commit, and exit to operational mode.

AL

lab@mxB-1:ceB-3> configure
Entering configuration mode

[edit]
lab@mxB-1:ceB-3# edit protocols bgp

TE
R

[edit protocols bgp]

lab@mxB-1:ceB-3# set group my-ext-group neighbor local-pe-address
[edit protocols bgp]
lab@mxB-1:ceB-3# set group my-ext-group type external

IN

[edit protocols bgp]

lab@mxB-1:ceB-3# set group my-ext-group peer-as 65512
[edit protocols bgp]
lab@mxB-1:ceB-3# set group my-ext-group export exp-policy
[edit protocols bgp]
lab@mxB-1:ceB-3# show
group my-ext-group {
type external;
export exp-policy;
peer-as 65512;
neighbor [Link];
}
Lab 826 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

[edit protocols bgp]

lab@mxB-1:ceB-3# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1:ceB-3>
Note

N
LY

Check with the team configuring the

remote CE router and ensure that they have
completed Step 5.14 before proceeding to
the next step.
Step 5.15

SE

lab@mxB-1:ceB-3> clear cli logical-system

Cleared default logical system

Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).

lab@mxB-1>

Step 5.16

Use the show route receive-protocol bgp command to verify that you are
receiving the static routes from the upper, local CE router at your PE router.

AL

lab@mxB-1> show route receive-protocol bgp upper-ce-address

inet.0: 33 destinations, 33 routes (33 active, 0 holddown, 0 hidden)

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

TE
R

[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)

IN

[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
[Link]/24
[Link]
65202 I
* [Link]/24
[Link]
65202 I
* [Link]/24
[Link]
65202 I
* [Link]/24
[Link]
65202 I
* [Link]/24
[Link]
65202 I
* [Link]/32
[Link]
65202 I
mpls.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
bgp.l3vpn.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

[Link]

Route Reflection and Internet Access (Detailed) Lab 827

Junos MPLS and VPNs

Question: Has your PE router received the BGP

routes that represent that static routes that were
redistributed by the local, upper CE router?

Answer: Your PE router should be receiving the

routes from the local, upper CE router.

N
LY

Step 5.17
Issue the show route advertising-protocol bgp [Link]
command to verify that you are sending the routes learned from the local, lower CE
router to the remote team through the route reflector.
lab@mxB-1> show route advertising-protocol bgp [Link]

SE

[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
Self
100
I
* [Link]/24
Self
100
65201 I
* [Link]/24
Self
100
65201 I
* [Link]/24
Self
100
65201 I
* [Link]/24
Self
100
65201 I
* [Link]/32
Self
100
65201 I

TE
R

AL

[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
Self
100
I
* [Link]/24
Self
100
65202 I
* [Link]/24
Self
100
65202 I
* [Link]/24
Self
100
65202 I
* [Link]/24
Self
100
65202 I
* [Link]/32
Self
100
65202 I

IN

Question: Is your PE router sending the BGP routes

that represent that static routes that were
redistributed by the local, upper CE router?

Answer: Your PE router should be sending the

routes to the route reflector.

Step 5.18
Issue the show route receive-protocol bgp [Link] command to
verify that you are also receiving the remote, upper CE routers static routes at your
PE router from the route reflector.
lab@mxB-1> show route receive-protocol bgp [Link]
inet.0: 33 destinations, 33 routes (33 active, 0 holddown, 0 hidden)
Lab 828 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

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

[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)
Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
[Link]
100
I
* [Link]/24
[Link]
100
65201 I
* [Link]/24
[Link]
100
65201 I
* [Link]/24
[Link]
100
65201 I
* [Link]/24
[Link]
100
65201 I
* [Link]/32
[Link]
100
65201 I

SE

N
LY

[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
[Link]
100
I
* [Link]/24
[Link]
100
65202 I
* [Link]/24
[Link]
100
65202 I
* [Link]/24
[Link]
100
65202 I
* [Link]/24
[Link]
100
65202 I
* [Link]/32
[Link]
100
65202 I
...

Question: Is your PE router receiving the BGP routes

that represent that static routes that were
redistributed by the remote, upper CE router?

Step 5.19

AL

Answer: Your PE router should be receiving the

routes from the route reflector.

TE
R

Issue the show route advertising-protocol bgp upper-ce-address

command to verify that you are sending the routes originated by the remote, upper
CE router to the local, upper CE router.

lab@mxB-1> show route advertising-protocol bgp upper-ce-address

IN

[Link].0: 13 destinations, 14 routes (13 active, 0 holddown, 0 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
Self
I
* [Link]/24
[Link]
65512 I
* [Link]/24
[Link]
65512 I
* [Link]/24
[Link]
65512 I
* [Link]/24
[Link]
65512 I
* [Link]/24
Self
65512 I
* [Link]/24
Self
65512 I
* [Link]/24
Self
65512 I
* [Link]/24
Self
65512 I
* [Link]/32
[Link]
65512 I
* [Link]/32
Self
65512 I

[Link]

Route Reflection and Internet Access (Detailed) Lab 829

Junos MPLS and VPNs

Question: Is your PE router sending the BGP routes

originated by the remote, upper CE router to the
local, upper CE router?

Answer: Your PE router should be sending the

routes to the local, upper CE router.

N
LY

Step 5.20
Use the set cli logical-system command to place the CLI in the context of
the upper CE router logical system (based on the location on diagram).
lab@mxB-1> set cli logical-system upper-ce-hostname
Logical system: ceB-3

lab@mxB-1:ceB-3>

Step 5.21

SE

Verify reachability to the remote, upper CE router by pinging the loopback address
five times. This task can be accomplished by issuing the ping
remote-ce-loopback source local-ce-loopback count 5 command.

AL

lab@mxB-1:ceB-3> ping remote-ce-loopback source local-ce-loopback count 5

PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=59 time=0.848 ms
64 bytes from [Link]: icmp_seq=1 ttl=59 time=2.029 ms
64 bytes from [Link]: icmp_seq=2 ttl=59 time=0.799 ms
64 bytes from [Link]: icmp_seq=3 ttl=59 time=0.814 ms
64 bytes from [Link]: icmp_seq=4 ttl=59 time=0.778 ms

TE
R

--- [Link] ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.778/1.054/2.029/0.488 ms

Question: Did the ping test complete?

IN

Answer: Yes, your pings should complete.

Note

If you are not receiving or sending any of

the routes from the previous steps, please
review your configuration and work with the
remote team for your pod. Request
assistance from the instructor as needed.

Lab 830 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

Do not proceed until the remote team finishes Part 7.

STOP

Part 6: Implementing Route Target Filtering

N
LY

In this lab part, you will implement route filtering on your PE router. You will alter the
upper CE routers 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 PE 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.
Step 6.1

lab@mxB-1:ceB-3> clear cli logical-system

Cleared default logical system

SE

lab@mxB-1>

Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).

Step 6.2

AL

Enter into configuration mode and navigate to the [edit routing-instances

vpn-upper] hierarchy. Alter the vrf-target you have configured for this VPN
using the table below as your guide. After making this configuration change, commit
and exit to operational mode.

PE

Target Community

pe1

target:65512:103

pe2

target:65512:104

pe1

target:65512:203

pe2

target:65512:204

pe1

target:65512:303

pe2

target:65512:304

pe1

target:65512:403

pe2

target:65512:404

IN

TE
R

Pod

[Link]

Route Reflection and Internet Access (Detailed) Lab 831

Junos MPLS and VPNs

Note

[edit]
lab@mxB-1# edit routing-instances vpn-upper
[edit routing-instances vpn-upper]
lab@mxB-1# set vrf-target new-target-value

lab@mxB-1>

SE

[edit routing-instances vpn-upper]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

lab@mxB-1> configure
Entering configuration mode

N
LY

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.

Step 6.3

AL

Review the routes that you have accepted and installed in your bgp.l3vpn.0
routing table.
lab@mxB-1> show route table bgp.l3vpn.0

TE
R

bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

IN

[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)
[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65201 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)
[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65201 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
Lab 832 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

> to [Link] via ge-1/0/0.220, Push 300032, Push

SE

N
LY

300096(top)
[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65201 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)
[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65201 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)
[Link]:9:[Link]/32
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65201 I, validation-state: unverified
> to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)

AL

Question: Do you see the vpn-upper routes for

the remote CE router?

IN

TE
R

Step 6.4

Answer: No, You should not see the routes since the
target communities are now mismatched. You
should not have routes with the prefixes advertised
by the remote CE router.

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.

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit protocols bgp
[edit protocols bgp]
lab@mxB-1# set keep all
[edit protocols bgp]
lab@mxB-1# commit and-quit
commit complete
[Link]

Route Reflection and Internet Access (Detailed) Lab 833

Junos MPLS and VPNs

Exiting configuration mode

lab@mxB-1>

Step 6.5
Review the routes that you have accepted and installed in your bgp.l3vpn.0
routing table after adding the keep all functionality.
lab@mxB-1> show route table bgp.l3vpn.0

N
LY

bgp.l3vpn.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

IN

TE
R

AL

SE

[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)
[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65201 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)
[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65201 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)
[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65201 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)
[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65201 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)
[Link]:9:[Link]/32
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65201 I, validation-state: unverified
> to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)
Lab 834 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

IN

TE
R

AL

SE

N
LY

[Link]:10:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300048, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300048, Push
300096(top)
[Link]:10:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65202 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300048, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300048, Push
300096(top)
[Link]:10:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65202 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300048, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300048, Push
300096(top)
[Link]:10:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65202 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300048, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300048, Push
300096(top)
[Link]:10:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65202 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300048, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300048, Push
300096(top)
[Link]:10:[Link]/32
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65202 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300048, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300048, Push
300096(top)

Question: Do you see the vpn-upper routes for

the remote CE router?

Answer: Yes, You should see the routes even though

they do not match any of your locally configured
target values.

[Link]

Route Reflection and Internet Access (Detailed) Lab 835

Junos MPLS and VPNs

Step 6.6
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. Commit your configuration and exit to operational mode.
lab@mxB-1> configure
Entering configuration mode

[edit protocols bgp]

lab@mxB-1# set group my-int-group family route-target

[edit protocols bgp]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode

N
LY

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

lab@mxB-1>

SE

Step 6.7

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.

lab@mxB-1> show route table bgp.l3vpn.0

AL

bgp.l3vpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

IN

TE
R

[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)
[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65201 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)
[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65201 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)
[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
Lab 836 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

300064(top)

AS path: 65201 I, validation-state: unverified

to [Link] via ge-1/0/1.221, Push 300032, Push

N
LY

> to [Link] via ge-1/0/0.220, Push 300032, Push

300096(top)
[Link]:9:[Link]/24
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65201 I, validation-state: unverified
to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
> to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)
[Link]:9:[Link]/32
*[BGP/170] [Link], localpref 100, from [Link]
AS path: 65201 I, validation-state: unverified
> to [Link] via ge-1/0/1.221, Push 300032, Push
300064(top)
to [Link] via ge-1/0/0.220, Push 300032, Push
300096(top)

SE

Question: Do you see the vpn-upper routes for

the remote CE router?

AL

Answer: No, You should not see the routes. If you do

not see any routes, 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.

IN

TE
R

Part 7: Configuring Internet Access Using a Non-VRF Interface

In this lab part, you will establish Internet access for your CE router connected to the
vpn-lower 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 routers non-VRF interface as the next
hop. You will configure the PE routers 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 routers loopback interfaces from your CE device to simulate connectivity to the
Internet (networks outside the VPN instance).

Step 7.1

Enter configuration mode and navigate to the [edit interface] hierarchy.

Configure the additional logical unit, VLAN, and IP address for the PE router
interface.
lab@mxB-1> configure
Entering configuration mode

[Link]

Route Reflection and Internet Access (Detailed) Lab 837

Junos MPLS and VPNs

[edit]
lab@mxB-1# edit interfaces
[edit interfaces]
lab@mxB-1# set ge-1/0/4 unit unit vlan-id vlan-id family inet address address/24
[edit interfaces]
lab@mxB-1#

Step 7.2

N
LY

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 (it will be a /22 route). 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
routers loopback address as a static route with the same next hop.

[edit interfaces]
lab@mxB-1# top edit routing-options

[edit routing-options]
lab@mxB-1# set static route network/22 next-hop ce-address

SE

[edit routing-options]
lab@mxB-1# set static route ce-loopback-address/32 next-hop ce-address

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

Step 7.3

AL

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@mxB-1# top edit policy-options

TE
R

[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

IN

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

Step 7.4

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 statics. This action allows the core networks IGP to
route traffic back to the CE network through the non-VRF connection.

[edit policy-options]
lab@mxB-1# top edit protocols ospf
[edit protocols ospf]
lab@mxB-1# set area 0 interface ge-1/0/[Link] passive
Lab 838 Route Reflection and Internet Access (Detailed)

[Link]

Junos MPLS and VPNs

[edit protocols ospf]

lab@mxB-1# set export statics
[edit protocols ospf]
lab@mxB-1#

Step 7.5

N
LY

Navigate to the [edit logical-systems local-ce] hierarchy and add the

non-VRF interface. Configure a static default route that points to the non-vrf
interface address as the next hop. Commit your configuration and exit to operational
mode.
[edit protocols ospf]
lab@mxB-1# top edit logical-systems local-ce

[edit logical-systems ceB-1]

lab@mxB-1# set interfaces ge-1/1/4 unit unit vlan-id vlan-id

[edit logical-systems ceB-1]

lab@mxB-1# set interfaces ge-1/1/4 unit unit family inet address ce-address/24

SE

[edit logical-systems ceB-1]

lab@mxB-1# set routing-options static route 0/0 next-hop pe-address

AL

[edit logical-systems ceB-1]

lab@mxB-1# show routing-options
static {
route [Link]/24 reject;
route [Link]/24 reject;
route [Link]/24 reject;
route [Link]/24 reject;
route [Link]/0 next-hop [Link];
}
autonomous-system 65201;

TE
R

[edit logical-systems ceB-1]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

IN

Step 7.6

Use the set cli logical-system command to place the CLI in the context of
the lower CE router logical system (based on the location on diagram).

lab@mxB-1> set cli logical-system local-ce-hostname

Logical system: ceB-1
lab@mxB-1:ceB-1>

[Link]

Route Reflection and Internet Access (Detailed) Lab 839

Junos MPLS and VPNs

Step 7.7
Issue the ping p-router-loopback source local-ce-loopback count 5
command to verify that you can ping the loopback address of one of the core routers
five times, sourced from your CE routers loopback address. You can review Part 1
diagram that shows the core network if you do not recall the loopback addresses of
the core routers.

N
LY

lab@mxB-1:ceB-1> ping p-router-loopback source local-ce-loopback count 5

PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=61 time=0.801 ms
64 bytes from [Link]: icmp_seq=1 ttl=61 time=0.761 ms
64 bytes from [Link]: icmp_seq=2 ttl=61 time=0.750 ms
64 bytes from [Link]: icmp_seq=3 ttl=61 time=0.736 ms
64 bytes from [Link]: icmp_seq=4 ttl=61 time=0.716 ms

--- [Link] ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.716/0.753/0.801/0.028 ms

SE

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.
Step 7.8

AL

Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).

Step 7.9

TE
R

lab@mxB-1>

lab@mxB-1:ceB-1> clear cli logical-system

Cleared default logical system

Log out of your assigned device using the exit command.

IN

lab@mxB-1> exit
mxB-1 (ttyu0)
login:

STOP

Tell your instructor that you have completed this lab.

Lab 840 Route Reflection and Internet Access (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

Route Reflection and Internet Access (Detailed) Lab 841

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 842 Route Reflection and Internet Access (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

Route Reflection and Internet Access (Detailed) Lab 843

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 844 Route Reflection and Internet Access (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

Route Reflection and Internet Access (Detailed) Lab 845

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 846 Route Reflection and Internet Access (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

Route Reflection and Internet Access (Detailed) Lab 847

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 848 Route Reflection and Internet Access (Detailed)

[Link]

Lab

N
LY

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

SE

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.

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

Load a baseline configuration for your router. This configuration includes your
baseline core configuration including OSPF and BGP. The baseline also
contains a logical router configuration that will act as your CE router for this
lab.

Configure a VPN routing and forwarding (VRF) table and OSPF routing between
your PE router and CE router and redistribute your CE routers static routes into
OSPF.

Configure a GRE tunnel to the remote PE router.

IN

TE
R

AL

[Link]

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.

GRE Tunnel Integration (Detailed) Lab 91

Junos MPLS and VPNs

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 a
baseline configuration and then configure MP-BGP and a route-distinguisher ID.
Note

N
LY

The instructor will tell you the nature of your

access and will provide you with the
necessary details to access your assigned
device.
Step 1.1

Ensure that you know to which device you are assigned. Check with your instructor if
necessary.

Step 1.2

SE

Consult the management network diagram, provided by your instructor, to determine

your devices management address.

Question: What is the management address

assigned to your station?

AL

Answer: The answer varies. The sample hostname

and IP address used in the output examples in this
lab are for mxB-1, which uses [Link] as its
management IP address. The actual management
subnet varies between delivery environments.

Step 1.3

IN

TE
R

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
mxB-1 using the Secure CRT program.

Lab 92 GRE Tunnel Integration (Detailed)

[Link]

Junos MPLS and VPNs

Step 1.4
Log in as user lab with the password supplied by your instructor. Enter
configuration mode and load the reset configuration file
jmv/[Link] and commit.
mxB-1 (ttyp0)

--- JUNOS 12.3R2.5 built 2013-03-22 [Link] UTC

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# load override jmv/[Link]
load complete

SE

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

N
LY

login: lab
Password:

[edit]
lab@mxB-1#

Step 1.5

AL

Navigate to the [edit protocols] hierarchy. Issue the show command and
analyze the protocols that have been preconfigured for you.
[edit]
lab@mxB-1# edit protocols

IN

TE
R

[edit protocols]
lab@mxB-1# show
bgp {
group my-int-group {
type internal;
local-address [Link];
neighbor [Link];
}
}
ospf {
area [Link] {
interface ge-1/0/0.220;
interface ge-1/0/1.221;
interface lo0.0;
}
}
[edit protocols]
lab@mxB-1#

[Link]

GRE Tunnel Integration (Detailed) Lab 93

Junos MPLS and VPNs

Question: Which protocols have been preconfigured

for you?

Answer: OSPF and BGP have been preconfigured.

N
LY

Question: What is the name of the preconfigured

BGP peer group? Which router in the network is
configured as a member of the group?

Answer: The configured peer group is called

my-int-group. The group is configured to
establish an IBGP session with the remote PE.

SE

Step 1.6

[edit protocols]
lab@mxB-1# exit configuration-mode
Exiting configuration mode

AL

lab@mxB-1> show ospf neighbor

Address
Interface
[Link]
ge-1/0/0.220
[Link]
ge-1/0/1.221

Exit to operational mode and verify your Open Shortest Path First (OSPF) neighbor
relationships are up and operational.

ID
[Link]
[Link]

Pri
128
128

Dead
34
39

State
Full
Full

IN

TE
R

Question: What is the state of your PE routers OSPF

neighbors?

Answer: After a short time, the OSPF neighbors

should attain the Full state.

Step 1.7

Verify that your PE router has established an IBGP neighbor relationship with the
remote PE router.

lab@mxB-1> show bgp neighbor

Peer: [Link]+179 AS 65512 Local: [Link]+58282 AS 65512
Type: Internal
State: Established
Flags: <Sync>
Last State: OpenConfirm
Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress Refresh>
Local Address: [Link] Holdtime: 90 Preference: 170
Lab 94 GRE Tunnel Integration (Detailed)

[Link]

Junos MPLS and VPNs

SE

N
LY

Number of flaps: 0
Peer ID: [Link]
Local ID: [Link]
Active Holdtime: 90
Keepalive Interval: 30
Group index: 0
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)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
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 19
Sent 8
Checked 31
Input messages: Total 9219
Updates 4
Refreshes 0
Octets 175246
Output messages: Total 9218
Updates 2
Refreshes 0
Octets 175250
Output Queue[0]: 0

IN

TE
R

AL

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.
Question: What address family has been negotiated
for the BGP session? What type of routes can be
advertised between the two PE routers?

Answer: The PE routers have negotiated the

advertisement of inet-unicast routes. That
means that only IPv4 unicast routes can be
advertised between the two neighbors.

[Link]

GRE Tunnel Integration (Detailed) Lab 95

Junos MPLS and VPNs

Step 1.8
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 and enable family mpls on both of the
core-facing interfaces.
lab@mxB-1> configure
Entering configuration mode

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

[edit interfaces]
lab@mxB-1#

N
LY

[edit]
lab@mxB-1# edit interfaces

SE

Step 1.9

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

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

AL

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

Step 1.10

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

TE
R

To allow the exchange of Layer 3 VPN routes, enable the inet-vpn unicast network
layer reachability information (NLRI) for your PE routers BGP session with the
remote PE router. Make sure to also enable the exchange of standard unicast IP
version 4 (IPv4) routes as well.

IN

[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.11
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 routers loopback address. Commit
your configuration and exit out to operational mode.
[edit protocols]
lab@mxB-1# top edit routing-options
Lab 96 GRE Tunnel Integration (Detailed)

[Link]

Junos MPLS and VPNs

[edit routing-options]
lab@mxB-1# set route-distinguisher-id local-pe-loopback-address
[edit routing-options]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 1.12

N
LY

Using the show mpls interface command, verify that MPLS is configured
correctly on the core-facing interfaces.

lab@mxB-1> show mpls interface

Interface
State
Administrative groups (x: extended)
ge-1/0/0.220
Up
<none>
ge-1/0/1.221
Up
<none>

SE

Question: Can your core-facing interfaces now

support the transmission of MPLS packets?

Step 1.13

AL

Answer: The outputs of the two commands show

that the two interfaces can now support the
forwarding of MPLS packets.

Verify the state of your PE routers BGP neighbor relationship with the remote PE
router.

IN

TE
R

lab@mxB-1> show bgp neighbor remote-pe-address

Peer: [Link]+52281 AS 65512 Local: [Link]+179 AS 65512
Type: Internal
State: Established
Flags: <Sync>
Last State: OpenConfirm
Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress AddressFamily Rib-group Refresh>
Address families configured: inet-unicast inet-vpn-unicast
Local Address: [Link] Holdtime: 90 Preference: 170
Number of flaps: 1
Last flap event: RecvNotify
Error: 'Cease' Sent: 0 Recv: 1
Peer ID: [Link]
Local ID: [Link]
Active Holdtime: 90
Keepalive Interval: 30
Group index: 0
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)
Stale routes from peer are kept for: 300
Peer does not support Restarter functionality
NLRI that restart is negotiated for: inet-unicast inet-vpn-unicast
[Link]

GRE Tunnel Integration (Detailed) Lab 97

Junos MPLS and VPNs

SE

N
LY

NLRI of received end-of-rib markers: inet-unicast inet-vpn-unicast

NLRI of all end-of-rib markers sent: inet-unicast inet-vpn-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
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 15
Sent 15
Checked 15
Input messages: Total 4
Updates 2
Refreshes 0
Octets 139
Output messages: Total 3
Updates 0
Refreshes 0
Octets 158
Output Queue[0]: 0
Output Queue[1]: 0

AL

Question: Is the neighbor relationship in the

established state with the remote PE?

TE
R

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.

IN

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.

Lab 98 GRE Tunnel Integration (Detailed)

[Link]

Junos MPLS and VPNs

Part 2: Verifying CE Router Configuration

In this lab part, you will view the configuration for CE router (logical system) that was
preconfigured as part of the loaded starting configuration in Part 1 of this lab.
Please refer to the diagram labeled GRE Tunnel Integration Lab: Parts 2-8.
Step 2.1

lab@mxB-1> set cli logical-system local-ce-hostname

Logical system: ceB-1
lab@mxB-1:ceB-1>

Step 2.2

N
LY

Use the set cli logical-system command to place the CLI in the context of
the CE router logical system.

IN

TE
R

AL

SE

lab@mxB-1:ceB-1> show configuration

interfaces {
ge-1/1/4 {
unit 620 {
vlan-id 620;
family inet {
address [Link]/24;
}
}
}
lo0 {
unit 1 {
family inet {
address [Link]/32;
}
}
}
}
policy-options {
policy-statement exp-policy {
term 10 {
from protocol static;
then accept;
}
term 20 {
from protocol direct;
then accept;
}
}
}
routing-options {
static {
route [Link]/24 reject;
route [Link]/24 reject;
route [Link]/24 reject;
route [Link]/24 reject;

Issue the show configuration command to view the configuration of the CE

router.

[Link]

GRE Tunnel Integration (Detailed) Lab 99

Junos MPLS and VPNs

}
autonomous-system 65201;
}
lab@mxB-1:ceB-1>

N
LY

Question: What interfaces have been configured on

the CE router? According to the lab diagram, do they
have the appropriate IP addressing?

Answer: The CE router should have both the

loopback and ge-1/1/4 interface configured with
the appropriate addressing according to the lab
diagram.

SE

Question: What is configured under the

routing-options hierarchy? According to the
lab diagram, are these setting appropriate?

AL

Answer: Four static routes (next hop of reject) and

the CE routers autonomous system should be
configured under routing-options hierarchy.
These settings are appropriate.

IN

TE
R

Question: What is configured under the

policy-options hierarchy? What does this
policy do?

Answer: A policy called exp-policy is configured

under policy-options hierarchy. If applied as
an export policy, this policy will redistribute active
direct and static routes into the protocol to which it
is applied. It is currently not applied to any protocol
in the configuration.

Step 2.3
Use the ping utility to attempt to ping the local PE routers ge-1/0/4 interface.
lab@mxB-1:ceB-1> ping local-pe-address count 1
PING [Link] ([Link]): 56 data bytes
--- [Link] ping statistics --1 packets transmitted, 0 packets received, 100% packet loss
Lab 910 GRE Tunnel Integration (Detailed)

[Link]

Junos MPLS and VPNs

Question: Does your ping succeed? Why?

Answer: The pings do not succeed because the PE

routers ge-1/0/4 interface has not been
configured at this point in the lab.

Part 3: Configuring the PE to CE Interface

N
LY

Do not proceed until the remote team finishes Part 2.

STOP

In this lab part, you will configure the PE to CE interface. You will verify reachability
using the ping utility.

SE

Step 3.1

Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).

lab@mxB-1:ceB-1> clear cli logical-system

Cleared default logical system

Step 3.2

AL

lab@mxB-1>

TE
R

Enter into configuration mode and navigate to the [edit interfaces]

hierarchy. Configure the appropriate interface properties foe the PE routers
ge-1/0/4 interface as found on the network diagram. Commit your change and exit
to operational mode to verify reachability to the CE interface.
lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit interfaces

IN

[edit interfaces]
lab@mxB-1# set ge-1/0/4 vlan-tagging unit unit vlan-id vlan-id family inet
address address/24
[edit interfaces]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

[Link]

GRE Tunnel Integration (Detailed) Lab 911

Junos MPLS and VPNs

Step 3.3
Verify connectivity to the local CE device using the ping utility with a count value
of 3.
lab@mxB-1> ping local-ce-address count 3
PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=64 time=2.024 ms
64 bytes from [Link]: icmp_seq=1 ttl=64 time=0.591 ms
64 bytes from [Link]: icmp_seq=2 ttl=64 time=0.552 ms

N
LY

--- [Link] ping statistics --3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.552/1.056/2.024/0.685 ms

Question: Does your ping complete?

Part 4: Configuring a Layer 3 VPN Instance

SE

Answer: Yes, your ping should complete. If they do

not, please review your configuration and request
assistance from your instructor, if needed.

AL

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 4.1

TE
R

Enter into configuration mode and navigate to the [edit

routing-instances] hierarchy. Create a new VRF instance named vpn-pod.
For example, if you are configuring mxB-1, your VRF instance would be named
vpn-B.

lab@mxB-1> configure
Entering configuration mode

IN

[edit]
lab@mxB-1# edit routing-instances
[edit routing-instances]
lab@mxB-1# set vpn-pod instance-type vrf
[edit routing-instances]
lab@mxB-1#

Step 4.2
Navigate to the [edit routing-instances vpn-pod] hierarchy. Configure
your route target. As mentioned earlier, you will be using the vrf-target option.
Use the table below to determine the target community for your router.
Lab 912 GRE Tunnel Integration (Detailed)

[Link]

Junos MPLS and VPNs

Target Community

target:65512:1

target:65512:2

target:65512:3

target:65512:4

[edit routing-instances]
lab@mxB-1# edit vpn-pod
[edit routing-instances vpn-B]
lab@mxB-1# set vrf-target target-community

[edit routing-instances vpn-B]

lab@mxB-1#

N
LY

Pod

Step 4.3

SE

Include the CE-facing interface in your VRF instance.

[edit routing-instances vpn-B]
lab@mxB-1# set interface ge-1/0/[Link]

Step 4.4

AL

Review your recent configuration changes. When you are satisfied with these
changes, commit your configuration and exit to operational mode.

[edit routing-instances vpn-B]

lab@mxB-1# show
instance-type vrf;
interface ge-1/0/4.620;
vrf-target target:65512:2;

TE
R

[edit routing-instances vpn-B]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

IN

Step 4.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 [Link].0 command.

lab@mxB-1> show route table [Link].0

[Link].0: 8 destinations, 8 routes (2 active, 0 holddown, 6 hidden)
+ = Active Route, - = Last Active, * = Both
[Link]/24

[Link]

*[Direct/0] [Link]
> via ge-1/0/4.620
GRE Tunnel Integration (Detailed) Lab 913

Junos MPLS and VPNs

[Link]/32

*[Local/0] [Link]
Local via ge-1/0/4.620

Question: Do you see your local and direct routes?

N
LY

Answer: You should see a local and direct route for

the ge-1/0/4 interface. If you do not see these
routes, please review your configuration and
request assistance from your instructor, if needed.

Part 5: 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.

SE

Step 5.1

Use the set cli logical-system command to place the CLI in the context of
the CE router logical system.

lab@mxB-1> set cli logical-system local-ce-hostname

Logical system: ceB-1

AL

lab@mxB-1:ceB-1>

Step 5.2

TE
R

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 routers static routes into OSPF.
lab@mxB-1:ceB-1> configure
Entering configuration mode

[edit]
lab@mxB-1:ceB-1# edit policy-options

IN

[edit policy-options]
lab@mxB-1:ceB-1# set policy-statement statics term 10 from protocol static
[edit policy-options]
lab@mxB-1:ceB-1# set policy-statement statics term 10 then accept
[edit policy-options]
lab@mxB-1:ceB-1#

Step 5.3
Navigate to the [edit] hierarchy. Configure your CE routers loopback and
Ethernet interfaces as OSPF area [Link] interfaces.
Lab 914 GRE Tunnel Integration (Detailed)

[Link]

Junos MPLS and VPNs

[edit policy-options]
lab@mxB-1:ceB-1# top
[edit]
lab@mxB-1:ceB-1# set protocols ospf area 0 interface lo0.1
[edit]
lab@mxB-1:ceB-1# set protocols ospf area 0 interface ge-1/1/[Link]

Step 5.4

N
LY

[edit]
lab@mxB-1:ceB-1#

Apply the statics policy as an export policy to your CE routers OSPF instance.
Commit your configuration and exit to operational mode.

lab@mxB-1:ceB-1>

Step 5.5

SE

[edit]
lab@mxB-1:ceB-1# commit and-quit
commit complete
Exiting configuration mode

[edit]
lab@mxB-1:ceB-1# set protocols ospf export statics

AL

Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).

lab@mxB-1>

Step 5.6

lab@mxB-1:ceB-1> clear cli logical-system

Cleared default logical system

TE
R

Enter configuration and navigate to the [edit routing-instances

vpn-pod] hierarchy. Configure your PE routers VRF interface in OSPF area [Link]
interface. Commit your configuration and exit to operational mode.

IN

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit routing-instances vpn-pod
[edit routing-instances vpn-B]
lab@mxB-1# set protocols ospf area 0 interface ge-1/0/[Link]

[edit routing-instances vpn-B]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>
[Link]

GRE Tunnel Integration (Detailed) Lab 915

Junos MPLS and VPNs

Step 5.7
Verify that the CE router and PE router have established an OSPF adjacency with
each other.
lab@mxB-1> show ospf neighbor instance vpn-pod
Address
Interface
State
[Link]
ge-1/0/4.620
Full

ID
[Link]

Pri
128

Dead
34

N
LY

Question: Has the CE router established an OSPF

adjacency with the local PE router?

Step 5.8

SE

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.

Verify that the static routes that are being redistributed by the CE router can be
found in the VRF table of the PE router.

lab@mxB-1> show route table vpn-pod

[Link]/32

TE
R

[Link]/24

*[Direct/0] [Link]
> via ge-1/0/4.620
*[Local/0] [Link]
Local via ge-1/0/4.620
*[OSPF/150] [Link], metric 0, tag
> to [Link] via ge-1/0/4.620
*[OSPF/150] [Link], metric 0, tag
> to [Link] via ge-1/0/4.620
*[OSPF/150] [Link], metric 0, tag
> to [Link] via ge-1/0/4.620
*[OSPF/150] [Link], metric 0, tag
> to [Link] via ge-1/0/4.620
*[OSPF/10] [Link], metric 1
> to [Link] via ge-1/0/4.620
*[OSPF/10] [Link], metric 1
MultiRecv

[Link]/24

AL

[Link].0: 14 destinations, 14 routes (8 active, 0 holddown, 6 hidden)

+ = Active Route, - = Last Active, * = Both

[Link]/24
[Link]/24

IN

[Link]/24

[Link]/32
[Link]/32

Lab 916 GRE Tunnel Integration (Detailed)

0
0
0
0

[Link]

Junos MPLS and VPNs

Question: Are the static routes from the local

CE router being received by your PE router as OSPF
routes?

N
LY

Answer: The PE router should have the received the

local CE routers static 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.
Step 5.9

Verify that you are advertising your OSPF routes to the remote PE router as BGP
routes.
lab@mxB-1> show route advertising-protocol bgp remote-pe-loopback-address

AL

SE

[Link].0: 14 destinations, 14 routes (8 active, 0 holddown, 6 hidden)

Prefix
Nexthop
MED
Lclpref
AS path
* [Link]/24
Self
100
I
* [Link]/24
Self
0
100
I
* [Link]/24
Self
0
100
I
* [Link]/24
Self
0
100
I
* [Link]/24
Self
0
100
I
* [Link]/32
Self
1
100
I

IN

TE
R

Question: What routes are being advertised to the

remote PE router?

Answer: You should see the PE-CE network, the four

CE static 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 5.10

Verify that you are receiving routes from the remote PE router.
lab@mxB-1> show route receive-protocol bgp remote-pe-loopback-address
inet.0: 39 destinations, 39 routes (39 active, 0 holddown, 0 hidden)
[Link].0: 14 destinations, 14 routes (8 active, 0 holddown, 6 hidden)

[Link]

GRE Tunnel Integration (Detailed) Lab 917

Junos MPLS and VPNs

[Link].0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)

mpls.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
bgp.l3vpn.0: 6 destinations, 6 routes (0 active, 0 holddown, 6 hidden)

N
LY

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.

SE

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 routers loopback in inet.3.

Step 5.11

Determine whether any hidden routes are being received from the remote PE router.

AL

lab@mxB-1> show route hidden

inet.0: 33 destinations, 33 routes (33 active, 0 holddown, 0 hidden)

[BGP/170] [Link], localpref 100, from [Link]

AS path: I, validation-state: unverified
Unusable
[BGP/170] [Link], MED 0, localpref 100, from [Link]
AS path: I, validation-state: unverified
Unusable
[BGP/170] [Link], MED 0, localpref 100, from [Link]
AS path: I, validation-state: unverified
Unusable
[BGP/170] [Link], MED 0, localpref 100, from [Link]
AS path: I, validation-state: unverified
Unusable
[BGP/170] [Link], MED 0, localpref 100, from [Link]
AS path: I, validation-state: unverified
Unusable
[BGP/170] [Link], MED 1, localpref 100, from [Link]
AS path: I, validation-state: unverified
Unusable

TE
R

[Link]/24

[Link].0: 14 destinations, 14 routes (8 active, 0 holddown, 6 hidden)

+ = Active Route, - = Last Active, * = Both

[Link]/24

IN

[Link]/24
[Link]/24
[Link]/24

[Link]/32

Lab 918 GRE Tunnel Integration (Detailed)

[Link]

Junos MPLS and VPNs

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

bgp.l3vpn.0: 6 destinations, 6 routes (0 active, 0 holddown, 6 hidden)
+ = Active Route, - = Last Active, * = Both

AL

SE

N
LY

[Link]:11:[Link]/24
[BGP/170] [Link], localpref 100, from [Link]
AS path: I, validation-state: unverified
Unusable
[Link]:11:[Link]/24
[BGP/170] [Link], MED 0, localpref 100, from [Link]
AS path: I, validation-state: unverified
Unusable
[Link]:11:[Link]/24
[BGP/170] [Link], MED 0, localpref 100, from [Link]
AS path: I, validation-state: unverified
Unusable
[Link]:11:[Link]/24
[BGP/170] [Link], MED 0, localpref 100, from [Link]
AS path: I, validation-state: unverified
Unusable
[Link]:11:[Link]/24
[BGP/170] [Link], MED 0, localpref 100, from [Link]
AS path: I, validation-state: unverified
Unusable
[Link]:11:[Link]/32
[BGP/170] [Link], MED 1, localpref 100, from [Link]
AS path: I, validation-state: unverified
Unusable

IN

TE
R

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
routers loopback exists in inet.3. Remember that
we have not yet configured an MPLS LSP which
would install the necessary route.

Part 6: Establishing a GRE Tunnel Between PE Routers

In this lab part, you will configure a GRE tunnel between the PE routers.
Step 6.1
Enter configuration mode and navigate to the [edit chassis] hierarchy. Enable
1 Gbps tunnel service on FPC 1/PIC 0.
[Link]

GRE Tunnel Integration (Detailed) Lab 919

Junos MPLS and VPNs

lab@mxB-1> configure
Entering configuration mode
[edit]
lab@mxB-1# edit chassis
[edit chassis]
lab@mxB-1# set fpc 1 pic 0 tunnel-services bandwidth 1g
[edit chassis]
lab@mxB-1#

N
LY

Step 6.2

SE

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

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 routers
loopback address. The interface should be configured to send packets destined to
the remote PE routers loopback address. Finally, enable forwarding of MPLS and
IPv4 traffic on the tunnel interface. Commit your configuration and exit to
operational mode.

[edit interfaces]
lab@mxB-1# set gr-1/0/10 unit 0 tunnel source local-pe-loopback-address

[edit interfaces]
lab@mxB-1# set gr-1/0/10 unit 0 tunnel destination remote-pe-loopback-address

AL

[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

TE
R

[edit interfaces]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

IN

Step 6.3

Verify that the GRE interface is up and functional.

lab@mxB-1> show interfaces gr-1/0/10 terse

Interface
Admin Link Proto
gr-1/0/10
up
up
gr-1/0/10.0
up
up
inet
mpls

Lab 920 GRE Tunnel Integration (Detailed)

Local

Remote

[Link]

Junos MPLS and VPNs

Question: Is the gr-1/0/10 interface in the up

state?

Part 7: Creating and Adding a Static Route to inet.3

N
LY

Answer: The tunnel interface should be in the up

state. If not, check your configuration and ask your
instructor for help, if needed.

In this lab part, you will configure a static route to the loopback of the remote PE
such that it is placed in the inet.3 routing table.
Step 7.1

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

lab@mxB-1> configure
Entering configuration mode

SE

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.

AL

[edit routing-options]
lab@mxB-1# set rib inet.3 static route remote-pe-loopback-address/32 next-hop
gr-1/0/10.0

TE
R

[edit routing-options]
lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 7.2

IN

Verify that the new static route exists in inet.3 and only inet.3.

lab@mxB-1> show route remote-pe-loopback-address

inet.0: 33 destinations, 33 routes (33 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
[Link]/32

*[OSPF/10] 6d [Link], metric 4

> to [Link] via ge-1/0/1.221
to [Link] via ge-1/0/0.220

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

+ = Active Route, - = Last Active, * = Both

[Link]

GRE Tunnel Integration (Detailed) Lab 921

Junos MPLS and VPNs

[Link]/32

*[Static/5] [Link]
> via gr-1/0/10.0

Question: In which routing table has the static route

been placed?

Step 7.3

N
LY

Answer: The route should only be in the inet.3

table. If not, check your configuration and ask your
instructor for help if needed.

lab@mxB-1> show route table [Link].0

Review the routes that are installed in your VRF table.

[Link]/24
[Link]/24

TE
R

[Link]/24

[Link]/24

AL

[Link]/32

*[Direct/0] [Link]
> via ge-1/0/4.620
*[Local/0] [Link]
Local via ge-1/0/4.620
*[BGP/170] [Link], localpref 100, from [Link]
AS path: I, validation-state: unverified
> via gr-1/0/10.0, Push 300064
*[OSPF/150] [Link], metric 0, tag 0
> to [Link] via ge-1/0/4.620
*[OSPF/150] [Link], metric 0, tag 0
> to [Link] via ge-1/0/4.620
*[OSPF/150] [Link], metric 0, tag 0
> to [Link] via ge-1/0/4.620
*[OSPF/150] [Link], metric 0, tag 0
> to [Link] via ge-1/0/4.620
*[BGP/170] [Link], MED 0, localpref 100, from [Link]
AS path: I, validation-state: unverified
> via gr-1/0/10.0, Push 300064
*[BGP/170] [Link], MED 0, localpref 100, from [Link]
AS path: I, validation-state: unverified
> via gr-1/0/10.0, Push 300064
*[BGP/170] [Link], MED 0, localpref 100, from [Link]
AS path: I, validation-state: unverified
> via gr-1/0/10.0, Push 300064
*[BGP/170] [Link], MED 0, localpref 100, from [Link]
AS path: I, validation-state: unverified
> via gr-1/0/10.0, Push 300064
*[OSPF/10] [Link], metric 1
> to [Link] via ge-1/0/4.620
*[BGP/170] [Link], MED 1, localpref 100, from [Link]
AS path: I, validation-state: unverified

[Link]/24

SE

[Link].0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

[Link]/24
[Link]/24

IN

[Link]/24
[Link]/24
[Link]/24

[Link]/32
[Link]/32

Lab 922 GRE Tunnel Integration (Detailed)

[Link]

Junos MPLS and VPNs

> via gr-1/0/10.0, Push 300064

*[OSPF/10] [Link], metric 1
MultiRecv

[Link]/32

Question: Do you see all the remote PE routes?

N
LY

Answer: Yes, you should see all the remote

PE routes.

Question: What is the next hop for the routes that

have been received from the remote PE router?

SE

Answer: The next hop should be the gr-1/0/10.0

interface.
Step 7.4

Use the set cli logical-system command to place the CLI in the context of
the CE router logical system.

lab@mxB-1:ceB-1>

Step 7.5

AL

lab@mxB-1> set cli logical-system local-ce-hostname

Logical system: ceB-1

TE
R

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 routers loopback address while
sourcing the packets from your local CE routers loopback address. You will send five
packets for this test. This task can be accomplished using the following command:
ping remote-ce-loopback source local-ce-loopback count 5 .

IN

lab@mxB-1:ceB-1> ping remote-ce-loopback source local-ce-loopback count 5

PING [Link] ([Link]): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
^C
--- [Link] ping statistics --5 packets transmitted, 0 packets received, 100% packet loss

[Link]

GRE Tunnel Integration (Detailed) Lab 923

Junos MPLS and VPNs

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.

N
LY

Step 7.6
Review the routes that are installed in the CE routers routing table.
lab@mxB-1:ceB-1> show route

[Link]/24
[Link]/24
[Link]/32

TE
R

[Link]/32

SE

[Link]/24

[Link]/24

AL

[Link]/32

*[Direct/0] 6d [Link]
> via ge-1/1/4.620
*[Local/0] 6d [Link]
Local via ge-1/1/4.620
*[Static/5] 6d [Link]
Reject
*[Static/5] 6d [Link]
Reject
*[Static/5] 6d [Link]
Reject
*[Static/5] 6d [Link]
Reject
*[Direct/0] 6d [Link]
> via lo0.1
*[OSPF/10] [Link], metric 1
MultiRecv

[Link]/24

inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

Question: Do you see all the remote routes?

IN

Answer: No, the remote routes should not exist in

the CE routers routing table.

Step 7.7

Review the LSAs that currently exist in the CE routers link state database.
lab@mxB-1:ceB-1> show ospf database
Area [Link]
Type
ID
Router
[Link]
Router *[Link]
Network *[Link]

Adv Rtr
[Link]
[Link]
[Link]

Lab 924 GRE Tunnel Integration (Detailed)

Seq
0x80000002
0x80000004
0x80000001

Age
1262
1261
1266

Opt
0x22
0x22
0x22

Cksum Len
0x278c 36
0xde98 48
0x46c5 32
[Link]

Junos MPLS and VPNs

OSPF AS SCOPE link state database

Type
ID
Adv Rtr
Extern *[Link]
[Link]
Extern *[Link]
[Link]
Extern *[Link]
[Link]
Extern *[Link]
[Link]

Seq
0x80000002
0x80000002
0x80000001
0x80000001

Age
712
222
1501
1501

Opt
0x22
0x22
0x22
0x22

Cksum Len
0xd99f 36
0xcea9 36
0xc5b2 36
0xbabc 36

N
LY

Question: Why do you think the remote networks

are not present in your CE routers link state
database?

Answer: This answer will vary by student.

SE

Question: How are the routes learned from the

remote PE routers? How are these routes
characterized in your PE routers VRF table? What
protocol is running on the PE/CE link?

AL

Answer: The routes from the remote PE router are

learned through BGP. The routes appear as BGP
routes in the PE routers routing table. OSPF is
running on the PE/CE link.

IN

TE
R

Question: Will the default OSPF export policy

advertise routes learned by BGP?

STOP

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.

Do not proceed until the remote team finishes Part 7.

Part 8: 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.

[Link]

GRE Tunnel Integration (Detailed) Lab 925

Junos MPLS and VPNs

Step 8.1
Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).
lab@mxB-1:ceB-1> clear cli logical-system
Cleared default logical system
lab@mxB-1>

Step 8.2

N
LY

Enter configuration mode and navigate to the [edit policy-options]

hierarchy. Create a policy named bgp-to-ospf that will be used to redistribute
BGP routes into OSPF.
lab@mxB-1> configure
Entering configuration mode

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

SE

[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

AL

Step 8.3

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

Navigate to [edit routing-instances vpn-pod] and apply the

bgp-to-ospf policy as an export policy to the VRFs OSPF instance. Commit your
configuration and exit to operational mode.

TE
R

[edit policy-options]
lab@mxB-1# top edit routing-instances vpn-pod
[edit routing-instances vpn-B]
lab@mxB-1# set protocols ospf export bgp-to-ospf

IN

[edit routing-instances vpn-B]

lab@mxB-1# commit and-quit
commit complete
Exiting configuration mode
lab@mxB-1>

Step 8.4
Use the set cli logical-system command to place the CLI in the context of
the CE router logical system.
lab@mxB-1> set cli logical-system local-ce-hostname
Logical system: ceB-1
lab@mxB-1:ceB-1>
Lab 926 GRE Tunnel Integration (Detailed)

[Link]

Junos MPLS and VPNs

Step 8.5
Review the LSAs that currently exist in the CE routers link state database.
lab@mxB-1:ceB-1> show ospf database
Age
86
1697
2197
86

Opt
0x22
0x22
0x22
0xa2

Cksum Len
0xfc9c 36
0xb0af 48
0x18dc 32
0xc75c 28

N
LY

Seq
0x8000001a
0x8000001b
0x80000018
0x80000001

Age
86
1197
697
197
2697
86
86
86
86

Seq
0x80000001
0x80000019
0x80000019
0x80000019
0x80000018
0x80000001
0x80000001
0x80000001
0x80000001

SE

Area [Link]
Type
ID
Adv Rtr
Router
[Link]
[Link]
Router *[Link]
[Link]
Network *[Link]
[Link]
Summary [Link]
[Link]
OSPF AS SCOPE link state database
Type
ID
Adv Rtr
Extern
[Link]
[Link]
Extern *[Link]
[Link]
Extern *[Link]
[Link]
Extern *[Link]
[Link]
Extern *[Link]
[Link]
Extern
[Link]
[Link]
Extern
[Link]
[Link]
Extern
[Link]
[Link]
Extern
[Link]
[Link]

Opt
0xa2
0x22
0x22
0x22
0x22
0xa2
0xa2
0xa2
0xa2

Cksum Len
0xbe7b 36
0xabb6 36
0xa0c0 36
0x95ca 36
0x8cd3 36
0x474d 36
0x3c57 36
0x3161 36
0x266b 36

AL

Question: Do any LSAs exist in the OSPF link state

database that represent the network from the
remote site? Why or why not?

IN

TE
R

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.
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 8.6
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 routers loopback address while
sourcing the packets from your local CE routers loopback address. You will send five
packets for this test. This task can be accomplished using the following command:
ping remote-ce-loopback source local-ce-loopback count 5 .
[Link]

GRE Tunnel Integration (Detailed) Lab 927

Junos MPLS and VPNs

lab@mxB-1:ceB-1> ping remote-ce-loopback source local-ce-loopback count 5

PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=62 time=0.881 ms
64 bytes from [Link]: icmp_seq=1 ttl=62 time=0.783 ms
64 bytes from [Link]: icmp_seq=2 ttl=62 time=0.701 ms
64 bytes from [Link]: icmp_seq=3 ttl=62 time=0.776 ms
64 bytes from [Link]: icmp_seq=4 ttl=62 time=0.790 ms
--- [Link] ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.701/0.786/0.881/0.057 ms

N
LY

Question: Do all your ping packets complete?

Answer: Yes, they should all complete. if they do not,

please review your configuration and request
assistance from your instructor, if needed.

SE

Step 8.7

Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).

lab@mxB-1>

Step 8.8

AL

lab@mxB-1:ceB-1> clear cli logical-system

Cleared default logical system

TE
R

lab@mxB-1> exit

Log out of your assigned device using the exit command.

mxB-1 (ttyu0)

IN

login:

STOP

Tell your instructor that you have completed this lab.

Lab 928 GRE Tunnel Integration (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

GRE Tunnel Integration (Detailed) Lab 929

Junos MPLS and VPNs

lab@mxB-1:ceB-1> ping remote-ce-loopback source local-ce-loopback count 5

PING [Link] ([Link]): 56 data bytes
64 bytes from [Link]: icmp_seq=0 ttl=62 time=0.881 ms
64 bytes from [Link]: icmp_seq=1 ttl=62 time=0.783 ms
64 bytes from [Link]: icmp_seq=2 ttl=62 time=0.701 ms
64 bytes from [Link]: icmp_seq=3 ttl=62 time=0.776 ms
64 bytes from [Link]: icmp_seq=4 ttl=62 time=0.790 ms
--- [Link] ping statistics --5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.701/0.786/0.881/0.057 ms

N
LY

Question: Do all your ping packets complete?

Answer: Yes, they should all complete. if they do not,

please review your configuration and request
assistance from your instructor, if needed.

SE

Step 8.7

Issue the clear cli logical-system to return to the CLI context of the
default routing instance (your PE router).

lab@mxB-1>

Step 8.8

AL

lab@mxB-1:ceB-1> clear cli logical-system

Cleared default logical system

TE
R

lab@mxB-1> exit

Log out of your assigned device using the exit command.

mxB-1 (ttyu0)

IN

login:

STOP

Tell your instructor that you have completed this lab.

Lab 928 GRE Tunnel Integration (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

GRE Tunnel Integration (Detailed) Lab 929

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 932 GRE Tunnel Integration (Detailed)

[Link]

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

[Link]

GRE Tunnel Integration (Detailed) Lab 933

IN

TE
R

AL

SE

N
LY

Junos MPLS and VPNs

Lab 934 GRE Tunnel Integration (Detailed)

[Link]