JUnlPe[

NETWORKS
Education Services

Junos Layer 3 VPNs

STUDENT GUIDE Revision V19A

Engineering
Simplicity

Education Services Courseware

Junos Layer 3 VPNs
V19A

Student Guide

Juniper University
un1Per NETWORKS Education Services
1133 Innovation Way
Sunnyvale, CA 94089 USA
408-745-2000
www.jun iper.net

Course Number: EDU-JUN-JL3V

This document is produced by Juniper Networks, Inc.
This document or any part t hereof may not be reproduced or t ransmitted in any f orm under penalty of law, without t he prior written permission of Juniper Networks Education
Services.
Juniper Netw orks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered t rademarks of Juniper Networks, Inc. in t he Unit ed States and other count ries. The
Juniper Networks Logo, the Ju nos logo, and JunosE are t ra demarks of Juniper Networks, Inc. All other t rademarks, service marks, registered t rademarks, or regist ered service
marks are t he property of t heir respective owners.
Junos Layer 3 VPNs Studen t Guide, Revision V19A
Copyright © 2020 Juniper Networks, Inc. All rights reserved.
Print ed in USA.
Revision History:
Revision 15.a- November 2016
Revision V-16.a- March 2017
Revision V19A-February 2020
The informat ion in t his document is current as of t he date listed above.
The informat ion in t his document has been carefully verif ied and is believed t o be accurat e for software Release 19.4R1.10 .
Juniper Networks assumes no responsibilities for any inaccuracies t hat may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special,
exemplary, incidental, or consequent ial damages resulting f rom any defect or omission in t his document, even if advised of the possibility of such damages.

Juniper Networks reserves t he right to change, modify, t ransfer, or otherwise revise t his publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known
t ime-related limitations through t he year 2038. However, the NTP application is known t o have some difficulty in t he year 2036.
SOFTWARE LICENSE
The terms and condit ions for using Juniper Networks software are described in t he software license provided with the software, or t o the extent applicable, in an agreement
executed between you and Juniper Net works, or Juniper Net works agent. By using Juniper Networks software, you indicat e that you understand and agree t o be bound by its
license t erms and condit ions. Generally speaking, the software license rest ricts t he manner in which you are permitted t o use t he Juniper Net works software, may contain
prohibitions against certain uses, and may state condit ions under which t he license is automat ically terminated. You should consult t he software license for further det ails.
 Contents

Chapter 1: Course Introduction ......................................................... 1-1

Chapter 2: MPLS VPNs . ... . ..... .. ... . ............ . ................... . . . .......... . .. 2-1
Overview of MPLS VPNs . . ..... . .... . ..... . ... .. .... .. ... . ..... .. .... .. ... ... ... . ... 2-3
Provider-Provisioned VPNs . ... ... ... . ..... .. ......... . ... . . . .............. . . . ... . .. 2-11

Chapter 3: Layer 3 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Layer 3 VPN Term inology . ..... . .... . ..... . .............. . ..... . ..... . .... . ..... . ... 3-3
VPN-1Pv4 Address Structure .. . . . ... . .......... . ..... . .... .. .... . ..... . .... . ..... . .. 3-10
Policy-Based Routing Information Exchange . . ... . ..... . .... . ..... . ..... . .... . ..... . ... 3-16
Traffic Forwarding ..... . .... . ..... . ... . ................ . . . ... . .......... . ..... . ... 3-28

Chapter 4: Basic Layer 3 VPN Configuration .............................................. 4-1

Preliminary Steps ........... . . . ... . .......... . ..... . .... .. .... . ..... . .... . ..... . ... 4-3
PE Router Configu ration . . ..... . .......... . ... . ..... . .... . ..... . ..... . .... . ..... . .. 4-10
Basic Layer 3 VPN Verifi cati on . .. .... . ..... . .............. . . . ... . .......... . ..... . .. 4-32
Lab: Layer 3 VPN with Static and BGP Routi ng .... . ..... . .................... . ..... . ... 4-52

Chapter 5: Layer 3 VPN Scaling and Internet Access ....................................... 5-1

Sea Iing Layer 3 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Public Int ernet Access Opt ions . .. .... . ..... . .............. . . . ... . .......... . ........ 5-26
Lab: Route Reflection and Internet Access ... . .... . ..... . ... . . . .............. . . . ...... 5-37

Chapter 6: Layer 3 VPNs-Advanced Topics . .............................................. 6-1

Exchanging Routes Between VRF Tables ... . .... . ..... . ..... . .................... . .... 6-3
Hub-and-Spoke Topologies ... . ..... . ..... . .... . ..... . .... . ..... . ..... . .......... . ... 6-9
Layer 3 VPN Cos Opt ions . .... .. .... . ..... . .............. . . . ... . .......... . ..... . .. 6-22
Layer 3 VPN and GRE Tunneling Integrat ion . . ... . .......... . ..... . ..... . .... . ..... . ... 6-29
Layer 3 VPN and IPsec Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-33
Layer 3 VPN Egress Protection . .. .... . ..... . .............. . . . ... . .......... . ..... . .. 6-36
Provider Edge Link Protection . ..... . ..... . .... . ..... . ..... . .......... . ... . ..... . ... 6-4 2
Seam Iess M PLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-.4 7
Lab: GRE Tunnels and Route Redistributi on . . .............. . . . ... . ..... . .... . ..... . ... 6-55

Chapter 7: lnterprovider VPNs . ......................................................... 7-1

Hiera rchical VPN Models . ..... . .... . ..... . .............. . ..... . ..... . .... . ..... . ... 7-3
Junos Support of Carrier-of-Carriers Model .............. . ... . . . .............. . ..... . ... 7-9
Junos Support of Carrier-of-Ca rriers VPN Applications ..... . ... . . . .............. . . . ... . .. 7-22
lnterprovider VPN Option C ... . ..... . ..... . .... . ..... . .... .. .... . ..... . ............. 7-35
Lab: Carrier-of-Carriers VPNs ....... . ... . . . .............. . . . ... . ..... . .... . ..... . ... 7-4 8

www.j uniper.net Contents • iii

 Chapter 8: Troubleshooting Layer 3 VPNs ............. . .................................. 8-1
Troubleshooting Overview .... . ..... .. .... . .... . ..... . ..... . .......... . ... . .......... 8-3
Verifying PE-CE Routing Protocols ... . .......... . ..... . .... .. .... . ..... . .... . ..... . ... 8-7
MPLS Transport and Label Distribution Protocols . ..... . .... . ..... . ..... . .... . ..... . ... 8-16
MP-BGP . .. .... . ..... . .... . ..... . ..... . .......... . ... . . . .............. . ..... . ... 8-19
The Forwarding Plane ....... . ..... . ..... . .... . .......... .. .... . ..... . .......... . .. 8-26
Troubleshooting MVPNs . . ..... . .............. . ..... . .... . ..... . ..... . .... . ..... . .. 8-29
Lab: Troubleshooting Layer 3 VPNs .. . ..... . .......... . ... . . . .............. . ..... . ... 8-37

Chapter 9: Multicast Review and Draft Rosen ................. . ........................... 9-1

Multicast VPN Overview . . ..... . .............. . ..... . .... . ........... . .... . ..... . ... 9-3
Distribution Modes .... . .... . ..... . ..... . .... . ......... . . . .............. . ..... . .... 9-8
Reverse Path Fo rwa rding . ................ . .............. . . . ... . ..... . .... . ........ 9-12
Internet Group Management Protocol . ..... . .... . ..... . .... . ..... . ..... . ............. 9-19
Draft Rosen Overview ....... . . . ... . ..... . .......... . .... .. .... . ..... . ............. 9-24
Draft Rosen Limitations ....... . .......... . ... . .......... . ..... . .......... . ..... . .. 9-40

Chapter 10: Next-Generation Multicast VPNs . ............................................. 10-1

Multicast VPN Overview . . ..... . .............. . ..... . .... . ........... . .... . ..... . .. 10-3
Next -Generation MVPN Operat ion ... . .......... . ..... . .... . ........... . .... . ..... . .. 10-8
Configu ration ... . ..... . .......... . ..... . .... . ..... . ... . ...................... . .. 10-31
Monitoring . . ... . .......... . ..... . ................ . .... .. .... . ..... . ............ 10-38
MVPN Int ernet Multicasting . . ................ . ..... . .... . ..... . ................ . .. 10-44
Lab: MVPNs . .............. . . . ... . ................ . .... .. .... . ..... . .... . ..... . . 10-53

Appendix A: Layer 3 VPN Egress Protection ................................................ A-1

Layer 3 VPN Egress Protection .. . .... . ..... . .............. . ..... . ................ . .... A-3

Appendix B: Lab Diagrams . .......... . .................................................. B-1

Lab Diagram : Network Management . . ..... . .... . ..... . ..... . .......... . .............. B-2
Lab Network Diagram ............. . ..... . .... . ..... . .... . ..... . ..... . .......... . ... B-2
Lab Network Diagram ............. . ................ . .... . ........... . .............. 8-3
Lab Network Diagram ....... . ..... . ..... . .......... . .... .. .... . ..... . .............. B-3
Lab Network Diagram: Advanced OSPF Opt ions - Part 4 . . .... . ........... . .... . ..... . ... B-4
Lab Network Diagram: Troub leshooting OSPF . .............. . ..... . ..... . .... . ..... . ... B-4
Lab Network Diagram: IS-IS Configu ration and Monitoring ..... . . . .............. . ......... B-5
Lab Network Diagram: Advanced IS-IS Configurat ion Options and Routing Policy .............. B-5
Lab Network Diagram: Configuring a Mult ilevel IS-IS Network . . . . ... . ................ . .... B-6
Lab Network Diagram: Troub leshooting IS-IS ..... . ..... . .... . ........... . .... . ..... . ... B-6

Acronym List ....................................................................... ACR-1

iv • Contents www.juniper.net
Course Overview

Th is three-day course is designed to provide students with MPLS-based Layer 3 virtual private network (VPN) knowledge
and configuration examples. The course includes an overview of MPLS Layer 3 VPN concepts, scaling Layer 3 VPNs,
Internet access, lnterprovider Layer 3 VPNs, and Multicast for Layer 3 VPNs. Th is course also covers Junos operating
system-specific implementations of Layer 3 VPNs.

The concepts are put into practice with a series of hands-on labs, which allow partic ipants to gain experience in
configuring and monitoring Layer 3 VPNs on Junos OS devices. These hands-on labs utilize Juniper Networks vMX Series
devices using the Ju nos OS Release 19.4R1.10 and are also applicable to other MX Series devices.

Course Level
Junos Layer 3 VPNs (JL3V) is an advanced-level course.

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

Prerequisites
The prerequisites for this course include the following:

• Intermediate-level networking knowledge and an understanding of OSPF, IS-IS, BGP, and Junos policy;

• Experience configuring MPLS label-switched paths using Ju nos;

• Introduction to the Junos Operating System (IJOS) course or equivalent;

• Junos Intermediate Routing (JI R) course or equivalent; and

• Junos MPLS Fundamentals (JMF) course or equ ivalent.

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

• Describe the value of MPLS VPNs .

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

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

• List the provider-provisioned MPLS VPN features supported by the Junos OS software .

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

• Describe the format of the BGP routing information, including VPN-1Pv4 addresses and route distinguishers .

• Describe the propagation of VPN routing information with in an AS .

• List the BGP design constraints to enable Layer 3 VPNs within a provider network .

• Explain the operation of the Layer 3 VPN data plane within a provider network.

• Create a routing instance, assign interfaces to a routing instance, create routes in a routing instance, and
import/export routes from a routing instance using route distingu ishers/route targets.

• Describe the purpose of BGP extended communities, configure extended BGP extended commun it ies, and
use BGP extended communities.

• List the steps necessary for proper operation of a PE-CE dynamic routing protocol.

• List the troubleshooting and monitoring techn iques for routing instances .

• Explain the difference between the bgp.13vpn table and the inet.O table of a routing instance .

• Monitor the operation of a CE-PE dynam ic routing protocol.

• Explain the operation of a PE multi-access interface in a Layer 3 VPN and list commands to modify that
behavior.

• Describe ways to support communication between sites attached to a common PE router .

www.juniper.net Course Overview • v

 • Provision and troubleshoot hub-and-spoke Layer 3 VPNs.

• Describe the flow of control traffic and data traffic in a hub-and-spoke Layer 3 VPN.

• Describe QoS mechanisms available in L3VPNs.

• Configure L3VPN over GR E tunnels.

• Describe the RFC 4364 VPN options.

• Describe the carrier-of-carriers model.

• Configure the carrier-of-carriers and "Option C" configuration.

• Describe the flow of control traffic and data traffic in a draft-rosen multicast VPN.

• Describe the configuration steps for establishing a d raft-rosen multicast VPN.

• Monitor and verify the operation of draft-rosen multicast VPNs.

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

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

• Monitor and verify the operation of next-generation multicast VPNs.

• Describe the flow of control traffic and data traffic when using MVPNs for Internet multicast.

• Describe the configuration steps for enabling Internet multicast using MVPNs.
• Monitor and verify the operation of MVPN Internet multicast.

vi • Course Overview www .juniper.net

Course Agenda

Day1
Chapter 1 : Course Introduction

Chapter 2 : MPLS VPNs

Chapter 3 : Layer 3 VPNs

Chapter 4 : Basic Layer 3 VPN Configuration

Lab 1: Layer 3 VPN with Static and BGP Routing

Chapter 5 : Layer 3 VPN Scaling and Internet Access

Lab 2: LOP over RSVP Tunnels and Public Internet Access

Day2
Chapter 6 : Layer 3 VPNs - Advanced Topics

Lab 3: GRE Tunnels and Ro ute Red istribution

Chapter 7 : lnterprovider Backbones for Layer 3 VPNs

Lab 4: Carrier-of-Carriers VPNs

Chapter 8 : Troubleshooting Layer 3 VPNs

Lab 5: Troubleshooting Layer 3 VPNs

Day3
Chapter 9 : Multicast Review and Draft Rosen

Chapter 10: Next-Generation Multicast VPNs

Lab 6: MVPNs

Appendix A: Layer 3 VPN Egress Protection

www.juniper.net Course Agenda • vii

 Document Conventions

CLI and GUI Text

Freq uently throughout this cou rse, we refer to text that appears in a command-line interface (CLI ) or a graphical user
interface (GU I). To make t he language of these documents easier to read, we distinguish GUI and CLI text f rom chapter
text according to the following table.

Style Description Usage Example

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

Cour i e r New Console text:

commi t comp l ete
• Screen captures

• Noncommand-related Exi t i ng co n figurati o n mode

syntax
GUI text elements:
Select Fi le > Open, and then click
• Menu names Configur at i on . con f inthe
Fi le name text box.
• Text fie ld entry

Input Text Versus Output Text

You will also f requently see cases where you must enter input text yo urself . Often t hese instances wi ll be shown in the
context of where yo u m ust enter them. We use bold style to distinguish text that is input versus text that is simply
displayed.

Style Description Usage Example

Normal CL I No distinguishing variant. Physical inte rf ace : f x pO ,

Enabled
Normal GUI
View configuration history by clic king
Con figurati o n > His t o r y .

CLI Input Text that you must enter. l ab@San Jose> sho w r o ute

GUI Input Select Fi l e > Save , and type

c o nfig. ini in the Fi len ame field.

Defined and Undefined Syntax Variables

Finally, this course distinguishes between regular text and syntax variables, and it also distinguishes between syntax
variables where the va lue is a lready assigned (defined variables) and syntax variables where you must assign the va lue
(undefined variab les) . Note that these styles can be combined with the input style as we ll.

Style Description Usage Example

CLI Va r iable Text where variable va lue is already pol icy my - pee r s
assigned.
GUI Va r iable Click my- peer s in the dia log.

CLI Undefi ned Text where t he variable's va lue is Type set p o l i c y policy-name.
the user's discretion or text where
ping 1 0 . 0 .x . y
the va riable's va lue as shown in
GUI Unde f i ned the lab guide might d iffer from the Select Fi le > Save, and type
value the user must input filename in the Fi l ename f ield .
according to the lab topology.

vi ii • Document Conventions www.juniper.net

Additional Information

Education Services Offerings

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

About This Publication

This course was developed and tested using the software release listed on the copyright page. Previous and later
versions of software might behave differently so you should always consu lt the documentation and re lease notes for the
version of code you are runn ing 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 train ing@juniper.net.

Technical Publications
You can print technical manuals and re lease notes directly f rom the Internet in a variety of formats:

• Go to http://www.juniper.net/techpubs/.
• Locate the specific software or hardware release and title you need, and choose the format in which you
want to view or print the document.
Documentation sets and CDs are avai lable thro ugh you r loca l Juniper Networks sales office or account representative .

Juniper Networks Support

For technica l support, contact Juniper Networks at http://www.juniper.net;customers/support/, or at 1-888-314-JTAC
(within the United States) or 408-7 45-212 1 (outside the United States).

www.j uniper.net Additional Information • ix

x • Additiona l Information www.juniper.net
 un1Pe[
NETWORKS
Education Services

Junos Layer 3 VPNs

Chapter 1: Course Introduction

Engineering Simplicity
Junos Layer 3 VPNs

Objectives

■ After successfully completing this content, you will be able to:

• Get to know one another
• Identify the objectives, prerequisites, facilities, and materials used
during this course
• Identify additional Education Services courses at Juniper Networks
• Describe the Juniper Networks Certification Program

C> 2020 Juniper Networks, Inc All Rights Reserved

We Will Discuss:
• Objectives and course content information;

• Additional Juniper Networks, Inc. courses; and

• The Juniper Networks Certification Program .

Chapter 1-2 • Course Introduction www.juniper.net

 Junos Layer 3 VPNs

Introductions

■ Before we get started ...

• What is your name?
• Where do you work?
• What is your primary role in your organization?
• What kind of network experience do you have?
• Are you certified on Juniper Networks?
• What is the most important thing for you to learn
in this training session?

C> 2020 Juniper Networks, Inc All Rights Reserved

Introductions
The slide asks several quest ions for you t o answer during c lass introductions.

www .j uniper.net Course Introduction • Chapter 1-3

Junos Layer 3 VPNs

Prerequisites

■ The prerequisites for this course are the following:

• Intermediate-level networking knowledge and an understanding of OSPF,
IS-IS, BGP, and Junes policy;
• Experience configuring MPLS label-switched paths using Junes;
• Introduction to the Junos Operating System (IJOS) course or equivalent;
• Junos Intermediate Routing (JIR) course or equivalent; and
• Junos MPLS Fundamentals (JMF) course or equivalent.

Q 2020 Juniper Networks, Inc All Rights Reserved Jun1Per

N(lWOPKS
4

Prerequisites
The slide lists the prerequ isites f or this course.

Chapter 1-4 • Course Introduction www.juniper.net

 Junos Layer 3 VPNs

Course Contents

■ Contents:
• Chapter 1: Course Introduction
• Chapter 2: MPLS VPNs
• Chapter 3: Layer 3 VPNs
• Chapter 4: Basic Layer 3 VPN Configuration
• Chapter 5: Layer 3 VPN Scaling and Internet Access
• Chapter 6: Layer 3 VPNs - Advanced Topics
• Chapter 7: lnterprovider Backbones for Layer 3 VPNs
• Chapter 8: Troubleshooting Layer 3 VPNs
• Chapter 9: Multicast Review and Draft Rosen
• Chapter 10: Next-Generation Multicast VPNs

Q 2020 Juniper Networks, Inc All Rights Reserved Jun1Per

N(l\\'OPl(S
5

Course Contents
The slide lists the topics we discuss in this course.

www .juniper.net Course Introduction • Chapter 1-5

Junos Layer 3 VPNs

Course Administration

■ The basics:
• Sign-in sheet
• Schedule
• Class times
• Breaks
• Lunch
• Break and restroom facilities
• Fire and safety procedures
• Communications
• Telephones and wireless devices
• Internet access

O 2020 Juniper Networ1<s, foe All Rights Resel'Jed.

General Course Administration

The slide documents genera l aspects of c lassroom administ ration .

Chapter 1-6 • Course Introduction www.juniper.net

 Junos Layer 3 VPNs

Education Materials
• Available materials for classroom-based
and instructor-led online classes:
• Lecture material
• Lab guide
• Lab equipment
• Self-paced online courses also available
• www.juniper.net/ondemand

Q 2020 Juniper Networks, Inc All Rights Reserved

Training and Study Materials

The slide describes Education Services materials that are available for reference both in the classroom and online.

www .juniper.net Course Introduction • Chapter 1-7

Junos Layer 3 VPNs

Additional Resources

■ For those who want more:

Resource Location
Junes Genius www.junosgenius.net

Juniper Open Learning openlearning.juniper.net

Juniper Networks Day One books www.juniper.net/books

Certification resources www.juniper.net/certification

Hardware and software technical Online: www.juniper.net/techpubs

documentation Portable libraries: www.juniper.net/techpubs/resources

Juniper Networks Technical Assistance Center www.jun iper.net/support/requesting-support.html

(JTAC)

C> 2020 Juniper Networks, Inc All Rights Reserved

Additional Resources
The slide provides links to additional resources available to assist you in the installation, configuration, and operation of
Juniper Networks products.

Chapter 1-8 • Course Introduction www.juniper.net

 Junos Layer 3 VPNs

Satisfaction Feedback

~
~
Class
r
"' ~
~
Feedback

►
~
~
.,>, ~
~

-
■

., ~

-- ~

~
I II I

i1

• To receive your certificate, you must complete the survey

• Either you will receive a survey to complete at the end of class ,
or we will e-mail it to you within two weeks
• Completed surveys help us serve you better!

C> 2020 Juniper Networks, Inc All Rights Reserved

Satisfaction Feedback
Juniper Networks uses an electronic survey system to col lect and analyze yo ur comments and feedback. Depending on the
class you are ta king, please complete the survey at t he end of the class, or be sure to look for an e-mail about two weeks
from class completion that directs you to complete an online survey form . (Be sure to provide us with you r current e-ma il
address.)

Submitting your feedback entit les you to a certificate of c lass completion. We thank you in advance for taking the time to
help us improve our educationa l offerings.

www .j uniper.net Course Introduction • Chapter 1-9

Junos Layer 3 VPNs

Certification

Juniper Networks Curriculum-Junos-Based .----,

Course
l_ ___ J In Development

Service Provider Routing & Switching Enterprise Routing & Switching Data Center Junos Security

JNCIE-SP JNCIE-DC

JNCIE-SP Self-Study Bundle JNCIE- ENT Self-Study Bundle JNCIE-DC Self-Study Bundle JNCIE-SEC Self-Study Bundle

JNCIP-SP JNCIP-ENT JNCIP-DC JNCIP-SEC

Advanced Ju nos Service Provider Advanced Junos Enterprise Switching (AJEX) Data Center Fabric with EVPN and Advanced Juniper Security (AJSEC)
Routing (AJSPR) VXLAN (ADCX)
Advanced Ju nos Enterprise Routing (AJER)
Ju nos Layer 3 VPNs (JL3V)

Ju nos Layer 2 VPNs (JL2V)

JNCIS-ENT

Ju nos MPLS Fundamentals (JMF) Junos Enterprise Switching (JEX) Juniper Security (JSEC)
Junos Service Provider Switching (JSPX) Junos Intermediate Routing (JIR)

Junos Intermediate Routing (JIR)

Introduction to the Junos Operating System (IJOS) Introduction to Juniper Security (IJSEC)

Networking Fundamentals

Note s: Information current as of February 2020. Course and exam information (length , availability, content, etc.) is subject to change; refer to www.iuniper.neUtraining for the most current information.

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Networks Education Services Curriculum

Juniper Networks Education Services can help ensure that you have the knowledge and skills to deploy and maintain
cost-effective, high-performance networks for both enterprise and service provider environments. We have expert training
staff with deep tec hn ical and industry knowledge, providing you with instructor-led hands-on courses in the classroom and
online, as well as convenient, self-paced eLearning courses. In addition to the courses shown on the sl ide, Education
Services offers training in automation, E-Series, firewall/ VPN, IDP, network design, QFabric, support, and wireless LAN.

Courses
Juniper Networks courses are available in the following formats:

• Classroom-based instructor-led techn ical courses;

• Online instructor-led technical courses;

• Self-paced on-demand train ing with labs;

• Hardware installation eLearning courses as we ll as technical eLearning courses;

• Learning bytes: Short, topic-specific, video-based lessons covering Juniper products and technologies.

Find the latest Education Services offerings covering a wide range of platforms at www.juniper.net/tra ining

Chapter 1-10 • Course Introduction www.juniper.net

 Junos Layer 3 VPNs

Juniper Networks Curriculum- Certification

Cloud, Automation & DevOps, Design Course

,-----
i_ __ _j In Planning

Cloud Automation and DevOps Design

Juniper Networks Certified Expert Cloud
(JNCIE-Cloud) , JNCDS-DC
I
JNCIE-Cloud Self-Study Bundle I
I
Juniper Networks Design-
·------------------------------------------------· Data Center (JND-DC)

Juniper Network s Juniper Networks l__________________:_~ .-~_:_____________J

Certified Professional Certified Professional Advanced Junos Platform Automation JNCDS-SP
Cloud (JNCIP-Cloud) Cloud (JNCIP-Cloud) and DevOps (AJAUT)
AppFormlx Network Automation In Network Automation In Juniper Networks Design-
Cloud Services the Enterprise Cloud the Service Provider Service Provider (JND-SP)
(AFCS) (NAEC) Cloud (NASPC)

Junos Platform Automation and DevOps

(JAUT) JNCDS-SEC
Juniper Networks Design-
Security (JND-SEC)
MPLS and Network Automation Using .... SD-WAN with
Contrail Controller (NACC) ..,,.. Contrail Service
Segment
------":---'--.c..--
--
Introduction to Junos Platform
Orchestration
Automation using
Northstar (NS)
Juniper Networks Certified
(SD-CSO)
Automation and DeVOJ>S (IJAUT)
-'-- JNCDA
Juniper Networks Design Fundamentals
(JNDF)
Associate Cloud (JNCIA-Cloud)
Juniper Cloud Fundamentals
(JCF)
Notes: See individual learning paths for full prerequisite course recommendations. Information current as of February 2020. Course and exam information (length, availability, content, etc .) is subject to
change; refer to www.juniper.neUtraining for the most current information.

C> 2020 Juniper Networks, Inc All Rights Reserved 11

Juniper Networks Certification Program

A Juniper Networks certification is the benchmark of skills and competence on Juniper Networks technologies.

www .j uniper.net Course Introduction • Chapter 1 - 11

Junos Layer 3 VPNs

Juniper Networks Certification Program

• Why earn a Juniper Networks certification?

• Juniper Networks certification makes you stand out
• Demonstrate your solid understanding of networking technologies
• Distinguish yourself and grow your career
• Capitalize on the promise of the New Network
• Develop and deploy the services you need
• Lead the way and increase your value
• Unique benefits for certified individuals

Education Services
CERTIFICATION PROGRAM

<O 2020 Juniper Nelwor1<s, foe All Rights ReseNed.

Juniper Networks Certification Program

A Juniper Networks certification is the benchmark of skills and competence on Juniper Networks technologies.

Chapter 1-12 • Course Introduction www.juniper.net

 Junos Layer 3 VPNs

Juniper Networks Certification Education Services

CERTIFICATION PROGRAM
Program Framework
Automation
• Data Center Security Cloud
· and DevOps
Design

.,
t::
JNCIE•
a.
)(
UJ C loud

-
Cl!
C
0
JNCIP-
"'8l
... C loud
-
0
CL

.!2
----:t•••••••·••••••• • 0 JNCIS-ENT

.!!! JNCIS•
.,
0
C loud
a.
(J)

$
.!!!
0
0
- •- •- - - - JNCIA-
1/1 C loud
"'
ct:

Service Provider Enterprise Data Junos Cloud Automation Data Center.

Routingand Routing and Center Securi1y andDevOps Service Provider.
Switching Switching Securify Design

Information as of February 2020. * In planning. Refer to www 1uniper net/cert1f1cat1on for the most current 1nformat1on.

C> 2020 Juniper Networ1<s, Inc All Rights Reserved.

Juniper Networks Certification Program Overview

The Juniper Networks Certification Program (JNCP) consists of multit iered tracks that enable participants to demonstrate
competence with Jun iper Networks technology through a combination of written proficiency exams and hands-on
configuration and troubleshooting exams. Successful candidates demonstrate a thorough understanding of Internet and
security technologies and Jun iper Networks platform configuration and troubleshooting skills.

The JNCP offers the fo llowing features:

• Mult iple tracks;

• Mult iple certification levels;

• Written proficiency exams; and

• Hands-on configuration and troubleshooting exams.

Each JNCP track has one to four certification levels- Associate-level, Specia list-level, Professional-level, and Expert-level. The
Associate-leve l, Specialist-level, and Professional-level exams are computer-based exams composed of multiple choice
questions administered at Pearson VU E testing centers worldwide.

Expert-level exams are composed of hands-on lab exercises administered at select Juniper Networks testing centers. Please
visit t he JNCP website at http://www.jun iper.net;certification for detailed exam information, exam pricing, and exam
registration .

www .j uniper.net Course Introduction • Chapter 1 - 13

Junos Layer 3 VPNs

Certification Preparation
Training and Study Resources
Juniper Networks Certification Program website www.juniper.net/certification

Education Services training classes www.juniper.net/trainingschedule

Juniper Networks documentation and white papers www.juniper.net/documentation

Community
J-Net http ://forums.juniper. net/t5/Training-Certification-
and/bd-p/Trai ni ng and Certification

Twitter @JuniperCertify

Linkedln Certification Group www.linkedin.com/groups/1878403/

C> 2020 Juniper Networks, Inc All Rights Reserved

Preparing and Studying

The slide lists some options for those interested in preparing for Juniper Networks certification.

Chapter 1-14 • Course Introduction www.juniper.net

 Junos Layer 3 VPNs

Junos Genius: Certification Preparation App

Junos Genius provides certification preparation resources
developed by Juniper technology experts covering automation, .,..,.. -
cloud, routing , switching, security, and more! Back to Cr•rt1f.c.1oon 1r,,r.;s > JNCP Prac

www.iunosgenius.net lets you:

24 Total
• Assess your skills with 65-item certification practice tests for Associate,
Specialist, and Professional-level exams
• View ongoing training opportunities, new content is regularly added
• Learn from topic-specific eLearning and Learning Bytes videos that help JNCIA,tunos (J~102): Pracuce Test
On•
1'307 VoNHf 65 Quewons
you become more proficient at managing your network
• Use any device: smartphone, tablet, desktop, laptop
• Access the platform at your convenience, anytime and anywhere
• View content offline - simply download and view when convenient
JNQA.(joud (JN0-2 10t Pra<IQ Tt::i,;t
"67 ~ I 65 Quei;tlCIM

C> 2020 Juniper Networks , Inc All Rights Reserved 15

1

Junos Genius
The Ju nos Genius mobile learning platform (www.junosgenius.net) helps you learn Juniper technologies and prepare for
Juniper certification exams on your sc hedule. An app for iOS and Android devices, along with laptops and desktops, Junos
Genius provides certification preparation resources, practice exams, and e-learning courses developed by experts in Juniper
tec hnology. Courses cover automation, routing, switching, security, and more.

www.j uniper.net Course Introduction • Chapter 1- 15

Junos Layer 3 VPNs

Find Us Online

J-n~ http://www.juniper.net/jnet

http://www.juniper.net/facebook

I http://www.juniper.net/youtube

http://www.juniper.net/twitter

C> 2020 Juniper Networks, Inc All Rights Reserved Jun1Per

N(l\\'OPKS
16

Find Us Online
The slide lists some on line resources to learn and share information about Juniper Networks.

Chapter 1-16 • Course Introduction www.juniper.net

 Junos Layer 3 VPNs

Questions

O 2020 Juniper Networks, lllC All Rights ReseNed.

Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you vo ice them now so that your
instructor can best address your needs during class.

www .juniper.net Course Introduction • Chapter 1- 17

Junos Layer 3 VPNs

Chapter 1-18 • Course Introduction www.juniper.net

 un1Pe[
NETWORKS
Education Services

Junos Layer 3 VPNs

Chapter 2: MPLS VPNs

Engineering Simplicity
Junos Layer 3 VPNs

Objectives

■ After successfully completing this content, you will be able to:

• Define the term virtual private network
• Describe the business drives for MPLS VPNs
• Describe the difference between provider-provisioned MPLS Layer 3 VPNs
and provider-provisioned MPLS Layer 2 VPNs and provide examples of each
• List some advantages for the use of MPLS Layer 3 VPNs and MPLS Layer 2
VPNs

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Onty
Jun1Per
.iETWOffKS
2

We Will Discuss:
• The purpose and features of M PLS virtual private networks (VPNs);

• The business drivers for use of MPLS VPNs;

• The principles of provider-provisioned MPLS Layer 3 VPNs, and MPLS Layer 2 VPNs; and

• Advantages and d isadvantages of MPLS Layer 3 VPNs and MPLS Layer 2 VPNs.

Chapter 2 - 2 • M PLS VPNs www.juniper.net

 Junos Layer 3 VPNs

Agenda: MPLS VPNs

➔ Overview of MPLS VPNs

■ Provider-Provisioned VPNs

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Joniperausaness use Only

Overview of MPLS VPNs

The slide lists the topics we will discuss. We wi ll discuss the highlighted topic first.

www .juniper.net MPLS VPNs • Chapter 2-3

Junos Layer 3 VPNs

What Is a VPN?

.... --
EBII II
_ __,

....
...
Shared Public Infrastructure
---------- -... Iii
Home

-- -
Corporate
Office Office

II
Branch Office
■ Virtual private network:
• A private network constructed over a shared infrastructure
• Virtual: Not a separate physical network
• Private: Separate addressing and routing
• Network: A collection of devices that communicate
• Constraints are key-restricted connectivity is the goal

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usiness Use Only

Virtual Private Network

A VPN is a private network that is constructed over a shared, public infrastructure such as Frame Relay, an Asynchronous
Transfer Mode (ATM) network, or the Internet. It is considered virtual because it does not require a separate physical
network, but instead it is a logical network, one of possibly many logical networks that use a single physical network. It is
considered a private network because a VPN can have its own separate addressing and routing scheme to interconnect
devices that must communicate.

A VPN is designed so that on ly devices intended to communicate with each other can do so. For instance, as shown on the
slide, a VPN can be the network infrastructure that provides communication between the corporate headquarters, branch
offices, mobile users, data centers, suppliers, and customers, while ensuring that unwanted devices cannot gain access to
this private network.

Chapter 2-4 • MPLS VPNs www.juniper.net

 Junos Layer 3 VPNs

Business Drivers for VPNs

■ Connectivity between geographically dispersed sites

• Topology requirements
• Full mesh versus partial mesh
• Bandwidth and CoS requirements
• Bandwidth requirements can vary greatly depending on application
• CoS similar to internal network
• Provisioning
• Move / Add / Changes
• Security
• Buy or build
• Use Service Provider network
- Routing requirements (outsource versus in-house)
• Build own MAN/WAN network
C/2020 Juniper Networks, Inc .All Rights ReseM!<I.
Jon1per8usiness Use Only

Business Drivers for VPNs

The main goal for VPNs is to provide connectivity between geograph ically dispersed sites. The connections between sites
have different requirements:

• Topology requ irements: Traditionally VPN solutions can provide full mesh or partial mesh (including hub and
spoke) connectivity. Fu ll mesh was typically more expensive and less scalable.

• Bandwidth and Cos requirements: Bandwidth requirements have changed over time from as little as 64Kb/ s to
10Gb/ s nowadays depending on application requirements. The CoS mechanisms are s imilar to internal
networks.

• Provisioning: Depending on the topology and technology, the provisioning of VPNs can vary greatly. It is
preferred not to have to provis ion every site when there are move/ add/ changes.

• Security: Security is a major concern for VPNs. MPLS VPNs are not inherently secure as they don't offer any
encryption like IPsec VPNs. The security offered by MPLS VPNs is primarily separation between different VPNs.

• Buy or build: When choosing a VPN there are two options, to build your own VPN or to buy the VPN from a
service provider. The routing requirements will determine the preference for Layer 2 VPN or Layer 3 VPN.

www.juniper.net MPLS VPNs • Chapter 2-5

Junos Layer 3 VPNs

LegacyVPNs

■ Legacy VPN Technologies

• Leased Ii nes
• X.25 I Frame Relay / ATM
• Dialup
■ Advantages of legacy VPNs
• Widely available
• Protocol independent (non-IP protocols supported)
■ Disadvantages of legacy VPNs
• Need for multiple separate networks at service provider
• Complex provisioning
• Limited bandwidth scalability

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Only

Legacy VPN Technologies

To connect multiple remote customer sites, legacy technologies like leased lines, X.25, Frame Relay, ATM, and dial-up (PSTN
/ ISDN) were popular at the end of the 1990s.

Advantages of Legacy VPNs

The big advantage of these legacy technologies was that these were read ily available in most places. Most of these
technologies supported any type of Layer 3 protocol providing customers flexibility to connect different applications across
the WAN network.

Disadvantages of Legacy VPNs

A service provider would provide each of these technologies using a separate network and typically a separate support team.
The provis ion ing for the different topo logies was complex (full-mesh, partial-mesh, hub-and-spoke). Although the
technologies were easily available they have major bandwidth limitations compared to more modern technologies like ADSL,
and Ethernet.

Chapter 2-6 • MPLS VPNs www.juniper.net

 Junos Layer 3 VPNs

Service Provider Business Drivers (1 of 2)

Frame Relay
Voice IP/Internet

MPLS
ATM core TDM

Layer 3 VPNs Layer 2 VPNs

Ethernet

■ Need for converged network infrastructure

• IP/MPLS network core
• Decouple edge technologies from core technologies
• Build once, sell many
• Single network to offer multiple services
C/2020 Juniper Networks, Inc .All R,ghlS Resenie<I.
Jon1per8usiness Use Only

Converged Network Infrastructure

In the early 2000's the need for a single infrastructure based on IP/MPLS core technologies arose. The core technologies
co uld now be sepa rated from the edge techno logies, which allowed for an easy transition of current legacy VPN customers.
For example, a service provider edge router can transport Frame Re lay f rames over t he IP/MPLS core, and removing the
need for a specific Frame Relay network.

Build Once, Sell Many

This s ingle core network can offer a multitude of services at the edge. From basic IP connectivity to VoIP/Video services. And
the legacy VPN customers can be migrated to MPLS VPNs (Layer 2 / Layer 3).

www .juniper.net MPLS VPNs • Chapter 2-7

Junos Layer 3 VPNs

Service Provider Business Drivers (2 of 2)

Frame Relay
Voice IP/Internet

MPLS
ATM core TOM

Layer 3 VPNs Layer 2 VPNs

Ethernet

Single management
and provisioning infrastructure

■ Benefits
• Flexible service offerings
• Lower CapEx / OpEx
• Simplify provisioning and management
C2020 Juniper Networks, Inc .All R,ghlS Resenie<I.
Jon1per8usiness Use Only

MPLS VPNs Benefits

The benefits for service providers are quite obvious as they allow f lexible service offerings to current and new customers. As
there is only the need for a single core infrastructure the CapEx/ OpEx are much lower. The new MPLS VPNs also enable
simpler provisioning and management.

One of the advantages of MPLS VPN offerings is that multiple services can be used even on a single physical network
connection. By using the f lexibl e-ethe rnet-se r vices encapsulation the Ju nos platforms can offer Layer 2 and
Layer 3 services on a single physical interface.

Chapter 2-8 • MPLS VPNs www.juniper.net

 Junos Layer 3 VPNs

Customer Business Drivers (1 of 2)

Site2 e CE Site2 $ cE
CP-VPN - wa PP-VPN

Site 1 PE

.__I---.> $--+-$
Site 1 Site 3
~ --
~- CE
- --- CE CE PE
IP/MPLS
SP Network
~eP CE

Site-to-site MPLS
VPN tunnels Provider-provisioned VPN

■ Customer benefits
• Lower operational costs
• Higher bandwidth offerings from service providers
• Easy transition from legacy VPNs
• Layer 2 VPNs offer very similar features
C/2020 Juniper Networks, Inc .All Rights Resenie<I.
Jon1per8usinessUse Only

Customer Benefits
The lower costs at the service provider result in lower prices for the cust omer offerings. Tec hnologies like ADSL and Ethernet
allow higher bandwidth connections, beyond what was possible with t raditiona l Customer-Provisioned VPNs.

For existing customers it is relatively easy to tra nsition to the new MPLS VPNs as they offer similar (or better) f eatures,
allowing a smooth migration path without the need of a redes ign.

www .j uniper.net MPLS VPNs • Chapter 2-9

Junos Layer 3 VPNs

Customer Business Drivers (2 of 2)

Site2 @ cE
IDP
PP-VPN

Site 1 PE Site 3
FW

CE
IP/MPLS
SP Network
~ eCE

NAT

MPLS
Provider-provisioned VPN

• Multiple services through single network connection

• Pick and choose per customer requirements
• Layer 3 connections allow additional service offerings by the provider
• Intrusion Protection/ Detection
• Stateful Firewall
• Network Address Translation
C 2020 Juniper Networks, Inc .All Rights Resenie<I.
Jon1per 8us1ness Use Only
Jun1Per
.iETWORKS
10

Multiple Services Through a Single Connection

Another important advantage of MPLS Layer-3 VPNs is the abi lity to provide multiple services such as Statefu l Firewall, NAT,
and IDP-IDS on the same connections, according to each specific customer needs.

This is attractive for service providers as it opens up new revenue generation possibilities. But it is also attractive to
customers, who can offload the complexity of operating these services to the provider and simultaneously achieve service
consistency and uniformity across all their sites.

Chapter 2-1 0 • MPLS VPNs www.ju n iper .net

 Junos Layer 3 VPNs

Agenda: MPLS VPNs

■ Overview of MPLS VPNs

➔ Provider-Provisioned VPNs

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Joniper8us1ness Use Onty
Jun1Per
.iETWOffKS
11

Provider-Provisioned VPNs
The slide lists the topic we will discuss next.

www .j uniper.net MPLS VPNs • Chapter 2 - 11

Junos Layer 3 VPNs

Provider-Provisioned VPNs
■ Provider-Provisioned VPN (PP-VPN):
• BGP/MPLS-based Layer 3 VPNs (RFC 4364)
• Circuit cross-connect (CCC)
• LOP Layer 2 circuits (RFC 444 7)
• VPWS
• BGP Layer 2 VPN (RFC 6624)

• VPLS
• FEC 129 BGP autodiscov eryforVPWS (RFC 6074)
i Site2

I PP-VPN I
• BGP signaled VPLS (RFC 4761 )
)-
~
PE
• LOP signaled VPLS (RFC 4762)
• EVPN (RFC 7432) c:~e~, CE
IP/MPLS
SP Network

• BGP MPLS-based Ethernet VPN

C/2020 Juniper Networks, Inc .All R,ghlS Resenie<I.

Jon1per8us1ness Use Onty
Jun1Per
~ETWORKS
12

Provider-Provisioned VPNs
The provider-provisioned VPNs are a category of VPNs that are mainly controlled by the service provider, on t heir PE rout ers.
Another category of VPNs are called customer-provisioned VPNs, which are controlled from the CPE devices, examples of this
cat egory are PPTP, L2TP, and IPsec VPNs.

The provider-provis ioned VPNs cover a range of different solutions. They differ in approach (Layer 2 versus Layer 3 ), topology
(point-to-point vs point-to-multipoint), and signa ling protocols (LOP versus BGP).

Here is the list of the different kind of provider-provisioned VPN technologies:

• BGP/MPLS-based Layer 3 VPNs (RFC4364).

• Layer 2 MPLS VPNs: Circuit-Cross Connect and LOP Layer 2 Circu its (RFC444 7).

• Virtual Private Wire Service: BGP Layer 2 VPN, (RFC 6624) and FEC 129 BGP Autodiscovery (RFC607 4 ).

• Virtual Private LAN Service: BGP signaled VPLS (RFC 4 761), and LOP signaled VPLS (RFC 4 762).

• Ethernet VPN: BGP MPLS-based Ethernet VPN (RFC 7 432).

Chapter 2-12 • MPLS VPNs www.juniper.net

 Junos Layer 3 VPNs

Provider-Provisioned VPNs: Layer 3 VPN

■ MPLS Layer 3 VPN characteristics

• Routing between provider edge (PE) and customer edge (CE) routers using
standard routing protocols
• The PE router becomes part of the customer routing domain
• PE routers manage VPN-specific routing tables, distribute routes to remote
sites

VPNA VPNA

e
CE
SP Network
Site 1 Site 2

VPNB
~
p VPNB

e
CE
e
CE
Site 1 Site 2

C/2020 Juniper Networks, Inc .All R,ghlS Resenie<J.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
13

MPLS Layer 3 VPN Characteristics

MPLS Layer 3 VPNs are an example of t he peer to peer model. Peer to peer means that the rout ing is bet ween the connected
peer routers of the service provider (PE) and the customer (CE). The service provider PE rout er becomes an active part of the
customer routing domain. For example the convergence with in the customer domain is now partially determined by t he PE
router convergence.

The service provider PE rout er is the workhorse in this solution. As multiple cust omers will connect to a specific PE, it wil l
need to keep the different customer routing information private by having mu ltiple VPN-specific routing tables. By separati ng
the customer route information, MPLS Layer 3 VPNs support overlapp ing address space between cust omers.

www .j uniper.net MPLS VPNs • Chapter 2 - 13

Junos Layer 3 VPNs

Provider-Provisioned VPNs: Layer 3 VPN

■ MPLS Layer 3 VPN routing

• Provider edge (PE) routers exchange VPN-specific routes using multi-protocol
BGP
• Either directly or using route-reflectors
• Service provider responsibilities
• Use of administrative policies to ensure each VPN's privacy

e~
VPNA VPNA

CE CE
Site 1 SP Network Site 2
'
VPNB

e .____·-.· --.e · · · ·.-

E···,. _ MP-BGP ,.. ....... VPNB

CE CE
Site 1 Route Reflector Site2

C/2020 Jun,perNetworks. Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
14

MPLS Layer 3 VPN Characteristics

The exchange of the customer routes across the IP/ MPLS core is done using Multiprotocol BGP (MP-BGP). MP-BGP delivers
great scalability and control for the route distribution of potential millions of customer routes. For even more sca lability, the
use of BGP route reflectors is supported.

The main role of the service provider is to ensure connectivity and privacy of the different customer VPNs. This is mainly
done by the use of administrative policies to control the exchange of route information.

Chapter 2-14 • MPLS VPNs www.juniper.net

 Junos Layer 3 VPNs

Layer 3 PP-VPNs: RFC 4364 (1 of 2)

■ Application: Outsource VPN
• PE router maintains VPN-specific forwarding tables for each of its directly
connected VPNs
• Conventional IP routing between CE and PE routers
• VPN routes distributed using MP-BGP
• Uses extended communities
• VPN traffic forwarded across provider backbone using MPLS

Site 1

Site 2

Site 3

C2020 Juniper Networks, Inc . All Rights Resenie<I.

Jon1per8usiness Use Only
Jun1Per
~ETWORKS
15

Outsourced VPNs
MPLS-based VPNs make it possible for a service provider to offer value-added services to new and existing customers using
its existing network infrastructure.

The Junos OS supports Layer 3 provider-provisioned VPNs based on RFC 4364. In th is model, the PE routers maintain
VPN-specific routing tables ca lled VPN route and forwarding (VRF) tables for each of their directly connected VPNs. To
populate these forward ing tables, the CE routers advertise routes to the PE routers using conventional routing protocols like
RIP, OSPF and EBGP.

The PE routers then advertise these routes to other PE routers with MP-BGP using extended communities to differentiate
traffic from different VPN sites. Traffic forwarded from one VPN site to another is tunneled across the service provider's
network using MPLS. The MPLS-based forwarding component allows support for overlapping address space and private
addressing.

www .juniper.net MPLS VPNs • Chapter 2 - 15

Junos Layer 3 VPNs

Layer 3 PP-VPNs: RFC 4364 (2 of 2)

■ LOP or RSVP is used to set up PE-to-PE LSPs

■ MP-BGP is used to distribute VPN-specific routing information
■ Constrain connectivity by route filtering
• Flexible, policy-based control mechanism

Service Provider Network

CE CE
Site 1 e:·v;;ss
·- •• J r-::- e V--RF!- I
••••••••
Site 3

--
CE (
LOP or RSVP
for LSP establishment •• •'"EB
: VRF : CE

MP-BGP
r
CE VRF
- to distribute VPN routes
1 CE
Site 3 ~-~R~~ • \......__ _ _ __.~~ ~
~ -VR
FL~
- I ~
Site 1
•.......... : PE

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usinessUse Only
Jun1Per
.iETWORKS
1s

Label Distribution Protocol for LSPs

Setting up and maintaining label-switched paths (LSPs) between PE rout ers requ ire a label distribution protocol. Options
include the LOP or RSVP.

MP-BGP Distributes VPN Information

MP-BGP is used to distribute information about the VPNs. These commun ications include routing and reachab ility
information as well as the MPLS labels that map traffic to a particular VPN forwarding table and interface.

Provider Constrains Connectivity by Route Filtering

To ensure that routing informat ion about a particu lar VPN is on ly made avai lable to sites participating in that VPN, the
provider must constrain advertisements using routing policy (for example, route filtering).

Chapter 2-16 • MPLS VPNs www.juniper.net

 Junos Layer 3 VPNs

Layer 3 PP-VPNs Advantages

• Subscriber can offload routing complexity to provider

• No need to build routing competency into their organizations
• Providers have new revenue opportunities
• Little impact on scalability as VPN routing information is maintained only on
PEs, not on al I backbone routers
Service Provider Network
CE CE _f'-r-...
J
Site 1
~ :••··•·--:PE
~ ;. V~~.
~
1 ~ e~~:.;-~
PE - - ~
Site 3
, --._

LOP or RSVP : VRF , CE

( for LSP establishment

MP-BGP
•• •• ' " '

to distribute VPN routes

__ CE~
Site 3 • \.
......._
_ _ _ __.~
~ ~
~ VRF L ~
- - I ~
Site 1 1

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per 8us1ness Use Only
Jun1Per
.iETWORKS
17

Advantages for the Subscriber

With Layer 3 provider-provisioned VPNs, the subscriber can offload its routing responsib ilities to the provider, thus allowing
the customer to focus on its core competencies.

Advantages for the Provider

The provider can offer a va lue-added (revenue producing) service to its customers using a sca lable IP-ce ntric-based
backbone techno logy.

www .juniper.net MPLS VPNs • Chapter 2- 17

Junos Layer 3 VPNs

Layer 3 PP-VPNs Limitations

■ Outsourcing moves administrative burden to provider

• Can be a substantial provisioning and maintenance burden
• Network management tools for adds, moves, and changes
■ Some customers prefer to maintain control of their routing
architecture
Service Provider Network

Site 1

IP/MPLS
Infrastructure

) CE
• \......__ _ _ ___.~~ ~
~ -VR
FL~
- I ~
Site 1

C2020 Juniper Networks, Inc . All Rights Resenie<I.

Jon1per8usinessUse Only
Jun1Per
~ETWORKS
1a

Limitations of Provider-Provisioned VPNs

Layer 3 provider-provis ioned VPNs do have some drawbacks. The configu ration and maintenance of an RFC 4364 solution
can represent a significant increase in the provider's administrative burden. This is especially true during situations where
adds, moves, and changes to the VPNs are required . The use of automat ed provisioning tools can simplify day-to-day
operations in the network greatly.

VPN provisioning mistakes can be costly, especially when considering that the provider cou ld become liable f or the security
of the customer's networks.

Resistance to Outsourced Routing

It might be diff icult to convince some customers to outsource their routing t o the provider. For t hese cust omers, a Layer 2
VPN can be an ideal fit, as it allows them to control all aspects of the ir routing.

Chapter 2-18 • MPLS VPNs www.juniper.net

 Junos Layer 3 VPNs

MPLS-Based Layer 2 PP-VPNs

■ Transport of Layer 2 frames over MPLS

• CCC
• LOP Layer 2 circuits (RFC 444 7)
• VPWS
• BGP Layer 2 VPNs (RFC 6624)
• FEC 129 BGP autodiscoveryforVPWS (RFC 6074)
• VPLS
• BGP VPLS (RFC 4761)
• LOP VPLS (RFC 4762)
• FEC 129 BGP autodiscovery for VPLS (RFC 6074)
• EVPN (RFC 7432)

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Onty
Jun1Per .iETWOffKS
19

Transport of Layer 2 Frames Over MPLS

The following pages discuss circuit cross-connect (CCC), BGP Layer 2 VPNs, LOP Layer 2 circuits, FEC 129 BGP autodiscovery
VPWS, BGP signa led VPLS, LOP signaled VPLS, and FEC 129 BGP autodiscovery protocol VPLS.

Point to point connections are provided by CCC, LOP Layer 2 circu its, and both virtual private w ire service (VPWS)
implementations.

Any to any connections are provided by VPLS and EVPN.

www .j uniper.net MPLS VPNs • Chapter 2-19

Junos Layer 3 VPNs

Provider-Provisioned VPNs: Layer 2

■ MPLS Layer 2 VPN characteristics

• Overlay model
• Service provider only provides virtual circuits to customer
- Different topologies are possible
- Overlapping circuit-ids are possible
• Routing occurs between local and remote CE routers
• Customer's routing is transparent to service provider
• Allows any type of protocol including non-IP
• Service provider responsibilities
• Creation of virtual circuits according to topology requirements
• Use of admin policies to ensure each VPN's privacy

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usiness Use Only

MPLS Layer 2 VPN Characteristics

MPLS Layer 2 VPNs are an example of the overlay model. The overlay model means that the customer routing is totally
transparent across the service provider. The routing is done between the customer's CE devices. Mu ltiple topo logies like
full-mesh, and hub-and-spoke are possible. By using separate connection tables re-use of the circuit-id 's is possible.

The Laye r 2 VPN connections allow any type of Layer 3 protocol so it is not limited to IP-only applications.

The exchange of the customer virtual circuits can be done by MP-BGP or by using LDP signaling.

The main role of the service provider is to ensure connectivity and privacy of the different customer VPNs. This is mainly
done by the use of administrative policies to control the exchange of virtual circuit information .

Chapter 2-20 • MPLS VPNs www.juniper.net

 Junos Layer 3 VPNs

Circuit Cross-Connect
■ Provides the foundation for MPLS-based Layer 2 VPNs
• Broad support of PE-CE interface types
• ATM, Frame Relay, VLAN, PPP, and HDLC
■ Service provider maintains LSPs between PE routers
• One LSP per virtual circuit being serviced
• Ingress PE maps each inbound PVC to a dedicated LSP
• Egress PE maps incoming LSP to outbound PVC
■ CE routes VPN traffic based on subnet/PVC mappings

Routing Table
In Out CCC Table Site 3
10/ 8 DLCI 600 DLCI 600 LSP 1 -+ ~ Network
DLCI 610 LSP 2
5·~0'8"~
~LC~I 20.0.0.0/8
20/8 DLCI 610
CE

C2020 Juniper Networks, Inc .All R,ghlS Resenie<I.

Jon1per8us1ness Use Only
Jun1Per
.iETWOffKS
21

CCC: The Foundation of Layer 2 VPNs

CCC provides t he foundation fo r MPLS-based Laye r 2 VPNs by providing support for the tunnel ing of Layer 2 frames over
MPLS LSPs. CCC supports a variety of Layer 2 protocols including ATM, Frame Relay, virtual LANs (VLANs), PPP, and
High-Speed Data Link Control (HDLC).

Provider Maintains LSP and Connection Mesh

The CCC application does not support label stacking. As a result, the provider must configure one LSP, per direction, per
virtual circuit being serviced. The provider must also define each connection by manually mapping loca l connection
identifiers to LSPs.

CE Maps Connections to Remote Sites

Customers route traffic based on subnet/permanent virtual connection (PVC) mappings, as they would with any conventional
Frame Relay, ATM, or private line solution.

www .juniper.net MPLS VPNs • Chapter 2- 21

Junos Layer 3 VPNs

Circuit Cross-Connect Drawbacks

■ List of CCC drawbacks includes:

• CE and PE router configuration
• Complex initial configuration
• Tedious configuration for adds, moves, and changes
• Interaction between service provider and customer required
• Each DLCI/PVC requires a dedicated set of LSPs
• Only appropriate for small numbers of individual private connections
• Interface types must be the same at all CE device locations
• TCC can be used for unlike interfaces

C2020 Juniper Networks, Inc . All Rights Resenie<I.

Jon1per8us1ness Use Onty

Circuit Cross-Connect Drawbacks

The following list details some of the drawbacks of CCC:

• CE and PE router configuration can be complex, especially during adds, moves, and c hanges. The customer
must coordinate with t he service provide r.

• Each data-link connection identifier (DLCl)/PVC requires a dedicated set of MPLS LSPs. There can be no sha ring
of the LSP when using CCC.

• CCC as a Layer 2 VPN sol ution is only appropriate for small numbers of individua l private connections.

Interface types must be the same at all CE device locations. For instance, if Frame Relay is used at one VPN s ite then Frame
Relay m ust be used at all other s ites . However, the Ju nos OS has a feature ca lled translationa l cross-connect (TCC) that can
be used when there are different interface types at the CE locations.

Chapter 2 - 22 • MPLS VPNs www.juniper.net

 Junos Layer 3 VPNs

LDP Layer 2 Circuits

■ Leverages experience with CCC and MPLS
■ Improved data plane scalability with Layer 2 VPNs
• Label stacking consolidates multiple DLCls, PVCs, or VLANs over a single
LSP
■ Must provision both ends of each circuit when adding a site using
LOP signaling
■ Routing for private network is CE to CE

Site 1 Site 2

C2020 Juniper Networl<s, Inc .All Rights ReseM!<I.

Jon1per8usinessUse Only
Jun1Per
~ETWORKS
23

Leverages Experience with CCC and MPLS

With LOP Layer 2 circuits, the point to point circuits are created using bidirectional MPLS LSPs, like CCC. However, instead of
mapping the LSPs to an interface on the PE routers, the LSPs are mapped to a VPN-specific forwarding table (simi lar to BGP
Layer 2 VPNs). This table then maps the data to a Layer 2 circuit. The LOP Layer 2 circuit approach also makes use of
stacked headers for improved scalability.

Data Plane Scalability

La bel stacking means that PE devices can use a single set of MPLS LSPs between them to support many VPNs. The LOP
Layer 2 circuit signaling approach does not support the auto-provisioning of Layer 2 connections, and it relies on LOP for
signa ling.

Manual Provisioning for Moves and Changes

The LOP Layer 2 circuit approach requires configuration on all PE routers involved in the VPN when moves, adds, and
changes occur. RFC 6024 support for MP-BGP-based signa ling and its automatic connection mapping features make it far
simpler to deploy and maintain a Layer 2 VPN service.

Routing for Private Network Is CE to CE

Because the provider delivers Layer 2 circuits to the customer, the routing for the customer's private network is entirely in
the hands of the customer.

www .juniper.net MPLS VPNs • Chapter 2- 23

Junos Layer 3 VPNs

VPWS: BGP Layer 2 VPNs

■ Leverages experience with CCC and MPLS

■ Scalable in data and control planes
• Data plane: Label stacking consolidates multiple DLCls, PVCs, or VLANs over
a single LSP
• Provisioning : BGP for autoconfiguration and signaling
■ Routing for private network is CE to CE

LCI 600 P IP/MPLS Network

e,. .
PE
DL-r:-:-:::-::-E:E Site 2

Site ••••• •• IBGP between PEs

LCl(3 RSVP or LDP for LSP signaling

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8usiness Use Only

Leverages Experience with CCC and MPLS

With BGP Layer 2 VPNs the point to point VPNs are created using bidirectiona l MPLS LSPs, s imilar to CCC. However, instead
of mapping the LSPs to an interface on the PE routers, the LSPs are automatically mapped to Layer 2 circuits. Data is
forwarded using a two-level label stack that permits the sharing of the LSP by numerous Layer 2 connections. The outer label
delivers the data across the core of the network from t he ingress PE router to the egress PE router. The egress PE router then
uses the inner label to map the Layer 2 data to a particular VPN-specific table.

Scalable in the Data and Control Planes

The use of label stacking improves scalability, as now multiple VPNs can share a single set of LSPs for the forwarding of
traffic. Also, by over-provisioning Layer 2 circuits on the PE device (described in a later chapter), adds and changes are
simplified, as only the new site's PE router requires configuration. Th is automatic connection to LSP mapping greatly
simplifies operations when compared to the CCC approach.

Routing Is CE to CE
Because the provider delivers Layer 2 circuits to the customer, the routing for the customer's private network is entirely in
the hands of the customer. From the perspective of the attached CE device, there is no operational difference between a
Frame Relay service, CCC, and a BGP Layer 2 VPN solution.

Chapter 2-24 • MPLS VPNs www.juniper.net

 Junos Layer 3 VPNs

VPWS: FEC 129 BGP autodiscovery

■ Very similar to BGP-based Layer 2 VPNs

■ Similar architecture, but different signaling plane
• MP-BGP (RFC 607 4) for autodiscovery and provisioning
• LOP for LSP signaling
■ Routing for private network is again CE to CE
\-,,,,. PE
e DLCl. ~05 Site 2
·
Site
Source~ ·······•e
CE DLCI 600 PE
~ __ .►.
OLCl610
IP/MPLS Network
IBGP between PEs
LOP for LSP signaling

~
....._....;:.....__ _ _. ,~
DLCl608aCE
Site 3
-......____.,

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Only

Leverages Experience with CCC and MPLS

As with BGP Layer 2 VPNs and LDP Layer 2 circuits, frames are forwarded using a two-level label stack that permits the
sharing of the LSP by numerous Layer 2 connections. The outer label delivers the data across the core of the network from
the ingress PE router to the egress PE router. The egress PE router then uses the inner label to map the Layer 2 data to a
particular VPN-specific table .

Scalable in the Data and Control Planes

Label stacking means that PE devices can use a single set of MPLS LSPs between them to support many VPNs. The FEC 129
BGP autodiscovery (RFC 607 4) uses BGP to autodiscover the remote PEs, and after discovery LDP signaling is used to
exchange the VPN label (FEC 129).

Manual Provisioning for Moves and Changes

The LDP Layer 2 circuit approach normally requ ires manual configuration on all PE routers involved in the VPN when moves,
adds, and changes occur. RFC 607 4 allows for autodiscovery using BGP to simplify provisioning of move/ add/ changes.

Routing for Private Network Is CE to CE

Because the provider delivers Layer 2 circu its to the customer, the routing for the customer's private network is entirely in
the hands of the customer.

www .j uniper.net MPLS VPNs • Chapter 2 - 25

Junos Layer 3 VPNs

Virtual Private LAN Service

■ To the customer in a VPLS environment, the provider' s network
appears to function as a single LAN segment
• Acts similarly to a learning bridge
■ Administrator does not need to map local circuit IDs to remote sites
• PE device learns MAC address from received Layer 2 frames
• MAC addresses are dynamically mapped to outbound MPLS LSPs, interfaces,
or both
I CE
,_ - ,- - - - - - - Site 3

Site 2

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8usinessUse Only
Jun1Per
~ETWORKS
2s

Provider's Network Appear to Be a Single LAN Segment

A newer any to any service that can be provided to the customer is VPLS. To the cust omer, VPLS appears to be a single LAN
segment. In fact, it appears to act similarly to a learning bridge. That is, when t he destination media access contro l (MAC)
address is not known, an Ethernet frame is sent t o all remote sites. If the destination MAC address is known, it is sent
directly to the site t hat owns it. The Ju nos OS supports three variations of VPLS, BGP signa led VPLS, LDP signa led VPLS and
FEC 1 29 BGP autodiscovery VPLS.

No Need to Map Local Circuit to Remote Sites

In VPLS, PE devices learn MAC addresses from the frames that they receive . They use the source and destination addresses
to dynamically create a forwarding table (vp n - name . v pl s ) for Ethernet frames . Based on this table, frames are forwarded
out of directly connect ed interfaces or over an MPLS LSP across the provider core. This behavior allows an adm inistrator to
not have to manually map Layer 2 c ircuits to remote sit es.

Chapter 2 - 26 • MPLS VPNs www.juniper.net

 Junos Layer 3 VPNs

Ethernet VPN
■ As with VPLS, the VPN appears to customers as a single LAN
segment
• EVPN improves on VPLS in a number of ways
• A more complex BGP-based control plane helps achieve overall better forwarding
performance (less flooding)
• Support for advanced features
• Unlike VPLS, PE devices learn remote IP/MAC address through MP-BGP

Site 3
PE P I
--Cl)-11~ -1
I
I
Site 2

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per 8us1ness Use Onty

Ethernet VPN
The latest Layer 2 service that can be provided to customers is Ethernet VPN (EVPN). Exactly as in VPLS, EVPNs appear to
customers as a s ingle LAN, which all CEs are connected.

EVPNs address some of the limitation of VPLS and provide a number of advanced features wh ile improving forwarding
performance by reducing the need of flooding traffic. Today, EVPNs are becoming the preferred solution for data center
interconnect (DCI), i.e. to provide any-to-any Layer 2 and Layer 3 connectivity between data centers.

One of the differences between VPLS and EVPN is a relative ly more complex control plane based on MP-BGP, which (un like
VPLS) is also used for advertising MAC addresses.

www .juniper.net MPLS VPNs • Chapter 2-27

Junos Layer 3 VPNs

Ethernet VPNs: Advantages

■ EVPN enhancements compared to VPLS
• Greater scalability
• Control plane for IP/MAC address learning instead of flooding
• Integrated Layer 2 and Layer 3 services
• Optimal intra-subnet and inter-subnet traffic flows
• Active/Active multi-homing support
• Improves load-sharing and high availability
• VM mobility support
• Improved MAC move detection
• Optimal default gateway usage
• Overlay encapsulation support
• VXLAN encapsulation

C2020 Jun,perNetworl<s, Inc .All Rights Resenie<I.

Jon1per8usiness Use Only
Jun1Per
.iETWOffKS
2a

Ethernet VPNs: Advantages

The goal of Et hernet VPN is to remove some of the current limitations of VPLS.

• Great er scalab ility: Control plane for IP/ MAC address learning instead of data plane f looding.

• Int egrated Layer 2 and Layer 3 services : Optimal intra-subnet, and int er-subnet t raffic f lows.

• Active/ Active mult i-homing support: Improves load-sharing and high availability.

• Virtual Machine (VM ) mobility support: Improved MAC move detection and optimal default gateway usage.

• Overlay encapsulation support: VXLAN encapsulation.

Chapter 2 - 28 • MPLS VPNs www.juniper.net

 Junos Layer 3 VPNs

MPLS-Based Layer 2 VPNs: Advantages

■ Subscriber:
• Can outsource circuits
• Maintains control of routing
• Uses any protocol
• Ideal for data center interconnects (DCI)
■ Provider:
• Complements RFC 4364
• Operates over the same core, using the same outer LSP
• Can collapse Layer 2 VPNs (Frame Relay, ATM, and VLANs) onto a single
IP/MPLS infrastructure
• Reduces the number of LSPs with label stacking compared with CCC
• Simplifies adds, moves, and changes with automatic provisioning when using
BGP Layer 2 VPNs

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
.iETWORKS
29

Subscriber Advantages
With Layer 2 VPNs the customer can outsource Layer 2 circuits to the provider over an existing Internet access circu it while
maintaining contro l over the routing of its traffic. Also, because the provider is encapsulating Layer 2 traffic for transport
using MPLS, the customer can use any Layer 3 protocol- not on ly IP-based protocols.

Provider Advantages
Layer 2 and Layer 3 VPNs can coexist by using the same MPLS transport and signa ling protocols. The provider can now se ll
Frame Relay or ATM circuits to different customers using its existing IP core. Automatic provisioning of Layer 2 circuits
simplifies the processes of adds, moves, and changes. Also, the use of label stacking greatly improves efficiency and
sea la bi Iity.

www .j uniper.net M PLS VPNs • Chapter 2- 29

Junos Layer 3 VPNs

MPLS-Based Layer 2 VPNs: Issues

■ Circuit type (ATM/Frame RelayNLAN) to each VPN site must be

uniform
• TCC can be used when circuits connecting sites differ
■ Removes a provider revenue opportunity
• Provider no longer adding value by managing routing over the backbone
■ Customer must have routing expertise

C/2020 Jun,perNetworl<s, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Only
Jun1Per
.iETWOffKS
30

Circuit Types Must Be the Same

The circuit type (ATM/ Frame Relay/ VLAN) to each VPN site must be uniform. TCC can be used to connect sites with different
circuit types. TCC removes the Layer 2 frame and rep laces it with a new one used for the outgoing circuit.

Removes Revenue Opportunity

Because the customer is responsible for the routing of traffic between its sites, the provider can no longer add va lue by
providing outsourced routing services, as is the case with Layer 3 VPNs.

Customer Routing Experience

The customer must have routing expertise and the necessary staffing to configure and ma intain its backbone routing.

Chapter 2-30 • MPLS VPNs www.juniper.net

 Junos Layer 3 VPNs

Summary

■ In this content, we:

• Defined the term virtual private network
• Discussed the business drivers for MPLS VPNs
• Explained the difference between provider-provisioned MPLS Layer 3 VPNs
and provider-provisioned MPLS Layer 2 VPNs and provided a few examples
of each
• Listed the advantages for use of MPLS Layer 2 VPNs and MPLS Layer 3
VPNs

C2020 Jun,perNetworl<s, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Onty
Jun1Per
.iETWOffKS
31

We Discussed:
• The purpose and features of MPLS VPNs;

• The business drivers for use of MPLS VPNs;

• The principles of provider-provisioned MPLS Layer 3 VPNs, and MPLS Layer 2 VPNs; and

• Advantages and d isadvantages of MPLS Layer 3 VPNs and MPLS Layer 2 VPNs.

www .juniper.net MPLS VPNs • Chapter 2-31

Junos Layer 3 VPNs

Review Questions

1. What is a virtual private network?

2. What are some of the business drivers for MPLS VPNs?
3. What are the differences between a Layer 2 VPN and a Layer 3
VPN?

~2020 Juniper Networlcs, Inc .All Rights Reserve<!.

Juniper8us1ness Use Onty
Jun1Per
~ETWORl(S
32

Review Questions
1.

2.

3.

Chapter 2-32 • MPLS VPNs www.juniper.net

 Junos Layer 3 VPNs

Answers to Review Questions

1.
A VPN is a private network that is constructed over a shared, public infrastructure such as Frame Re lay, an ATM network, or
the Internet.

2.
Business drivers for the deployment of MPLS VPNs are lower CapEx/ OpEx, flexib le service offerings, easy transition from
legacy VPNs, and higher bandwidth offerings.

3.
The first and most notable difference is with a Layer 2 VPN solution, the backbone routing is the respons ibility of the
customer. With a Layer 3 VPN solution, the backbone routing is handled by the provider. Another difference is that with a
Layer 2 VPN solution, non-IP traffic can be passed from s ite to site. With a Layer 3 VPN solution, the traffic has to be IP.

www .juniper.net MPLS VPNs • Chapter 2 - 33

Junos Layer 3 VPNs

Chapter 2-34 • MPLS VPNs www.juniper.net

 un1Pe[
NETWORKS
Education Services

Junos Layer 3 VPNs

Chapter 3: Layer 3 VPNs

Engineering Simplicity
Ju nos Layer 3 VPNs

Objectives

■ After successfully completing this content, you will be able to:

• Define the roles of P, PE, and CE routers
• Describe the format of VPN-1Pv4 addresses
• Explain the role of the route distinguisher
• Describe the flow of RFC 4364 control information
• Explain the operation of the RFC 4364 forwarding plane

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
.iETWOffKS
2

We Will Discuss:
• The roles of provider (P), provider edge (PE), and customer edge (CE) routers;

• Virtual private network (VPN ) IP version 4 (1Pv4) address formats;

• Route distinguisher use and fo rmats;

• RFC 4364 control flow; and

• RFC 4364 data flow .

Chapter 3-2 • Layer 3 VPNs www.j uniper.net

 Junos Layer 3 VPNs

Agenda: Layer 3 VPNs

➔ Layer 3 VPN Terminology

■ VPN-1Pv4 Address Structure
■ Operational Characteristics
• Policy-Based Routing Information Exchange
• Traffic Forwarding

~ 2020 Juniper Networks, Inc . All Rights Resenie<I.

Juniper Business Use Only
Jun1Per
NETWORKS
3

Layer 3 VPN Terminology

The slide lists the topics we will discuss. We wi ll discuss the highlighted topic first.

www .j uniper.net Layer 3 VPNs • Chapter 3 - 3

Junos Layer 3 VPNs

Customer Edge Routers

■ CE routers:
• Located at customer premises
• Provide access to the service provider network
• Can use any access technology or routing protocol for the CE/PE connection

Customer Edge

PE

VPNA E
~-~ VPNA

~p
~
PE CE

VPN B
- VPN B

C 2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per 8us1ness Use Only

Customer Edge Routers

CE routers are located at the customer location and provide access to the provider-provisioned VPN (PP-VPN) service . CE
routers can interface to provider PE routers using virtually any Laye r 2 techno logy and routing protocol.

Chapter 3-4 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Provider Edge Routers

■ PE routers:
• Maintain VPN-specific forwarding tables
• Exchange VPN routing information with other PE routers using BGP
• Use MPLS LSPs to forward VPN traffic

Provider Edge

PE
p p e
VPNA ICE
~ '
~e -~ - VPNA

~
PE "' CE

VPN B e VPN B

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Only

Provider Edge Routers

PE routers are located at the edge of the provider's network. They interface to the CE routers on one s ide and to the
provider's core routers on the other. PE routers maintain site-specific VPN route and forward ing (VRF) tables. The PE and CE
routers function as routing peers, with the PE router terminating the routing exchange between customer sites and the
provider's core.

Routes learned from the CE routers (and stored in the PE router's VRF table) are sent to remote PE routers using
Multiprotocol Border Gateway Protocol (MP-BGP).

PE routers use MPLS LSPs when forwarding customer VPN traffic between sites. LSP tunnels in the provider's network
separate VPN traffic in the same fashion as PVCs in a legacy ATM or Frame Relay network.

www .j uniper.net Layer 3 VPNs • Chapter 3-5

Junos Layer 3 VPNs

Provider Routers

■ P routers:
• Forward VPN data transparently over established LSPs
• Do not maintain VPN-specific routing information

Provider Routers

'"-- PE

VPNA
~
--.....__,
~ - e --~p~------~ ~-,E+3_____,
~
VPNA

VPN B CE VPN B

C/2020 Juniper Networl<s, lnc ,AII Rights ReseM!<I,

Jon1per8us1ness Use Only

Provider Routers
Provider (P) routers are located in the provider's core. These routers do not carry VPN customer routes, nor do they interface
in the VPN control and s ignaling planes. This is a key aspect of the RFC 4 364 scalability model; only PE routers are aware of
VPN customer routes, and no single PE router must hold all VPN customer state information .

P routers are involved in the VPN forwarding plane where they act as label-switching routers (LSRs) perform ing label
swapping (and popping) operations.

Chapter 3 - 6 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

VPN Sites

■ A site is a collection of machines that can communicate without

traversing the service provider backbone
■ Each VPN site is mapped to a PE router interface
• Routing information is stored in different tables for each site
VPN Site

PE

p p e
VPN A
~ ~e -0 ~ ',~~
'
VPNA

· / 0 PE ~ CE

VPN B ~ E e VPN B

C/ 2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per 8usiness Use Only

VPN Sites
A VPN site is a collect ion of devices that can communicate with each other without the need to transit the provider's
backbone. A site can range from a single location with one router to a network consisting of many geographically diverse
routers.

Mapped to a VRF
Each VPN site is attached to at least one PE router and can be dual-homed with multiple connections to different PE routers.
Each site is associated with a site-specific VRF tab le in the PE routers. It is here that the PE router maintains the routes
specific to that site and, based on policy, the routes for remote sites to which t his location can commun icate.

www .j uniper.net Layer 3 VPNs • Chapter 3- 7

Junos Layer 3 VPNs

VPN Routing and Forwarding Tables

A VRF is c reated
VPNA for each site
Site 1 connected to the PE
VPN B
Site 2
OSPF ~ ITT.;
Routing ~ -- ,!! LI
Static - ~~-- CE-B2
-~
- ---, .1 :.il)
!I
VPN B
Site 1 Routing I :-, ;
. ,". \ :)'
, , , VPN A
> =: CE- A3 . - . Site 3

p p PE 3 .--,----::~. ~ ,. ,.,., ~
.
---~
BGP ~ - ',,~
.......,__,. . _ ~ ~ Routing
CE-B3

VPN C
-- - -<.,
Site 1
VPN B ~ ~--. ~
-- -
Site 3 !!!

0 2020 Jumpor Nolworks, Inc All R,ghls Rosorvod

Ju nlper8osiness Use Onty
JUn!J?~[. a

Virtual Private Network Routing and Forwarding Tables

In the Layer 3 VPN model, site-specific VRF tables house each site's routes. This separation of routes allows VPN customers
to use private addresses that can overlap with addresses used by other VPN customers.

On th is slide, PE 1 has three VRF tables-one for each of its attached VPN sites. The VRF tables store routes learned from the
attached site, as well as routes learned through MP-BGP interaction with remote PE routers. In the latter case, VPN po licy
determines which routes are cop ied into which VRF tables based on the presence of a VPN-1Pv4 route attribute known as a
route target.

Chapter 3-8 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

VRF Tables

■ Each VRF table is populated with:

• Routes received from directly connected CE sites associated with the VRF
table
• Routes received from other PE routers with acceptable
MP-BGP attributes
■ Packets from a given site are only matched against the site's
corresponding VRF table
• Provides isolation between VPNs

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usinessUse Only

VRF Table Population

As mentioned previously, each PE router maintains site-specific VRF tables that house routes learned from the local CE
device, as well as routes learned from remote PE routers having matching route attributes.

Site Separation
When a packet is rece ived from a given site, the PE router performs a longest-match Layer 3 lookup against only the entries
housed in that site 's VR F tab le. This separation permits duplicate addressing among VPN customers with no chance of
routing ambiguity.

www .j uniper.net Layer 3 VPNs • Chapter 3-9

Junos Layer 3 VPNs

Agenda: Layer 3 VPNs

• Layer 3 VPN Terminology

➔ VPN-1Pv4 Address Structure
• Operational Characteristics
• Policy-Based Routing Information Exchange
• Traffic Forwarding

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usinessUse Only
Jun1Per
~ETWORKS
10

VPN-1Pv4 Address Structure

The slide highlights the topic we d iscuss next.

Chapter 3-1 0 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Overlapping Address Spaces

■ VPNs A and B use the same address space

• PE 1 uses a separate routing (VRF) table for each VPN site
• PE 2 would normally choose between the two 10.1/16 routes
• MPLS/BGP VPNs solve this problem with the route distinguisher

r- - - - VPNA
L 1_E.~1! ~ ~ Site2

VPN A cJ=I ,' CE-A1

Site 1 ~ , ,~ -@ ---- IIIi: 1 1

PE 1
VPN B 10.1/16
Site 1
CE- 8 2 VPN B
I

~-~- - ~~

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usinessUse Only
Jun1Per
~ETWORKS
11

Duplicate Addresses Welcome!

Th is slide stresses that two VPN customers can use overlapping address space with no issues due to the separation of their
routes in site-specific VRF tables.

In th is example, VPN Site A is using the 10.1/16 addresses space, which is also being used by VPN customer B. However,
housing these overlapping routes in separate VRF tab les on PE routers is only half of the solution. A mechanism is needed to
allow the PE routers to exchange these routes with remote PE routers without any chance of one address stepping on the
other.

For example, when PE 1 advertises routes from its two VRF tables to PE 2, they arrive over a common MP-BGP connection
that is not inherently associated with a particular VRF table . How can we assure that PE 2 interprets these routes as being
independent and unrelated? The answer lies in the structure of a VPN-1Pv4 address containing a route distinguisher
designed to fix the very problem posed here.

www .j uniper.net Layer 3 VPNs • Chapter 3 - 11

Junos Layer 3 VPNs

VPN-1Pv4 NLRI Format

■ VPN-1Pv4 address family

• New BGP-4 subsequent address family identifier (SAFI 128)
• Consists of MPLS label + route distinguisher+ subscriber 1Pv4 prefix
• Route distinguisher disambiguates 1Pv4 addresses
• Allows service provider to administer its own numbering space
■ VPN-1Pv4 addresses are distributed by MP-BGP
• Uses multiprotocol extensions for BGP4 (RFC 2858)
■ A /32 1Pv4 prefix produces a VPN-1Pv4 prefix with a mask of /120 (15
octets) Note: The Junos OS only displays the IPv4 prefix portion (/32)
I Route Distinguisher
I
Mask MPLS Label ~ IIA~rnTs . _ _ --• _ _. -- Subscriber 1Pv4 Prefix
(1 byte) (3 bytes) (2 bytes) (variable length) (variable length) (0-4 bytes)

C2020 Jun,perNetworks, Inc .All R,ghlS Resenie<I.

Jon1per8usinessUse Onty
Jun1Per
.iETWORKS
12

VPN-1Pv4 Address Family

The slide shows the structure of a VPN-1Pv4 address. VPN addresses use a new MP-BGP subsequent address fami ly
identifier (SAFI). Because they are, in the end, 1Pv4 addresses, and they use the same family identifier (1) as conventional
1Pv4 routes .

VPN network layer reachability information (NLRI) conta ins a 24-bit MPLS label, which is sometimes called a VRF label
because the label's function is to associate packets with a particular VRF instance in the receiving PE router. VPN addresses
also contain a route distinguisher field, which is used to disambiguate VPN routes. In other words, two identical IP prefixes
are cons idered as different, and therefore incomparable, when they carry different route distinguisher values.

Distributed by MP-BGP
Labeled VPN routes are exchanged over the MP-BGP sessions, which term inate on the PE routers.

VPN Route Masks

A 32-bit 1Pv4 prefix combined with the other fields in a VPN-1Pv4 address produce a VPN-1Pv4 prefix with a mask of 120 bits.
The Ju nos operating system only disp lays the mask for the 1Pv4 prefix portion of the prefix. Thus, in this case, the operation
would see a VPN-1Pv4 prefix with a mask length of / 32.

Chapter 3-12 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Route Distinguisher Formats

• Two values are defined for type field: 0 and 1
• Type 0: adm field = 2 bytes, AN field = 4 bytes (Ex: 10458:22: 10.1.0.0/16)
• Adm field should contain an ASN from IANA
• AN field is a number assigned by service provider
• Type 1: adm field = 4 bytes, AN field = 2 bytes (Ex: 1.1.1.1:33:10.1.0.0/16)
• Administration field should contain an IP address assigned by IANA
• Assigned number field is a number assigned by service provider

..... --- ---

8-Byte Route Distinguisher
~- ' ----------- - ~. . -- ___
1-I- -1----114-Byte IP Address ~
_..,'

(Type) (Adm) (AN)

I Assigned Number Field: Num ber assigned by the

identified authority for a partic ular purpose
- Administration Field: Identifies the assigned nu mber authority
. . .
- •
2 Byte Type Field . Determines the lengths of the other two fields

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usiness Use Only
Jun1Per
~ETWORKS
13

Two Route Distinguisher Formats Defined

The route distingu isher can be formatted in two ways:

• Type O: This format uses a 2-byte administration field that codes the provider's autonomous system number,
fol lowed by a 4-byte assigned number field . The assigned number field is adm inistered by the provider and
should be unique across the autonomous system.

• Type 1 : This format uses a 4-byte administration field that is norma lly coded with the router ID (RID) of the
advertising PE rout er, fol lowed by a 2-byte assigned number field that caries a un ique value for each VRF table
supported by the PE router.

The examples on t he sl ide show bot h t he Type O and Type 1 route distinguisher format s. The f irst example shows the 2-byte
adm inistration f ield with the 4-byte assigned n umber f ield (Type 0).

www .j uniper.net Layer 3 VPNs • Chapter 3 -13

Junos Layer 3 VPNs

The VPN-1Pv4 Address Family

■ Route distinguisher disambiguates 1Pv4 addresses

■ VPN-1Pv4 routes
• Ingress PE router prepends route distinguisher to 1Pv4 prefix of routes
received from each CE device
• VPN-1Pv4 routes are exchanged between PE routers using
MP-BGP
• Egress PE router converts VPN-1Pv4 routes into 1Pv4 routes before inserting
into site's routing (VRF) table
■ VPN-1Pv4 is used only in the control plane
• Data plane uses MPLS-encapsulated IPv4 packets

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usiness Use Only
Jun1Per
~ETWORKS
14

Disambiguates 1Pv4 Addresses

As mentioned on the previous page, the route distingu isher al lows the router to disambiguate two identical IP prefixes.

VPN-I Pv4 Routes

The ingress PE router adds (or prepends) the route distinguisher to the 1Pv4 prefix of routes received from each CE router.
These VPN-1Pv4 routes are then exchanged between PE routers using MP-BGP. The egress router converts the VPN-1Pv4
routes back into 1Pv4 routes before inserting them into the site's routing table.

Used Only in the Control Plane

The VPN address family exists only in the signaling or control plane between PE routers. Routes that match VPN pol icy, and
are therefore installed into a particu lar VRF table, have the 8-byte route distinguisher (and MPLS label) removed so that they
appear as conventiona l 1Pv4 routes in the VRF table. Because the site-specific VRF tables provide route isolation, there is no
need for the route distinguisher once a route is safely stored away in a VRF table. Only signaling exchanges between
PE routers use the VPN-1Pv4 address format.

Chapter 3-14 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Using Route Distinguishers to Disambiguate

Addresses
■ The overlapping routes from A and B appear to be non-overlapping
to PE2 because of the prepended route distinguisher

VPNA
. - . Site2

VPN A
Site 1

VPN B
Site 1

••••••••••••••••
: 10.1 /16 :
• • ••••••••••••
••••

C 2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per 8us1ness Use Only
Jun1Per
.iETWORKS
15

Overlapping Routes Revisited

With t he inclusion of the route distinguisher, the ove rlapping address spaces used by VPN customers A and B do not cause
ambiguity at PE 2 because the different route distinguishers make these routes incomparable.

The sole purpose of the rout e disti nguisher is to make what would otherwise be identica l addresses incomparable. The PE
routers do not int erpret or act on the fields in the route distinguisher for any other reason.

www .j uniper.net Layer 3 VPNs • Chapter 3 - 15

Junos Layer 3 VPNs

Agenda: Layer 3 VPNs

■ Layer 3 VPN Terminology

■ VPN-1Pv4 Address Structure
➔ Operational Characteristics
➔ Policy-Based Routing Information Exchange
• Traffic Forwarding

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Onty
Jun1Per
.iETWOffKS
1s

Policy-Based Routing Information Exchange

The slide highlights the topic we d iscuss next.

Chapter 3 - 1 6 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

RFC 4364: Operational Overview

• Control flow (signaling plane):
• Routing information exchange between CE and PE routers
• Independent at both ends
• Routing information exchange between PE routers
• LSP establishment between PEs (RSVP or LOP signaling)
• Data flow (forwarding plane):
• Forwarding user traffic VPNA
Site 2
VPN A
Site 1
j ,<~ CE-A1
~, ~
VPN B
VPNB --..,_,.,,. Site 2
Site 1 ,__

VPNA
p Site 3

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usiness Use Only
Jun1Per
~ETWORKS
17

Control Flow
VPN control flows exist at various places in the RFC 4364 environment. First, we have the signaling exchange between CE
and PE routers that can take the form of OSPF, RIP, BGP, or even static routing. The control exchanges between PE and CE
routers are totally independent, due to the PE routers terminating the local CE-PE signa ling flows. The PE routers then use
MP-BGP to convey routes from site-specific VR F tables for the purposes of populating the VRF tables on remote PE routers.

Finally, the need for LSPs in the provider's networks resu lts in the presence of MPLS-related signaling in the form of either
RSVP or LDP.

Data Flow
Data flow relates to the actual forwarding of VPN traffic from CE router to CE router using MPLS label-based switch ing
through the provider's core.

www .juniper.net Layer 3 VPNs • Chapter 3 - 17

Junos Layer 3 VPNs

RFC 4364 Policies

■ VPNs are defined by administrative policies

• Used for connectivity and quality of service guarantees
• Defined by customers
• Implemented by service providers
■ Full-mesh or hub-and-spoke connectivity
• Logical VPN topology results from the application of export and import route
target policies

C2020 Juniper Networks, Inc . All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
1a

Administrative Policy
The use of pol icy in the PE routers determines the connectivity that results between VPN sites. While site connect ivity
requirements are defined by the VPN customers, the act of implementing this policy is the job of the service provider.

Mistakes made by the provider when defining and implementing VPN policy can lead to security breaches at worst and
broken VPN connectivity at best.

VPN Topology Options

VPN policy is extremely flexible and can result in ful l-mesh, partia l-mesh, or hub-and-spoke topologies. The combination of
VPN import and export policy determ ines the resu lting site connectivity.

Chapter 3-18 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

PE-PE Route Distribution

■ Distribution of routes is controlled by BGP extended community
attributes and VRF policy
• Route target
• Identifies a set of VRFs to which a PE router distributes routes
• Site of origin/route origin
• Identifies the specific site from which a PE router learns a route
■ Structured similarly to the route distinguisher
• 8 bytes in length (2-byte type field, 6-byte value field)
• Type 0:
• 2-byte global administrator subfield (ASN)
• 4-byte local administrator subfield
• Type 1:
• 4-byte global administrator subfield (!ANA-assigned IP Address)
• 2-byte local administrator subfield
C/2020 Juniper Networks, Inc . All R,ghlS Resenie<J.
Jon1per8usiness Use Only
Jun1Per
.iETWORKS
19

Route Distribution Between PE Routers

VPN policy makes use of extended BGP communities that allow PE routers to filter routes for which they have no VPN
members. When a PE router has locally attached VPN members, these communities allow the PE router to install the VPN
route into the VRF tab le associated with specific sites.

The most important extended community is the route target, which is used to convey a route's association with a given VPN/
VR F table. The site of origin (SoO) commun ity is used in certain corner cases to prevent the unnecessary advertisement of
routes back to a site that originated it.

Structure of Extended Communities

BGP extended communities are defined in RFC 4360. Extended communities' attributes have a structure simi lar to the route
distinguisher in that they are 8 bytes in length and support the same type code options and structure.

www .juniper.net Layer 3 VPNs • Chapter 3 - 19

Junos Layer 3 VPNs

Route Target Extended Community

■ Each VPN-1Pv4 route advertised through MP-BGP is associated with
a route target community
• Export policy or explicit configuration define the targets associated with routes
a PE router sends
■ Upon receipt of a VPN-1Pv4 route, a PE router decides whether to
add that route to a VRF table
• Import policies or explicit configuration define which routes to add to a given
VRF table
■ Route isolation between VRF tables is accomplished through careful
policy administration
• Service provider provisioning tools can determine the appropriate export and
import targets automatically

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usinessUse Only
Jun1Per
~ETWORKS
20

Route Advertisements
Each VPN-1Pv4 route advertised by a PE router contains one or more route target communities. These communities are
added using VRF export po licy or explicit configuration.

Receiving Routes
When a PE router receives route advertisements from remote PE routers, it determines whether the associated route target
matches one of its local VRF tables. Matching route targets cause the PE router to install the route into al l VRF tables whose
configuration matches the route target.

Careful Policy Administration

Because the application of policy determines a VPN 's connectivity, you must take extra care when writing and applying VPN
policy to ensure that the VPN customer's connectivity requirements are faithfully met. Several companies offer automated
VPN provisioning tools to minimize the work required when reprovisioning a VPN to meet changing customer requirements.
These tools can also limit the errors that tend to occur when changes are manually entered by human operators.

Chapter 3-20 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Exchange of Routing Information (1 of 7)

■ CE device advertises route to PE router

• Using traditional routing techniques (for example, OSPF, RIP, BGP, and static
routes)

- - 1 10.1/161

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
21

Routing Exchange
The following sequence of slides discusses the end-to-end exchange of routing information between CE routers belonging to
the same VPN.

CE-4 sends the routes associated with VPN A Site 2 to its attached PE router. The 10.1/ 16 prefix can be exchanged using
OSPF, RIP, or BGP. Static routing can also place a site 's routes into the local PE router's VRF table.

Whatever protocol is used between CE-4 and PE-2, the operation of this protocol is term inated by the PE router. Th is
termination provides isolation of the VPN site's routing protocol and the MP-BGP protocols used to convey the routes
between PE routers. Th is isolation improves scalability and stability as malfunctions in the PE-CE routing protocol tend to be
limited to that PE-CE pairing.

www .j uniper.net Layer 3 VPNs • Chapter 3 - 21

Ju nos Layer 3 VPNs

Exchange of Routing Information (2 of 7)

■ 1Pv4 address is added to the appropriate VRF table

10458:23:10.1/16

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Onty
Jun1Per
.iETWORKS
22

Populating the Local VRF Table

Routes received by a local CE device are automatica lly installed into the VRF table associated with that sit e.

Chapter 3-22 • Layer 3 VPNs www.j uniper.net

 Junos Layer 3 VPNs

Exchange of Routing Information (3 of 7)

■ VRF table is configured to advertise the routes in the VRF table as L3

VPN routes using MP-BGP
• VRF table configuration adds VPN RED route target community

10458:23:10.1/16 - -I10.1 ,1s

0
J

VPN RED Ex ort

C2020 Juniper Networks, Inc . All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
23

VRF Export Policy

The PE router evaluates the route based on its configuration . If the VRF export policy accepts the route, or if a VRF target is
configured, the PE router converts the address into the VPN-1Pv4 format by adding the configured route distinguisher. At this
time the PE router also chooses a 20-bit MPLS label value used to associate rece ived traffic with this VRF table. Lastly, the
PE router associates the route with one or more extended communities. At a minimum, the route will have a route target
community added.

www .juniper.net Layer 3 VPNs • Chapter 3 - 23

Junos Layer 3 VPNs

Exchange of Routing Information (4 of 7)

• VPN-1Pv4 NLRI is advertised to other PE routers
Route Type VPN-1Pv4 Route (AFI 1, SAFI 128)
Length Label + RD + Prefix

NLRI Label VRF Label = Z (Chosen by advertising PE2)

Route Distinguisher (RD) RD=10458:23 (Configured on advertising PE2)

IP Prefix 10.1/1 6

Next-hop Loopback of advertising PE2

Route-target = VPN RED (Configured on advertising

Extended Community
PE2)

Other attributes (Origin, AS-Path, Local-Pref, etc)

CE-1 CE-2
p 1 MP-BGP Sessio E2
Site 2
.. .. .. .

VPN A
Site 1
e - VRF:1
CE 3 · · · · .
-:-:-:-,.,
~
.
• - - - -
. - -~ ~
-
:-,-~,.,::;::
.,_,~
iYRffl
CE-4

OSPF
VPN
Site 2

,:::: ~ 10458:23:10.1/16
VPN RED Export - -I 10.1,1s J

C/ 2020 Juniper Networks, Inc .All Rights ReseM!<I.

0
······· 4 Label Z
Next Hop PE-2

Jon1per8us1ness Use Only

Advertisement to Remote PE Routers

In Step 4, PE-2 generates a BGP update message conta ining the route learned f rom CE4 at VPN Site A. This route is sent to
all MP-BGP peers configured on the PE router that have successfully negotiated the support of the VPN-1 Pv4 add ress family.
Other ro utes learned from the CE device that share common community attributes can be packed into a single NLRI
advertisement.

Chapter 3-24 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Exchange of Routing Information (5 of 7)

• Each PE router is configured with import route targets
• Import route target is used to incorporate VPN-1Pv4 routes into VRF tables
selectively
• If import route target matches route target attribute in BGP route, the route is installed into the
bgp . 13vpn table and copied into appropriate VRF table(s)
• Based on configured route target or import policies, 10458:23: 10.1 /16 is copied into the RED
VRF-but not the BLUE VRF

........._ _ _-:r,
10~458:23:10.1 /16
VPN RED Import MP-BGP VPN RED Export
LabelZ

C/2020 Juniper Networks, Inc .All Rights Reserlle<I.

0 Next Hop PE-2

Jon1per8us1ness Use Only

Import Targets Determine the Route's Fate

Step 5 shows the remote PE routers receiving the VPN route advertisement. These PE routers use the ir configured VRF
import policy or VRF target to determine if any of their local VRF tables have matching route targets.

If no local configuration matches the route target, the PE router silently d iscards the route. Thus, a PE router must only carry
VPN routes when it has one or more loca lly attached sites belonging to the same VPN. Should the remote PE router's import
policy or VRF target change, BGP route refresh is used to solicit a retransmission of previously advertised routes, because
route target matches can now occur due to the policy modifications. Use of BGP route refresh means that BGP sessions do
not have to be disrupted when adds, moves, or changes to the VPN topology occur.

When the received route's target does match a VRF table's route target configuration, the PE router copies the VPN route
into the b gp . 1 3vpn. o table. This table houses all received VPN routes whose route target matched at least one VPN 's
configuration. The route is also copied into one or more local VRF tables after having the route distingu isher removed. The
result is that prefix 10.1/ 16 is now present in PE-i's random early detection (RED) VRF table in a native 1Pv4 format.

PE-1 now associates the RID of PE-2 as the next hop for 10.1/ 16 when forwarding traffic that matches the prefix and was
received on its RED VRF interface.

www .juniper.net Layer 3 VPNs • Chapter 3-25

Junos Layer 3 VPNs

Exchange of Routing Information (6 of 7)

■ Each VPN-1Pv4 route in a VRF table is associated with:
• Inner (VRF) label to reach the advertised NLRI (carried in
MP-BGP update)
• Outer label to reach the PE router
■ All routes associated with the same VRF interface can share a
common label

CE-1 }' 1 MP-BGP Sessio CE-2 VPN B

Site 1 ,~ ~-"-, ~ __ - - -- - - __ ~ 2
E~ . ·-: i---~ Site 2
.)/Rf::
. . ... . . ..:VRt=:.
. .. ... '1r
CE-3 .•:: .,.,,,,: · --- · •.• •.• · · CE-4
PN :V.RF,=
Site 1 .,.,.,.,.,.,.

VPN RED lm~ort 10458:23:10.1/ 16

10458:23:10.171 6 VPN RED Export

0
MP-BGP
6 GP Label (Inner) Label ( 2 ' - - - - - LabelZ
MPLS (Outer) Label (y) Next Hop PE-2

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Only

Label Association
When VPN routes are advertised, part of the NLRI is the VRF label chosen by the advertising PE router. Th is label is often
ca lled the inner label because it is always found at the bottom of the label stack. The p urpose of this label is to associate
received packets with the correct VRF tab le.

The receiving PE router m ust be able to resolve the RID of the advertising route to an MPLS LSP stored in the i ne t. 3 table.
If an LSP does not exist to the advertising PE ro uter, the route is hidden due to an unusable next hop. VPN traffic can only be
forwarded across the provider's backbone using MPLS switching. If an LSP to the egress PE router does not exist, the VPN
route can never be used.

The result of t his process is a two-level label stack used to forward packets across the provider's backbone, and then to
associate t he traffic with a specific VRF table on the receiving PE router.

Common Labels
RFC 4364 allows the PE router to issue a single VRF label for al l routes belonging to a common VRF interface or to allocate a
unique label for each route being advertised . The Ju nos OS takes the former approach because it drastically reduces the
number of VRF labels that must be managed. Compliant implementations that use per-route VRF label assignment are
interoperable with this one-label-per-VRF-interface approach, however.

Chapter 3-26 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Exchange of Routing Information (7 of 7)

■ Each 1Pv4 route installed in a VRF table can be advertised to the CE
devices associated with that VRF table
• For example, RIP, OSPF, and BGP
• Routing policy can be used on the PE-CE link to control the exchange of
routing information further

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Onty
Jun1Per
~ETWORKS
27

Advertising Received Routes

In the last step of the Layer 3 VPN signaling flow, t he receiving PE router (PE-1) re-advertises the routes learned from remote
PE routers to its locally attached CE routers.

These routes can be exchanged using any supported PE-CE routing protocol, or they can be defined statically on the CE
device. The CE device associates the PE router's VRF interface as the next hop for the routes learned from the PE router.

Because the local PE-CE routing protocol is terminated by the PE router's VRF table, in this examp le, CE-4 can run EBGP,
whi le CE-3 might be running OSPF or RIP.

Where wanted, you can use routing policy to control or refine the route exchange between PE and CE routers further. This
policy would function in addition to the VRF import and export policy discussed in this section.

www .juniper.net Layer 3 VPNs • Chapter 3 - 27

Junos Layer 3 VPNs

Agenda: Layer 3 VPNs

■ Layer 3 VPN Terminology

■ VPN-1Pv4 Address Structure
➔ Operational Characteristics
• Pol•cy-Based Routing Information Exchange
➔ Traffic Forwarding

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usiness Use Only
Jun1Per
.iETWOffKS
2a

Traffic Forwarding
The slide highlights the topic we d iscuss next.

Chapter 3-28 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Data Flow (1 of 7)

■ The PE-to-PE LSP must be in place before forwarding data across

the MPLS backbone
• LSPs are signaled through LOP or RSVP

10.1 /1 6

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per 8us1ness Use Only
Jun1Per
.iETWOffKS
29

LSP Must Exist Between Ingress and Egress PE Routers

Because VPN t raffic is forwarded across the provider's backbone using MPLS, the presence of an MPLS LSP between
ingress and egress PE routers must be in place before VPN packets can be forwarded .

RSVP or LDP can establish the PE-to-PE LSP. The PE-to-PE LSPs can involve PE routers run ning LDP with the resulting LDP
LSPs tunne led over a traffic engineered RSVP LSP.

www .juniper.net Layer 3 VPNs • Chapter 3 - 29

Junos Layer 3 VPNs

Data Flow (2 of 7)

■ The CE device performs a traditional 1Pv4 lookup and sends packets

to the PE router

IP
10.1.2.3

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
.iETWOffKS
30

CE Device Forwards VPN Traffic to PE Router

On th is slide, the CE device performs a longest-match lookup on a packet addressed to 10 .1/ 1 6. Th is lookup results in the
CE device forwarding the packet to the IP address associated with t he PE route r's VRF interface.

Chapter 3 - 30 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Data Flow (3 of 7)

■ The PE router consults the appropriate VRF table for the inbound
interface
■ Two labels are derived from the VRF route lookup and are pushed
onto the packet
PE-1
1) Look up route in Red VRF
2) Push BGP label (z)
3) Push outer label (x)

CE-1
Site 2
Site 1 0·~ -:vRF~ ~1

VPN A
Site 1 e CE-
3
,\iij#,:
,- , : < -: .
- 1......,. .... . CE-4

Y,'.Rf OSPFe v;;t~ :

- -·
IP 10.1/16
10.1 .2.3

C/2020 Jun,perNetworl<s, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
31

PE Router Consults VRF Table for Longest Match

Upon receipt of the packet, the PE router conducts a longest-match route lookup in the VRF table associated with the
interface on which the packet arrived.

Two Labels Derived

Assuming that a match is found, the PE router associates the packet with two labels: the VRF label origina lly advertised with
the route, and an outer MPLS label, assigned by either LDP or RSVP, which is used to associate the packet with the LSP
between ingress and egress PE routers.

www .juniper.net Layer 3 VPNs • Chapter 3 - 31

Junos Layer 3 VPNs

Data Flow (4 of 7)
• Packets are forwarded using two-level label stack
• Outer (MPLS) label: • Inner (MP-BGP) label:
• Identifies the LSP to egress • Ident ifies outgoing
PE router interface from egress PE
• Resolves BGP next hop to CE
th rough inet · 3 • Communicated in MP-BGP
• Distributed by RSVP
_ o_
r_LD
_P_ _ _ _ _ updates (control plane)
PE-1

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usiness Use Onty
Jun1Per
.iETWORKS
32

Two-Level Label Stack Required

The PE router performs a double label push operation involving both the VRF and M PLS labels. The VRF label associates the
packet with the correct VRF table on the egress PE router wh ile the MPLS label associates the packet with the LSP t hat
t erminates on t he egress PE router. The ingress PE rout er now forwards the labeled packet t o the next-hop LSR along the
LSP's path.

Chapter 3 - 3 2 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Data Flow (5 of 7)

■ After packets exit the ingress PE router, the outer label is used to
traverse the service provider
• P routers are not VPN aware

--..,uuter label (x
BGP label (z)
10.1/16
IP
10.1.2.3

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Only

MPLS Forwarding Across Provider Core

As the labeled packet traverses the provider's core, the LSRs that make up the LSP act upon (and swap) the outer MPLS
label. In contrast, the inner VRF label remains untouched throughout the labeled packet's journey.

The use of exact match MPLS forwarding allows the P routers to forward the packet toward the egress PE router correctly,
without any awareness of the labeled packet's contents. This concept is key to RFC 4364 scalabi lity, because th is MPLS
capability is what allows P routers to rema in unaware of the VPN .

www .juniper.net Layer 3 VPNs • Chapter 3 - 33

Junos Layer 3 VPNs

Data Flow (6 of 7)

■ Penultimate hop popping (before reaching the egress PE router)

removes the outer label
Penultimate
op top labe

I BGP label (z) I

10.1/16
I IP 10.1.2.3 I

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usiness Use Only
Jun1Per
.iETWOffKS
34

Penultimate Hop Popping

The last P router in the LSP's path performs a pop operation, which results in a single-level label stack. The packet is now
forwarded to the LSP's egress point with only the VR F label.

Chapter 3-34 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Data Flow (7 of 7)

■ The inner label is removed at the egress PE router

■ The native 1Pv4 packet is sent to the outbound interface associated
with the label
CE-1 CE-2 VPN B

Site 1 ~ -.i.\i.Rf:: E:.Re.:: i...---e Site 2

Site 1 - =~'-
1

.__~....__ _ _ __,,,,.
--..
OSPF

IP 10.1/16
10.1.2.3

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
.iETWOffKS
35

VRF Label Removed by Egress PE Router

The egress PE router uses the received VRF label to map the packet to a specific VRF interface.

IPv4 Packet Sent to Outbound Interface

After mapping the packet to a specific VRF interface, the VRF label is popped, and the packet is sent to the CE device
attached to that VRF interface.

www .juniper.net Layer 3 VPNs • Chapter 3 - 35

Junos Layer 3 VPNs

Summary

■ In th is content, we:
• Defined the roles of P, PE, and CE routers
• Described the format of VPN-1Pv4 addresses
• Explained the role of the route distinguisher
• Described the flow of RFC 4364 control information
• Explained the operation of the RFC 4364 forwarding plane

~2020 Juniper Networks, Inc . All Rights Reserlle<I.

Jo niper8us1ness Use Only
Jun1Per
~ETWOffKS
36

We Discussed:
• The roles of P, PE, and CE routers;

• VPN-1Pv4 address formats;

• Route distinguisher use and formats;

• RFC 4364 control flow; and

• RFC 4364 data flow .

Chapter 3-36 • Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Review Questions

1. Can you define the roles of P, PE, and CE routers?

2. What is the format of VPN-1Pv4 addresses?
3. What is the role of the route distinguisher?
4. What is the flow of RFC 4364 control information?
5. How does the RFC 4364 forwarding plane operate?

~ 2020 Juniper Networlcs, Inc . All Rights Reserve<!.

Juniper Business Use Onty
Jun1Per
~ETWORl(S
37

Review Questions
1.

2.

3.

4.

5.

www .juniper.net Layer 3 VPNs • Chapter 3 - 37

Junos Layer 3 VPNs

Answers to Review Questions

1.
The CE router is located at the customer's VPN site and only participates in the customer's routing. The PE router is located
on the edge of the provider network and participates in both the customer's routing and the provider's network. The PE
maintains all of the customer specific VRF tables. The P routers participate in the core network and is able to forward VPN
traffic using MPLS LSPs without knowledge of the customer's network.

2.
The VPN-1Pv4 NLRI consists of an MPLS label, a route distinguisher, an 1Pv4 address, and a 120 bit mask.

3.
The route distingu isher is used to disambiguate overlapp ing 1Pv4 addresses.

4.
Some routing method (OSPF, BGP, static routing) is used to share routes between the customer VPN sites and the PE routers.
MP-BGP is used by PE routers to pas.s customer routes learned from CE routers to other PE routers. PE routers will then pass
VPN routes learned from other PE routers to the associated CE routers.

5.
A CE router will forward 1Pv4 packets to the locally connected PE router. The PE router will perform an route lookup using the
VRF table associated with the incom ing interface. The PE router will then encapsulate the packets in 2 MPLS headers: the
innermost will be the label learned from MP-BGP wh ile the outermost will be the label associated with the LSP that ends at
the remote PE. The P routers along the LSP will perform label swapping on the outermost header as the packet traverses the
provider's network. The penultimate router along the LSP will pop the outermost label and send a singly labeled packet to
the remote PE. The remote PE will ana lyze the packets label in order to map the packet to a particu lar routing table, VRF. The
remote PE pops the MPLS label and forwards the 1Pv4 packet to the remote CE router.

Chapter 3-38 • Layer 3 VPNs www.juniper.net

 un1Pe[
NETWORKS
Education Services

Junos Layer 3 VPNs

Chapter 4: Basic Layer 3 VPN Configuration

Engineering Simplicity
Junos Layer 3 VPNs

Objectives

■ After successfully completing this content, you will be able to:

• Create a routing instance, assign interfaces, create routes, import routes, and
export routes for the routing instance using route distinguishers and route
targets
• Describe the purpose of BGP extended communities, configure, and use BGP
extended communities
• List the steps necessary for proper operation of a PE-CE dynamic routing
protocol
• Configure a simple Layer 3 virtual private network using a dynamic PE-CE
routing protocol
• Basic verification of Layer 3 virtual private networks

C> 2020 J uniper Networks, Inc All Rights Reserved

Juniper Business Use On ly

We Will Discuss:
• Creating a routing instance, assigning interfaces, creating routes, and importing/exporting routes within the
routing instance using route distinguishers and route targets;

• The purpose of BGP extended communities and how to configure and use these communities;

• The steps necessary for proper operation of a provider edge (PE) to customer edge (CE) dynamic routing
protocol;

• Configuring a simple Layer 3 virtual private network (VPN) using a dynamic CE-PE routing protocol; and

• Basic ve rification of a Layer 3 virtual private network.

Chapter 4-2 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

Agenda: Basic Layer 3 VPN Configuration

➔ Preliminary Steps
■ PE Router Configuration
■ Basic Layer 3 VPN Verification

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per aus1ness use Onty
Jun1Per
.iETWOffKS
3

Preliminary Steps
The slide lists the topics we will discuss. We wi ll discuss the highlighted topic first.

www .juniper.net Basic Layer 3 VPN Configuration • Chapter 4-3

Junos Layer 3 VPNs

Layer 3 VPN Preliminary Configuration

■ Preliminary steps:
1. Choose and configure the IGP for PE and P routers
2. Configure MP-BGP peering among PE routers
• Must include VPN-1Pv4 NLRI capability
3. Enable the label-switched path signaling protocols
4. Establish LSPs between PE routers
■ The PE routers perform VPN-specific configuration

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8usinessUse Onty

Preliminary Steps
The following steps are needed to establish an IP infrastructu re capable of supporting a Layer 3 VPN :

1. The provider core must have a functional interior gateway protocol (IGP) provisioned on the PE and provider (P)
routers. Generally speaking, neither internal BGP (IBGP) nor MPLS signal ing protocols function without a
working IGP. If Constrained Shortest Path First (CSPF) label-switched paths (LSPs) are used, the IGP must
support traffic engineering extensions.

2. Next, the Multi protocol Border Gateway Protocol (MP-BGP) peering sessions should be established between the
loopback addresses of the PE routers. PE routers not sharing VPN membership do not have to peer with
MP-BGP. However, havi ng the sessions in place can simplify operations later, should the PE routers f ind
themselves attached to sites that are to form a VPN. Because these MP-BGP sessions are used to advertise
VPN routes, the VPN-1Pv4 address family must be configured and successfully negotiated.

3. You shou ld now decide on an MPLS signal ing protocol and provision it on all PE and P routers involved in VPN
signaling or traffic forwarding. Wh ile it is possible to use a static LSP, the degree of manual labor and lack of
operational status makes a static LSP difficult in large-scale networks.

4. Once you have completed the previous steps, configure LSPs between all PE routers that are expected to
support a given VPN. The use of RSVP requires that you manually configure each LSP at the ingress node. In
contrast, just enabling LDP results in LSP connectivity among all routers.

VPN Configuration in PE Routers Only

When your PE-PE MP-BGP sessions and LSPs are correctly establ ished and operationa l, you are ready to begin the task of
configuring a Laye r 3 VPN . The good news is that a subset of your routers, namely the PE routers, perform all VPN-specific
configuration .

Chapter 4-4 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

Introduction to VPN Routing Tables (1 of 2)

■ VPN routing tables (Part 1):

• i net . 0
• Main IP routing table, relevant for IGP and BGP
• inet . 3
• RSVP and LOP routes installed, relevant for BGP only
• mpls . O
• MPLS switching table

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

Routing Tables Used for VPNs: Part 1

The following list provides information about the routing tables used for VPNs:

• i n et . o: Stores rout es learned by the IGP and IBGP sessions between the PE routers. To provide Internet
access to the VPN sites, configure the vpn . inet . O routing tab le to conta in a default route to the i ne t. O
routing tab le.

• i n et . 3 : Stores all MPLS routes learned from LDP and RSVP signaling done for VPN traffic. VPN IBGP (family
i n et-vpn ) re lies on next hops in t he inet . 3 tab le.
• mpl s . o: Stores MPLS swit ch ing information. Th is table contains a list of the next label-switching router (LSR) in
each LSP. It is used on trans it routers to route packets t o the next rout er along an LSP.

www .j uniper.net Basic Layer 3 VPN Configuration • Chapter 4-5

Junos Layer 3 VPNs

Introduction to VPN Routing Tables (2 of 2)

■ VPN routing tables (Part 2):

• vpn - name . i net . 0
• Stores all unicast 1Pv4 routes received from directly connected CE routers and all
explicitly configured static routes in the routing instance
• For each vpn - name . inet . o routing table, one forwarding table is maintained
• bgp . 13vpn. 0
• Stores all VPN-1Pv4 unicast routes received from other PE routers
• This table is present only on PE routers- routes are resolved using the information in the
inet . 3 routing table

C> 2020 Juniper Networ1<s, Inc All Rights Reserved

Juniper Bu si ness Use On ly

Routing Tables Used for VPNs: Part 2

• v pn-name . inet . O: Stores all unicast 1Pv4 routes received from directly connected CE routers in a routing
instance and all explicitly configu red static routes in the routing instance. This table is the VPN routing and
forwa rding (VRF) tab le and is present only on PE routers. For example, fo r a ro uting instance named vpn-a, the
routing tab le for t hat instance is named vpn-a . inet . O. The v pn-name . inet . O table also stores routes
announced by a remote PE router that match the import criteria for that VPN. This PE router tags the route with
the ro ute ta rget that co rresponds to the VPN site to which the CE belongs. A label is also distributed with the
route. Routes are not redistributed from the v pn-name . inet . o tab le to the b gp . 13v p n . o table; they are
directly advertised to other PE routers. For each routing instance, one forwarding table is maintained in addition
to the forwarding tables that correspond to the router's inet . o and mp l s . o routing tables.

• b gp .1 3vp n . o: Stores all VPN-1Pv4 un icast routes rece ived f rom other PE routers. This table is present only on
PE routers. When a PE router receives a route from another PE router, it places t he route into its b gp. l 3vp n . o
routing table after evaluating th is route against the configured VR F parameters. The route is resolved using the
information in the i ne t. 3 routing table. The resu ltant route is converted into IP version 4 (1Pv4) format and
redistributed to the v pn-name . inet . O tab les on the PE router if it meets the configured criteria.

Chapter 4-6 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

PE-PE MP-BGP Peering

■ PE-to-PE MP-BGP sessions require VPN-1Pv4 NLRI

■ The Junos OS automatically negotiates BGP route refresh

[edit]
user@Rli show protocols bgp
group my- int- group {
type internal ;
local - address 192 . 168 . 1 . 1 ;
family inet {
unicast ;
}
family inet- vpn {
unicast ;
}
neighbor 192 . 168 . 1 . 3 ;
}

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

The Need for the inet-vpn Address Family

Because the PE routers are expected to send and receive labeled VPN routes, you must configure the corresponding address
fami ly on the MP-BGP sessions between PE routers.

This slide shows the configuration syntax used to support the VPN-1Pv4 network layer reachability information (NLRI) for a
BGP session.

Once an address family is explicitly configured on a BGP session, you must also explicitly configure the default address
fami ly of i net un icast if the PE router is expected to receive both conventiona l IP as well as VPN routes. Many providers
try to keep full Internet routing feeds off their PE routers by using a default route in i net . o that points to a P router with a
comp lete BGP table. In such a network, your PE-to-PE MP-BGP peering sessions might not need the i n et un icast family.

BGP Route Refresh

The BGP route refresh capability is important when supporting VPNs as PE routers summarily discard all route
advertisements that do not contain matching route targets. Without the route refresh capability, you would have to clear
MP-BGP sessions when changes are made to VPN membership, which wou ld resu lt in disruption to all other VPNs that might
share the MP-BGP session. The Ju nos operating system automatically negotiates the route refresh capability, so this feature
does not require any explicit configuration.

www .juniper.net Basic Layer 3 VPN Configuration • Chapter 4-7

Junos Layer 3 VPNs

MP-BGP Peering: PE-PE (NLRI Information)

user@Rl> show bgp neighbor 192.168.1.3

Peer : 1 92 . 168 . 1 . 3+54470 AS 655 1 2 Local : 192 . 168 .1. 1+179 AS 65512
Type : Internal State : Established Flags : <ImportEval Sync>
Last State : Openconfirm Last Event : RecvKeepAlive
Last Error : None
Ontions : <Preference LocalAddress AddressFamilv Rib- nroun Refresh>
Address families configured : inet- unicast inet- vpn- unicast
Local A ress : l~L .1 68 .1.1 Holdt1me : ~u Prererence : ltu
Number of flaps : 0
Peer ID : 192 . 168 . 1 . 3 Local ID : 192 . 168 . 1 . 1 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 Retres h capao1l1ty (L )
Stale routes from peer are kept for : 300
Peer does not support Restarter functionality

iQ 2020 Juniper Networks, Inc All Rights Reserved 8

Juniper Business Use On ly

Verifying MP-BGP Peering Session: NLRI Information

Th is slide shows the results of the show bgp neighbor command, where the BGP speakers have successfully negotiated both
the VPN-1Pv4 address family and the BGP route refresh capab ility.

Chapter 4-8 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

MP-BGP Peering: PE-PE (Route Tables)

user@Rl> show bgp neighbor 192.168.1.3

... ________
Peer : 192 . 168 . 1 . 3+50833 AS 65512 Local : 192 . 168 . 1 . 1+179 AS 65512

! Table bgp . 13vpn . o!

RIB State : BGP restart is complete
RIB State : VPN restart is complete
Send state : not advertising
Active prefixes : 2
Received prefixes : 2
Accepted prefixes : 2
Sunnressed due to damping : 0
Table vpn- a . inet . O Bit : 30000
RIB State : BGP restart is complete
RIB State : VPN restart is complete
Send state : in svnc
Active prefixes : 2
Received prefixes : 2
Accepted prefixes : 2
Suppressed due to damping : 0
Advertised prefixes : 2

C> 2020 Juniper Networks, Inc All Rights Reserved 9

Ju niper Bu si ness Use On ly

Verifying MP-BGP Peering Session: Route Tables

A BGP speaker that has negotiated the VPN-1Pv4 address family automatically creates the bgp . 13vpn. o route table used
to store all routes received from other PE routers with at least one matching route target. If no routes have matched the PE
router's VRF import policies, the bgp .1 3vpn. o table is still created, but it rema ins empty.

Routes with matching route targets are also copied into one or more local VRF tables. In this examp le, all received routes
with a matching route target were cop ied into the vpn-a . i net . o VRF table. The sum of all VRF table entries should match
the total number of routes stored in the bgp . l 3vpn . o table.

www .juniper.net Basic Layer 3 VPN Configuration • Chapter 4-9

Junos Layer 3 VPNs

Agenda: Basic Layer 3 VPN Configuration

■ Preliminary Steps
➔ PE Router Configuration
■ Basic Layer 3 VP1\I Verification

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

PE Router Configuration
The slide highlights the topic we d iscuss next.

Chapter 4-10 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

PE Router Basic Configuration

■ All VPN-specific configuration on the PE routers

■ PE routing instance
• Create routing instance and list associated VRF interfaces
• Assign a route distinguisher
• Link the VRF table to import and export policies or configure the vrf-target
statement
• Configure PE-CE routing protocol properties
■ VPN policy
• Create and apply BGP extended communities (for example, the route
target/site of origin)
• Create VRF import and export policies

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly
Jun1Per
N (T\\()kl(S
11

PE Router Configuration
Virtual ly all VPN-specif ic configuration and operational monitoring occurs on the PE routers.

PE Routing Instance
VR F tables are created as separate rout ing instances within the Ju nos OS. You must associate each inst ance with one or
more logical interfaces. Configuration of the route distinguisher is another mandatory aspect of VR F instances.

You must also link the VRF inst ance with either the v rf-target statement or VR F import and export policy statements.
Finally, you must conf igure the VRF instance with a set of routing protocol properties compat ible with the configuration of the
attached CE routers.

VPN Policy
In the case where VRF import and export pol icies are used, the Junos OS does not allow you to commit your VPN
configuration until the po licy statements to wh ich t he VRF table is linked are created.

Minimum policy configuration involves the definition of route target community and the VRF import and export policies t hat
use the route target to associate the route with a particular set of VR F tables.

www .j uniper.net Basic Layer 3 VPN Configuration • Chapter 4- 11

Junos Layer 3 VPNs

Layer 3 VPN Topology Example

■ Network characteristics:
• IGP is single-area OSPF
• RSVP signaling between PE devices, LSPs established between PE routers
(CSPF not required)
• MP-BGP peering between PE routers, loopback peering, VPN-1Pv4 NLRI
• CE-PE link running EBGP
• Full-mesh Layer 3 VPN between CE-A and CE-B
Provider Core
· AS 65512 •
Site 1 ~ / OSPF Area O ) Site 2
AS 651 01

rSite 1 ~ 1 .. t1
I .1 .
-

.1
-..

R2 .2
.2 ~
" 6 .1
_

.1 .
AS 65101

~ t
Site 2
~ ) 10.0. 10.0124 · 172.22.21 0.0,24 ·' 1, 172.22.212.0124 10.0.11.0124 C'i!r
CE-A PE p • PE .., ~ CE-B
loO 192.168.11 .1 loO 192.168.1.1

:......._----------~ loO 192. 168.1.3 loO 192.168.11.2

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly
Jun1Per
N£T\\()kl(S
12

Layer 3 VPN Example

The diagram on th is slide serves as the basis for the various configuration and operational mode examples that follow.

The IGP in use is Open Shortest Path First (OSPF), and a single area (Area 0) is configured . This example does not rely on the
functionality of CSPF, so traffic engineering extensions are not enabled.

RSVP is deployed as the MPLS signa ling protocol, and an LSP is configured between the R1 and R3 PE routers .

An MP-BGP peering session is configured between the loopback addresses of the PE routers . The VPN-1Pv4 and ine t
u n i cast address fam ilies are configured.
In th is example, the CE routers run EBGP. This results in the need for the PE routers to also run EBGP with in their VRF routing
instance.

The overal l goal of this network is to provide ful l-mesh (which is point-to-point in th is case) connectivity between the two CE
routers shown. This application is considered ful l mesh as the resulting configuration read ily accommodates the additional
sites with any-to-any connectivity.

Chapter 4 -12 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

VRF Routing Instances

• VRF tables are created at the [edit routing - instances
instance-name] hierarchy:

[edit routing- instances vpn - a]

user@Rl# show
instance-type vrf ;
interface <interface-name> ;
route - distinguisher <rd type> ;
vrf-target <target community> ;

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

RF Instances
VR F routing instances are configured under the [e dit r out ing- i ns t a n ces i nstance - name ] portion of the
configuration hierarchy.

This slide reflects the required parameters for a VRF instance called vpn-a using the vrf-target option. Additional
details about each requ ired option is outlined in the following section:

• instanc e-type: Defines the type of routing instance being created and what parameters you have available
to configure;

• i nterface: Identifies the logical, private interface between the PE router and the CE router on the PE side;
• route-distinguisher: An identifier attached to a route, enabling you to distinguish to which VPN the route
belongs. Each routing instance must have a un ique route distinguisher configured; and

• v rf-target or v rf-import/ vrf-expo rt policies:

vrf-target: VRF import and export policies are generated that accept and tag routes with the
specified target community.

vrf-impo rt/ vrf-expo rt policies: Defines how routes are imported and exported for the local PE
router's VR F table.

You configure the PE-CE routing protocol under the p r otoco l s subhierarchy; you configure static routing under the
r o uti ng-op t ion s sub-hierarchy.

www .juniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 13

Junos Layer 3 VPNs

Assigning the Route Distinguisher

■ Manually assign the route distinguisher per VRF

[edit routing-instances vpn-a]
user@Rl# s ho w
instance - type vrf ;
interface ge-1/1/4 . 100 ;
!route-disting uisher 192 . 168 .1. 1 : 1; !

■ Enable router to dynamically assign a unique Type 1 route

distinguisher to every configured VRF
[edit routing- options]
user@Rl# s ho w
!route - distinguisher- id 192 . 168 . 1 . 1 ; !
autonomous-system 65512 ;

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

Manually Assigning the Route Distinguisher per VRF Table

We manual ly assigned the VRF table on the slide a route distinguisher of 192.168.1 .1 :1, which is an example of the Type 1
Route Distinguisher format. Each unique instance of a VRF table on this PE router must be given a unique assigned number
to ensure that overlapping addresses from multiple VPN custome rs do not interfere with each other. This task can become
daunting when dea ling with hundreds of VR F tab les on a single PE router.

Dynamic Assignment of the Route Distinguisher

With this configuration, all VRF tab les configured on this router will have a dynamica lly assigned Type 1 route distinguisher
based on the r oute-di st i ngui s h er- id configured on the slide (fo r example, 192.168.1 .1 :1, 192.168.1.1:2, etc ...) The
function of assigning a unique route distinguisher per VRF table is no longer your responsibility. You can override the
dynamically assigned route distinguisher by manually configuring it under the [ edit r out i ng- i ns t ances v p n - name ]
hierarchy.

For multihomed sites, connected to two or more PEs, it is required to use unique route distinguishers (typical ly type 1 ) on
each PE to allow for load-sharing traffic toward these sites. By using unique route distinguishers, the BGP selection algorithm
will always see the routes as different, for example on route reflectors.

Chapter 4-14 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

VRF Instance Configuration Example

■ Create a VRF table called vpn - a with BGP running between the PE
and CE routers using the vrf-target statement:

[edit routing- instances]

user@Rl# show
vpn-a {
instance - type vrf ;
interface ge - 1/1/4.100 ;
route-distinauisher 192 . 168 . 1 . 1 : 1 ;
vrf-taraet taraet : 65512 : 101;
protocols {
bgp {
group my-ext-group {
type external ;
peer- as 65101 ;
neighbor 10 . 0 . 10 . 2 ;
}
}
}
}

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

A VRF Instance Example

The example on the slide has a sample VRF instance configuration that supports EBGP routing on the PE-CE link. VRF tables
require a routing instance type of vrf.

As reflected on the slide, we configured a single VRF interface (ge-1/ 0/ 4.100). You should take care to specify the correct
logical unit, especially when non-default unit numbers are in use.

We assigned th is VRF table a route distinguisher of 192.168.1.1:1, wh ich is an examp le of the Type 1 route distinguisher
format. In this case, the PE router's loopback address is used as the administration fie ld. Using the PE's router ID (RID) in the
route distinguisher can assist with troubleshooting. You can easily track route advertisements back to the PE that generated
them, based on the route distinguisher. The assigned number for this VRF table is 1. As mentioned previously, each unique
instance of a VRF table on th is PE router must be given a unique assigned number to ensure that overlapping addresses
from multiple VPN customers remain separate.

We linked this VRF instance to a VRF target community. This method is the easiest way to configure advertisements of Layer
3 VPN routes between PE routers. Another method that can be used is to specify the import community and export
community independently (not shown). The import statement causes all received Layer 3 VPN MP-BGP routes tagged with
the correct target community to be placed into the vpn - a . i n et . O table. The export statement causes al l routes in the
vpn - a . i net . o table to be advertised and tagged with the listed target community to all MP-BGP peers.

Finally, the slide shows a standard EBGP configuration under the pro t ocols hierarchy of the VRF instance's configuration.
PE-CE routing protocols are configured for VRF instances the same way as they are configured under the main instance, with
the only differences being their association with a VRF instance. If needed, BGP import and export policies can be applied to
the BGP instance to refine and control the exchange of BGP routes on the PE-CE routing instance (not shown).

www.juniper.net Basic Layer 3 VPN Configuration • Chapter 4-15

Junos Layer 3 VPNs

Another VRF Configuration Example

■ Create a VRF table called vpn - a with BGP running between the PE
and CE routers using vrf-import and vrf-export policies:
[edit routing- instances]
user@Rli show
vpn-a {
instance - type vrf ;
interface ge - 1/1/4 . 100 ;
route-distinguisher 192 . 168 . 1 . 1 : 1;
vrf-import import-vpn - a;
vrf - export export - vpn - a ;
protocols {
bgp {
group my- ext- group {
type external ;
peer-as 65101 ;
neighbor 10 . 0 . 10 . 2 ;
}
)
}
}

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Business Use Only

AnotherVRF Example
The example on the slide shows the use of vrf-import and vrf-export policies rathe r than the vrf-target
statement. This methodology gives an administrator more control over the routes advertised between PE routers, but it
requires more configuration.

We lin ked th is VR F instance to VRF policy statements. The router does not allow a commit until the i mpor t - vpn - a and
export - vpn - a policy statements are c reated under the [edi t pol i cy-opt i ons J hiera rchy. We will define these
policies next.

Chapter 4-1 6 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

VRF Import Policy Example

■ Installs routes learned from other PE routers using
MP-BGP
• Routes with the specified community are installed in the associated VRF table

[edit po l icy- opt i ons]

user@Rl# show
.. .
policy- statement import - vpn - a {
term 1 {
from {
protocol bgp ;
!community vpn- a ; !
}
then accept ;
}
term 2 {
t hen re j ect ;
}
}
community vpn- a members target : 65512 : 10 1;

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

VRF Import Filters Routes Learned from Remote PE Routers

Th is slide provides an example of a typical VRF import policy. A VRF import policy only f ilt ers routes learned from remote PE
routers through the MP-BGP peering sessions.

The te r m 1 of policy i mpo r t-vp n-a matches BGP routes containing the community string defined under the community
name vpn-a. You can also see that the commun ity associated with t his name is a route target extended community. When
a match occurs in te r m 1, the rout e is accepted and installed into the VRF tables linked t o th is policy.

The t e r m 2 of policy impo r t-vp n -a serves as an explicit definition of t he defau lt policy for VRF import; that is, the PE
router rej ects all VPN routes by def ault. Put anot her way, a PE router on ly accepts a VPN route when an explicit rout e target
match occurs in conjunction with an accept action . When dealing with security, it is usually better t o use explicit rather
t han implicit ru les, as explicit ru les tend to avoid the misinterpret ations, which can lead to unexpected connectivity.

www .j uniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 17

Junos Layer 3 VPNs

VRF Export Policy Example

■ This policy advertises routes learned through BGP from the CE
router, and the PE-CE interface, while adding the route target
• Matching routes are sent to MP-BGP peers that have advertised VPN-1Pv4
NLRI capabilities
[edit policy-options]
user@Rl# show
• • •
policy-statement export-vpn-a {
term 1 {
from protocol [ bgp direct] ;
then {
c...,
o_ I
mm_u_n_i t- y- ad-d- vp_n___a _;
,..l

accept ;
}
}
term 2 {
then reject ;
}
}
community vpn-a members target : 65512 : 101 ;

C> 2020 Juniper Networ1<s, Inc All Rights Reserved

Juni per Bu si ness Use On ly

VRF Export Policy Filter Routes Sent to Remote PE Routers

This slide provides an example of a typica l VRF export policy. A VRF export policy is only used to filter routes being advertised
to remote PE routers through the MP-BGP peering sessions.

Term 1 of the policy matches routes learned from BGP, and direct routes (PE-CE interface). Because in this example the
PE-CE routing protocol is BGP, all routes learned f rom the CE router match term 1 of the policy.

Matching routes have the community associated with the named community vpn-a added before being accepted for
advertisement to the remote PE routers. Aga in, you can see that the community being added to the route is a route target
BGP extended community.

As with the VRF import policy, term 2 provides explicit decla ration of the default VRF policy action. Together, the two terms
ensu re that only routes learned from the CE route r using EBGP are accepted for transmission to the remote PE routers with
the proper parameters.

Chapter 4-18 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

Extended BGP Communities

■ The target tag specifies the route target community

• Policy matches on the route target control which routes are imported into a
given VRF table

[edit policy- options]

user@Rl# show
• • •
community vpn- a members !target : 65512 : 10 1;!

■ The origin tag allows the specification of site of origin community

• Site of origin can be used to prevent routing loops when a user has multiple
AS numbers
[edit policy- options)
user@Rl# show

community SoO members l origin : 192 .1 68 . 1 .1:101 ; 1

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

The Route Target Community

Named communities under the [edi t po l i cy-op t i o n s J portion of the configuration hierarchy define extended BGP
communities. The slide shows the syntax for extended community definition.

The route target community is critical to the operation of Layer 3 VPNs because only routes with matching route targets can
be installed into a particular VRF table. This example shows a route target community using the Type O format, which uses a
2-byte administration field-set to the provider's autonomous system (AS) number- followed by a 4-byte assigned number
field.

All members of a VPN setting and matching the same route target is common, but not mandatory.

The Site of Origin Community

The site of origin community associates a route with the site that originates the advertisement. A PE filter uses this
community to filter the advertisement of a route back to the site from which it originated. Site of origin is optional and is only
needed in certain corner cases. A sample application of the site of origin community is shown in subsequent pages.

The site of origin commun ity in the example on the slide uses the Type 1 format using a 4-byte administration field followed
by a 2-byte assigned number field. In th is case, the community is coded with the RID of the PE router that attaches to the CE
device. The community uses the number 101 to distinguish this site from other sites th is PE router might also serve.

www.juniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 19

Junos Layer 3 VPNs

PE-CE Policy

■ Junes OS import/export policies can be applied to VRF instances

• BGP and RIP allow both import and export
• OSPF allows export policies and limits import policies that set priority or filter
OSPF external routes
• Reject action is ignored if applied to a non-external route on an import policy
■ Affects routes being sent and received over the
PE-CE link

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

PE-CE Routing Policy

In addition to the VRF import and export policies, which control the exchange of routes between PE route rs, you can also use
routi ng policy to control the exchange of routes on the PE-CE routing instance. Using BGP or RIP as a PE-CE routing protocol
permits both import and export policies. OSPF can also have export policies, but has limited functionality when implementing
an import pol icy. OSPF import policy can only be used to set priority or to filter OSPF external routes. If an OSPF import policy
is applied that results in a reject terminating action for a non-external route, then the reject action is ignored and the route is
accepted anyway. This behavior prevents traffic black holes, that is, silently discarded traffic, by ensuring consistent routing
within the OSPF doma in.

Affects PE-CE Route Exchange

Routi ng pol icy applied under the pro t ocols portion of a VRF table only affects the routes being exchanged on the local
PE-CE link. To control the exchange of VPN routes between PE routers, VRF import and export policies must exist.

Chapter 4-20 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

PE-CE BGP Routing/Policy Example

[edit routing-instances vpn-a protocols]
user@Rl# show
bgp {
group my- ext - group [
tvoe external ;
import import-cust-a;
peer - as 65 101 ;
neighbor 10 . 0 . 10 . 2 ;
}
}

[edit policy- options]

user@Rl# show
policy-statement import-cust-a {
term 1 {
from protocol bgp ;
then {
community add cust- a ;
accept ;
)
)
}
community cust - a members 65101 : 1 ;

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu siness Use On ly

PE-CE Policy Example

Th is slide provides an example of a PE-CE BGP routing instance using an import policy to alter the properties of the routes
received from the local CE device. The po licy statement import -cust-a accepts all BGP routes into the local VRF table
after adding the community values associated with the named community cust-a.

You can also use route filter statements to accept or rej ect routes explicitly based on the prefix and mask lengths.

www .j uniper.net Basic Layer 3 VPN Configuration • Chapter 4- 21

Junos Layer 3 VPNs

AS Override
■ Use the as-override option when CE routers belong to the same
AS
• Causes the PE router to overwrite CE' s AS number with the provider's AS
number (two provider AS numbers in AS path)
■ The autonomous-system loops n option can also be used on
the CE router -
• advertise-peer-as needs to be configured on the PE
■ remove-private can also work if private AS numbers are in use
Provider Core
AS 65512
Site 1 )I'---~
AS 65101
OSPF Area O

R2
- Site 2
AS 65101

Site1 ~ -· ·1 .1 .2 ~ -2 .1 .1
~ ) 10.0.10.0/24 • 172.22.210.0/24 'i!r 172.22.212.0/24 0.0.11.0/24
eE p PE

_______,,~
CE-
lo ~i.-f68.11 .1
---~
..........__..._
C> 2020 J uniper Networks, Inc All Rights Reserved
Juniper Bu si ness Use On ly

Customer Sites with a Common Autonomous System Number

Because BGP uses the AS-path attribute to detect loops, problems can arise when VPN sites use the same AS number, as
the CE routers ordinarily discard routes indicating an AS path loop. When sites are assigned the same AS number, the
as-override configuration option is one way of supporting the interconnection of custome r sites using EBGP as the PE-CE
routing protocol (as-ove r r i de is configured on the PE router, under the p r otocol s b gp hierarchy within the VRF
routing instance).

PE Router Overwrites Site's AS Number

In operation, t he egres.s PE router configured to perform the AS override f unction replaces the AS number added by the
originating VPN site with a second copy of the provider's AS number. This replacement results in two provider AS numbers in
the AS-path attribute when the route is delivered to the destination site. The sl ide shows the operation, where the
192.168.11.1/ 32 route is delivered to CE-B, with two instances of AS 65512 at the f ront of the AS-path attribute.

Allowing AS Loops
The Ju nos OS a lso supports the explicit all owance of AS loops by setting the auto nomous-system loops B. pa rameter
under the BGP routing instance. When configured on the CE router, this parameter allows the CE router to install the
VPN-learned routes in its routing table by ignoring up to Q instances of its own AS in the AS path attribute of rece ived routes.

By default, t he Ju nos OS does not advertise routes whose AS path attribute contains t he peer's AS. Because of th is default
behavior, the auto nomous-system loops B. solution also requi res that the PE router be configured with the
adv ertise-peer-as parameteratthe [edit p r otoco l s b gp group group - name n e i ghbor x . x . x . x ]
hiera rchy. This parameter causes t he PE router to include routes whose AS path attribute contains the CE router's AS number
in its advertisements the CE router.

Remove Private
The remo ve-private option provides yet another way of solving the problem, but only when the customer sites use AS
number f rom the private-use AS numbering space. In this case, you co uld enable remove-priv ate under the PE router's
main BGP routing instance. Enabl ing remove-private causes the PE router to remove any private AS numbers from the
front of the AS path when sending MP-BGP updates to remote PE routers.

Chapter 4 -22 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

CE-PE IBGP: Independent Domain

■ Use this setting when CE routers belong to the same AS and IBGP is
used between CE and PE routers
• Causes the PE router to use an attribute called ATTRSET to carry customer
attributes across provider network
• Customer's attributes are restored or preserved when advertised to the remote
CE router
• Allows any EBGP peers of the customer to see only the customer's attributes,
not the provider's
Provider Core
Site 1 AS 65512 Site 2
AS 65101 OSPF Area 0 AS 65101
R1 ~ R3 ~
Site 1 ~·· I .1 ~ -1 .2 ~ -2 .1 ~..;..;.·1- . - - - -i-~· s :te2'
'ilr. } 10.0.10.0/24 'i!r 172.22 210 0/24 ~ · 172.22.212.0/24 ·~ ~
10.0.11 .0/24
CE-K ~ P PE CJ::-B
~ _,___ _ _ _.....
100 1921 '68'"'1-H
loO 192.168.11.1
Route-192.168.11.1 Route-192.168.1 1.1
Route-192 .168 .11 .1 AS Path I (PE Path) / AS Path I (CE Path) a----.
AS Path I (CE path) ATTRSET AS I (CE Path)
PE router copies attributes contained in A TTRSET
attribute into the IBGP advertisement sent to CE
rou ter
C> 2020 Juniper Networ1<s, Inc All Rights Reserved
Juni per Bu si ness Use On ly

Independent Domain Setting

Here is a sample configuration of independent-domain on R1:

[ edit r ou t ing- instances vpn-a]

user@Rl# sho w
instance- t ype v rf;

rou t ing-opt i ons {

au t o nomous-sys t em 6510 1 indepe ndent-doma in;
}
[ edit r ou t i ng -opt i ons ]
user@Rl# show
au t o nomous-system 65512 ;
As defined in draft-marques-ppvpn-ibgp-version.txt, th is setting allows the PE rout ers to preserve the customer's attributes
by storing them in the ATTRSET attribute because the routes cross the provider's backbone. Normally, without setti ng
independent-domain, the provider's attributes are added to the customer's routes . In the example on the slide, the
independent-domain setting allows the remote PE router to advertise routes to the remot e CE router using the routes'
original attributes. Without the use of independent-domai n on R1 , the routes advertised from R3 to CE-B, would contain
an AS path of 65512 65101. This wou ld cause CE-B to detect an AS-pat h loop and drop the routes. Also, if CE-B allowed for
AS-path loops as described on the previous slide, any downstream EBGP peers of the customer's wou ld evaluat e these
routes as being three AS hops away (that is, AS path= 65101 65512 65101.)

www .j uniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 23

Junos Layer 3 VPNs

Site of Origin
■ Use site of origin when CE router is dual-homed and as-override
is required (corner case)
• as-override needed to exchange routes between sites
■ Site of origin (and policy) prevents advertising routes back to the
source
• Advertising these routes back to the CE router can cause forwarding loops
with equipment that prefers EBGP over !GP-learned routes
Provider Core Routes advertised with SoO
AS65512
OSPF Area O
R2 ,,,, - - -
community192.168.1.3:1
_____ ! R3

·1- @ 3 ·1
.

1 0/2 ,
crs
.1 2 ~J 22
212.0/24 . 10.0.1 .
172.22.210.0/24 • . 172· · PE Site 2
PE p , 1?2_-,,., R4 AS65101
.... <<.213
Provider Loopbacks
192.168.1 .x
............... :._0124
8
......... .,.
· .4 .1

PE
10
.O. 12.012
4
Routes rejected by
R4' s VRF import policy

C> 2020 Juniper Networks. Inc All Rights Reserved

Juniper Bu si ness Use On ly

Dual-Homed Sites Using as-override

In the example on the slide, we see a two-site VPN, where one of the sites is dual-homed to two different PE routers. If the
sites were using different AS numbers, then use of the site of origin comm unity wou ld not be required as routes originated by
Site 2 would be rej ected based on AS loop detection if they should ever be advertised back to Site 2. In this example,
however, because both sites use the same AS number, the as-override option is needed so that the routes being
exchanged between Sites 1 and 2 are not rejected due to AS path-based loop detection.

The resulting scenario is one example of a corner case where you might use the site of origin community.

Preventing Inefficiencies and Potential Loops

In operation, t he VRF export policy of the R3 is set to add the site of origin community to the routes it rece ives from CE-8. This
community uses the Type 1 format, with the PE router's RID used as the administrator f ield . The assigned number, wh ich is 1
in th is case, is associated with Site 2 .

The VR F import policy statements of R4, match and reject routes having th is particular community. The result is that routes
learned f rom Site 2, CE-B, are filtered upon receipt by R4, so they are not sent back to Site 2 . To comp lete the application,
similar VRF export and import pol icies are applied on the R4 and R3 routers so that both PE ro uters prevent routes from
being sent back to Site 2.

In some cases, the use of site of origin as shown in this application just makes t hings more efficient in that it elim inates the
unnecessary transmission of route updates to Site 2 . This elimination of unnecessary transmission in turn prevents t he BGP
speakers in Site 2 from having to ca rry duplicate BG P routing information. In other cases, t he use of site of origin can be
necessary to prevent forwarding loops. Some vendors prefer EBGP routes over IGP routes (the Junos OS does not), wh ich
co uld resu lt in a fo rwarding loop when routes learned from a site are redistributed back to that site using EBGP.

Chapter 4-24 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

PE-CE OSPF Routing

■ Requires a separate OSPF process for each VRF table

■ Carries OSPF routes across backbone as BGP routes

■ Uses the OSPF sham link to advertise OSPF routes between

customer sites

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly
Jun1Per
NIITWOkl<S
2s

OSPF Routing
The support of OSPF routing on the PE-CE link requires a sepa rate OSPF process for each VRF t ab le. You conf igure t hese
processes under the pro t ocol s portion of a VRF table conf iguration. The actua l steps required to conf igure an OSPF
inst a nce in th is case are no different from the steps needed to configure t he main OSPF routing instance.

OSPF Routes Transported Between PE Routers Using MP-BGP

Routes learned from t he CE device us ing OSPF are sent to remote PE routers as labeled VPN routes using MP-BGP. The
receiving PE router can red istribut e these routes to its attached CE device using OSPF or another rout ing protoco l, such as
BGP or RIP.

Sham Link
RFC 4577 allows f or a sham link to advertise OSPF routes between CE routers t hat are ru nning OSPF with their loca l PE
routers. We wi ll d iscuss t h is method next.

www .j uniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 25

Junos Layer 3 VPNs

PE-CE OSPF Using a Sham Link

■ Can be used only when carrying OSPF routes between CE routers
within the same OSPF domain
■ Flooding of OSPF LSAs is automatic
• Sham link appears as a point-to-point link between the PEs
• Point-to-point link within customer's OSPF domain
• Can be assigned a metric
• OSPF packets (hellos, LS updates, and so forth) are tunneled across MPLS
LSPs between PE routers
• vrf - target or vr f - import/exp ort policy still required

Provider Network
PE PE
·- CI,-
OSPF Sham Link

C> 2020 Juniper Networ1<s, Inc All Rights Reserved

Juni per Bu si ness Use On ly

Using Sham Links

A sham link can be used when the CE routers belong to the same OSPF domain but not necessarily the same OSPF area. The
sham link essentially mocks an unnumbered point-to-point link within the VRF routing instance between PE routers.

Automatic Flooding of OSPF LSAs

Normally, a PE router must redistribute the VPN routes it has learned through its MP-BGP peering sessions into OSPF as
externa l routes (LSA Type 5/ 7) or summary routes (LSA Type 3 ). In the case of a sham link, once it is operational, OSPF
packets are tunneled between PE routers using the MPLS LSPs that are established between them. A PE router learning the
MPLS-tunneled LSAs from a remote PE router floods those LSAs to the local CE router. This behavior allows Type 1 and Type
2 LSAs to be passed across the VPN between CE routers.

Although a PE router learns routes from the remote PE router using OSPF, it cannot use the OSPF routes for forwarding and
instead must use MP-BGP learned routes to forward traffic to the remote site. Thus, a PE router must not only learn the
routes using OSPF, but it must also learn the same routes using MP-BGP.

Chapter 4-26 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

OSPF Sham Link Example (1 of 2)

[edit routing-instances vpn-a] loO . 1 added to vrf to be used as router ID
user@Rl# show for tunneled OSPF packets
instance - type vrf ;
interface ae - 1/1/4 .1 00 ,·~.....-
interface lo0 . 1;
route - distinguisher 192.168.1.1:1;
vrf - target target:65512:101;
protocols {
ospf_..{_ _ _ _ _ _ _ _ _ _ __
!sham- link local 192 . 168.11.3;! . - - - - - - - -
area 0 . 0 . 0 . 0 {
sham-link-remote 192 . 168 . 11 . 4 metric 1 ;
interface ge-1/ 1/4 .1 00 ;
interface lo0.1;
}
} Source address of tunneled OSPF packets.
} which must also be advertised using MP-BGP
[edit interfaces loO]
user@Rl# show
...
unit 1 {
family inet {
!address 192 . 168 .1 1 . 3/32 ; )
}
}
C> 2020 Juniper Networks. Inc All Rights Reserved
Juni per Bu si ness Use On ly

OSPF Sham Link Example: Part 1

Th is slide shows a VRF table configured to support OSPF operation on the PE-CE link as well as a sham link between PE
ro uters. The OSPF sham link's local address must be the loopback VPN interface for the local VPN. To be reachable by the
remote PE router, this loopback address must be advertised using MP-BGP (solved with the vrf- t arget statement in the
slide.) The OSPF sham link's remote address must be a loopback VPN interface on the remote PE router.

www .juniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 27

Junos Layer 3 VPNs

OSPF Sham Link Example (2 of 2)

user@Rl> show ospf interface instance vpn - a
Interface State Area DR ID BDR ID Nbrs
ge - 1/1/4 . 100 DR 0. 0. 0. 0 192.168 . 11 . 3 192 .1 68 . 11 . 1 1
lo0 . 4 Waiting 0 . 0 . 0 . 0 0.0. 0.0 0.0.0 .0 0
shamlink . O PtToPt o. o. o. o o.o. o.o o.o.o.o 1

user@Rl> show ospf neighbor instance vpn-a

Address Interface State ID Pri Dead
10 . 0 . 10 . 2 ge-1/1/4 . 100 Full 192 . 168 . 11 . 1 128 34
192 . 168 . 11.4 shamlink . 0 Full 192.168 . 11 . 4 0 33

user@Rl> show ospf database instance vpn-a Router LSA for local CE. local PE.
remote PE. and remote CE routers
OSPF database , Area 0 . 0 . 0 . 0
Tvoe ID Adv Rtr Sen Ane Ont Cksum Len
Router 192 . 168 . 11 . 1 192 . 168 . 11 . 1 Ox80000006 2386 Ox22 Oxf799 48
Router 192 . 168 . 11 . 2 192 .1 68 . 11 . 2 Ox80000007 59 Ox22 Ox1279 48
Router *192 . 168.11 . 3 192 .1 68 . 11 . 3 Ox80000006 2376 Ox22 Ox9a6f 48
Router 192 . 168 . 11 . 4 192 . 168 . 11 . 4 Ox80000006 2377 Ox22 Ox8a7c 48
Network 10 . 0 . 10 . 2 192 . 168 . 11 . 1 Ox80000002 450 Ox22 Oxlba5 32
Network 10 . 0 . 11 . 2 192 .1 68 . 11 . 2 Ox80000002 343 Ox22 Ox229a 32

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

OSPF Sham Link Example: Part 2

This slide d isplays some of the operational commands to help troubleshoot and verify OSPF sham links. Notice in the sho w
o spf neighbo r command that the local PE router has formed an adjacency with the remote PE router over the sham link.
The topo logy used in the example is simply two CE routers, one P router, and two PE routers. Each router is an OSPF Area
0.0.0 .0 internal router for the VPN. Notice in the output of the sho w o spf database command that exactly four router
LSAs are advertised representing each of the four routers in Area 0 .0 .0 .0 .

Chapter 4 -28 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

Basic OSPF VRF Table Example

[edit routing-instances vpn-a]
user@Rl# show
instance- type vrf ;
interface ge - 1/1/4 . 100 ;
route-distinguisher 192 . 168 . 1 . 1 : 1 ;
vrf-import import- vpn - a ;
vrf - export export- vpn - a ;
protocols {
ospf {
-,e-x-p o_ r_t_ e-xp_o_r_t _- -c u_ s_t__-a...
;!
area 0 . 0 . 0 . 0 { '~
interface all ; _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
} An export policy is req uired!
} OSPF does not red istribute BGP routes by default
}

[edit policy-options]
user@Rl# show
fpolicy- statement e xport - cust- a ! {
term 1 {
from protocol bgp ;
then accept ;
}
}

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

OSPF VRF Table Example

This slide shows a VRF table configured to support basic OSPF operation on the PE-CE link. You can assume that the VRF
import policy matches BGP routes, and that the VRF export po licy matches OSPF routes (the actual VRF policies are
discussed in the next slide).

As indicated, you must specify an export policy under the OSPF instance to allow the red istribution of BGP into OSPF. This
policy is needed because, between PE routers, al l routes are learned through the BGP protocol, regardless of what protocol is
being used on the PE-CE link.

The actual configuration of the OSPF instance is really no d ifferent from the configuration of a main OSPF routing instance.
You must specify the OSPF area number and list the VR F interfaces belonging to that area.

www .j uniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 29

Junos Layer 3 VPNs

VRF Policies When Using OSPF

[edit policy-options]
user@RlJt s h o w
policy- statement export - vpn - a {
term
1
{
!from protocol ospf ; !◄·
---1J1 The protocol match criteria is OSPF )
-
then {
community add vpn- a ;
accept ;
}
)
term 2 {
then reject ;
)
)
policy- statement import - vpn - a {
term 1 {
from {
protocol bgp ;
community vpn - a ;
)
then accept ;
)
term 2 {
then reject ;

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

Examples of VRF Policies for OSPF Support

This slide shows the VRF import and export policy needed to ensure that routes learned from the CE device using OSPF are
sent to remote PE routers, and that routes learned from remote PE routers using MP-BGP are accepted and insta lled into the
local PE router's VRF table.

These two policies get the routes to and from the PE routers, but remember that a BGP redistribution policy is needed to get
the BGP routes learned from remote PE routers sent to the local CE device running OSPF.

Chapter 4-30 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

OSPF Configuration Results

■ Routes are advertised to the CE device as:
• AS-external (Type 5)
• When received as AS-external
• When OSPF domain IDs do not match
• Summary LSAs (Type 3)
• When received as Type 1, 2, or 3 LSA and domain IDs match (lack of domain ID causes
implicit match)
user@CE - A> show ospf database
OSPF database , Area 0 . 0 . 0 . 0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 1 0 . 0 .1 0 . 1 10 . 0 .1 0 . 1 Ox80000004 2294 Ox22 Oxld6 36
Router *1 92 . 168 . 11 . 1 192 . 168 . 11 . 1 Ox80000004 2293 Ox22 Oxfb97 48
Network *JO . O. J0 . 2 192 . 168 . 11 . J Ox80000002 2293 Ox22 Ox30f2 32
Summary 10 . 10 . 10 . 0 10 . 0 . 10 . 1 Ox80000002 1581 Oxa2 Ox482 28
Summary 10 . 10 . 11 . 0 10 . 0 . 10 . 1 Ox80000002 1174 Oxa2 Oxf88c 28
Summarv 192 . 168 . 11 . 2 10 . 0 .1 0 . 1 Ox80000002 766 Oxa2 Ox240b 28
OSPF AS SCOPE link state database
Tvoe ID Adv Rtr Sen Ane Ont Cksum Len
Extern 200 . 200 . 200 . 0 10 . 0 .1 0 . 1 Ox80000002 359 Oxa2 Ox3ld6 36
Extern 201 . 201 . 201 . 0 10 . 0 . 10 . 1 Ox80000001 2307 Oxa2 Oxff6 36

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

OSPF Routes Presented as Summary and External LSAs

The result of this basic PE-CE OSPF configuration is shown on the sl ide where the contents of CE-A's OSPF link-state
database (LSDB) are displayed. Because this basic example does not make use of the OSPF domain ID community, the R1
PE router assumes that the remote CE router belongs to the same OSPF domain and presents them as summary LSAs to the
attached CE router when the ir route type does not indicate externa l.

As a result, the remote CE router's externa l routes (the 200.200 .200/ 24 and 201.201.201/ 24 prefixes), which are being
redistributed from static into OSPF, are presented as externa l LSAs (Type 5s), wh ile the remote CE router's internal OSPF
routes (the 192.168.11.2 loopback address, the 10.10.10/ 24, and the 10.10.10.11/ 24 OSPF interface routes not shown on
the topology) appear in the receiving CE router as OSPF summary routes (LSA Type 3s).

Subsequent slides detail the operation of the OSPF domain ID and show the effect of mismatched domain IDs on these
same routes.

www .juniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 31

Junos Layer 3 VPNs

Agenda: Basic Layer 3 VPN Configuration

• Preliminary Steps
• PE Router Configuration
➔ Basic Layer 3 VPN Verification

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly
Jun1Per
NET\\()kl(S
32

Basic Layer 3 VPN Verification

The slide highlights the topic we d iscuss next.

Chapter 4-32 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

Examining Routes in a VRF Table

■ Junes OS allows the viewing of a VRF table with the show route
table vpn-name command
• VRF tables contain:
• The matching routes learned from remote PE routers
• Routes learned over the PE-CE link or static routing entries
■ The bgp . l 3vpn . o table contains all routes learned from other PE
routers with at least one matching route target
• Functions as a RIB-In for VPN routes
• Discards NLRI updates that do not match at least one VRF table
• keep all is useful for troubleshooting route target-related problems-use
only for troubleshooting!
■ The show route protocol bgp command displays all BGP
routes in all RIBs
• Output can be filtered by providing a prefix/mask or by piping to match or
f ind
C> 2020 Juniper Networ1<s, Inc All Rights Reserved
Juni per Bu si ness Use On ly

Viewing VRF Tables

You can view the contents of a specific VRF tab le using the show r o ute table vpn-name operational command. This
table shows entries learned from the local CE router (or static route definitions) as well as routes learned from the remote PE
routers having matching route targets.

The bgp .13vpn. 0 Table

The bgp . 13vpn. o table houses routes learned from all remote PE routers having at least one matching route target. This
table functions as a RIB-In for VPN routes that match at least one local route target. When troubleshooting route
target-related problems, enable the keep a ll option under the BGP configuration stanza. This option places all received
VPN routes into the bgp . l 3vpn. o table, rega rdless of whether matching route targets are present. Do not leave this option
enabled in a production PE router, however, due to the increased memory and processing requ irements that can result. In
normal operation, a PE router should only house VPN routes that relate to its directly connected sites.

A Shortcut
By issuing a sho w r oute pro t ocol bgp command, you can view all BGP routes, regardless of the table in which they
are placed . This approach proves helpful when you cannot recall the exact name of a particular VPN's routing instance. You
can include a prefix and mask pair to filter some of the output; you also can use the pipe command in conjunction with the
match or fi n d arguments.

www .juniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 33

Junos Layer 3 VPNs

Viewing the Route Table Example (1 of 2)

user@PEl> show route table vpn-a

vpn - a . inet . 0 : 12 destinations, 12 routes (12 active , 0 holddown , 0 hidden)

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

10 . 0 . 20 . 0/24 *[Direct/OJ 23 : 29 : 10
> via ge- 1/0/4 . 620
[BG P/170 J 22 : 48 : 41 , localpref 100
AS path : 65201 I , validation-state : unverified
> to 10 . 0 . 20 . 2 via ge - 1/0/4 . 620
10 . 0 . 20 . 1/32 *[Local/OJ 23 : 29 : 10
Local via ge-1/0/4 . 620
10 . 0 . 21 . 0/24 *[BGP/170J 22 : 59 : 10 , localpref 100 , from 193 . 168 . 2 . 2
AS path : I , validation- state : unverified
> t o 172 . 22 . 220 . 2 via ge - 1/0/0 . 220 , label - switched- path lspl
172 . 20 . 0 . 0/24 *[BG P/170] 22 : 4 8 : 41 , localpref 100
AS path : 65201 I , validation-state : unverified
> to 10 . 0 . 20 . 2 via ge - 1/0/4 . 620
172 . 20 . 1 . 0/24 *[BG P/170] 22 : 4 8 : 41 , localpref 100
AS path : 65201 I , validation-state : unverified
> to 10 . 0 . 20 . 2 via ge-1/0/4 . 620

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu siness Use Only

Viewing VRF Tables: Part 1

This slide provides an example of how you can view a loca l VRF table. In th is case, vpn-a is the name of the VRF instance.
The resulting display shows the local VRF routes and routes learned from the local CE router using EBGP, and routes learned
from the remote PE router using MP-IBGP. It is easy to tell the difference between the two sources of BGP routes because
routes learned from remote PE routers always point to an LSP as the next hop.

Chapter 4-34 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

Viewing the Route Table Example (2 of 2)

user@PEl> show route table vpn-a 172.20.4.0 detail

vpn-a . inet . O: 12 destinations , 12 routes (12 active , 0 holddown , 0 hidden)

172 . 20 . 4 . 0/24 (1 entry, 1 announced)
*BGP Preference : 170/ - 101
Route Distinguisher : 193 . 168 . 2 . 2 : 1
Next hop type : Indirect
Address : Ox27c8c3c
Next-hop reference count : 18
Source : 193 . 168 . 2 . 2
Next hop type : Router , Next hop index : 643
Next hop : 172 . 22 . 220 . 2 via ge - 1/0/0 . 220 weight Oxl , selected
Laoel-swiccnea-path 1sp1
Label operation : Push 299904 , Push 300080(top)
Label TTL action : prop- ttl , prop - ttl(top)
Session Id : Ox108
Protocol next hop : 193 . 168 . 2 . 2
Push 299904
Indirect next hop : 2868000 1048575 INH Session ID : Ox113

! Communities : targ et : 65512 : 2 !

Import Accepted
VPN Label : 299904
Localpref : 100

C> 2020 Juniper Networks, Inc All Rights Reserved

Ju-niper Business Use Only

Viewing VRF Tables: Part 2

This slide shows the optional prefix/ mask pair and the detai l switch added to t he same command as the preced ing slide.

Here, the 1 72.20.4.0/ 24 rout e is associated with two labels. The BGP next hop is the PE2 router (193.168.2 .2). This next
hop is associated with an LSP named lspl .

www .j uniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 35

Ju nos Layer 3 VPNs

Viewing the bgp .13vpn. 0 RIB

• Displays all Layer 3 VPN NLRI with at least one matching route
target
• keep all useful for troubleshooting
• Enabled by default on route reflectors
• Must be explicitly set on confederation C-EBGP speakers
user@PE l > show route table bgp.13vpn

bgp . 13vpn . 0 : 6 destinations , 6 routes (6 active , 0 holddown , 0 hidden)

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

193 . 168 . 2 . 2 : 1 : 10 . 0 . 21 . 0/24

* [BGP/170] 23 : 03 : 17 , localpref 100, from 193 . 168 . 2 . 2
AS path : I , validation - state : unverified
> to 172 . 22 . 220 . 2 via ge-1/0/0 . 220 , label - switched-path lspl
193 . 168 . 2 . 2 : 1 : 172 . 20 . 4 . 0/24
*[BGP/170] 22 : 56 : 06 , localpref 100, from 193 . 168 . 2 . 2
AS path : 65201 I , validation-state : unverified
> to 172 . 22 . 220 . 2 via ge - 1/0/0 . 220 , label - switched- path lspl
193 . 168 . 2 . 2 : 1 : 172 . 20 . 5 . 0/24
*[BGP/170) 22 : 56 : 06 , localpref 100, from 193 . 168 . 2 . 2
AS path : 65201 I , validation - state : unverified
> to 172 . 22 . 220 . 2 via ge-1/0/0 . 220 , label-switched-path lspl

C> 2020 Juniper Networks, Inc All Rights Reserved

Ju niper Bu si ness Use On ly

Viewing the bgp . 13vpn . o Table

Th is slide shows the output associated with the viewing of the bgp. l 3vpn . o routi ng t able. This t able holds all received
MP-IBGP routes conta ining at least one matching route target. Note that t he routes in the bgp . 1 3vpn. o table have the
8-byte route distinguisher associated with the VPN prefixes. Also, the route d istinguisher is only used in the control plane.

The keep al 1 option forces the PE router to retain all VPN route advertisements, which can assist with route target-related
troubleshooting. Route reflectors have t he keep all option enabled by default because t hey do not maintain VRF tables
and can therefore never be expected to fi nd rout e t arget matches. When using confederations, t he C-EBGP speakers must
have this option explicitly set so that all VPN routes are exchanged across sub-confederation boundaries.

The example here is from the PE1 router. The route distinguisher indicates that the PE2 router originated the routes because
the route distinguisher is coded based on the originating PE router's loopback address in these examples.

Chapter 4-36 • Basic Layer 3 VPN Configu ration www.j uniper.net

 Junos Layer 3 VPNs

Viewing Routes Sent to Other PE Routers

•Usetheshow route advertising-protocol bgp peer-
address command
user@PEl > show route advertising-protocol bgp 193.168.2.2 172.20/16 detail

vpn-a . inet . O: 12 destinations , 12 routes (12 active , O holddown , 0 hidden )

* 172 . 20 . 0 . 0/24 (1 entry , 1 announced)
BGP group my- int- group type Internal
Route Distinguisher : 193 . 168 . 2 . 1 : 1
VPN Label : 299952
Nexthop : Self
Flags : Nexthop Change
Localpref : 100
AS path : (65512] 65201 I
l
!communities : targ et : 65512 : 2

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu siness Use On ly

Viewing PE-PE Route Advertisements

You can use the sho w r o ute advertising-proto c o l bgp peer-address command to view the route
advertisements being sent to a remote PE router. In this example, the provided prefix/ mask pair and the optional d e ta il
switch control the output.

The resulting output displays the route distinguisher, the assigned VR F label, and the communities attached to the route.

www .juniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 37

Junos Layer 3 VPNs

Viewing Routes Received from Other PE Routers

•Use the show route receive-protocol bgp peer-address
command
user@PEl> show route receive-protocol bgp 193.168.2.2

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

...
l~ n-a . inet . o :1 12 destinations, 12 routes (12 active , 0 holddown , 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10 . 0 . 21 . 0/24 193 . 168 . 2 . 2 100 I
* 172 . 20 . 4 . 0/24 193 . 168 . 2 . 2 100 65201 I
* 172 . 20 . 5 . 0/24 193 . 168 . 2 . 2 100 65201 I
* 172 . 20 . 6 . 0/24 193 . 168 . 2 . 2 100 65201 I
* 172 . 20 . 7 . 0/24 193 . 168 . 2 . 2 100 65201 I
* 193 . 168 . 12 . 2/32 193 . 168 . 2 . 2 100 65201 I

l bgp . 13vpn . o :I 6 destinations , 6 routes (6 active , 0 holddown , 0 hidden)

Prefix Nexthop MED Lclpref AS path
193 . 168 . 2 . 2 : 6 : 10 . 0 . 21 . 0/24
* 193 . 168 . 2 . 2 100 I
193 . 168 . 2 . 2 : 6 : 172 . 20 . 4 . 0/24
* 193 . 168 . 2 . 2 100 65201 I
193 . 168 . 2 . 2 : 6 : 172 . 20 . 5 . 0/24
* 193 . 168 . 2 . 2 100 65201 I
C> 2020 Juniper Networks. Inc All Rights Reserved
Juniper Business Use Only

Viewing Routes Learned from Remote PE Routers

You can use the show route receive-protocol bgp peer-address command to v iew the route advertisements
being received from the remote PE router specified on the command line.

In th is example, the loca l PE router has received the 172.20.4.0/ 24 prefix from 193.1 68.2 .2 . Because th is route has a
matching route target, it is copied into both the bgp .13vpn. o tab le and the vpn-a VRF table, wh ich matches that route
ta rget.

Chapter 4 -38 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

Viewing a VPN Forwarding Table

■ Use the show route forwarding-table vpn vpn-name
command
user@PEl> show route forwarding- table vpn vpn- a
Routing table : vpn- a . inet
Internet :
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 626 1
0.0 . 0 . 0/32 perm 0 dscd 624 1
10 . 0 . 20 . 0/24 intf 0 rslv 647 1 ge-1/0/4 . 620
10 . 0 . 20 . 0/32 dest 0 10 . 0 . 20 . 0 recv 645 1 ge-1/0/4 . 620
10.0.20 . 1/32 intf 0 10.0.20 . 1 locl 646 2
10 . 0 . 20 . 1/32 dest 0 10 . 0 . 20 . 1 locl 646 2
10 . 0 . 20 . 2/32 dest 1 80 : 71 : lf : c3 : 7 : 7c ucst 648 9 ge-1/0/4 . 620
10 . 0 . 20 . 255/32 dest 0 10 . 0 . 20 . 255 best 644 1 ae-1/0/4 . 620
10 . u . 21 . u/24 user u inar 1,1 n"!:>1!:> I
172 . 22 . 220 . 2 Push 299904 , Push 300080/tori\ 643 2 ae-1/0/0 . 220
172 . 20 . 0 . 0/24 user 0 10 . 0 . 20 . 2 ucst 648 9 ge-1/0/4 . 620
172 . 20 . 1 . 0/24 user 0 10 . 0 . 20 . 2 ucst 648 9 ge- 1/0/4 . 620
172 . 20 . 2 . 0/24 user 0 10 . 0 . 20 . 2 ucst 648 9 ge-1/0/4 . 620
172 . 20 . 3 . 0/24 user 0 10 . 0 . 20 . 2 ucst 648 9 rre-1/0/4 . 620
72 . 20 . 4 . 0/24 user 0 indr 1048575 7
172 . 22 . 220 . 2 Push 299904 , Push 300080(top) 643 2 ge- 1/0/0.220
.72 . 20 . 5 . 0/24 user 0 indr 1048575 7
172 . 22 . 220 . 2 Push 299904 , Push 300080(top) 643 2 ge-1/0/0 . 220
. . .

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Business Use Only
Juna?~f 39

Viewing VRF Tables

You can use the show r o ute f o rwarding-table vpn vpn-name command to view the forwarding table associated
with the specified VR F instance. This command is useful because of its compact (and dense) d isplay, wh ich is easier to
parse through when compared to viewing received routes with the sho w r o ute commands.

The resulting output shows local forwarding tab le entries as well as entries for routes learned from remote PE routers .

www .j uniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 39

Junos Layer 3 VPNs

Clearing VRF ARP Entries

■ Use the clear arp vpn vpn-name command
user@PE l > show arp
MAC Address Address Name Interface Flags
80 : 71 : lf : c3 : 07 : 64 10 . 0 . 20 . 1 10 . 0 . 20 . 1 ge-1/1/4 . 620 none
80 : 71 : lf : c3 : 07 : 7c 10 . 0 . 20 . 2 10 . 0 . 20 . 2 ge- 1 /0/4 . 620 none
50 : c5 : 8d : 87 : 8b : 3a 172 . 22 . 220 . 2 172 . 22 . 220 . 2 ge - 1 /0/0 . 220 none
Total entries : 3

user@PE l > clear arp

172 . 22 . 220 . 2 deleted

user@PEl> clear arp vpn vpn-a

10 . 0 . 20 . 1 deleted
10 . 0 . 20 . 2 deleted

■ The show arp command displays both inet. O and VRF ARP
entries

C> 2020 Juniper Networks. Inc All Rights Reserved

Ju niper Bu si ness Use On ly

Clearing VRF ARP Entries

When needed, you can flus h ARP entries associated with a VRF instance by including the VPN name as an argument to the
c l ear arp command. The slide shows VRF ARP entries both before and after the VRF ARP cache is cleared . It also shows
that the c l e a r arp command by itself on ly affects ARP entries associated with the main routing instance.

The show arp Operational Command

To display ARP entries in both the main routing instance and for VRF instances, use the show arp operational command.

Chapter 4-40 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

Monitoring PE-CE BGP Operation

■ Use the standard BGP CLI operational-mode commands:

•show bgp neighbor ce
•show bgp summary
•show route advertising-protocol bgp ce
•show route receiving-protocol bgp ce
•show route protocol bgp source-gateway ce
■ Standard Junes OS tracing options available for PE-CE routing
instance

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu siness Use On ly

PE-CE BGP Monitoring Uses Standard Commands

You can use the standard set of BGP-related CLI operationa l-mode commands to monitor and troubleshoot BGP instances
operating over a VRF interface.

BGP Tracing
When needed, you can configure standard protocol tracing under the VRF table's BGP instance to provide additional
debugging information.

www .juniper.net Basic Layer 3 VPN Configuration • Chapter 4-41

Junos Layer 3 VPNs

Monitoring PE-CE OSPF Operation

■ Use the instance switch when issuing OSPF operational
commands
■ Tracing operations can be performed on OSPF instances
user@PEl> show ospf interface instance vpn-a
Interface State Area DR ID BDR ID Nbrs
ge- 1/0/4 . 620 BDR 0.0.0.0 193.168 .1 2 . 1 10 . 0 . 20 . 1 1

user@PEl> show ospf neighbor instance vpn-a

Address Interface State ID Pri Dead
10 . 0 . 20 . 2 ge-1/0/4 . 620 Full 193 . 168 . 12 . 1 128 38

user@PEl> show ospf database instance vpn-a

OSPF database , Area 0 . 0 . 0 . 0

Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10 . 0 . 20 . 1 10 . 0 . 20 . 1 Ox80000005 56 Ox22 Oxfed7 36
Router 193 . 168.12.1 193.168.12.1 Ox80000004 57 Ox22 Ox589 48
Network 10 . 0 . 10 . 2 1 93 . 168 . 12 . 1 Ox80000002 437 Ox22 Ox32ee 32
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *10 . 0 . 21 . 0 10.0.20.1 Ox80000001 56 Oxa2 Ox73da 36
Extern 172 . 20 . 0 . 0 193 . 168 . 12 . 1 Ox80000001 482 Ox22 Oxe496 36
Extern 172 . 20 . 1 . 0 193.168 . 12.1 Ox80000001 482 Ox22 Oxd9a0 36

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu siness Use On ly

Use the instance Switch When Monitoring OSPF

When monitoring the operation of a PE-CE OSPF instance, you must include the instance switch with a VRF instance as an
argument. With the exception of needing instance specification, the standard set of OSPF-related CLI operational-mode
commands are ava ilable for OSPF monitoring and troubleshooting.

OSPF Tracing
When needed, you can configure standard protocol tracing under the VRF table's OSPF instance to provide additional
debugging information.

Chapter 4-42 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

The routing-instance Command

■ VRF interface is not installed in inet . o

■ The routing - instance switch associates the packet with a
particular VRF table
• Intended for local PE-CE communications using Telnet, SSH, pings,
traceroute, and FTP
user@PEl> ping 10.0.21.2 count 1
PING 10 . 0 . 21 . 2 (10.0 . 21 . 2) : 56 data bytes
ping : sendto : No route to host

--- 10 . 0 . 21 . 2 ping statistics ---

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

user@PEl> ping 10.0.21.2 routing-instance vpn-a count 1

PING 10 . 0 . 21 . 2 (10 . 0 . 21 . 2) : 56 data bytes
64 bytes from 10 . 0 . 21 . 2 : icmp_ seq=O ttl=60 time=7 . 510 ms

--- 10 . 0 . 21 . 2 ping statistics ---

1 packets transmitted, 1 packets received, 0% packet loss
round-trip mi n/avg/max/stddev = 7 . 510/7 . 510/7 . 510/0 . 000 ms

C> 2020 Juniper Networks. Inc All Rights Reserved

Juni per Bu si ness Use On ly

VRF Interface Routes Are Not Placed in inet. o

Once you configure an interface as part of a VRF instance, the interface route is no longer placed into the main routing table
(i net . O). As a result, you must associate commands like ping and telnet with the correct VRF table to avoid no route to
host error messages.

The routing-instance Switch

Use of the r o u t ing- i ns t a n ce switch causes the router to consult the VRF table associated with the interface name
specified. This switch thereby enables the use of commands like ping, telnet, trac ero ute , ssh, and ftp in the
context of a particular VPN.

On the slide, the first ping attempt from the PE1 router to CE-A fa ils with a No r o ute t o h o st error message. When the
operator includes the correct VPN instance as an argument to the ping command, the ping succeeds.

www .juniper.net Basic Layer 3 VPN Configuration • Chapter 4- 43

Junos Layer 3 VPNs

CE-CE VRF Interface Pings

■ Not an issue for point-to-point interfaces

• Redistribution of direct routes or use of vrf - target statement on PE router
works with no issues
■ Multi-access technologies (GE/FE) require special steps to facilitate
advertisement of direct routes
• Exporting direct routes or vrf - target configuration on PE router
• Requires that the PE router has learned at least one route (static/dynamic) with the CE
device as a next hop
• vrf-table-label or virtual tunnel interface configuration negates the need for the
CE-learned route

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly
Jun1Per
N£T\\()kl(S
44

Point-to-Point= No Problem
By default, PE routers runn ing the Ju nos OS can advertise directly-connected VRF interface routes using export policy or the
vr f - t a r get statement. Because of th is, t here is no issue with the support of traffic either originating or terminating on
point-to-point VRF interfaces.

Special Steps for Multi-Access VRF Interfaces

By default, PE routers running the Junos OS cannot advertise directly connected VRF interface routes using export policy or
the v rf - t arget statement on multi-access interfaces. For th is type of configuration to work, the PE router must have
learned, through static or dynamic routing, a ro ute from the local CE device with that CE device as the next hop for the route.
Th is is an inherent security feature due to the broadcast nature of FE/ GE interfaces.

Without learning a route from the local CE device, another way of f ixing this problem is to configure vrf- tabl e - label on
the local PE route r. Use of this feature elim inates the need for the routes described above, because the Internet Processor II
can now perform ARP operations as needed to determine the MAC address of the correct CE device.

Chapter 4-44 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

Egress PE Label Allocation

■ Per Next Hop (default)
• When VPN packets (MPLS encapsulated packets) arrive on the egress PE:
• MPLS label is popped and resulting packet is sent to next hop
• IP header is not evaluated for forwarding purposes
■ Per VRF Table (configured with vrf - table -l abe l)
• When VPN packets (MPLS encapsulated packets) arrive on the egress PE:
• MPLS label is popped
• IP header used for Layer 3 operations (for example, routing table lookup, egress filtering,
etc.)
• With Trio chipset, it is a good idea to configure
vrf - table - label on all VRFs
• Except when number of L3VPN instances exceeds 4000

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

Per Next Hop Label Allocation

The default behavior of a Junos device is to al locate labels on a per next hop basis. A single VRF may have multiple attached
CEs. VPN labels are allocated (and advertised using MP-BGP) for each CE-learned VPN routes by the PE router based on the
PE router's determination of the best next hop to reach the destination (a PE may learn the same route from multiple PEs). If
a next hop cannot be determined for a route, and label is not allocated and the route is not advertised to the remote PE.

When VPN packets arrive on the egress PE, they are encapsulated in a single MPLS label (the VPN label). The forwarding
procedure, in the case of per next hop label allocation, is to pop the MPLS label and forward it to the next hop that was
learned as described earlier. The IP header is not evaluated for forward ing purposes.

Per VRF Table Label Allocation

When vr f -table-labe l is configured, the allocation behavior for the VRF is changed to per VRF table label allocation.
That means, regardless of how many CEs are associated with a VRF, only a single VPN label is allocated (and advertised) for
all the VPN 's routes. That is, all VPN routes will be advertised with the exact same label for a particular VRF. The label for this
type of allocation is in a special range (16-2048 and/ or 4096-6144). A receiving PE will not only pop the MPLS label but it
will also perform a lookup based on the IP header.

The Trio chipset al lows for usage of a maximum of 4000 table labels. Therefore, it is recommended to almost always
configure VRFs with v rf -table-labe l on Trio ch ipset platforms. Other platforms will generally support a smaller number
of table labels.

www .j uniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 45

Junos Layer 3 VPNs

Per Next Hop Allocation Issues

• A lookup for a packet is based on a single key
• The key is either an IP or MPLS header but not both
• Two problems arise when VPN packets (MPLS encapsulated packets) arrive
on the egress PE:
1. If the PE-CE link is a shared medium (CE is a Layer 2 switch), how can the lookup chip
determine the outbound layer 2 encapsulation (usually accomplished with an ARP)
when the lookup is based on an MPLS header (that is, it does not know the destination
IP address)?
2. Except on Trio, if we want to perform packet filtering based on the IP header, how can
the lookup chip filter on the IP header fields when the lookup is based on an MPLS
header?
• vrf - table - label or virtual tunnel interface configuration permits these
operations

C/2020 Juniper Networl<s, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
46

Issues with Per Next Hop Allocation

The lookup chip uses the received key to determine how to forward a packet. The header will generally be an IP header or an
MPLS header, but not both. As we know, VPN traffic arrives on the egress PE as a packet encapsulated with a single MPLS
label. That means that the key for a lookup will be the MPLS header. The slide lists the two problems that can occur when the
key to a lookup is the MPLS header.

With the Trio chipset, the packet parsing, key generation, and lookup are all performed on the same chip. Although #1 in the
slide applies to Trio, #2 does not apply to the Trio chipset as egress f iltering is always available for VPN traffic without any
special configuration.

There are two methods of f ixing the two problems. You can either change the label allocation method to (per VRF table with
vr f - t ab l e- l abel) or apply a VPN Tunnel interface to a VRF.

Chapter 4-46 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

vrf-table-label Configuration

■ vr f -table-labe l resulting behavior

• This configuration causes the router to advertise a VPN label in the range of
16 to 2048 and/or 4096-6144 (these labels can be mapped to a vrf routing
table)
• Advertised by BGP using the i ne t- vpn address family (as usual)
• When MPLS encapsulated packets arrive with labels in this range, an ASIC earlier in the
packet's path (L chip for T640) will pop the MPLS label, associate the packet with a VRF
table (using LSI), and send the IP header-based key to the lookup ASIC (R chip for T640)

[edit routing-instances vpn-a]

user@mxB-li show
instance - type vrf ;
interface ge- 1/0/4 . 620 ;
route-distinguisher 193 . 168 . 2 . 1 : 1;
vrf-target target : 65512 : 2;
vrf- table- label ;
protocols {
bgp {

C2020 Juniper Networl<s, Inc .All Rights ReseM!<I.

Jon1per 8us1ness Use Only

Resulting Behavior
When per table label al location is enabled, the router will advertise (or readvertise) its VPN routes to its MP-BGP peers with
labels in the ranges listed in the slides. Arriving MPLS encapsu lated packets with labels in those ranges, will have their MPLS
header processed by a ch ip early in the packets path through the router. On the T640, it is the L ch ip that pops the MPLS
header, associates the rema ining IP packet with a VRF table, and passes the IP header-based key to the R-ch ip. The lookup
will now be performed based on the destination IP address of the packet using the correct VRF table.

www .j uniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 4 7

Junos Layer 3 VPNs

vrf-table-label Caveats

• Caveats:
• For Trio, only ~4000 table labels available
• Might be less depending on the platform
• Only ~4000 VRF tables can be configured with this setting
• No bandwidth limitations
• VT interfaces can be used once table labels have been exhausted
• Only certain core-facing interface types supported
• Consult the documentation for your software version
• Not supported for MP-BGP-labeled routes (carrier of carriers/interprovider)
• Operational display changes

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Only

Feature Restrictions
The vr f -tab l e- l a b e l feature is only supported on certain core-facing interfaces types. Consult the documentation fo r
your software version for a list of supported interface types. Table labels are not used for MP-BGP label routes to avoid
operational problems with carrier-of-carriers and interprovider applications.

Th is feature makes use of the LSP sub-interface (LSI) abstract that allows an LSP to be treated as an interface. When you
configure the vr f -table-label option under a VRF routing instance, an LSI is created for that VRF tab le. You can view
LSls with the s h o w i n terf aces command. Also, a dummy route is added to the ma in mp l s . O table, which shows the
LSl-to-VRF mapping. This route is never used, however, because the inner label is now stripped prior to the lookup chip.

Juniper Networks, starting with Ju nos OS Release 5 .2, added support for Internet Processor II functions for egress PE routers
running the Junos OS with a new VRF table configuration option called vr f -table-label .

Chapter 4-48 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

VPN Tunnel Interface

■ A router equipped with tunnel service capability allows for the
configuration of a VPN tunnel interface
• Causes two lookups on the egress PE router
• The first lookup is to determine to which VRF table the
MPLS-encapsulated packet belongs (MPLS label is popped)
• Rather than forwarding the packet directly out the physical VRF interface, the resulting IP
packet from the first lookup is sent to the tunnel service interface (next hop equals the
vt-~l:t.l!. interface)
• The second lookup occurs when the packet returns from the tunnel services interface and
then IP operations are allowed (ARP , firewall filters, and so forth)

[edit rout i ng-instances vpn-a]

[edit interfaces vt-1/0/10] user@PEl# s how
user@PE2JI show instance-type vrf ;
unit O { interface ge-1/0/4 . 620 ;
family inet ; interface vt-1/0/10 . 0;
fami l y mpls ; vrf-target target : 65412 : 100 ;
}

C/2020 Juniper Networl<s, Inc .All R,ghlS Resenie<I.

Jon1per 8usiness Use Only

VPN Tunnel Interface

To allow a PE router running the Ju nos OS to perform Internet Processor II functionality, you can configure a VPN tunnel
interface for the egress VRF table . To configure a VPN tunnel interface, a router must have a tunnel services enabled. Tunnel
services can be enabled in simple configuration on an MX Series Ethernet Services Router, while other routers require either
a Tunnel Services or Adaptive Services PIC installed. The slide shows the configuration steps for a VPN tunnel interface. With
a VPN tunnel interface configured, the PE router pops the label stack as normal. Before passing the remaining packet to the
CE device as it usua lly would, the packet is passed through a logical VPN tunne l interface. The packet is then sent back to
the Internet Processor II from the VPN tunnel interface where the Internet Processor II performs the functions it could not on
the first pass.

www .juniper.net Basic Layer 3 VPN Configuration • Chapter 4-49

Junos Layer 3 VPNs

Summary

■ In this content, we:

• Created a routing instance, assigned interfaces, created routes, and
imported/exported routes for the routing instance using route
distinguishers/route targets
• Described the purpose of BGP extended communities, configured, and used
BGP extended communities
• Listed the steps necessary for proper operation of a PE-CE dynamic routing
protocol
• Configured a simple Layer 3 VPN using a dynamic PE-CE routing protocol
• Verified the working of a Layer 3 VPN

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Onty
Jun1Per
.iETWOffKS
50

We Discussed:
• Creating a routing instance, assigning interfaces, creating routes, and importing/exporting routes within the
routing instance using route distinguishers and route targets;

• The purpose of BGP extended communities and how to configure and use these communities;

• The steps necessary for proper operation of a PE-CE dynamic routing protocol;

• Configuring a simple Layer 3 VPN using a dynamic CE-PE routing protocol; and

• Basic verification of a Layer 3 VPN.

Chapter 4-50 • Basic Layer 3 VPN Configuration www.juniper.net

 Junos Layer 3 VPNs

Review Questions

1. Which three extended communities did we use?

2. What are the four required options for creating a Layer 3 VPN?
3. When using OSPF as your PE-CE routing protocol, what protocol
match criteria must be used when sending the routes to the remote
PE?
4. Which tables contain the Layer 3 VPN routes?
5. What two possible issues does the vrf-table-label command
solve?

~2020 Jun,perNetworlcs, Inc . All Rights Reserve<!.

Juniper Business Use Onty
Jun1Per
~ETWORl(S
s1

Review Questions
1.

2.

3.

4.

5.

www .j uniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 51

Ju nos Layer 3 VPNs

Lab: Layer 3 VPN with Static and BGP Routing

■ Configure static and BGP routing between CE and

PE routers.
■ Verify proper VPN operation by examining routing tables, PE-PE
BGP announcements, and perform ping tests.

~2020 Juniper Networl<s, Inc . All Rights ReseM!<I.

Jo niper8us1ness Use Only
Jun1Per
NETWORKS
s2

Lab: Layer 3 VPN with Static and BGP Routing

Th is slide provides the object ives for th is lab.

Chapter 4-52 • Basic Layer 3 VPN Configu ration www.j uniper.net

 Junos Layer 3 VPNs

Answers to Review Questions

1.
We used the target, origin and do main-id extended communities.

2.
The four requ ired options for creating a Layer 3 VPN inst ance are instanc e-type, interfaces,
r o ute-distinguisher, and vrf-target or vrf-impo rt/ vrf-expo rt policies.

3.
The protocol match criteria required when exporting OSPF routes across your Layer 3 VPN to a remote PE is OSPF.

4.
The Layer 3 VPN routes are initially rece ived in the b gp .1 3vpn . o t ab l e , based on at least 1 match ing route-target of any
of the VPN customers on that given PE. The specific rout es for a given customer (vpn-A) will be installed in the
routing-instance table vpn -A . i ne t. O

5.
The vrf-table-label command solves two potentia l issues. The fi rst is to advertise t he local PE-CE int erface regardless of any
Layer 2 issues (no routes, no ARP info), the second is to al low packet inspect ion (filtering, policing) on non-Trio ch ipset
platforms. Remember the original issue is the single lookup limitation.

www .j uniper.net Basic Layer 3 VPN Configuration • Chapter 4 - 53

Junos Layer 3 VPNs

Chapter 4-54 • Basic Layer 3 VPN Configuration www.juniper.net

 un1Pe[
NETWORKS
Education Services

Junos Layer 3 VPNs

Chapter 5: Layer 3 VPN Scaling and Internet Access

Engineering Simplicity
Junos Layer 3 VPNs

Objectives

■ After successfully completing this content, you will be able to:

• Describe different ways to improve Layer 3 VPN scaling
• Describe three methods for providing Layer 3 VPN customers with Internet
access

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Business Use On ly

We Will Discuss:
• Four ways t o improve Layer 3 virtua l private network (VPN) scaling; and

• Three methods for providing Layer 3 VPN customers with Internet access.

Chapter 5-2 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

Agenda: Layer 3 VPN Scaling and Internet Access

➔ Scaling Layer 3 VPNs

■ Public Internet Access Options

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Onty
Jun1Per
.iETWOffKS
3

Scaling Layer 3 VPNs

The slide lists the topics we will discuss. We wi ll discuss the highlighted topic first.

www .j uniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5-3
Junos Layer 3 VPNs

How to Make It Scale

■ Recommendations from RFC 4364

• Observe PE router limits regarding total number of routes
• Keep the CE-to-PE routing simple
• Create multiple BGP route reflectors for VPN routes
• Use BGP-RFRSH (refresh)
• RFC 2918
• Use route target filtering
• RFC 4684

C/2020 Juniper Networks, Inc .All R,ghlS Resenie<J.

Jon1per8us1ness Use Onty

Observe Vendor-Specific PE Router Limits

Determining how many VPNs can be supported by a given provider edge (PE) router is a somewhat difficult question . There
are many variables that come into play when facto ri ng t he VPN load on a PE router. For example, having 1000 VPN routing
and forwa rding (VRF) tables that use static routing might be no problem at all, but the same number of VRF tables using
Open Shortest Path First (OSPF) routing cou ld result in a PE router becoming overloaded. Where possible, PE routers shou ld
not carry full Internet routing tables in addition to their VR F table-related burden . A simple static default route to a provider
(P) router with a full BGP table normally makes this possible.

Additional PE ro uter sca ling factors include memory, processing power, limits on total numbers of labels, and limits on logical
interface counts.

Keep the PE-CE Routing Simple

A large portion of t he processing burden placed on a PE route r is the need to maintain multiple routing protocol instances.
Receiving large numbers of routes from custome r edge (CE) routers can also present a resource d rain. Where possible, you
shou ld implement static routing and address aggregation to help ensure that PE routers are not over-taxed.

Continued on the next page.

Route Reflection
A key aspect of the RFC 4364 model is that no single PE router has to carry all VPN state fo r the provider's network. This
concept can be extended to route reflection by deploying multiple route reflectors that are responsible fo r different pieces of
the total VPN customer base. Route reflection has the added advantage of minimizing the number of Multi protocol Border
Gateway Protocol (M P-BGP) peering sessions in the provider's network .

Continued on the next page.

Chapter 5 - 4 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

BGP Route Refresh

The use of the BGP refresh mes.sage (defined in RFC 2918 ) allows for non -disruptive adds, moves, and changes, wh ich in
turn reduces routing disruption by not forcing the termination of PE-PE MP-BGP sessions when changes are made to the VPN
topo logy or membership.

Route Target Filtering

The use of route target filtering (defined in RFC 4684) can improve efficiencies, because it allows a route reflector to reflect
only those routes which a particular client PE router cares about.

www .juniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5-5
Junos Layer 3 VPNs

Scalability: Divide and Conquer

■ Two levels of labels allow P routers to forward VPN traffic without

needing to learn VPN routes
■ PE router maintains routes only for VPNs with sites directly
connected to the PE router
■ If necessary, partition BGP route reflectors among VPNs served by
the provider
• No single component within the system is required to maintain routes for all
VPNs
• Capacity of the system is not bound by the capacity of an individual
component

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Only

Two-Level Label Stacks Spare P Routers

The use of a two-leve l label stack allows P routers to remain ignorant of all things having to do with the VPN . P routers should
only carry the provider's internal routes and, in most cases, full BGP tables. Because VPN traffic is label-switched across the
core, the P routers never have to route to VPN destinations.

PE Routers Only Keep What Concerns Them

PE routers use route targets to fi lter out VPN routes that do not concern the PE router's directly connected VPN sites.
Therefore, no single PE router must ever carry a state for all VPN customers using a Layer 3 service.

Route Reflection
The use of route reflection could result in a single router (the route reflector) having to store all VPN states. To eliminate this
serious scaling issue, it is possible to deploy multiple route reflectors with each reflector servicing a subset of the tota l VPN
population. You must ensure, however, that PE routers are configured correctly to peer with all route reflectors serving VPN
customers for which th is PE router has locally attached sites.

Based on these methods, Layer 3 VPNs can be scaled virtually without bounds, as no single device must ever carry the total
VPN states for the provider's VPN service.

Chapter 5-6 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

Scalability: VPN-Specific Route Reflectors

VPN RR VPN RR
■ Use VPN route reflectors for 1-99 for 100-199

to handle VPN-specific routes ,, .,, p

.... I
• Add additional VPN route ., ..•• •• PE-2
VPN 1~ •••••·
reflectors for VPNs as needed VPN50 =-~ ®
VPN150 / PE-1
• PE routers peer with as
PE-3
many route reflectors as needed
■ Route reflectors do not need p
®
/
to be PE routers-normally they are P routers
• Not in the forwarding plane-do not require VRF tables
• Must support family inet-vpn
• Must have LSPs to each PE to resolve advertised next hop
• Keep all routes in bgp. 13vpn . o

C/ 2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8usiness Use Onty

Use VPN-Specific Route Reflectors

The use of route reflection is an important part of Layer 3 VPN scal ing because their presence dramatically reduces the
numbers of MP-BGP peering sessions on the PE routers.

We recommend using one or more P routers to provide VPN-related reflection services. If possible, you should not use the
VPN route reflectors for conventiona l (non-VPN) reflection duties.

Th is slide illustrates how you can deploy multiple route reflectors so that no s ingle reflector is required to carry all VPN
routes. A PE router with local VPN sites ranging from 1 through 99 MP-BGP peers with the reflector on the left, while a PE
router with local sites in the 100-199 space peers with the reflector on the right. A PE router must peer with both reflectors
if it has local sites belonging to both VPN spaces.

Route Reflectors Should Not Be PE Routers

While a PE router could serve double duty as a reflector, we recommend that you use a P router for VPN reflection. The VPN
route reflector automatically keeps all received VPN routes in the b gp . 13vpn. o table and is not required to maintain VRF
tables, as the reflector is not in the data forwarding path. The automatic use of the k eep a l l option in VPN route reflectors
means that route target matching is not performed. Therefore, you do not need VRF import and export pol icy.

The route reflector configuration must include the VPN IP version 4 (1Pv4) fam ily because it receives and reflects VPN routes.
A BGP route can on ly be active when it has a resolvable next hop. Also, because VPN routes must resolve to a label-switched
path (LSP), the route reflector requires LSPs terminating at each PE router to avoid h idden routes and the resulting problems
these hidden routes cause with regards to reflection . When running LOP in the provider core, all routers are connected to all
other routers with LSPs, so this requirement is not an issue. The use of RSVP generally requires that an LSP be defined from
the route reflector to each of its client PE routers. Workarounds to th is requirement do exist, for example, placing a static
default route into i ne t. 3 .

www .j uniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5- 7

Junos Layer 3 VPNs

Layer 3 VPN Route Reflection

■ Route reflector does not need VRF tables configured-must support
family inet-vpn and BGP refresh
■ Activating routes requires LSPs from route reflector to PE routers
■ PE routers filter received routes based on route targets

Route Reflector

C> 2020 Juniper Networks, Inc All Rights Reserved

Juni per Bu si ness Use On ly

Route Reflector Has No VRF Tables

As mentioned on the previous page, a route reflector does not require VRF tables or VRF-related routing policy. The reflector
must support the i n et-vpn fam ily and must support BGP refresh to accommodate non-disruptive moves and changes. The
Ju nos operating system wi ll automatical ly negotiate BGP refresh, and the keep a l l option is automatically enabled when a
cluster ID is configured (thereby making the device a route reflector).

For a P router to become a VPN route reflector, the only things needed are the configuration of a cluster ID, the declaration of
PE routers with which it peers, and configuration of the i ne t -vpn address fami ly. These steps accommodate the BGP
peering and VPN route reflector functionality, but remember that LSPs are also needed to ensure that routes are considered
usable by the route reflector.

LSPs Needed for Next-Hop Resolution

As the sl ide shows, LSPs are generally needed from the route reflector to each of its PE cl ients so that the BGP next hops of
the VPN routes can be resolved to an LSP. Routes that cannot be resolved are hidden on the route reflector. Therefore, these
routes cannot be re-advertised to other clients. Because the reflector is not in the forwarding path, there is no need for LSPs
in the PE client-to-route reflector direction.

When a PE router peers with a VPN route reflector, it is sent all routes contained in the reflector's b gp . 13vpn. o table. The
PE router uses its VRF import policies to match and keep the routes relating to its locally attached sites.

Chapter 5-8 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

Scalability: BGP Refresh

■ BGP is a stateful protocol
• Once peers are synchronized ,
they do not exchange routes
again until a change occurs
or the session is disrupted
■ PE router has filtered route exchange with route reflector VPN to limit
the number of routes it must maintain
■ PE router adds/deletes a VPN, which requires the updating of BGP
routing table
■ BGP route refresh allows PE router to obtain routes for new VPNs in
a non-disruptive fashion (without terminating BGP sessions with
route reflectors or remote PE routers)

C2020 Jun,perNetworl<s, Inc .All Rights Resenie<J.

Jon1per8usinessUse Only

BG P Is Statefu I
Unlike most routing protocols, BGP uses the reliable delivery services of Transmission Control Protocol (TC P). As a result,
once a BGP speaker receives a TCP acknowledgment for network layer reachability information (NLRI) updates sent to a
peer, it does not advertise the same routes aga in unless it must modify the NLRI or the path attributes, or the BGP session
itself is disrupted.

PE Routers Filter Routes Based on Route Targets

As discussed, a PE router immediately discards all VPN routes not containing at least one matching route target.

Adds and Changes

When the PE router's VPN-related configuration is modified, it must reevaluate all routes as changes in VRF po licy, which
might result in route target matches for routes previously ignored. The dilemma that faces our PE router is how to get the
BGP peer to resend routes that have already been received and acknowledged!

BGP Refresh
The so lution is using the BGP refresh capability as defined in RFC 2918, Route Refresh Capabi lity for BGP-4. BGP refresh
allows a BGP speaker to request that its BGP peer readvertise all NLRI associated with the session . Support of BGP refresh
is critica l to the Layer 3 VPN model, as it al lows for non-disruptive changes to VPN membership. The Junos OS supports BGP
refresh by default.

www .juniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5-9
Junos Layer 3 VPNs

Scalability: BGP Route Target Filtering

■ Without BGP route target filtering:

• PE router receives an update,
consisting of every route
RR-VPN knows, from RR-VPN
ere are all the
• PE router applies route filter based routes I know.

on route targets and drops routes that are not appropriate

■ With BGP route target filtering: Here are the routes
with your targets
• PE router sends a list of route Only send me routes

targets that it is interested

in to RR-VPN
• RR-VPN applies route filter and Here are the
only sends appropriate routes to the PE router routes
with your targets

C2020 Juniper Networks, Inc . All Rights Resenie<I.

Jon1per8usinessUse Only
Jun1Per
~ETWORKS
10

Without Route Target Filtering

Another BGP enhancement, ca lled route target filtering, also promises to improve Layer 3 VPN sca lability. Without route
target fi ltering, a PE router must receive all VPN routes from all BGP peers. Upon receipt, the PE router's VRF pol icy can result
in the vast majority of these routes being ignored. This problem is most pronounced when route reflection is in use, as a
single route reflector might be servicing a large portion of the provider's VPN routes.

With Route Target Filtering

With route target filtering, the PE router sends a list of route targets it is interested in, based on its local VRF policy, to the
BGP peer. The BGP peer applies this route target list as an outbound fi lter so that the routes sent to the PE router match at
least one of its configured route targets. Route target filtering improves efficiency because fewer BGP updates and protocol
traffic are required .

The BGP route target fi ltering functional ity is defined by RFC 4684.

Chapter 5-10 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

Route Target Options

■ MP-BGP route - target address family (AFl=1, SAFl=132)
Maximum number of received and accepted fam ily route
target advertisements allowed from peer
[edit l
user@PE-1# s ho w pro t o c o l s bgp
family route-target {
Maximum number of received fami ly route target
accepted-prefix-limit {
advertisements allowed from peer
maximum number ;
teardown <percentage - threshold> idle- timeout (forever I minutes) ;
} If maximum is reached. BGP neighbor relationsh ip is
prefix - limit { term inated for specified number of seconds

maximum <1 .. 4294967295>;

teardown <1 . . 100>
- idle-timeout <1 . . 2400> ;
.
} At% of maximum. syslog message is generated

external-paths X; ♦:-----------1
advertise-de fault ; _ This setting is used for interprovider VPNs Option B. Allows for
· multiple EBGP peers to receive VPN routes (default= 1)
proxy- generate {
route- taraet- oolicy oolicv-name ; Usually configured on route reflector only
) Create route target membership on behalf of
) peers that do not have the route target filtering functionality

C> 2020 Juniper Networks. Inc All Rights Reserved

Juniper Bu si ness Use On ly

The route-target Address Family

The slide shows the optional settings for the rou te-ta r ge t address fami ly.

• prefix-l imit: Limits the number of route-target advertisements that can be received from a peer router. By
default, when the limit is reached, the router stops accepting route-target advertisements from the peer. Using
the optional tea r down statement causes the neighbor re lationsh ip with a peer to be torn down when the
max i mum limit is reached . The diagram also shows the usage of the optional percentage and idle-ti meo u t
configuration . The a ccepted-prefix-l i mit setting is similar except that it tracks the number of accepted
routes as opposed to received routes .

• external-paths (default va lue=1): Affects EBGP Layer 3 VPN route advertisements between autonomous
system (AS) boundary routers when perform ing interprovider VPNs Option B (described in a future chapter).
When a router learns the same r oute-target advertisement from multiple EBGP peers, this option allows
for Layer 3 VPN advertisements to be sent to more t han only one of those EBGP peers.

• adverti se-default: Causes the router to advertise the default route target route (0 :0 :0/ 0) and suppress
all routes that are more specific. A router reflector can use this on BGP groups consisting of neighbors that act
as PE routers only. PE routers often must advertise al l routes to the route reflector. Suppressing all route target
advertisements other than the default route reduces the amount of information exchanged between the route
reflector and the PE routers.

• pro xy-generate: Enables proxy BGP route target f iltering (also known as proxy route target constrain, or
proxy RTC). This feature is useful if you have a network environment where route target filtering is not widely
deployed or fully supported. When configured for proxy BGP route target filtering, the device creates route target
membership (RT membership) on behalf of its peers that do not have the route target filtering functionality. The
device then distributes the RT membersh ip advertisements from incoming BGP VPN routes to other devices in
the network that need them . An optional route-target policy may be specified to select a subset of the VPN
routes that are learned from this peer (or group) to be used as contributors for proxy RT-Constrain route
generation .

Continued on the next page.

www .j uniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5 - 11

Junos Layer 3 VPNs

The route-target Address Family (contd.)

po l icy-op t ion s {
p o l icy-s t ateme n t statemen t {
term ter m {
+ from p r otocol r o ut e- t a r get ;
+ from rtf - pre fi x- li st tes t - li st ;
t he n accep t ;
}
}
}

+rt f-p r e fix - l is t test- li st {

+ 0 : 100 :1 00/96 ;
+ 1 00 : 300 : 0/48 ;
+ 1 00 : 300 : 300/96 ;
+}

Chapter 5 - 1 2 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

Route Target Filtering (1 of 5)

'1
192.168.1.3

VPN-A ~ VPN-8
-1
.168.1.1
p -2
192.168.1.2
Hs
AS 65512

user@RR- 1> show configuration protocols bgp

group pe {
type i n ternal ;
l ocal- address 1 92 . 1 68 . 1 . 3 ;
f ami ly i net - vpn {
u n i cast ;
}

family route - target ;

cluster 1 . 1 . 1 . 1;
•--------J capabilities are negotiated with(AFl=1. SAFl=132)
f'amj ly route-target
the PE routers
neighbor 1 92 . 168 .1. 1 ;
neighbor 1 92 . 168 .1. 2 ;
}
C> 2020 J uniper Networks, Inc All Rights Reserved
Juni per Bu si ness Use On ly

Route Target Filtering: Part 1

The s lide shows the minimal configuration needed on a route reflector to negotiate the route-target address fami ly with
its peers. A similar configuration is needed on the two PE routers .

www .j uniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5- 13

Junos Layer 3 VPNs

Route Target Filtering (2 of 5)

VPN-A
PE-2
68.1.1 192.168.1.
AS 65512

user@RR- 1> show bgp swnmary

Groups : 1 Peers : 2 Down peers : 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
bgp . 13vpn . O 8 8 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State I#
1 92 . 168 .1.1 65512 6 8 0 0 1: 18 Establ
bgp . 13vpn . O: 2/2/0
bgp . rtarget . O: 1/1/0
1 92 . 168 .1. 2 65512 6 0 0 1: 04 Establ
bgp . 13vpn . O: 6/6/0
b gp . r t arge t . O : 1 / 1 / 0 ,- . - - - - ~ PE-1andPE-2automaticallyadvertisearoute
target for each VPN in which they participate

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per 8usiness Use Only

Route Target Filtering: Part 2

The slide shows that when the r o ut e- t a r get address family is correctly negotiated between routers, all route target
advertisements are placed into a new table called bgp . rtarget . o. Notice that PE-1 and PE-2 automatically advertise a
route target to the route reflector. The specif ics relating to these advertisements are shown on the next page.

Chapter 5-14 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

Route Target Filtering (3 of 5)

AS# : target : # __ __ AS#: target:#
65512 : 65512 : 100 65512 : 65512 : 200

~ VPN-8
~B
68 .1.1
AS 65512
target:65512:100 target: 65512 : 200

user@RR- 1> show route receive-protocol bgp 192.168.1.1 detail table bgp.rtarget.O

bgp . rtarget . O: 2 destinations , 2 routes (2 active , 0 holddown , 0 hidden )

* 65512 : 65512 : 100/96 (1 entry , 1 announced)
Nexthop : 192 . 168 . 1 . 1
Localpref : 100
AS path : I

user@RR-1> show route receive-protocol bgp 192.168.1.2 detail table bgp.rtarget.O

bgp . rtarget . 0 : 2 destinations , 2 routes (2 active , 0 holddown, 0 h i dde n)
* 65512 : 65512 : 200/96 (1 entry , 1 announced)
Nexthop : 192 . 168 . 1 . 2
Localpref : 100
AS path : I
C/2020 Juniper Networks, Inc .All Rights ReseM!<I.
Jon1per8us1ness Use Only

Route Target Filtering: Part 3

Once the BGP peering relationsh ips are established using the r o u te-ta r ge t address fam ily, the PE routers send a route
target advertisement for each of their configured import route targets. For example, because PE-1 has a VRF table
configured with a vr f -tar get impo rt targe t: 65 51 2 : 1 OO statement, PE-1 is requesting that the route reflector
send all routes tagged with that community. This is demonstrated in the output of a sho w r o ute-rec eive pro t ocol
bgp 1 92 .1 68 . 2 1.1 command on the slide. A route target advertisement takes the form of o riginati n g
AS# : ta rge t communi t y .

Notice that the route reflector reflects the route target advertisement to all c lients, including the client that originally sent the
advertisement. The d iagram only shows the route reflector reflecting PE-i's advertisement, but it also reflects PE-2 's
advertisement in a similar fashion .

www .j uniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5 - 15

Junos Layer 3 VPNs

Route Target Filtering (4 of 5)

AS# : target:#
RR-1 reflects route target to all clients.
BGP NH= RR-1 Originator ID= RR-1
192.

••
VPN-A VPN-8
PE-2 -8
68.1.1 192.168.1.
AS 65512

target : 65512 : 100 target : 65512 :2 00

user@PE-1> show route table bgp.rtarget.O

bgp . rtarget . 0 : 2 destinations , 3 routes (2 active , 0 holddown , 0 hidden)

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

65512 : 65512 :1 00/96

*[RTarget/5) 00 :1 1 :1 9
Local
[BGP/170] 00 : 03 : 31 , localpref 100 , from 192.168.1.3
AS path : I
> to 172 . 22 . 210 . 2 via ge- 1/0/0.210
65512 : 65512 : 200/96
*[BGP/170) 00 : 03 : 31 , localpref 100 , from 192 . 168 . 1.3
AS path : I
> to 172 . 22 . 210 . 2 via ge- 1/0/0.210
C> 2020 Juniper Networks. Inc All Rights Reserved
Juniper Bu si ness Use On ly

Route Target Filtering: Part 4

When the route reflector reflects the route target advertisements to its internal BGP (IBGP) peers, it changes the BGP
next-hop and originator ID to reflect itself. Without these modifications, PE-1 would discard the route target advertisement
that it originated. The output of a show route table bgp. rtarget. O command shows that PE-1 considers the
reflected route to be a val id route because of the alterations made by the route reflector. Because the route reflector
changes the next hop and originator ID to itself, there must be an LSP on PE-1 that egresses on the route reflector. This LSP
is required to resolve the route target NLRls received on PE-1. PE-1 now knows that it must send any routes contained in
locally configured VRF tables that are using export targets of target:65512:100 and target:65512:200 to the route reflector.

Chapter 5-16 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

Route Target Filtering (5 of 5)

_-t VPN-B routes tagged with:
target : 65512 : 200

VPN-A
e
CE-A ~ p -
192,168,1,2
' -- ~
Ct:-B
VPN-B

AS 65512
target: 2:100 target: :200

user@PE - 1> show configuration protocols bgp

Ifamily ; l~~-i----J
keep allinet- vpn { Causes PE-1 to place all received Layer 3 VPN routes into
bgp . 13vpn . 0 table. regardless of configured vrf- targets
unicast ;
}
family route-target ;
RR-1 does not send VPN-B's Layer 3 VPN routes to PE-1
. . .

user@PE - 1> show route table bgp . 13vpn .O

C> 2020 Juniper Networks, Inc All Rights Reserved

Juniper Bu si ness Use On ly

Route Target Filtering: Part 5

Without route target filtering, PE-1 wou ld unnecessarily rece ive routes from PE-2. Because of route target filtering, the route
reflector knows that it should only send routes tagged with the ta r get : 65512 : 100 community to PE-1.

In the example on the s lide, t he keep a l l statement is used to force PE-1 to store all Layer 3 VPN routes received f rom the
route reflector in its bgp . l 3vpn . O table. Notice that the bgp. l 3vpn . O table is empty on PE-1. The empty table shows
t hat route target fi ltering is working because the route reflector is not sending the Layer 3 VPN ro utes learned from PE-2 to
PE-1.

www .j uniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5 - 17

Junos Layer 3 VPNs

Adding Traffic Engineering

3) Enters RSVP- engineered

core and pushes RSVP label 4) Pops RSVP label
2) Finds inet.3 route to the BGP 5) Pops LOP label
next hop and assigns LOP label

1) Finds BGP next hop to Y 6) Pops VPN label and forwards

and assigns VPN label packet out the CE port
Source X
Destination Y
........0 ....... 0 _.......- 0 .........~ y
PE-1 P1 P2 P3 ~

Packet Labels:

LOP-Signaled LSP ---I Outer Label: RSVP

Middle Label: LOP
RSVP-Signaled LSP Inner Label: VPN

C/2020 Juniper Networks, lnc _AII Rights Resenie<J_

Jon1per8us1ness Use Only

Adding Traffic Engineering

The use of MPLS traffic engineering can also improve VPN scal ing and performance. With the Junos OS, you can extend
RSVP-based engineered LSPs all the way to the PE routers. The ability to map VPN traffic onto LSPs routed over specific
facilities in the provider's core is useful when the VPN service is associated with a service level agreement of some kind .

RFC 4364 requ ires t hat the PE router support the LDP signaling protocol; RSVP is optional. As a resu lt, some non-Juniper
Networks equipment might only support LDP at the PE router. Because LDP does not support traffic engineering, it might
seem that all hope for traffic engineered VPNs is lost. With the Junos OS, you can tunnel LOP-based LSPs over an RSVP
traffic engineered LSP. Therefore, traffic engineering across the core is still possible, even though the PE routers might only
support LDP signa ling.

Th is slide shows how the tunneling of LDP over RSVP results in a three-level label stack for VPN traffic. The ingress PE router
pushes both a VRF label (inner) and LDP label (middle) before forwarding the labeled packet to the Pi router. The Pi route r
now pushes a third label (outer) to be swapped as the packet traverses the RSVP core. Penultimate-hop popping (PHP)
resu lts in a two-level label stack when the packet arrives at the P3 router. The P3 router also performs PHP so that the PE-2
router receives a packet with a single-level label stack. PE-2 uses the remaining VRF label to associate the packet with the
correct VRF interface.

Chapter 5-18 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

LDP Tunneling Configuration Example

[edit J
user@Pl# show protocols mpls
label-switched-path Pl-to-P3 {
to 192 . 168 . 5 . 3 ;
l dp- tunne l ing ;
no - cspf ;
}
interface all ;

[edit]
user@Pl# show protocols ldp
interface ge - 0/0/0 . 0 ;
interface lo0 . 0 ;

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Only

LDP Tunneling
Th is slide shows the key configuration steps requ ired for LDP tunneling over RSVP. In this case, the P1 router has an RSVP
session to the P3 router that includes the ldp- tunneling statement. This router is also configured to run LDP on the
PE-facing interface (ge-0/ 0/ 0 ) as well as on its loO interface, because you must run LDP on the router's loO interface when
performing tunneling.

The following capture is from a core P router, where LDP tunne ling over RSVP is configured. It clearly shows the three-level
label stack that results from LDP tunnel ing:

Fr ame 25 (1 1 0 on wi re , 110 captured)

Ethe rnet II
Dest i nat i o n: OO : d0 : b7 : 3 f: b5 : 0c (00 : d0 : b7 : 3 f: b5 : 0c)
Sou rce : OO : d0 : b7 : 3 f: b4 : ce (00 : d0 : b7 : 3 f: b4 : ce)
Type : MPLS l abel swi tched p acke t (Ox8847)
Mul tiP r otocol Labe l Switc hi ng Head e r
MPLS Label : Unknown (1 00003)
MPLS Exper i me nt a l Bi ts : 0
MPLS Bott om Of Labe l St ac k: 0
MPLS TTL : 254
Mul tiP r otocol Labe l Switc hi ng Head e r
MPLS Label : Unknown (1 00003)
MPLS Exper i ment a l Bi ts : 0
MPLS Bott om Of Labe l St ac k: 0
MPLS TTL : 254
Mul tiP r otocol Labe l Switc hi ng Head e r
MPLS Label : Unknown (1 00002)
MPLS Ex per i me nt a l Bi ts : 4
MPLS Bott om Of La b e l St ac k: 1
MPLS TTL : 254
I nter net Pro t ocol
Ve r s i on : 4
Head e r l eng t h : 20 bytes
• • •

www .j uniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5 - 19

Junos Layer 3 VPNs

VRF Table Adds, Moves, and Changes

■ When a VPNNRF table is added to or removed from a PE router, is it

disruptive?
• No
■ How many router configurations must be changed when you add or
remove VPNNRF tables?
• Only the affected PE router must be configured-in this case, to peer with the
route reflector responsible for the new VPN
• When a VPN is completely removed from the PE router,
it simply withdraws all those VPN-1Pv4 routes
• Route target filtering and route refresh simplify this process

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usinessUse Only
Jun1Per
~ETWORKS
20

VRF Table Modifications Are Non-Disruptive

The support of BGP refresh means that modification to a PE router's VRF-related configuration is non-d isruptive to the
operation of the other VPNs configured on that PE router. Without refresh, changes to VPN membersh ip would requ ire
clearing the shared MP-BGP sessions between PE routers, wh ich would be disruptive to all VPNs supported by that PE router.

Adding a New VPN

In general, add ing a new VPN site to a PE router does not require the modification of the configuration in the remote PE
router, the provider core, or in any route reflectors that are deployed, especially when all PE routers have fu ll MP-BGP and
MPLS connectivity (with or without route reflectors). With these prerequisites, the new VPN site requires configuration
changes only to the PE router attaching to the new site.

If ful l MP-BGP and MPLS connectivity is not preprovisioned among the PE routers, the remote PE routers requ ire changes;
the remote PE routers must then establish LSP and MP-BGP sessions to the PE router serving the new VPN site.

Chapter 5-20 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

Layer 3 VPN Scaling Guidelines

■ Number of VRF tables
• Might be up to 9000 depending on the Routing Engine
■ Number of total routes per device can vary a great deal depending on
platform and hardware
• MX-960 can handle up to 5 million forwarding table routes
• Could be possible to reach up to 10 million routes with newer MPC
• Option to limit prefixes received from CE router
• maximum-routes route limit [log-only I { threshold <1-100> } ]
■ Additional factors
• Does the PE router carry Internet routes?
• Are the CE routing protocols stable?
• Is the PE router performing value-added services, such as rate limiting and
firewall?

C> 2020 Juniper Networ1<s, Inc All Rights Reserved

Juni per Bu si ness Use On ly

Number of VRF Tables

Th is s lide outlines some of the recommended guidelines for scal ing. You shou ld understand, that many of the limitations are
related to available Routing Engine memory. The total number of VRF instances per device can be as high as 9000. This total
number might be more or possibly less depending on the resources needed for the PE-CE routing. It is recommended that
the PE-CE routing protocol be kept as simp le as possible. For instance, static or RIP routing presents less processing load on
the PE router when compared to the OSPF or BGP routing protocols.

Number of Routes Per Device

The total number of routes that are supported widely varies depending on the platform and the hardware combinations
being used. The MX960 fo r instance, can handle up to 5 m illion forwarding table routes. With some of the newer Modular
Port Concentrators (MPCs) the number of forwarding tab le routes can reach as high as 10 million.

The Junos OS allows you to limit t he number of prefixes received from the CE router using a dynamic routing protocol. When
the prefix limit is reached, you can choose to have warning messages logged, or to stop accepting additional routes. The
maximum- routes option is configured under the rou t ing-opt i ons portion of a routi ng instance's configuration. Take
care when opting to ignore CE routes in excess of t he limit, as the results can lead to some interesting troubleshooting!

With the above guidelines in mind, you must also consider other factors that can affect the processing and resource loads on
a PE router. For example, does the PE router serve double duty by providing non-VPN Internet access services? Does it carry
a full BGP table? Is the CE routing protocol stable? Instability (route f lap) within a VPN site can result in substantial
processing loads on t he PE router. Have valued-added services such as firewall filtering been deployed on the PE router?

Because so many variables exist, it is difficult to provide a concrete rule defining how much is too much. Adhering to these
scaling recommendations should result in successful VPN deployment.

www.juniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5 - 21

Junos Layer 3 VPNs

VRF Localization in Layer 3 VPNs (1 of 2)

■ VRF localization provides a mechanism for localizing Layer 3 VPN

routes to a specific line card
• Maximizes the total number of VRF routes for a given PE
■ PE routers in Layer 3 VPN deployment have two types of line cards:
• Linecards hosting CE-facing interfaces
• Linecards hosting Core-facing interfaces
• vpn-core-facing-default
- Core-facing FPC installs all the routes and next-hops of the VRF routes
• vpn-core-facing-only
- Core-facing FPC installs all the routes of the VRF, but NOT the next-hops

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
.iETWOffKS
22

VRF Localization in Layer 3 VPNs

By default on Junos devices, all the routes of all VRFs are present on all linecards with chained composite next hops. This
uses up memory on all line cards, and the reby limits the scaling of L3VPN deployment on a given PE router.

VRF localization provides a mechanism for localizing routes of VRFs to specific lineca rds, the reby increasing the amount of
VRF routes supported on that PE ro uter.

Core-Facing Interfaces
The Core-facing interfaces can be configured as two types:

• vpn-core-facing-default; FPC installs all the routes and next-hops of the VRF routes.

• vpn-core-facing-only; FPC installs all the routes of the VRF, but NOT the next-hops (results in greater scalabi lity).

The VRF localization feature is supported on MX240, MX480, MX960, MX2010, and MX2020 in Junos 15.1 re lease.

Chapter 5-22 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

VRF Localization in Layer 3 VPNs (2 of 2)

■ Configuring VRF localization

• Configure the core-facing interface option
[edit chassis]
user@Rl# set fpc 2 vpn-localization vpn-core-facing-only
user@Rl# set fpc 3 vpn-localization vpn-core-facing-default

■ Configure the enhanced IP network services on the chassis

[edit chassis]
user@Rl# set network- services enhanced-ip

• Configure the VRF instance localization

• For physical CE-facing interfaces
[edit routing-instances vpn-a routing-options]
user@Rli set localized fib
• For logical interfaces like AE, and IRB interfaces
[edit routing - instances vpn- a routing - options]
user@Rli set localized fib fpc 0

C/2020 Juniper Networks, Inc .All R,ghlS Resenie<I.

Jon1per8us1ness Use Only

Configuring VRF Localization for Layer 3 VPNs

The slide above shows t he configuration commands to enable VRF localization, both for the Core-facing interfaces, and for
t he individual VRFs.

Use the below commands to verify VRF localization for Layer 3 VPNs:

• show route vpn-localization

user@PEl> show route vpn-localization

Rou ti n g table : v pnl.ine t, Local iz ed

In d ex : 7 , Add r ess Fami ly : inet , Loca li za t ion s t atu s : Comple t e
Loca l FPC ' s : 2 8

Rou ti ng table : v pn 2 .ine t, No n -loca liz ed

In d ex : 8 , Add r ess Fami ly : inet , Loca liz a t ion s t atu s : Comple t e
Loca l FPC ' s : Al l

• show route vpn-localization vpn-name v p nl

user@PEl> show route vpn-localization vpn-name vpnl

Rou ti n g table : v pnl.ine t, Local iz ed

In d ex : 7 , Add r ess Fami ly : inet , Loca liz a t ion s t atu s : Comple t e

www .j uniper.net Layer 3 VP N Scaling and Internet Access • Chapter 5- 23

Junos Layer 3 VPNs

Allowing Increased Unique Inner Labels for

Multivendor Layer 3 VPNs (1 of 2)
■ Junes conserves label space by advertising:
• One label for all Layer 3 VPN routes learned on same
CE-facing interface
• One label for all local VRF routes (vrf-table-label)
■ Other vendors might allocate one label per advertised Layer 3 VPN
prefix
• Possibility of million or more labels in large deployments
• Slower system processing and convergence
■ Junes uses next-hop-chaining = chained composite next hop to limit
number of route updates and individual states a Junes router must
maintain
• Enhanced scaling and convergence
C> 2020 Juniper Networks, Inc All Rights Reserved
Juni per Bu si ness Use On ly
Jun1Per
NITWOkl<S
24

Allowing Increased Unique Inner Labels for Multivendor Layer 3 VPNs

Ju nos devices conse rve label space by advertising:

• One label for all L3VPN routes learned on same CE-facing interface.

• One label for all local VR F routes if vr f - t ab l e- l abel is used.

Other vendors can allocate 1 label per advertised Layer 3 VPN prefix, wh ich results in millions of advertised labels in large
multivendor Layer 3 VPN deployments. This wou ld result in slower system processing and slower convergence.

Ju nos uses next-hop-chaining, a lso called chained composite next hops to limit the number of route updates and individual
states a Ju nos OS router must ma inta in, resulting in enhanced sca ling and faster convergence. The chained composite next
hops allow the router to direct sets of routes sharing the same destination to a common forwarding next-hop, instead of each
route having its own individual, but identical, next-hop.

Chapter 5 - 24 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

Allowing Increased Unique Inner Labels for

Multivendor Layer 3 VPNs (2 of 2)
■ Configuring for up to one million Layer 3 VPN route labels
[edit routing-options forwarding-table chained-composite-next-hop ingress]
user@Rl* set 13vpn

[edit chassis memory- enhanced]

user@Rl* set vpn-label

■ Configuring for more than one million Layer 3 VPN route labels
[edit routing- options forwarding - table chained- composite- next - hop ingress]
user@Rl# set 13vpn

[edit routing-options forwarding-table chained-composite-next-hop ingress 13vpn]

user@Rl* set extended- space

[edit chassis]
user@Rl* set network-services enhanced-ip

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usiness Use Onty

Configuring for Allowing Increased Unique Inner Labels for Multivendor Layer 3 VPNs
Depending on the scale of the multivendor Layer 3 VPN, more or less than 1 m illion ind ividual Layer 3 VPN labels used, the
slide above shows the configuration commands to enable this enh anced scaling.

For high scale implementations (> 1 m illion) 64-bit route-engines are strongly recommended .

The feature only benefits indirectly connected PE routers, so not if the Ju nos OS PE is directly connected to the multivendor
PE.
If you need to change the network services mode, a reboot might be required .

For verification the following commands can be used:

• show route route-value extensive

• show route forwarding-table destination destination-value extensive

www .juniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5- 25

Junos Layer 3 VPNs

Agenda: Layer 3 VPN Scaling and Internet Access

• Scaling Layer 3 VPNs

➔ Public Internet Access Options

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usiness Use Only
Jun1Per
.iETWOffKS
2s

Public Internet Access Options

Th is slide high lights the topic we discuss next.

Chapter 5-26 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

Accessing the Public Internet

Public Internet

■ If the VPN uses private addresses,

connecting to Internet requires NAT
VPN
• CE or service provider can perform NAT function
■ RFC 4364 Internet access options
• Option 1: PE router does not participate in Internet routing
• Option 2: PE router performs redistribution between VRF tables and main
instance while matching packets against both tables
• Option 3: Central CE device sends Internet/default routes to remote sites

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usinessUse Only

Private Addressing Requires NAT

If a VPN site uses private addressing, Internet access requires some form of Network Address Translation (NAT). Either the
CE or PE routers can perform the NAT function .

RFC 4364 Internet Access Options

The following list provides details about the various RFC 4364 Internet access options:

• Option 1 : RFC 4364 defines several Internet access options. In Option 1 , the PE router does not exchange
routes between its main routing instance and the instances associated with its VR F tab les. Option 1 solutions
are often referred to as non-VRF Internet access because Internet traffic ultimately crosses a non-VRF interface
before leaving or entering a VPN site.

• Option 2 : Option 2 defines Internet access options in which the PE router maintains partia l or full Internet
routes in its main routing table and has the ability to redistribute routes between the VRF tables and the main
routing instance. Option 2 solutions can provide VRF interface-based Internet access, depending on
implementation specifics. Option 2 might requi re the PE ro uter to place some or all of the VPN's routes into the
main forward ing table to accommodate return traffic. The routes copied into the main forwarding table must
represent globally unique addresses.

• Option 3 : Option 3 defines Internet access options in which a central CE location is used to provide Internet
access to other sites using both a VRF and non-VRF interface. Option 3 solutions are referred to as VRF-based
Internet access, beca use remote CE locations use a VR F interface to connect to the central site providing
Internet access.

In operation, the central site advertises a default route placed into the VRF tables of the remote locations. When the central
CE device receives nonlocal traffic, it t urns the traffic around and sends it to the PE router using a non-VRF interface.

www .juniper.net Layer 3 VPN Scaling and Inte rnet Access • Chapter 5 - 27
Junos Layer 3 VPNs

Accessing the Public Internet: Option 1.1

■ Option 1.1: VPN service provider plays no role in Internet connectivity

• VPN customer has separate connection to Internet from some or all of its sites

Public Internet

Customer
Site 1 Provider VPN

Customer
,--,--i Customer
Site 3

Site 2

C2020 Jun,perNetworl<s, Inc .All Rights Resenie<I.

Jon1per 8us1ness Use Only
Jun1Per
~ETWORKS
2a

Option 1.1
In Option 1.1, the VPN service provider and PE router provide no Internet access functionality. The customer sites have
separate connections for Internet access, so the PE router never rece ives nor transmits Internet traffic.

By default, the Ju nos OS supports Option 1.1.

Chapter 5-28 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

Accessing the Public Internet: Option 1.2

Internet Internet aware router

__,_---o1::-::;:--1,._..__.~ ..-,,,~~ Internet traffic

Customer
Site 1 ~~,cf.:~
~
- -=-: - ~ - -
P1
-"1>'-
P2
''~--~ ----~
~ - -~ - - -
P3 PE-

VPN Provider VPN traffic

■ Option 1.2: PE router provides Layer 2 connectivity to a router that

maintains some or all Internet routes
• Service provider provides both BGP/MPLS VPNs and Layer 2 MPLS VPNs
• VPN connection assumes a separate logical (but not necessarily physical) link
between CE device and PE router (for example, DLCI, VLAN, and GRE)
• Layer 2 VPN has connectivity to an Internet-aware router
• Different VPNs can use different Internet-aware routers
C2020 Juniper Networks, Inc . All Rights ReseM!<I.
Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
29

Option 1.2
In Option 1.2, the PE router provides a Layer 2 connection to an Internet-aware router. This Layer 2 VPN connection does not
require a separate physical interface, as it can function over a second logical unit on the interface used for VPN access. Each
CE router can be connected to the same Internet-aware device or can be attached to separate Internet-aware provider
routers.

The Ju nos OS supports Option 1.2 using either circuit cross-connect (CCC) or Layer 2 VPN technology.

www .juniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5 - 29

Junos Layer 3 VPNs

Accessing the Public Internet: Option 2.1

Customer
Site 1

VPN traffic VPN Provider

• Option 2.1: Main routing table contains Internet routes and is

consulted for packets received over non-VRF interfaces
• Forces homogeneous Internet route selection for all VPNs connected to the
PE router
• Requires a separate logical link between CE device and PE router for carrying
traffic to and from the Internet

C2020 Juniper Networks, Inc .All R,ghlS Resenie<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
30

Option 2.1: Separate Interfaces for VPN and Internet

In Option 2 .1, the PE router maintains partial or full Internet routes in its main routing instance. All VPN customers attached
to the PE router share these routes, which forces homogeneous Internet access.

With this option, the CE router attaches to the PE router using both a VRF and a non-VRF interface. Traffic rece ived over the
non-VR F interface is matched against the main routing table, while traffic received over the VRF interface is matched against
the VRF table.

The VPN site's global addresses are associated with the non-VR F interface. These routes are placed into the main routing
table to attract reverse traffic. Because all VPN customers have the non-VRF interface traffic matched against a common
routing table, the result is homogeneous routing for Internet access.

Chapter 5 - 30 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

Accessing the Public Internet: Option 2.2

9
... . . .
Internet

Return Internet traffic - •• ••

,,--.. 1'-----r~-.,---~ ~ ~~ Outbound Internet traffic r---.
Customer
Site 1 - -0 -- .CI)_- -0 -- - - ...
P1 P2 P3 PE-
Customer
Site 2

...-----'-----.,;:a,........---. VPN Provider

VPN/Internet traffic VPN traffic l----------~

■ Option 2.2:
• Some or all Internet routes maintained in VRF table on PE
• Routes matching non-VPN addresses are directed to the main routing table for lookup
using the n ext- t abl e operation
• Requires a separate logical link between CE and PE router for carrying return
traffic from the Internet (which presents scaling problems if VRF tables
maintain a full set of routes)
• PE probably maintains a 0/0 plus a small number of other Internet routes per VRF table
with this option
C> 2020 Juniper Networks, Inc All Rights Reserved
Juni per Bu si ness Use On ly
Jun1Per
N £TWOkl<S
31

Option 2.2: Separate Interface for Returning Internet Traffic

In Option 2.2, the PE router and CE device once again attach with both a VRF and non-VRF interface. In th is case, the CE
router sends both VPN and Internet traffic to the PE router using the VRF interface. The PE router must be able to match the
packet against the VRF tab le as wel l as the main routing table . The Ju nos OS can accompl ish this matching by placing a
static route (usually a default route) in the VRF table that uses the next - t able option to force a second lookup in the
default routing table.

Traffic returning from the Internet is matched against the main routing instance and delivered to the customer using the
non-VRF interface. All the global addresses associated with the VPN site must be added to the ma in routing table to allow
reverse traffic.

www .j uniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5 - 31

Junos Layer 3 VPNs

Accessing the Public Internet: Option 2.3

Internet traffic

Customer Customer
Site 1 Site 2

VPN Provider
VPN/Internet traffic VPN traffic t---------...-
■ Option 2.3:
• Single interface for VPN and Internet access
• Requires that:
• Either VPN has no private addresses or that it uses BGP with community tagging
• VRF routes be copied into i net . o using RIB groups
• Non-VPN routes be matched against the main routing table using the next-table
operation
C/2020 Juniper Networks, Inc .All Rights Resenie<J.
Jon1per8usiness Use Onty

Option 2.3: Single VRF Interface for VPN and Internet Access
If the VPN does not use private addresses space, both VPN and Internet access can be ach ieved with a single VRF interface
by copying the routes from the VRF table into the main routing table using RIB groups. This option also requ ires that the VRF
tab le carry a default route using the next- table option to direct non matching packets to the main routing table for
longest-match lookup.

When the PE-CE protocol is BGP, Option 2 .3 can be achieved when the VPN site is using a mix of private and global
addressing. In this case, BGP community tags differentiate between global and private addressing. By sorting out the global
from private addresses from the tags values, the global routes that are to be copied into the main routing instance can be
determined.

Chapter 5-32 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

Accessing the Public Internet: Option 3.x

All Internet traffic

Customer Customer
Site 1 Site 2

VPN/Internet traffic

■ Option 3.x:
• Central CE device sends lnterneUdefault routes to remote sites
• Remote sites access both VPN and Internet using their single VRF interface
• Central CE device turns Internet packets around and sends them to PE router
over a non-VRF interface

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per 8us1ness Use Only

Option 3.x: VRF Internet Access

The Option 3 solutions use a central CE site to provide Internet access for remote CE s ites belonging to the same VPN . These
solutions often are called VRF Internet access because from the perspective of the remote CE locations, the same VRF
interface and VRF table is used to access VPN and Internet destinations.

In operation, the central CE route normally connects to the PE router using both a VRF and a non-VRF interface. The VPN 's
global addresses are associated with the non-VRF interface. These routes are placed in the main routing table . The central
CE router then redistributes Internet routes (th is can be a default route) to the remote CE locations.

Therefore, the central CE device receives both VPN and Internet traffic over its VRF interface. In the case of Internet traffic,
the central CE device turns the packets around and sends them back to the PE router using its non-VRF interface.

www .juniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5 - 33

Ju nos Layer 3 VPNs

Internet Access Support

■ Internet access summary:
• Internet access through a non-VRF interface (PE router has no Internet routes)
• Options 1.1 and 1.2
• Internet access through a VRF interface (PE router has some or all Internet
routes)
• Options 2.1, 2.2, and 2.3
• Uses a default route in VRF table that points to next-table inet . o
• Routes in inet . o cannot point back to a VRF table
• RIB groups are required to install VPN routes into inet . o so that return traffic can be
routed correctly to CE device
• Can use a single PE-CE VRF interface
• Central CE device providing Internet access (Option 3.x)
• In all cases, the CE device must use globally assigned IP addresses for
Internet traffic

~ 2020 Juniper Networks, Inc . All Rights Reserve<!.

Juniper Business Use Onty
Jun1Per
NETWORKS
34

The Ju nos OS Internet Access Support

Th is slide summarizes the Internet access options supported by the Ju nos OS.

Chapter 5-34 • Layer 3 VPN Scaling and Internet Access www.j uniper.net
 Junos Layer 3 VPNs

Summary

■ In th is content, we:
• Described four ways to improve Layer 3 VPN scaling
• Describe three methods for providing Layer 3 VPN customers with Internet
access

~ 2020 Juniper Networks, Inc . All Rights Resenie<I.

Jo niper8us1ness Use Only
Jun1Per
~ETWOffKS
35

We Discussed:
• Several ways to improve Layer 3 VPN sca ling; and

• Three methods for providing Laye r 3 VPN customer with Internet Access.

www .j uniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5- 35

Junos Layer 3 VPNs

Review Questions

1. What are several methods to improve Layer 3 VPN scaling?

2. List and briefly explain three ways to provide Layer 3 VPN
customers with Internet access.

~2020 Juniper Networlcs, Inc .All Rights Reserve<!.

Ju niper Business Use Onty
Jun1Per
NETWORKS
36

Review Questions
1.

2.

Chapter 5-36 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 Junos Layer 3 VPNs

Lab: Route Reflection and Internet Access

■ Configure a Layer 3 VPN using a route reflector to distribute routes.

■ Configure route target filtering.
■ Configure a PE router to route between the public Internet and a
Layer 3 VPN.

~2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jo niper8us1ness Use Only
Jun1Per
NETWORKS
37

Lab: Route Reflection and Internet Access

Th is slide provides the obj ectives for this lab.

www .j uniper.net Layer 3 VPN Scaling and Internet Access • Chapter 5 - 37

Junos Layer 3 VPNs

Answers to Review Questions

1.
Some of t he recommended methods are: observing PE router limits regard ing total number of routes, keeping the CE-to-PE
routing simple, using BGP route reflect ors for VPN rout es, using the BGP refresh option, and using route target f iltering.

2.
Option 1 provides Internet access through a non-VRF interface (PE router has no Internet routes). Option 2 provides Internet
access through a VRF interface (the PE router has some or all Internet rout es). Option 3 provides Internet access through a
centra l CE device.

Chapter 5-38 • Layer 3 VPN Scaling and Internet Access www.juniper.net

 un1Pe[
NETWORKS
Education Services

Junos Layer 3 VPNs

Chapter 6: Layer 3 VPNs Advanced Topics

Engineering Simplicity
Junos Layer 3 VPNs

Objectives

■ After successfully completing this content, you will be able to:

• Describe how the auto-export command and RIB groups can be used to
support communications between sites attached to a common PE router
• Explain the flow of control and data traffic in a hub-and-spoke topology
• Describe various Layer 3 VPN Cos mechanisms supported by the Ju nos
operating system
• Describe support for GRE and IPsec tunnels in Layer 3 VPNs
• Describe support for various types of egress protection

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

We Will Discuss:
• How the auto-export command and routing table groups can be used to support communications between sites
attached to a common provider edge (PE) router;

• The flow of control and data traffic in a hub-and-spoke topology;

• The various Layer 3 virtua l private network (VPN) class of service (CoS) mechanisms supported by the Ju nos
operating system;

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

• Ju nos OS support for different types of egress protection .

Chapter 6-2 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Agenda: Layer 3 VPNs-Advanced Topics

➔ Exchanging Routes Between VRF Tables

■ Hub-and-Spoke Topologies
■ Layer 3 VPN CoS Options

■ Layer 3 VPN and GRE Tunneling Integration

■ Layer 3 VPN and IPsec Integration

■ BGP PIC Edge for MPLS Layer 3 VPN

■ Provider Edge Link Protection

■ Seamless MPLS

~2020 Juniper Networks, Inc .All Rights Resenie<I. Jun1Per

NETWORKS
3

Exchanging Routes Between VRF Tables

The slide lists the topics we will discuss. We will discuss the highlighted topic first.

www .juniper.net Laye r 3 VPNs-Advanced Topics • Chapter 6-3

Junos Layer 3 VPNs

Sharing Routes Between VRF Tables

in the Same PE Router

VRF-8
VPN-8/A
Routes

CE-A
VPN-A

• Goal: Allow communications between CE-A and CE-8 without

placing them into the same VPN
• Solution: Use the auto-export command or RIB groups
C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Allowing Communication
At t his point, you should be we ll versed in the procedures used to populate VPN routing and forwarding tables (VRFs) with routes
learned from local custome r edge (CE) devices and with the routes learned from remote PE routers. However, what if you want to
all ow comm unications between two different VPN sites t hat attach to the same PE router?

A common example why this m ight be necessary is a provider's network management system requiring communications with CE
routers at customer sites that are attached to the same PE router. In some cases, it might be possible to resolve th is dilemma by
simply combining the two VRF tables into one VRF table by placing both CE routers into the same VPN. Unfortunately, this
straightforward sol ut ion does not work well for the example on the slide because administrative boundaries (which are the
whole purpose of VPNs) are difficult to maintain when different VPNs sudden ly merge into one VPN.

VRF policy does not solve th is problem either. VR F policy normally only affects routes exchanged between PE routers.
Because t he sites shown on the slide are attached to the same PE router, no Multi protocol Border Gateway Protoco l
(MP-BGP) session exists to which you could even apply VR F policy. However, if you configure the auto-export command in
each VRF table, the import and export VR F policies are evaluated witho ut the need for MP-BGP sessions to exist, as
descri bed in the following pages.

Using Routing Table Groups

Another solution to this problem involves routing table groups. Routing table groups allow t he linking of different routing tables
within the router so t hat routes can be exchanged between them. The use of routing table groups to solve this problem is
demonstrated as wel l in fo llowing pages.

Chapter 6 - 4 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

auto-export Example

• auto-export command configured in multiple VRF tables causes

router to analyze vrf-import/export policies or vrf-target
statements in those VRF tables
• VPN routes are copied into appropriate local VRF tables
[edit routing- instances) vpn- b (
user@PE# show instance-type vrf ; 10.0.21/24
vpn-a { interface ge-0/0/3 . 0 ;
instance-type vrf ; vrf-target target : 65412 :1 00 ; .2 .1 PE
interface ge-0/0/0 . 0 ; routing-options { ge-0/0/0
loO: 192.168.16.1
vrf- target target : 65412 : 100 ; auto- e xport ;
routing-options { }
auto-export ; protocols {
} bgp {
protocols { group ce- b (
bgp { peer-as 65000 ;
group ce-a { as- override ;
peer-as 65000 ; neighbor 10 . 0 . 50 . 2
as-override ;
neighbor 10 . 0 . 21 . 2;

C/2020 Juniper Networl<s, Inc .All R,ghlS ReseM!<I.

auto-export Example
This slide provides an example of how to use the auto-export command to leak routes between VR F tables in the same PE
router. The d rawing on the slide s hows the PE router that now has CE-8 attached to its ge-0/ 0/ 3 interface. In each VRF table on
the PE, the auto-export command is enabled . This command ca uses the router to analyze some combination of the
vr f -import pol icy, vr f -exp o r t policy, and the vr f -tar ge t statements of each VRF table t hat has the auto-export
command configured . Any routes with the correct target communities are then copied between these VRF t ables.

In the example on the s lide, because both VRF tables use the same import and export VRF target, all ro utes in the vpn-a
table are copied into the vpn-b table, an d contra riwise.

www .juniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 5

Junos Layer 3 VPNs

VRF RIB Group Example

routing-options {
riu-groups \
a-to-b {
import- rib [ vpn- a . inet . O vpn- b . inet . O ) ;
}
b- to- a {
10.0.21/24 ____....._
import-rib [ vpn-b . inet . 0 vpn-a . inet . 0 ] ; .2 PE
} ge-0/0/0
loO: 192.168.16.1
J
autonomous-system 65412 ;
}
routine-instances {
vpn-a {

routing- options {
interface-routes {
rib- group inet a - to- b ;
}
/
protocols {
bgp {
group ext {
type external ;
familv inet I
unicast {
rib- nroun a - to- b ;
)
}

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

VRF Routing Table Group Example

This slide provides an example of how to use routing table groups to leak routes between VRF tables in the same PE router. The
code snippet begins with the creation of two routing table groups under the [e dit r ou t i ng-op t i o n s ] hierarchy. In th is
example, the a-to-b routing table group is to ld to place its routes into its own instance ( vpn - a . inet . O) and into t he routing
table associated with t he vpn - b . i net . o instance. The same effect is configured for the opposite direction with the b - t o - a
routing table group.

When listing the i mport-r i b variables, the first routing tab le listed is considered the owner of the routing table group.
Therefore, the vpn - a . i ne t. O is listed before the vpn - b . inet . O in the a - t o - b routing table group. This order prevents the
a - to - b routing table group from functioning if it is applied later to t he vpn - b routing instance.

The next code snippet shows the re levant portions of the vpn-a VRF table . While the VRF tab le configuration fo r vpn-b is
not shown, that instance requires similar configuration steps. In th is case, the VRF instance has its routing-options
configured to place t he VRF interface routes into the a-to-b routing table group. This configuration is required so t hat the
interface routes associated with each VRF tab le are copied into the VRF tables of the other sites with wh ich it is to
communicate. If the VR F interface routes are not copied into the other VRF tables, the routes that are copied will be
unresolvable (and therefore unusable) by virtue of their pointing to an unknown interface as part of the packet's next hop.

The last relevant portion of vpn - a's VRF configu ration is the need to link t he CE-PE routing protocol to the a - to - b routing
table group. This step ca uses the BGP routes learned from CE-A to be copied into both the vpn - a and vpn - b VRF tables. EBGP,
OSPF, and RI P support routing table groups. You can define static routes in each site's VRF table, or they can be specified in a
routing table group that imports into the VRF tables.

The Ju nos OS a lso allows the use of pol icy to control the exchange of routes between routing tab le groups. To use th is feature,
include the i mport-po licy option when defining the routing table groups:

u se r @PE# show routing-options

r ib-gr oup s {
a-to-b {
impo rt - rib [ vp n-a . i ne t. 0 vpn- b.ine t. 0 ] ;
impo rt -pol i cy r i b-pol i cy ;
• • •

Chapter 6 - 6 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Verifying the Results

user@PE# run show rou te table vpn-b

vpn - b . inet . O: 11 destinations , 11 routes (11 active , 0 holddown , 0 hidden)

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

10 . 0 . 21 . 0/24 *[Direct/OJ 03 : 21 : 27 -
> via ge - 0/0/0 . 0
[BGP/170] 03 : 21 : 27 , l ocalpref 100 VRF routes
AS path : 65001 I (local and BGP) from
> to 10.0 . 21 . 2 via ge - 0/0/0 . 0 VPN-A are now in
10.0 . 21 . 1/32 *[ Local/OJ 03 : 21 : 27
Local
-----t-
•
VPN-B's VRF table
10 . 0 . 50 . 0/24 *[Direct/O J 00 : 16 : 48
> via ge-0/0/3 . 0
10 . 0 . 50 . 1/32 *[Local/OJ 00 : 16 : 48
Local
• • • •

• VPN-A's interface and BGP routes are in VPN-B's VRF table

(although not shown , VPN-B's interface/BGP routes are also present
in VPN-A's VRF table)
• Traffic can now be forwarded between sites served by CE-A and CE-B

C> 2020 Juniper Networks, Inc All Rights Reserved

Verifying the Results

To verify the results, we issued a command to display t he VRF table associated with the vpn - b routing instance. The display
co nfirms that the interface and BGP ro utes conta ined in t he vpn - a VRF table are now present in the vpn - b VRF table. The
screen capture also confirms that the interface routes associated with the vpn - b instance are also present in t he vpn - b VRF
t able.

The 10.0.21/ 24 interface route is listed twice because it is both a direct route and a route learned through BGP (the CE-A router
has a BGP policy to redistribute direct routes). Because pol icy is not used in th is rout ing table group example, both routes are
copied from the vpn - a VRF ta ble to the vpn - b VRF table even though only the direct ro ute is current ly active in t he vpn - a VRF
t able.

Alt hough not shown on the sl ide, the conf iguration steps performed under the vpn - b routing instance cause the interface and
BGP routes in the vpn - b VRF tab le t o be copied into the vpn - a VRF table.

Site A and Site B Can Communicate

Because both VPN s ites now have routes for each other's site, the two locations can now communicate free ly through the PE
router.

www .j uniper.net Layer 3 VPNs- Advanced Topics • Chapter 6- 7

Junos Layer 3 VPNs

Keeping Shared VRF Routes from Other PE and

CE Routers
[edit po li cy - opt i ons po li cy- statement ! v p n b - exp or tll
user@PE# show
term 1 {
from {
protocol bgp ;
g nterface g e-0 / 0 / 3 . 0 ; !
}
then {
community add vpnb-target ;
accept ;
}
}
term 2 {
then re j ect ;
}

• VRF export policy for vpn-b matches the routes learned from
interface ge - 0 / O/ 3
• Routes copied from the vpn - a VRF table are not sent to remote PE routers
C> 2020 Juniper Networks, Inc All Rights Reserved

vpn-b's Modified VRF Export Policy: The Final Step

Now that we have the two VR F tab les sharing routes, the question might arise as to how we can keep these routes from being
sent to remote PE routers. Assum ing this is a problem, the answer is making an easy modification to the VR F export polices of
the affected VRF tables.

The example shows vpn-b's VR F export pol icy, which now includes an interface condition in term l 's from clause. The
result is that on ly routes learned from the ge-0/0/ 3 interface are accepted for export to remote PE route rs. This result
prevents the vpn-b instance from advertising routes leaked from the vpn-a VR F table.

Chapter 6 - 8 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Agenda: Layer 3 VPNs-Advanced Topics

■ Exchanging Routes Between VRF Tables

➔ Hub-and-Spoke Topologies
■ Layer 3 VPN Cos Options

■ Layer 3 VPN and GRE Tunneling Integration

■ Layer 3 VPN and IPsec Integration

■ BGP PIC Edge for MPLS Layer 3 VPN

■ Provider Edge Link Protection
■ Seamless MPLS

C2020 Juniper Networks, Inc . All Rights Resenie<I. Jun1Per

~ETWORKS
9

Hub-and-Spoke Topologies
The slide highlights the topic we d iscuss next.

www .j uniper.net Layer 3 VPNs- Advanced Topics • Chapter 6-9

Junos Layer 3 VPNs

Hub-and-Spoke Topologies
■ Reduces the number of BGP sessions and LSPs required, but the
cost is an extra CE router hop
• Spoke-to-spoke communications must transit hub site
■ Requires two VRF instances in the hub PE router
• Spoke VRF table contains routes received from spoke sites
• Hub VRF table contains routes received from the hub CE device
■ Requires two VRF interfaces at the hub CE/PE link
• Can be logical units on the same interface
■ Requires two route targets and possibly two route distinguishers
when supporting route reflectors
■ Watch for AS path loop detection and OSPF domain ID problems
■ Issues might arise when hub PE router has locally connected spokes,
or when multiple spoke sites attach to the same spoke PE router
C/2020 Jun,per Networks, Inc .All R,ghlS Resenie<I. Jun1Per 10 ~ETWORKS

Reduces the Number of BGP Sessions and LSPs Required

Layer 3 VPNs can be deployed in a hub-and-spoke topology in wh ich remote sites communicate through the hub site CE router.
This topology is well suited for centralized data processing environments where spoke-to-spoke communications are the
exception rather than the norm. A hub-and-spoke VPN has the added advantage of reducing BGP peering and LSP requirements
in that spoke locations only require a single BGP session and LSP to the hub site. The hub site must support n - 1 LSPs and BGP
sessions, however, because it must connect back to each spoke site.

Two VRF Instances Required at Hub

For proper operation, the hub PE router requires two VRF instances. The spoke instance receives routes from the spoke
locations and conveys them to the hub CE router. The hub instance receives routes from the hub CE router and redistributes
them out to the spoke sites.

Two VRF Interfaces Required at Hub

A separate VRF interface is requ ired to back up each VRF instance in the hub PE router. In practice, th is interface is normally
one physical interface with two logical units.

Two Route Targets Needed

The hub-and-spoke topology uses two route targets. Spoke sites advertise routes to the spoke instance using one route target
and receive routes from the hub instance with another route target. You can implement a hub-and-spoke topology with a single
route distinguisher used for both the hub and spoke instances, but the presence of route reflection forces a unique route
distinguisher value for each instance. Th is requirement is needed to ensure that the route reflector does not attempt to
compare the routes advertised (and choose a best route) by the two instances.

Continued on the next page.

Chapter 6-10 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

AS Path Loops and Domain ID Issues

The use of BGP in a hub-and -spoke topology can result in problems with AS loop detection. Enabling autonomous system (AS)
l oops on the hub PE router might be required, even when using as-ove rr ide and remove-p r iva t e .
The use of OSPF as the hub PE-CE routing protocol can present problems due to the up/down bit that prevents link-state
advertisement (LSA) looping. A PE router that receives an LSA with this bit set will not install the corresponding route. By default,
this bit is set on all LSAs that the PE router advertises to the CE router. You can disable this functionality by explicitly configuring
domain-vpn tag o. Hub sites must manually configure this VPN route tag in their spoke instance so that the hub instance
will install the routes to spoke CE routers.

Locally Attached Spokes

The presence of multip le spokes attached to the same PE router, or a spoke site attached to the hub PE router, requ ires
additional configuration steps to ensure the hub CE device is transited for spoke-to-spoke communications.

www .juniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 11

Junos Layer 3 VPNs

Signaling Flow Between Spokes

Hub
CE

ge-0/0/0.0 4 ge-0/0/0. 1
--- 3
Spoke ~
---
--- Hub PE_..____.i-.1 Hub
VRF VRF

Target: Target:
Spoke Hub
2 5

Spoke Spoke
CE-1
. .. CE-2
1 6

C> 2020 Juniper Networks, Inc All Rights Reserved

Signaling Flow Between Spoke Locations

Th is slide high lights the flow of signa ling (routing protocol exchanges) between two spoke locations. The result is that spokes
learn each other's routes through the hub PE router, thereby causing the hub CE router to act as a transit point fo r a ll traffic
between spoke locations.
The following list provides details of t he signa ling flow shown on t he slide:

1. Spoke CE-1 advertises a route.

2. Spoke PE-1 advertises this route to the spoke instance on the hub PE router using the spoke route target.

3. The spoke instance in the hub PE router sends the route to the hub CE router using the ge-0/ 0/ 0.0 VRF interface.
4. The hub CE router either re-advertises the route or generates an aggregate for all spoke sites, which is sent to the
hub PE ro uter's hub instance using the ge-0/ 0/ 0.1 VRF interface.
5. The hub instance in the hub PE router advertises this route to t he spoke sites using the hub route target.

The spoke sites match the routes with the hub route target and install the route in their VRF table. For spoke PE-2, the route
is sent to the attached spoke CE router (CE-2).

Chapter 6-12 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Data Flow Between Spokes

Hub
CE
4 3
ge-0/0/0 .1_ __
--.....;;,.
ge-0/0/0 .0

Spoke 1...+---- Hub PE...__-4-J Hub

VRF ....._VRF

5 2

Spoke
CE-1 6

C2020 Juniper Networks, Inc .All R,ghlS Resenie<I.

Data Flow Between Spoke Locations

Th is slide high lights the flow of data (forwarding plane) between two spoke locations. The following list provides the deta ils of
this flow:

1. CE-2 sends a packet addressed to the CE-1 site.

2. PE-2 has learned the routes for Site 1 through the hub instance, so it forwards the packet to the hub PE router.

3. The packet is received by the hub PE router's hub instance. It is forwarded out the
ge-0/ 0/ 0 .1 VRF interface, because the hub instance has learned these routes from the hub CE router.
4. The hub CE router has learned about Site l 's routes from the hub PE router's spoke instance. Therefore, the packet
is turned around by the hub CE router and is sent back to the hub PE router on the ge-0/ 0/ 0 .0 VRF interface.
5. The spoke instance in the hub PE router forwards the packet to spoke PE-1.

6. Spoke PE-1 forwards the packet to CE-1.

www.j uniper.net Layer 3 VPNs- Advanced Topics • Chapter 6-13

Ju nos Layer 3 VPNs

Sample Spoke Configuration (1 of 3)

■ A single routing instance is defined in the spoke sites:

routing-instances {
vpna {
instance-type vrf ;
interface ge-0/0/0 . 0 ;
route-distinguisher 192 . 168 . 16 . 1 : 1 ;
vrf-import vpna-import ;
vrf-export vpna-export ;
protocols {
bgp {
group ext {
type external ;
peer-as 65001 ;
as-override ;
neighbor 10 . 0 . 21 . 2 ;
}
}
}
}
}

C/2020 Jun,perNetworl<s, Inc .All Rights ReseM!<I.

Sample Spoke VRF Table

Th is slide provides an example of a spoke PE router's VRF t able co nf iguration . Only one instance is required for spoke sites.
In th is example, t he PE-CE rout ing protocol is EBGP.

Chapter 6-14 • Layer 3 VPNs- Advanced Topics www.j uniper.net

 Junos Layer 3 VPNs

Sample Spoke Configuration (2 of 3)

■ A spoke site's VRF import policy that accepts route tagged as coming
from the hub route target:
pol i cy- options {
policy-statement vpna-import {
term 1 {
from {
protocol bgp ;
community hub;
}
then accept ;
}
term 2 {
then reject ;
}
}
community origin-pel members origin : 192 . 168 . 16 . 1 : 1 ;
community hub members target:65412:100;
community spoke members target : 654 12:1 01 ;
}

~2020 Juniper Networks, Inc .All Rights ReseM!<I.

Sample Spoke VRF Import Policy

This slide shows a spoke site 's VRF import policy set to match the routes with the hub route target.

www .juniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 15

Junos Layer 3 VPNs

Sample Spoke Configuration (3 of 3)

■ A spoke site's export policy and community definitions:

policy - statement vpna - export {
term 1 {
from protocol [bgp static direct] ;
then {
community add origin-pel ;
community add spoke ;
accept ;
}
}
term 3 {
then reject ;
}
}
community origin-pel members origin : 192 . 168 . 16 . 1 : 1 ;
community hub members target : 65412 : 100 ;
community spoke members target : 65412 : 101 ;
}

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Sample Spoke VRF Export Policy

This slide shows that a spoke site 's VRF export policy is configured to attach the spoke route target to the advertisements it
sends to the hub PE router.

This example also shows the extended community definitions, including both a hub and a spoke route target.

Chapter 6-16 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Sample Hub Configuration (1 of 4)

■ Multiple interfaces (logical or physical} needed at the hub location:

interfaces {
ge - 0/0/0 {
vlan- tagging ;
unit O {
v l an - id 100 ;
family inet {
address 10 . 0 . 29 . 1/24 ;
}
}
unit 1 {
vlan-id 200 ;
family inet {
address 10 . 0 . 30 . 1/24 ;
}
}
}

C2020 Juniper Networks, Inc .All Rights Reserlle<I. Jun1Per

.iETWOffKS
17

Sample Hub Configuration: VRF Interfaces

Th is portion of the hub PE router's configuration shows that two virtual LAN (VLAN )-tagged logica l interfaces are provisioned
to support the two routing instances required by t he hub PE router.

www.j uniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 17

Junos Layer 3 VPNs

Sample Hub Configuration (2 of 4)

■ The hub instance exports routes learned from the hub CE device to
the remote spokes:
routing-instances {
hub {
instance-type vrf ;
interface ge-0/0/0 . 1 ;
route-distinguisher 192 . 168 . 24.1 : 1 ;
vrf-import null ;
vrf-export hub-out ;
protocols {
bgp {
group extl {
type external ;
peer - as 65001 ;
neighbor 10 . 0 . 30 . 2 ;
}
}
}
}

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Sample Hub Configuration: Hub Instance

This slide displays the hub PE router's hub VRF configuration. This instance is tied to the hub PE router's ge-0/ 0/ 0 .1 VRF
interface and is configured for EBGP routing exchange with the hub CE router.

Because spoke routes are learned by the hub site's spoke VRF instance, the hub instance uses a null VRF import policy. As
shown on subsequent slides, this policy requires that a policy statement named null be configured with a single then
reject statement.

Chapter 6 - 1 8 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Sample Hub Configuration (3 of 4)

• The spoke instance imports routes from the remote spokes and
sends them to the hub CE device:
routing- instances {
• • •

spoke {
instance - type vrf ;
interface ge - 0/0/0 . 0 ;
route - distingu i sher 192 . 168 . 24 . 1 : 1 ;
vrf - import spoke -i n ;
vrf - export nul l;
protoco l s {
bgp {
group ext {
type external ;
peer-as 65001 ;
as - override ;
neighbor 10 . 0 . 29 . 2 ;
}
}

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Sample Hub Configuration: Spoke Instance

This slide displays the hub PE router's spo k e VRF table configuration. This instance is tied to the hub PE router's ge-0/ 0/0.0
VRF interface and also is configured for EBGP routing exchange with the hub CE router.

Because the hub site 's hub VRF instance advertises spoke routes, the spoke instance is using a nu l l VRF export policy. As
shown on subsequent s lides, this policy requires that a policy statement named null be configured with a s ingle the n
r e j ect statement.
Because EBGP is used on the hub's PE-CE link, AS-path loop detection is a prob lem . In this case, the use of the as-ove rr ide
knob prevents loop detection problems as the spoke routes are delivered to the hub CE router through the spoke instance.
However, because the provider's AS number is now at the front of the AS path, when the hub CE router readvertises the routes
back to the hub PE router's hub instance, the hub PE router detects an AS loop and discard the routes. Therefore, you should
observe the following guidel ine:

• Do not use EBGP at the hub site.

• Configure AS loop s 2 on the hub PE router's hub instance.

Configure the hub CE router with static routes (which can be aggregates) redistributed into the hub CE device's hub instance
EBGP session . Because these routes originate at the hub CE router, the provider's AS number is not present in the AS path.

www .juniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 19

Junos Layer 3 VPNs

Sample Hub Configuration (4 of 4)

■ Sample hub policy (two route targets are used):

policy- options {
pol i cy-statement spoke- i n {
from {
protoco l bgp ;
community spoke ;
}
then accept ;
}
po l icy- statement hub- out {
from protocol bgp ;
then {
community add hub ;
accept ;
}
}
policy- statement null {
then reject ;
}
community hub members target : 65412 : 100 ;
community spoke members target : 65412 : 101 ;
}

C2020 Juniper Networks, Inc . All Rights Resenie<I.

Sample Hub Configuration: VRF Policy

Th is slide displays the hub PE router's VRF pol icy and extended BGP commun ity definitions. The hub's spoke-in policy
matches the routes with the spoke route target, whi le t he hub-out policy adds the hub community. The spoke VRF policy
configuration in effect reverses the above policies by attaching the spoke community on advertised routes and matching the
routes learned from the hub community for rece ived routes.

Chapter 6-20 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Hub-and-Spoke Troubleshooting

■ Most problems relate to signaling

• Verify the signaling exchange by confirming the presence of a spoke route at
each stage
• Start with an examination of the hub PE router's spoke instance to save time
• Suspect route target mismatches
• Suspect AS loop detection when using EBGP at the hub site
■ Perform a traceroute from spokes to hub before trying spoke-to-
spoke traceroutes

C2020 Juniper Networks, Inc . All Rights Resenie<I. Jun1Per

~ETWORKS
21

Most Problems Relate to Signaling Exchanges

Because the signaling plane is more complex than the forward ing plane, and because forwarding cannot work when signaling is
broken, you should approach hub-and-spoke troubleshooting by first verifying proper signaling flows .

While complex in its entirety, breaking down the signaling into discrete steps makes signaling verification a manageable task.
For example, if the spoke route is in the local spoke CE device's VRF table but not in the hub PE router's spoke instance, the
problem must relate to either that spoke router's advertisements (VR F export) or the hub PE router's reception (VR F import).

By exam ining the hub PE router's spoke VR F instance f irst, you can verify nearly one half of the total signaling exchange in one
step. El iminating half of all possible causes with each test is a prime way of expediting the fau lt isolation process.

Because of the requ irement for two route targets, and the like lihood of AS loop detection when EBGP is provisioned at the
hub PE-CE link, you always should suspect these two areas as likely causes for operational problems.

Traceroute from Spoke to Hub First

When a traceroute between two spoke locations fai ls, it is often difficult to determine the location of the problem. Because
spoke-to-spoke communications must transit the hub location, first verify that each spoke location can communicate
successfully with the hub site. When two spokes can reach the hub, but not each other, the problem normally lies in the hub
CE device operation, as it would re late to the re-advertisement of the spoke routes.

www .j uniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 21

Junos Layer 3 VPNs

Agenda: Layer 3 VPNs-Advanced Topics

■ Exchanging Routes Between VRF Tables

■ Hub-and-Spoke Topologies
➔ Layer 3 VPN Cos Options
■ Layer 3 VPN and GRE Tunneling Integration

■ Layer 3 VPN and IPsec Integration

■ BGP PIC Edge for MPLS Layer 3 VPN

■ Provider Edge Link Protection
■ Seamless MPLS

C2020 Juniper Networks, Inc .All R,ghlS Resenie<I. Jun1Per

~ETWORKS
22

Layer 3 VPN Cos Options

The slide highlights the topic we d iscuss next.

Chapter 6-22 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

VPNs and Cos

■ Filtering and CoS mapping functions available at ingress PE router
• Firewall filtering, classification, rate limiting, precedence mapping
■ Filtering functions might be unavailable on egress PE
• Support of vrf-table-label and vt-interface allows filtering functions
at egress router
■ VRF label EXP bits can be set based on FW filters, ingress interface,
or IP precedence bits
■ Outer label (RSVP) can be set statically with
class-of - service configuration option
• Enhanced FPC can write both labels independently
■ classifiers exp option is available on transit and egress PE
router
• Accommodates WRR and RED functions for labeled packets

C/2020 Juniper Networks, Inc .All Rights Resenie<I. Jun1Per

~ETWORKS
23

Filtering and Cos Functions Available at Ingress

The f ull range of filtering and Cos functions are available at the ingress PE router. The functions include f irewa ll fi ltering, rate
limiting, queue selection, and IP precedence mapping.

Filtering and Cos Functions Available at Egress

You can also employ fi ltering and Cos f unctions at the egress PE router when certain conditions are met. These f unctions
all ow for Add ress Resolution Protocol (ARP) operations, egress rate limiting, and f irewa ll f iltering.

VRF Label Experimental Bits

The EXP bits in the VRF label can be set based on f irewa ll classification, IP precedence bits, or ingress interface.

RSVP Label Experimental Bits

The EXP bits of the RSVP label can be set with a static Cos val ue. Or, with t he En hanced Flexib le PIC Concentrator (FPC), the
RSVP or LDP label can have its EXP field set to the va lue used by the VR F label.

classifiers exp Setting on Transit LSRs

Setting the c las s ifi ers exp option on transit LSRs makes weighted round-robin (WRR) and random early detection
(RED) functionality available for labeled packets. Failing to specify an EXP c lassifier results in all labeled packets being
placed into output queue Oby default. With Enhanced FPC hardware, yo u can create custom EXP to output queue mappings,
b ut an exp c l as s i fiers statement is still necessary to effect EXP-based output queue selection for queues 1- 3 .

www .j uniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 23

Junos Layer 3 VPNs

VPNs CoS Configuration Example

user@Rl# show interfaces ge-1/0/0
unit O {
family inet {
filter {
I
!input test ;
l
address 10 . 0 . 6 . 1/24 ;

user@Rl# show firewall family inet

filter !test {!
term 1 {
from {
protocol icmp ;
l
then forwarding-class assured-forwarding ;
l
term 2 {
then accept ;
l
• • •
user@Rl# show protocols mpls label-switched-path am
to 192 .1 68 . 24 . 1 ;
! class - of- service 4 ; !

C2020 Juniper Networks, Inc . All Rights ReseM!<I.

Layer 3 VPN Cos Example

Th is slide provides an example of how you can use firewall filters to classify packets for queuing, and how you can configure
an RSVP session with a static CoS value. The result of this configuration is that transit LSRs queue the labeled packets in
queue number 2 (assured-forwarding forwarding class). The ingress PE router places all Internet Control Message Protocol
(ICMP) traffic into queue 2 with all other traffic going into queue O (the default queue).

With an Enhanced FPC, both labels can be written independently. Th us, the queuing decisions made by the ingress PE router
can be mirrored in the transit LSRs and at the egress PE router.

Chapter 6-24 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

VPNs CoS Example: The Result

Frame 12 (106 on wire , 106 captured)
Ethernet II
MultiProtoco l Labe l Switching Header
MPLS Label : Unknown (100003)
! MPLS Exp erimental Bits : 4l +------TopLabel
MPLS Bottom Of Label Stack : 0
MPLS TTL : 254
MultiProtoco l Labe l Switching Header
MPLS Label : Unknown (100001)
I MPLS Exp er i menta l Bi ts : 41+------Bottom Label
MPLS Bottom Of Label Stack : 1
MPLS TTL : 254
Internet Protocol
Version : 4
Header length : 20 bytes
• • • •

■ The top (RSVP) label is set using the class-of-service

command under LSP definition
■ The bottom (VRF) label is set based on firewall classification at
ingress PE router
C2020 Juniper Networks, Inc .All R,ghlS Resenie<I.

RSVP Label Has Static CoS

This protocol capture shows the results of the CoS configuration shown on the previous page. The top label in this example is
carrying the static Cos value associated with the LSP itself.

Bottom Label Has Firewall-Based Classification

The bottom (VRF) label in this example is carrying a Cos va lue set by the f irewall-based classification of the packet at
ingress. With a 82 FPC, the firewall-based classification is overwritten by the outer label's EXP va lue. Therefore,
differentiated queuing is only possible at the ingress PE router. With the Enhanced FPC, the values are set independently. By
default, an Enhanced FPC-equipped router sets the outer label to the value of the inner label such that classification at the
ingress PE router sets the EXP field of both labels, thereby allowing transit and egress queuing based on input classification.

www .juniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 25

Junos Layer 3 VPNs

VPN Load Balancing/Prefix Mapping

■ Can balance VPN traffic over equal-cost LSPs

• Export policy applied to main routing instance forwarding table
■ Can map VPN traffic to specific LSPs when equal-cost LSPs exist
• Policy used at ingress or egress nodes
• Tag VPN routes with communities at LSP egress, match these communities at LSP
ingress node
• Manipulate BGP next hop at LSP egress, map LSPs to the correct BGP next hop at LSP
•
ingress

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Load Balancing
You can load-balance VPN traffic across multiple LSPs by applying a load-balancing policy to t he main forwarding instance.

Mapping Traffic to Specific LSPs

You also can map VPN traffic to a specific LSP when multiple LSPs exist between a pair of PE routers. This mapping allows a
service provider to offer a multitier service by deployi ng LSPs between PE routers havi ng differing performance
characteristics.

The most common techn ique for prefix-to-LSP mapping involves routing policy at t he LSP ingress node. This policy maps
traffic to a particular LSP using community-based match criteria. Th is technique assumes that t he LSP egress node tags VPN
prefixes with the correct community value as the routes are advertised to PE routers using multiprotocol lBGP. Note that this
tec hn ique currently does not support route f ilter match conditions at the LSP ingress node.

You can also map prefixes to LSPs by manipulating the BGP next hop at the LSP egress node as the routes are advertised to
PE routers. When establishing the two LSPs, you must use care to ensure that each is defined to terminate on the correct IP
address at the LSP egress node. The result is that the LSP ingress node reso lves some of the VPN routes to one of the BGP
next hops and t he remai ning routes to the other BGP next hop. When the LSP egress node resolves these BGP next hops
th rough its inet . 3 routing tab le, it selects the LSP that matches the route 's BGP next hop for installation in the forwarding
tab le.

Chapter 6-26 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

VPN Prefix Mapping: Policy Example (1 of 2)

user@Rl# show policy-options policy-statement map
term 1 {
from {
_ u_n_i _t _y _g_o_1..,c""'t ";...I - - - - Communities tagged at remote PE router
-1c_o_mm
}
then {
install-nexthop lsp am ;
accept ;
}
}
term 2 {
from {
community silver ;
}
then {
install - nexthop l sp am2 ;
accept ;
}
}
term 3 {
then accept ;
}

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Prefix Mapping Example

Th is slide demonstrates the technique of mapping prefixes to LSPs using routing policy, which matches commun ities at the
LSP ingress node.

The policy uses the i nstall-next h op l s p action modifier to direct matching routes to a specific RSVP session. Term 3
accepts all nonmatching routes for the default action of per-p refix load ba lancing across equal-cost LSPs.

www .j uniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 27

Junos Layer 3 VPNs

VPN Prefix Mapping: Policy Example (2 of 2)

• map policy is applied to main routing instance:

use r @Rl# show routing-options

autonomous - system 65412 ;
forwarding-table {
export ! map ; j
}

• And the results ...

user@Rl> show route forwarding -table vpn vpnb
Routing table :: vpnb . inet
Internet :
Destination Type RtRef Nexthop Type Index NhRef Netif
172 . 16 . 4 . 0/24 user O 10 . 0 . 16 . 2 Push 100001, Push 100032(top) [4] ge-0/0/1 . 0

172 . 16 . 6 . 0 24 user 0 10 . 0 . 16 . 2 Push 100001 Push 100032 to 4 .0

172 . 16 . 7 . 0/24 user 0 10.0 . 16 . 2 Push 100001 , Push 100032(top) [4] ge- 0/0/1 . 0

l 192 . 168 . 53 . 0/24 user 0 10 . 0 . 16 . 2 Push 100001 , Push 100030(top ) (4] 9e - 01011 . o I
192 . 168 . 53 . 1/32 user 0 10 . 0 . 16 . 2 Push 100001, Push 100030(top) [4] ge-0/0/1 . 0

C2020 Juniper Networks, Inc . All Rights Resenie<I.

Prefix Mapping Policy

You must apply the policy shown on the previous page if it is to have any effect. Prefix mapping and load-balancing policies
must be applied to the main instance's forwarding table. The slide shows this application.

The Results ...

After applying and committing the prefix mapping policy, you can verify the resu lts by examining the vpnb VRF table. The
highlighted entries confirm that traffic associated with the 172.16 routes is mapped to one LSP (top label set to 100032),
whi le traffic to the 192.168 routes is mapped to a different LSP (top label set to 100030).

Chapter 6-28 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Agenda: Layer 3 VPNs-Advanced Topics

■ Exchanging Routes Between VRF Tables

■ Hub-and-Spoke Topologies
■ Layer 3 VPN Cos Options

➔ Layer 3 VPN and GRE Tunneling Integration

■ Layer 3 VPN and IPsec Integration
■ BGP PIC Edge for MPLS Layer 3 VPN
■ Provider Edge Link Protection
■ Seamless MPLS

C/2020 Jun,perNetworks, Inc . All Rights Resenie<I. Jun1Per

~ETWORKS
29

Layer 3 VPN and GRE Tunneling Integration

The slide highlights the topic we discuss next.

www .j uniper.net Layer 3 VPNs- Adva nced Topics • Chapter 6 - 29

Junos Layer 3 VPNs

PE-PE GRE Tunnels

Customer Customer
Site 1 Site 2

GRE Tunnel
••... ••• Between PE • ••
..tt
• •••
.. ······....................... R OU ter-s·· ··················· ····· ····· ········... •••• •

• The Junos OS supports PE-to-PE GRE tunnels

• Allows carrier-of-carriers VPN applications when provider's network does not
support MPLS
• Requires tunnel services on customer PE routers
• Does not use MPLS forwarding

C/2020 Juniper Networks, Inc .All Rights ReseM!<I. Jun1Per

.iETWOffKS
30

PE-PE GRE Tunnels

The Ju nos OS supports the GRE tunneling of VPN traffic between PE routers. As shown, this support allows an interprovider
VPN application when the provider's backbone does not support MPLS.

To support GRE tunnels, a tunnel services must be enabled as described in previous slides. GRE-encapsulated packets are
not forwarded over MPLS tunne ls.

Chapter 6-30 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

PE-PE GRE Tunnel Configuration

• Unnumbered GRE tunnel with family mpls
user@pel# show interfaces gr-1/0/10
unit O {
tunnel {
source 192 . 168 . 8 . 1 ;
destination 192 . 168 . 28 . 1 ;
}
family inet ;
family mpls ;
I
user@pel# show routing-options
rib inet . 3 {
static {
route 192 . 168 . 28 . 1/32 next - hop gr - 1/0/10 . 0 ;
I
I

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

PE-PE GRE Tunnel Configuration

This slide high lights the key aspects of a PE-to-PE GR E tunnel configuration. Use of a GRE tunnel has no impact on the PE
router's VR F table, VRF policy, or MP-BGP session configuration. Although not shown on the slide, you should ensure that the
customer's IGP does not run over the GRE tunnel, because this can lead to recursion problems.

On the slide, uni t o of the Tunnel Services interface is configured with tunnel properties such as the tunnel's source and
destination addresses. In this case, the addresses represent the va lues assigned to the PE router's loopback interfaces. This
example shows an unnumbered GR E tunnel, and therefore no IP address is specified. Because this tunnel will be used to
support MPLS, f ami l y mpls must also be specified .

As illustrated on the slide you need to configure a static route with the next-hop of the GRE interface in the i ne t. 3
routing table. This is route is configured under the [edi t r o ut i n g-op t ion s r ib i n e t. 3 J h ierarchy.

Note that you must also include the routing instance destination under the tunnel hierarchy if the GRE-encapsulating
interface is also configured under the VRF table. In the example on the slide, the VRF table does not include the PE router's
encapsulating interface.

www .juniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 31

Junos Layer 3 VPNs

PE-CE GRE Tunnels

Provider C ore
PE
OSPFArea 0 2 loO: 192.168.24.1

1 2 192.168.9.97
1/24 1 24/24

AS 65412 GRE Tunnel

( ) PrivateAddresses ( : )

■ The Junes OS supports PE-to-CE GRE tunnels

• Allows connection to remote CE devices across an IP backbone
• routing - instance configuration option to associate GRE tunnel with
correct routing instance
C/2020 Juniper Networks, Inc .All Rights Resenie<I.

PE-CE GRE Tunnels

The Junos OS supports GRE tunnels for PE-CE connections. As shown, th is support allows the interconnection of a remote CE
device across an IP network. The use of GRE tunneling allows the use of private and overlapping addresses as the packets
are forwarded across the IP network based on the global addressing used for the GRE tunnel.

To support GRE tunnels, tunne l services must be enable on routers runn ing the Junos OS. The new r outi ng-i n stan ce
configuration is used to place a GRE tunnel into the correct routing instance:

g r -1/0/0 {
u ni t O {
t u n nel {
source 192 .1 68 . 9 . 98 ;
des t i nat i o n 192 .1 68 . 9 . 97 ;
r o ut i ng- i ns t a n ce {
d est i na t ion v r f - name ;
}
}
}
}

Normally, static routing is used to populate the PE router's VRF table, because running a routing protocol over a GRE tunnel
can lead to low speeds or a complete halt.

Chapter 6-32 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Agenda: Layer 3 VPNs-Advanced Topics

■ Exchanging Routes Between VRF Tables

■ Hub-and-Spoke Topologies
■ Layer 3 VPN Cos Options
■ Layer 3 VPN and GRE Tunneling Integration
➔ Layer 3 VPN and IPsec Integration
■ BGP PIC Edge for MPLS Layer 3 VPN
■ Provider Edge Link Protection
■ Seamless MPLS

C2020 Juniper Networks, Inc . All Rights Resenie<I. Jun1Per

~ETWORKS
33

Layer 3 VPN and IPsec Integration

The slide highlights the topic we d iscuss next.

www .j uniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 33

Junos Layer 3 VPNs

IPsec and Layer 3 VPN Integration

172.20.4/24
,-------,ge-01010.0 IP e-01010.0
CE
Provider Core 2 PE-2 - - - Networkv<--- B
- - --rc~oir- ',.200.0.1 .1 200.0.0 .
.- ge-0 0/1
172.20.0/24
ge-0/0/0 e-0/0/1 10.0.29_1 IPsec Tunnel 10.0.29.2
2 PE-1
1 21/24 1 loO: 192.168.16.1 1 l~)
CE-CE IPsec Tun net
PE-CE Traffic
,.__,....__ _ _ _ _ _ __
( ~)

() CE-CE Traffic (=)

■ The Junos OS supports IPsec/Layer 3 VPN integration

• IPsec tunnels terminate between the PE and CE routers
• CE-CE IPsec tunnels extend through PE routers
• IPsec tunnels can use manual or dynamic security associations
• PE and CE routers both require AS PIC or ES PIC
• PE-PE configuration requires no change, firewall filter-based classification not
used
C2020 Juniper Networ1<S, Inc .All R,ghlS Resenie<I.

IPsec and Layer 3 VPN Integration

The Ju nos OS supports the integration of provider-provisioned Layer 3 VPNs and IPsec protocols. This appl ication most likely
will be used to support the secure exchange of information between the local PE router and a CE router that is remotely
connected t hrough an IP cloud.
• PE-CE IPsec tunnel termination: The Junos OS offers support for the term ination of IPsec tunnels between the
PE and CE routers.
• CE-CE tunnels: As shown, t he CE route rs establish end-to-end IPsec tunnels, which are passed transparently
through the PE routers. These IPsec tunnels provide secure site-to-site communications for data transferred
over the provider's backbone.
• Manual or dynamic SAs: The PE-CE IPsec tunnel can use either manual or dynamic security associations (SAs).
When configuring dynamic SAs, you must ensure that t he encapsulating interface is not listed in the PE router's
VRF table, because this causes dynamic SAs to fa il.
• Hardware required: To support PE-CE IPsec tunnels, both the PE and CE routers requ ire the presence of either
an AS PIC, ES PIC, or a service Dense Port Concentrator (DPC).
• PE-PE configuration: The termination of IPsec tunnels between the PE and CE routers does not affect the PE-PE
or P router configuration. The following pages highl ight the configuration needed to support PE-CE IPsec
tunnels. Because the IPsec tunnel is associated with the control traffic to and from the VRF table, you do not
need to use firewall filters to classify t raffic for encryption. We also discuss PE-PE configuration over GRE and
IPsec.

Chapter 6-34 • Layer 3 VPNs- Advanced Topics www.ju n iper .net

 Junos Layer 3 VPNs

PE-PE GRE and IPsec Tunnels

ge-0/0/0.0
IP e-0/0/0.0
Provider Core PE-2 t----1' Networkv'---
_ - --t2~1005;;
: 1F92:.:.:..1~6s~
.24;;,;.:
.1_, 200.o.o.1
ge-0/0/1 + 172.20.4/24
••
PE •••
••
e-0/0/1 •• ••
2 ge-0/0/0 PE-1
1
G~~ ,...•·
21 /24 1 loO: 192.168. 16.1 c,\ ~
•••. \ • '"""· \{\{\e
172.20.0/24 ,.. ........ •.. . . . . . \l"" ;;;, "v
o "'"ec

192.168.16. 1 ( ) PE-PE Traffic . . ( ~) 192.168.24. 1

■ Provide BGP/MPLS VPN service without MPLS backbone

• Secure transport across the provider's backbone when the CE device does not
supportlPsec
• Configure GRE and IPsec tunnels between PE routers
• MPLS information encapsulated with IP and IPsec header
• Source address is ingress PE router, destination address is BGP next hop-
the address of the egress PE router
C2020 Juniper Networl<s, Inc .All R,ghlS Resenie<I.

IPsec Between PE Routers Instead of M PLS

A conventional Layer 3 BGP/ MPLS VPN requires the configuration of MPLS LSPs between the PE routers. When a PE router
receives a packet from a CE router, it performs a lookup in a specific VRF table for the IP destination address and obtains a
corresponding MPLS label stack. The label stack is used to forward the packet to the egress PE router, where the bottom
label is removed and the packet is forwarded to the specified CE router.

You can also provide Layer 3 BGP/ MPLS VPN service without an MPLS backbone by configuring GRE and IPsec tunnels
between the PE routers . The MPLS information for the VPN (the VPN label) is encapsulated within an IP header and an IPsec
header. The source address of the IP header is the address of the ingress PE router, whi le the destination address has the
BGP next hop, the address of the egress PE router.

www .juniper.net Layer 3 VPNs- Advanced Topics • Chapter 6-35

Junos Layer 3 VPNs

Agenda: Layer 3 VPNs-Advanced Topics

• Exchanging Routes Between VRF Tables

• Hub-and-Spoke Topologies
• Layer 3 VPN Cos Options
• Layer 3 VPN and GRE Tunneling Integration
• Layer 3 VPN and IPsec Integration
➔ BGP PIC Edge for MPLS Layer 3 VPN

• Provider Edge Link Protection

• Seamless MPLS

C> 2020 Juniper Networks, Inc All Rights Reserved Jun1Per

N CTWOkl<S
36

Layer 3 VPN Egress Protection

The slide highlights the topic we d iscuss next.

Chapter 6-36 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

BGP PIC Edge for MPLS Layer 3 VPN (1 of 2)

■ BGP PIC Edge for MPLS Layer 3 VPN

• Support starting in Junos OS Release 13.2
• Installs a Layer 3 VPN route in the forwarding table as an alternate path
• Provides fast failover during PE router failure
• The alternate path is used until IGP has converged
• Supports multiprotocol BGP 1Pv4 or 1Pv6 VPN NLRI resolved using any of
these IGP protocols:
• OSPF
• IS-IS
• LOP
• Reduces eventual traffic loss during failure
• Does not support Multicast

C2020 Juniper Networks, Inc . All Rights Resenie<I. Jun1Per

~ETWORKS
37

BGP PIC Edge for MPLS Layer 3 VPN

In an MPLS VPN Layer 3 environment, it is common for customers to multihome their networks to provide link redundancy.
Although the interior gateway protocol (IGP) can provide fast convergence, in certa in instances, the time to reso lve a link
failure and provide an alternate route can be time consuming. For example, a provider edge (PE) router might be configured
with 200,000 or more IP prefixes, and a PE router failure could affect many of those prefixes.

BGP Prefix-Independent Convergence (PIC) Edge allows you to install a Layer 3 VPN route in the forwarding table as an
alternate path, enabling fast failover when a PE router fails or you lose connectivity to a PE router. Th is already installed path
is used until global convergence through the IGP is resolved. Using the alternative VPN route for forwarding unti l global
convergence is complete reduces traffic loss.

BGP PIC Edge supports multi protocol BGP 1Pv4 or 1Pv6 VPN network layer reachability information (NLRI) resolved using any
of these IGP protocols:

• OSPF

• IS-IS

• LOP

BGP PIC Edge does not support multicast traffic.

www.juniper.net Layer 3 VPNs- Advanced Topics • Chapter 6-37

Junos Layer 3 VPNs

BGP PIC Edge for MPLS Layer 3 VPN (2 of 2)

■ Example topology
• PE1 has BGP PIC edge configured
• Routes via PE2 are protected
• PE3 provides alternate path
• CE2 loO configured with 172.16.1.5/24 for testing

loO 192.168.0. 1
CE1

Site 1
AS 101

Prov~der Core
AS 100
OSPF

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Example Topology
Th is example shows two customer edge (CE) routers, Device CE1 and Device CE2. Devices PE1, PE2, and PE3 are PE routers.
Device Pl is a provider core router. Only Device PE1 has BGP PIC edge configured. The example uses the P1-PE2 link (P-PE)
link to simulate the loss of a section of the network.

For testing, the address 172.16.1.5/ 24 is added as a loop back interface address on Device CE2. The address is announced
to Device PE2 and Device PE3 and is relayed by way of internal BGP (IBGP) IBGP to Device PE1. On Device PE1, there are two
paths to the 172.16.1.5/ 24 network. These are the primary and a backup path.

Chapter 6-38 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

BGP PIC Edge Configuration

user@PElf show policy- options
poJ..icy s1:ai::emeni:. • ....., 1
then {
load-balance per-packet;
)
}

user@PEll show routing- i nstances

customer! (
instance- type vrf ;
interface ge-1/2/0 . 0 ;
route-distinguisher 100 : 1 ;
vrf-target target : 100 : 1;
routing-options {
I
protect core; I
}
protocols (
bgp (
group ebgp I
type external ;
peer- as 101 ;
neighbor 10 . 0 . 0 . l ;
)
)
)
}

user@PEl# show routing- options

router-id 192 . 168 . 0 . 2;
autonomous-system 100 ;
forwarding- tabllee_:(' . . _ . - - - - - - ~
export lb ; •
)

C/2020 Juniper Networl<s, Inc .All R,ghlS Resenie<I.

Example Configuration
Before the BGP PIC Edge in an MPLS Layer 3 VPN configuration ma ke sure you have configu red

1. Configure LOP

2. Configure an IGP, either OSPF or IS-IS

3. Configure a Layer 3 VPN

4. Configure multiprotocol BGP for either an 1Pv4 VPN or an 1Pv6 VPN

5. Enable BGP PIC Edge:

[ edit r o ut i ng- instances routing-instance-name r o ut i ng-opt i o n s ]

user@PE l # set protect core

6. Configure per-packet load balancing:

[ edit policy-op t ion s ]

user@PEl# set policy-statement policy-name then load-balance per-packet

7. Apply the per-packet load balancing policy to all routes exported from the routing tab le to t he fo rwarding tab le

[ edit r o ut i ng-opt i ons f orwardi ng-tab l e ]

user@PEl# set export policy- statemen t - name

www.juniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 39

Junos Layer 3 VPNs

BGP PIC Edge Verification (1 of 2)

user@PEl> show route extensive table custornerl . inet.O 172 . 16.1/24
customerl . inet . O: 7 destinations , 12 routes (7 active, 0 holddown , 0 hidden)
172 . 16.1 . 0/24 (3 entries, 2 announced)
State : <CalcForwarding>
TSI :
KRT in-kernel 172 . 16.1 . 0/24 -> f indirect(262146) , indirect(262142 j l

Path 172 . 16 . l . O from 192 . 168 . 0 . 6 Vector len 4 . Val : 0

@BGP Preference : 170/-101

Indirect next hop : Ox96bc104 j262146 jINH Session ID : Ox280006

State : <Secondary Active Int Ext ProtectionPath ProtectionCand>

BGP Preference : 170/-101

Indirect next hop : Ox96bcOOO j 262142 j INH Session ID : Ox280005

State : <Secondary NotBest Int Ext ProtectionPath ProtectionCand>
Inactive rea3on : Not Be3t in it3 group - Router ID

#Multipath Preference : 255

Next hop type : Indirect

Protocol next hop : 192 . 168 . 0 . 6

Label operation : Push 299824
Label TTL action : prop-ttl
Load balance label : Label 299824 : None ;
Indirect next hop : Ox96bcl04 262146 INH Session ID : Ox280006j weig ht Oxl j
Protocol next hop : 192 . 168 . 0 . 7
Label operation : Pu3h 299856
Label TTL action : prop-ttl
Load ba l ance l abel : Label 299856 : None ;
Indirect next hop : Ox96bc000 262142 INH Session ID : Ox280005 i Weiaht Ox4000 1

C2020 Juniper Networks, Inc.All Rights ReseM!<I. Jun1Per

.iETWOffKS
40

Verification of Protection
BGP routing information displays load balancing availability to the destination via both PE2 and PE3.

The Indirect next hop output lines that contain weight follow next hops that the software can use to repair paths where a link
failure occurs.

The next-hop weight has one of the following values:

• Oxl : indicates active next hops

• Ox4 oo o: indicates pas.sive next hops

Chapter 6-40 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

BGP PIC Edge Verification (2 of 2)

user@PEl> show route forwarding- table table customerl destination 1 72.16.1.0/24
Routing table : custornerl . inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
172 .16 . 1 . 0/24 user 0 ulst 262147 2
indr 262146 3
10 . 0 . 0 . 5 Push 299824, Push 299856 ( top) 990 2 ge- 1/2/1 . 0
indr 262144 3
10 . 0.0 . 5 Push 300080, Push 299920(top) 1000 2 ge-1/2/1.0

user@PEl> show ospf route detail

betsy@tpO:PEl> show ospf route detail
Topology default Route Table:

Prefix Path Route NH Metric NextHop Nexthop

Type Type Type Interface Address/LSP

192 . 168 . 0 . 3/32 Intra Network IP 1 ge-1/2/1.0 10 . 0.0 . 5

area 0 . 0 . 0 . 0 , origin 192 . 168 . 0 . 3, priority medium
192 . 168 . 0 . 6/32 Intra Network IP 2 ge- 1/2/1 . 0 10 . 0 . 0 . 5
area 0.0.0 . 0, origin 192.168 . 0 . 6, priority medium
I
session- id : 262144!J version : 1
192 . 168 . 0 . 7/32 Intra Network IP 2 ge-1/2/1 . 0 10 . 0 . 0 . 5
area 0.0.0 . 0, origin 192.168 . 0.7, priority medium
I
session- id : 2621450I, version : 1

C> 2020 Juniper Networks, Inc All Rights Reserved 41

Checking the Forwarding and Routing Tables

The forwarding table shows the u li st i n de x (26 2 147) used by the Packet Forwarding Engine.
The OSPF route output shows the tracked session IDs for the loopback interface addresses on Devices PE2 and PE3.

www .juniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 41

Junos Layer 3 VPNs

Agenda: Layer 3 VPNs-Advanced Topics

• Exchanging Routes Between VRF Tables

■ Hub-and-Spoke Topologies

• Layer 3 VPN Cos Options

• Layer 3 VPN and GRE Tunneling Integration
■ Layer 3 VPN and IPsec Integration
■ BGP PIC Edge for MPLS Layer 3 VPN
➔ Provider Edge Link Protection
■ Seamless MPLS

C> 2020 Juniper Networks, Inc All Rights Reserved Jun1Per

N (T\\()kl(S
42

Provider Edge Link Protection

The slide highlights the topic we discuss next.

Chapter 6-42 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Provider Edge Link Protection (1 of 2)

■ Provider Edge Link Protection

• Support starting in Junos OS Release 12.3
• A precomputed protection (backup) path for a dual homed CE router
configured in a backup PE router
[edit routing-instances instance-name protocols bgp fami ly]
user@routerf set family [inet unicast I inet6 unicast] protection

• Indicates that protection is required on prefixes received from a particular

neighbor or family
• Protection entries are added to prefixes or next hops received from the given
peer
• Protection path cannot be used as the best path
• Configured only for external peers

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Provider Edge Link Protection

A precomputed protection path can be configured in a Layer 3 VPN such that if a link between a CE router and a PE router
goes down, the protection path (also known as the backup path) between the CE router and an alternate PE router can be
used . The protection path can be configured on a PE router in a Layer 3 VPN by configuring the protection statement at the
[edit r outi ng-i n stan ces i ns t a n ce- n ame protoco l s b gp f amil y i ne t un icas t] or [e dit
r o u t i ng-i n stan ces ins t a n ce- name p r otocol s bgp f a mi ly i ne t 6 u n i cas t ] hierarchy level. The
protection statement indicates that protection is required on prefixes received from a particular neighbor or family. After
protection is enabled for a given family, group, or neighbor, protection entries are added for prefixes or next hops received
from the respective peer.

A protection path can be selected only if the best path has already been installed by BGP in the forward ing table. This is
because a protection path cannot be used as the best path. There are two conditions under which the protection path wi ll
not work :

• When configured for an interna l BGP peer; and

• When configured with external and internal BG P multipath.

Provider edge link protection is configured only for external peers.

Note: The option v rf-table-label must be configured under the [ r outi ng-i n stan ces instan ce-name ]
hierarchy for the routers that have protected PE-CE links. This applies to Ju nos OS Releases 12.3 through 13.2 inclusive.

www .juniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 43

Junos Layer 3 VPNs

Provider Edge Link Protection (2 of 2)

■ Example topology
• Routes through PE2 are protected
• PE3 provides protection for inet unicast routes

loO 1.1.1.3
loO 1.1.1.1 . Protected PE
- 1 Primary Data Path PE2 ,,cc2
~ _ ~')1~ -- ~ ~910.11'.24/30 .3,0 ~
~ r 0 _,) -~ ~ 'i!rge-1/2/3 ,
.... _. -.. .14 '\ _.. ----......... 2~
~~ - - - - - - - ~ .-9Je- ~1017- 7-Atl'~o · Stt---
'ilr ~ / 109e-112io11 ~ 9Je~ ,o-'·'· AS 464498
PEL P . · -16130 - ~.25
loO t::lJ. .2 loO 1.1.1.5 -1~
,_ _ _ _,_✓ --PE3
Protector PE
loO 192.168.0.6

C 2020 Juniper Networks. Inc .All Rights ReseM!<I.

Example Topology
This example shows the customer edge CE2 router being dua l homed to PE2, and PE3 routers. Device P is a provider core
router. Only Device PE3 has the Provider Edge Link Protection configured.

Chapter 6 - 44 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Provider Edge Link Configuration

user@PE2i show policy-options
pol icy-statement lb {
then {
load-balance per- packet

user@PE2i show routing- instances

customerl {
instance-type vrf ;
interface ge- 1/2/0 . 0;
route - distinguisher 100 : 1;
vrf- target target : 100 : 1 ;
routing-options {
protect core ;
)
protocols {
bgp {
group ebgp {
type external ;
peer-as 64498 ;
neiahbor 10 . 1 . 1.26;
family inet {
unicast {
orotection ;
)
)
)

user@PE2i show routing- options

router-id 1.1.1.4;
autonomous- system 64497 ;
forwarding- table {
export l b ;
}

C2020 Juniper Networks, Inc . All Rights Resenie<I.

PE2 Router Configuration

The protection statement ind icates that protection is required on prefixes received from a particular neighbor or family. After
protection is enabled for a given family, group, or neighbor, protection entries are added for prefixes or next hops received
from the respective peer.

To minimize packet loss when the protected path is down, also use the per-prefix-label statement at the [ edi t
r o u t i ng-i n stan ces instance-name pro t ocols bgp f amil y inet labe l e d - u nicast ] hierarchy level.
Configure this statement on every PE router within the AS containing the protected path.

www .juniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 45

Junos Layer 3 VPNs

Provider Edge Link Verification

user@PE3> show route 1.1.1 . 6
customerl . inet . O: 9 destinations , 1 4 routes (9 active , 0 holddown, 0 hidden)
@=Routing Use Only, ff= Forwarding Use Only
+=Active Route, - = Last Active , •=Both

1 . 1 . 1 . 6/32 @[BGP/170] 02 : 55 : 36, localpref 100

AS path : 64498 I, validation- atate : unverified
> to 10 . 1 . 1 . 26 via ge-2/0/2 . 0
[BGP/170] 00 : 10 : 13, localpref 100, from 1 . 1 . 1 . 3
AS path : 64498 I , validation-state : unverified
> to 10 . 1 . 1 . 17 via ae-2/0/1 . 0 . Push 299840 . Push 299776/ton1
#[Multipath/255) 00 : 10 : 13
> to 10 . 1 . 1 . 26 via ge-2/0/2 .0
to 10 . 1 . 1 . 17 via ge-2/0/1.0, Push 299840, Push 299776(top)

user@PE3> show route 1.1.1.6 extensive

#Multipath Preference : 255

Next hop type : List , Next hop index : 1048585
Address : Ox944c154
Next-hop reference count : 2
Next hop : ELNH Address Ox9240a74 l weight Oxl , sel ectectl
equal-external- internal- type external
Next hop type : Router, Next hop index : 994
Address : Ox9240a74
Next-hop reference count : 5
Next hop : 10 . 1 . 1 . 26 via ge-2/0/2 . 0
Next hop : ELNH Address Ox92413a8 Pjw ""e""1'""
9fi""'t,...,.
b""
x 4"6"'
6""
6j
equal - external- internal- type internal
Next hop type : Indirect
Address : Ox92413a8
Next-hop reference count : 6
Protocol next hop : 1 . 1 . 1.3
Push 299840

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Verification of the Protection

The show r o ute 1.1.1. 6 output confirms that a route on rout er CE2 is advertised to router PE3, directly and th rough
router PE2 . If the route is advertised correctly, you will see mu lt iple paths for the route. The output verifies t he presence of
multiple paths from router PE3 to the destination rout e, 1 .1.1.6, on router CE2 . The fi rst path is directly through t he PE3-CE2
link (10.1 .1 .26). The second path is through the provider core and PE2 (10.1.1.17).

The sho w r o ute 1. 1. 1. 6 extensive output verifies that the protection path is correctly co nfigured by confirm ing that
the weight for the active path being protected is Ox1 (lower), and the we ight for the protection ca ndidate path is Ox4000
(greater).

Chapter 6-46 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Agenda: Layer 3 VPNs-Advanced Topics

■ Exchanging Routes Between VRF Tables

■ Hub-and-Spoke Topologies
■ Layer 3 VPN CoS Options
■ Layer 3 VPN and GRE Tunneling Integration
■ Layer 3 VPN and IPsec Integration

■ BGP PIC Edge for MPLS Layer 3 VPN

■ Provider Edge Link Protection
➔ Seamless MPLS

C2020 Juniper Networks, Inc .All Rights Resenie<J. Jun1Per

~ETWORKS
47

Seamless MPLS
The slide highlights the topic we discuss next.

www .j uniper.net Layer 3 VPNs- Adva nced Topics • Chapter 6 - 47

Junos Layer 3 VPNs

Seamless MPLS
I, ---------------------------------------------------------------------------------------,'
I
I
I
I
I
I

00 00 00
I

''
I
I
I
Metro-1 Region WAN Backbone Region Metro-2 Region I

.. ______ I

------- ,
., I

■ Seamless MPLS network

• Also known as Unified MPLS
• All user data is forwarded using MPLS from entry to exit from network
• No MPLS boundaries exist
• Network can be divided into regions
• Each region is an independent manageable entity
• Helps scale when there are 1Os of thousands of nodes
(IGPs generally do not scale at that level)
C2020 Juniper Networks, Inc . All Rights Resenie<I.

Seamless MPLS
A seam less MPLS network is one in which all forwarding packets within the network, from the time a packet enters the
network until it leaves t he network, are based on MPLS. Seamless MPLS introd uces a systematic way of enabling MPLS
end-to-end across all segments- access, pre-aggregation, aggregation, and co re. In a seamless MPLS network, t here are
effectively no boundaries, which allows very flexible models of service delivery and decoupling of network and service
architectures, which in turn can present a scaling cha llenge.

RSVP and LDP rely heavily on IGP, which can create prob lems in large networks. In systems with many d istribution systems,
the leaking of routes can lead to problems scaling.

Several different types of nodes appear in an MPLS network, each with a different function . A physical device can combine
several of t hese functions. Conve rsely, a single function can require multiple physical devices for its execution.

• Service node (SN)- Nodes that apply services to customer packets. Examples include Layer 2 PE routers, Layer
3 PE routers, and SONET Clock Generators (SCGs).

• Transport node (TN)- Nodes that connect access nodes to service nodes, and service nodes to service nodes.
Ideally, transport nodes do not have a customer-specific or service-specific configuration .

• Border node (BN)- Nodes that enable inter-region packet transport (s imilar to area border routers and
autonomous system [AS] boundary routers).

• Service helper (SH)- Nodes that enable or scale the service control plane. Service helpers do not forward
custome r data. Examples include service route reflecto rs.

• Access Node (AN)- Nodes where t raffic enters into t he MPLS Network. For example PE, DSLAM or Cell-Site
Router.

• End Node (EN)- Node at the customer site; the CE device.

Chapter 6 - 48 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Inter-Region Network Example

Inter-Region and Inter-AS Service Plane

Inter-Region Transport LSP Inter-Region Transport LSP Inter-Region Transport LSP

Local IGP Local IGP Local IGP

Local Transport LSP Local Transport LSP Local Transnort LSP

P2 ASBR3 ASBR4 P3 PE2

~G
· ~
::J ~ ,-...i- -1-1.::J
:-lG,--' 0
Edge Region 2
Edge Region 1 Transport Region
ASx ASy ASz

■ Multi-region network with numerous autonomous systems

• Segments the end-to-end connectivity problem into inter-region and intra-
region connectivity allowing the network to scale
• Independent IGPs
• Multiple BGP ASs with ASBRs connecting the regions
• LOP or RSVP signaled local transport LSPs

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Inter-Region Network Example

A region is an independent, manageable entity. Large, global networks can have as many as 200 to 300 regions. Regions are
an important concept in seam less MPLS because they address many of the cha llenges inherent in large routed networks.
The primary challenge is that Internal Gateway Protocol (IGP) and Resou rce Reservation Protocol (RSVP) with Labe l
Distribution Protocol (LOP) do not scale well in a Mobile Backhaul Network that consists of one flat IGP region with tens of
thousands of nodes. In such a flat network, there are too many nodes, too many peering sessions, too many routes, and too
many transit LSPs, wh ich all slow down the convergence time. By dividing the network into regions, service providers can
increase the scale of the ir networks and improve convergence times .

www .juniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 49

Junos Layer 3 VPNs

lnterdomain LSP Signaling

■ RSVP and LOP are not used to signal LSPs between regions (ASBR
to ASBR)
• BGP labeled unicast routes are used to advertise the loopbacks from other
regions between PEs and ASBRs
• Each labeled unicast route is associated with an MPLS label
• Essentially stitches together the LSPs between regions at the ASBRs by adding another
level of MPLS labeling (end-to-end)

AS2
AS 1
VRF VRF

LSP

C2020 Juniper Networks, Inc .All Rights ReseM!<I. Jun1Per

.iETWORKS
50

lnterdomain LSP Signaling

After you have defined the regions and roles for each router, the regions need a way to create end-to-end connectivity and enable
inter-region commun ication. Because regions are not configured to sha re IGP routing information, an additional protocol is
introduced, Border Gateway Protocol (BGP) Labe led Unicast, to hand le interdomain LSP signaling so that PE routers can reach
remote PE routers in other regions.

Chapter 6-50 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Roles and Label Mapping

Seamless MPLS Roles

■ Push El nm IGP/ LOP Label ■

l
Outer
Pop Push Swap

~
:1--te: Push
Ill
ei=,:a :~go:
~
II Ill
320. Swap :fff}:
ID
11 Swap
mPop m BGP-LU Label

Inner
Service Label ■
LOP LSP • LOP LSP • LOP LSP • L3VPN Label
Advertisment
- - ►
BGP LSP

■ No IGP route is propagated from the Aggregation to the Core

C> 2020 Juniper Networks, Inc All Rights Reserved

Roles and Label Mapping

The seamless MPLS architecture must scale to support end to-end MPLS in a network on the order of 100,000 nodes. We
build upon the merits of existing control plane functionality and deliver a sca lable and operationally intelligent network. The
key to scaling is to create hierarchical end-to-end LSPs by distributing the right amount of routing intelligence with BGP
Labeled Unicast (BGP-LU).

• No IGP route is propagated from the aggregation layer to the core. IGP area has routes for that area only plus
routes to the core ASBRs. Only the core ASBRs are propagated from ISIS L2 to Li.

• LOP labels are used to traverse within each domain and reach the core ASBRs.

• BGP labels are used by Labeled BGP PEs & ASBRs to reach Labeled BGP PEs in remote areas.

• Service labels, such as PseudoWire, are used by Label BGP PEs.

The slide provides an example of how the L3 VPN prefix and label exchange operates and how the MPLS label stack is
created to have the end-to-end path information for the traffic flow between both PEs.

The network example is partitioned as three independent IGP/ LOP domains. The reduced s ize of routing and forwarding
tables on the routers enables better stability and faster convergence. LOP is used to bui ld intradomain LSPs within each
doma in. BGP LU labels are used as interdomain label d istribution protocol in order to build hierarchical BGP LSPs across
doma ins. BGP LU inserts one extra label in the forwarding label stack in the Seamless MPLS architecture.

Continued on the next page.

www.juniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 51

Junos Layer 3 VPNs

Roles and Label Mapping (contd.)

VPN Prefix is advertised by PE2 to PE1 with L3VPN service label 12 and next hop as PE2's loopback through an end-to-end
interdomain hierarch ica l BGP LSP. Now, let's look at the forwarding path for VPN traffic from PE1 to PE2.

• On PE1, service label 12 is known via BGP session with PE2 as next-hop PE2 and PE2 is recursively reachab le
via ASBR10 with BGP label 110. PE1 received 1Pv4 + Label information from ASBR10 as BGP updates because
it is enabled with the BGP LU feature in order to send the 1Pv4 + Label information.

• P1 is reachable from PE1 through an intradomain LDP LSP and it adds another LDP label on top of the BGP
label. Finally, the packet goes out of the PE1 node with three labels. For example, the 12 L3VPN service label,
the 100 BGP label, and the 210 LDP IGP label.

• The LDP top label continues to swap in intradomain LDP LSP and the packet reaches ASBR10 with two labels
after penultimate hop popping.

• ASBR10 is configured as inline Route Reflector (RR ) with next-hop self and it joins two IGP domains or LDP LSP.

• On ASBRIO, the next hop for PE2 is changed to ASBR20 and the update is received via BGP LU. The BGP label is
swapped with new label because next-hop is changed and the IGP label is pushed on top.

• The packet goes out of the ASBR10 node with three labels and service label 12 is untouched. That is, the 12
L3VPN service label, 120 BGP label, and 300 LDP label.

• The LDP top label swaps in intradomain LDP LSP and the packet reaches ASBR20 with two labels after
penultimate hop popping.

• On ASBR20, the next hop for PE2 is changed again and it is reachable via IGP. The BGP label is removed as an
implicit-null BGP label is received from PE2 for penultimate hop popping.

• The packet leaves with two labels. For example, the 12 L3VPN service label and the 400 LDP label.

• On PE2, the packet arrives with one label after PHP of the LDP label and based on the service label 12. The
unlabeled packet is forwarded to the CE2 destination under Virtua l Routing and Forwarding (VRF).

Chapter 6-52 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Summary

■ In this content, we:

• Described how the auto-export command and RIB groups can be used to
support communications between sites attached to a common PE router
• Explained the flow of control and data traffic in a hub-and-spoke topology
• Described the various Layer 3 VPN CoS mechanisms supported by the Ju nos
OS
• Described support for GRE and IPsec tunnels in Layer 3 VPNs
• Described support for various types of egress protection
• Discussed Seamless MPLS fundamentals

iS> 2020 Juniper Networks, Inc All Rights Reserved Jun1Per

NETWOAAS
s3

We Discussed:
• How the auto-export command and routing table groups can be used to support communications between sites
attached to a common provider edge (PE) router;

• The flow of control and data traffic in a hub-and-spoke topology;

• The various Layer 3 virtua l private network (VPN) class of service (CoS) mechanisms supported by the Ju nos
operating system;

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

• Ju nos OS support for different types of egress protection .

• Seamless MPLS Fundamentals

www .j uniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 53

Junos Layer 3 VPNs

Review Questions

1. How can you use RIB groups to support communications between

sites attached to a common PE router?
2. What is the control plane flow for a hub-and-spoke topology?
3. What are various Layer 3 VPN Cos mechanisms supported by
Junos OS?
4. What support exists for GRE and IPsec tunnels in Layer 3 VPNs?

iQ 2020 Juniper Networks. Inc All Rights Reserved Jun1Per

NfTW0kKS
s4

Review Questions
1.

2.

3.

4.

Chapter 6 - 54 • Layer 3 VPNs- Advanced Topics www.juniper.net

 Junos Layer 3 VPNs

Lab: GRE Tunnels and Route Redistribution

■ Configure GRE tunnel interface.

■ Place GRE interface route in inet.3.
■ Verify L3VPN connectivity between sites.

C> 2020 Juniper Networks, Inc All Rights Reserved Jun1Per

NET\\()kl(S
55

Lab: GRE Tunnels and Route Redistribution

The slide provides the objectives for th is lab.

www .j uniper.net Layer 3 VPNs- Advanced Topics • Chapter 6 - 55

Junos Layer 3 VPNs

Answers to Review Questions

1.
To place routes from one routing table into a second routing table, you must first create a routing table-group that lists both
routi ng tables as an import routing tab le with the primary table listed first. Once the routing table-group is specified, you
need to specify which routes will go into the routing table-group. A common set of routes to place in the routing table-group
would be interface routes which can be applied to the routing table-group under [ edit rou t ing-op t i ons
i nte rf ace- r o ut es J level of the hierarchy. Apply the routing table-group at this level of the hierarchy will take the local
and direct routes found in the primary table (the first tab le in the list) and ensure they exist in both tables. For routes learned
by routing protocols, t hese routes can be applied to the routing table-group at the [ edit p r otoco l s p r otocol - name J
level of the hierarchy.

2.
Routes from Spoke PEs and CEs are received by and accepted by the Spoke instance on the Hub PE. The HUB PE pas.s es
those route to the HUB CE. The HUB CE then advertises those routes to the Hub instance on the Hub PE. The Hub PE then
advertises those routes to the Spoke sites.

3.
The Ju nos OS supports f irewall filtering and rate limiting. It also support the setting of the experimental bits on both the inner
and outer headers of an MPLS packet.

4.
GRE and IPsec tunnels are support from CE to CE, PE to PE, and CE to PE using the Junos OS.

Chapter 6-56 • Layer 3 VPNs- Advanced Topics www.juniper.net

 un1Pe[
NETWORKS
Education Services

Junos Layer 3 VPNs

Chapter 7: lnterprovider VPNs

Engineering Simplicity
Junos Layer 3 VPNs

Objectives

■ After successfully completing this content, you will be able to:

• Describe Junos support for carrier-of-carriers
• Describe Junos support for interprovider VPN applications
• Configure Layer 3 VPNs for interprovider Option C

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

We Will Discuss:
• Ju nos operating system support for carrier of carriers;

• Ju nos support fo r interprovider virtual private networks (VPNs); and

• Configuring Layer 3 VPNs for interprovider Option C.

Chapter 7-2 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

Agenda:
lnterprovider Backbones for Layer 3 VPNs
➔ Hierarchical VPN Models
■ Junos Support of Carrier-of-Carriers Model
■ Junos Support of Carrier-of-Carriers VPN Applications
■ lnterprovider VPN Option C

C/2020 Jun,perNetworl<s, Inc .All Rights Resenie<I. Jun1Per

.iETWOffKS
3

Hierarchical VPN Models

The slide lists the top ics we will discuss. We will discuss the highlighted topic first.

www .juniper.net lnterprovider VPNs • Chapter 7-3

Junos Layer 3 VPNs

Hierarchical VPN Models

■ Carrier-of-carriers model
Customer Customer External
External Site 1 Site 2 Routes
Routes Provider A
C. 0-0~~~,~,-,,,~,~i----L.0,-1
-~ SBR CE LSP CE AS R

Global Addressing Global Addressing

■ lnterprovider VPN model

Provider 1 Provider 2 Customer
Customer
Site 1 Site 2

...__'- !1-C-1--Al~Si;:,BR1-~--------------I-A~
, --P-E,
, 2

LSP [S~

Private Addressing Private Addressing

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Carrier-of-Carriers Model
This model allows service provider A to offer a backbone service to the customer, another service provider. Assume the
customer is a new service provider that has a point of presence (POP) in a few sparse locations with no backbone network to
interconnect those POPs. The customer (the new service provider) can purchase the carrier-of-carriers service f rom the
service provider A to interconnect its sites ma king the custome r network appear as a single autonomous system (AS) without
service provider A having to carry the external routes learned by the customer. The details of this model are discussed in the
subsequent slides.

lnterprovider VPN
This model allows for a Layer 3 VPN, BG P Layer 2 VPN, or a BGP virtua l private LAN service (VPLS) to extend between
autonomous system or service providers.

Chapter 7 - 4 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

Carrier-of-Carriers VPN Support

■ Carrier-of-carriers and VPN integration

External External
Customer Customer VPN
VPN Site 1 Site 2
Routes Routes
Provider

c. e-,~ ~~~r-~~----r ~--~~

PE-C1 CE-1 CE-2 PE-C2
(ASBR LSP (ASBR)
LSP LSP
Private Private
Addressing Addressing

C2020 Jun,perNetworl<s, Inc .All Rights ReseM!<I.

Carrier-of-Carriers VPN
Th is model is a combination of the two models d iscussed on the previous slide. In th is model, the customers of service
provider A will be providing VPN service to its own customers. The details of this model are described in subsequent slides.

www .j uniper.net lnterprovider VPNs • Chapter 7-5

Ju nos Layer 3 VPNs

lnterprovider VPNs: Option A

■ Option A describes EBGP VRF table to VRF table operation between

ASBRs
• Serious scalability issues
• Separate VRF table required for each VPN
• Provider PE router must house all customer VPN routes
• Inherently supported by the Junos OS
VPN B Unlabeled VPN routes VPN B
Site 1 Site 2

VPNA SP 1 SP 2 VPNA
Site 1 Site 2

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Option A
RFC 4364 describes three methods of providing mult iple AS backbones. Option A is the least scalable of t he options. This
option requ ires that t he autonomous system boundary routers (ASBRs) maintain separate VPN routing and forwarding tables
(VRFs) and store all of the associated routes for every one of its customers. Although th is option is supported by the Ju nos
OS, it is not a recommended solution.

Chapter 7-6 • lnterprovider VPNs www.j uniper.net

 Junos Layer 3 VPNs

lnterprovider VPNs: Option B

■ Option B describes MP-EBGP-labeled route distribution between
ASBRs
• Better than Option A as ASBRs do not need per-VPN VRF tables
• Still has scalability issues
• Requires that ASBRs carry VPN routes and state for transit MPLS sessions

Labeled VPN Routes

VPN B VPN B
MP-IBGP Site 2
Site 1

ASBR-2q6
P-1 P-2 PE-2
•
•• • .....-..... • ••
EBGP •

MP-EBGP
VPNA
SP 1 SP 2 VPN A
Site 1 Site 2

C2020 Juniper Networks, Inc . All Rights ReseM!<I.

Option B
With option B, the ASBRs do not need to maintain separate VRF instances for each VPN. However, the ASBR wi ll still have to
keep VPN routes in a single routing table, bgp.13vpn.O for L3VPN routes. Through an EBGP session between one another, the
ASBRs wi ll then exchange VPN routes as label routes. The EBGP advertised labels are used to stitch together the
label-switched paths (LSPs) that term inate between provider edge (PE) and ASBR .

www .j uniper.net lnterprovider VPNs • Chapter 7-7

Junos Layer 3 VPNs

lnterprovider VPNs: Option C

■ Option C describes MP-EBGP-labeled route distribution between
source and destination ASs
• ASBRs now only carry internal routes
• Requires labeled- un i cast family on ASBR-ASBR MP-EBGP sessions
• External prefixes are exchanged through 1/EBGP sessions between provider
PE routers
• EBGP requires multihop

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Option C
Th is option is generally accepted as the most scalable solution for interprovider VPNs. Th is option allows the PE routers in
different autonomous systems to exchange VPN routes (Layer 3 VPN, BGP Layer 2 VPN, or BGP VPLS) using a multi hop BGP
session. The ASBRs do not need to store any VPN routes in this case. Instead, the ASBRs will exchange the internal networks
of each service provider (most importantly the loopback addresses of the PEs) using labeled IP version 4 (1Pv4) routes. The
labels associated with the internal networks will be used to stitch together the MPLS LSPs that exist between PE and ASBR in
the service provider networks.

Chapter 7-8 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

Agenda:
lnterprovider Backbones for Layer 3 VPNs
• Hierarchical VPN Models
➔ Junos Support of Carrier-of-Carriers Model
• Junos Support of Carrier-of-Carriers VPN Applications
• lnterprovider Option C

C2020 Juniper Networks, Inc . All Rights ReseM!<I. Jun1Per

~ETWOffKS
9

Junos Support of Carrier-of-Carriers Model

This slide high lights the topic we discuss next.

www .juniper.net lnterprovider VPNs • Chapter 7-9

Junos Layer 3 VPNs

Carrier-of-Carriers: Operation
■ Service provider routers:
• P routers maintain only provider internal routes
• PE routers maintain provider internal and customer internal routes
• PE routers do not carry customer external routes
■ Customer routers:
• CE routers maintain internal routes and external routes learned from their
customers
• ASBRs interface to downstream subscribers to exchange internal routes
(subscriber internal = customer external)
Customer Customer External
External Site 1 Site 2 Routes
Routes Provider
CI)
LSP

C/2020 Juniper Networks, Inc .All Rights Resenie<I. Jun1Per

.iETWORKS
10

Service Provider Routers

The service provider's P routers on ly maintain routes internal to the provider's network. The PE routers maintain both
provider interna l routes and customer interna l routes. Customer-specific VRF tables on the PE routers house the customer's
internal routes. These routes normally consist of at least the customer's / 32 loopback addresses. The provider's PE routers
do not carry the customer's external routes, which is critica l to the overall scalability of th is model.

Customer Routers
The customer's routers must maintain both customer internal and external routes. The customer's external routes are those
learned from the customer's downstream subscribers.

Chapter 7-10 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

Carrier-of-Carriers: Signaling
■ Provider network requires LSP signaling
■ MP-BGP signaling between CE and PE routers
• Uses labeled- unicast address family
■ IBGP/EBGP signaling between ASBRs
• Full mesh (except CE routers) for IBGP, multihop for EBGP
• Route reflection possible to improve scalability
• BGP sessions between ASBRs are tunneled over LSP in provider' s backbone
:- • E~ G·P~~lt; o·p - • 1 · - · - · - MP~BGP • - • - • - • - • - • - • - • - • ~ \
~ s ession::____; Site 2 Internal Route Label 101 1 External
External I Servic~ 3 • Route x
Route . ~ 4- Provider ~ . I To Site 1
I Customer Site 1 Customer Site 2 . (EBGP)
X AS=64512 --. I 6
External
8 Route x

C - 4
MP-EBGP ~ 30 LSP MP-EBGP
5
IBGP Site 2 Internal Site 2 Internal
Site 2 Internal Rou te Label 300 Route Label 200

C/2020 Juniper Networks, Inc .All R,ghlS Resenie<I. Jun1Per

~ETWORKS
11

LSP Signaling Needed in Service Provider Network

Because the provider's network uses MPLS forwarding, an LSP must be established between provider PE routers. This LSP
can be established with RSVP or LDP s ignaling. In th is example, the LSP is established using RSVP; PE-1 is assigned MPLS
label 30 by the P router.

MP-BGP Signaling Between PE and CE Routers

The customer edge (CE) routers use EBGP with labeled-unicast network layer reachability information (NLRI) to exchange
labeled routes with the provider's PE routers. The use of labeled routes allows the provider to extend its LSPs to the customer
CE router, which thereby eliminates the need to carry customer internal routes in its P routers. While the customer's network
does not require MPLS signaling, the CE router must support the family MPLS on its PE-facing interface, because it must
send labeled packets.

IBGP/EBGP Signaling Between Customer ASBRs

Once the customer's internal routes are exchanged across the provider's backbone, the ASBRs can establish internal BGP
(IBGP) (same AS numbers) sessions or multi hop EBGP (different AS numbers) sessions through the provider's backbone for
the purposes of exchanging externa l routes. A full lBGP mesh is needed between routers at the customer sites when using
IBGP, except for the CE routers, which peer indirectly using the provider's backbone. Because this example demonstrates the
use of EBGP, on ly the peering session between ASBR-2 and CE-1 is needed. The second BGP session between the two
ASBRs (shown as a dotted line) is only required for IBGP peering when the customer sites share the same AS number.

Continued on the next page.

www .juniper.net lnterprovider VPNs • Chapter 7 - 11

Junos Layer 3 VPNs

Signaling: Step by Step

The details of the signaling exchanges shown on the slide are:

1. The IGP at customer Site 2 exchanges interna l reachabi lity with CE-2. ASBR-2 establishes an IBGP neighbor
relationsh ip with CE-2.

2. CE-2 selectively advertises Site 2 's internal routes to the provider's PE-2 router using multi protocol EBGP
(MP-EBGP) with the support of l a b e l ed-u ni cas t routes. These routes are advertised with a valid label,
which is 200 in th is example.

3. PE-2 houses Site 2 's internal routes in a VRF table and uses MP-IBGP to send labeled VPN-1Pv4 routes to PE-1.
The route to ASBR-2 is assigned Label 101 in this example.

4. PE-1 uses MP-EBGP to send Site 2 's internal routes to CE-1. PE-1 changes the BGP next hop. Therefore, it must
assign a new label to the prefix advertised (Label 300 in th is example).

5. After receiving the labeled route, CE-1 distributes Site 2's internal routes to ASBR-1 using IBGP. No labels are
needed, because conventional IP forwarding is used within the customer sites. At this point, the ASBRs can
establ ish an EBGP multihop session through the provider's backbone. This session is tunneled through the LSP
in the provider's network.

6. ASBR-2 learns an external route x from one of its subscribers. IBGP conveys external routes from ASBR-2 to
CE-2. PE-1, PE-2, and P routers never become aware of the external route advertisement x.

7. The external route x is now advertised to ASBR-1 using the EBGP session established at Step 5. No labels are
associated with this route due to the lack of MPLS forwarding in the customer networks.

8. External route xis advertised by ASBR-1 to its downstream subscribers as well as to CE-1.

Chapter 7-12 • lnterprovide r VPNs www.juniper.net

 Junos Layer 3 VPNs

Carrier-of-Carriers: Data Flow

■ Two-level label stack in provider's network

-:- • E-;;G·P~~lt;o·p - • 1 · - · - · - MP-=i°BGP • - • - • - • - • - • - • - • - •~\ ro Site 1
~ session::.._____; Site 2 Internal Route Label 101 1 (EBGP)
I Service • Extern al
• ~ Provider Customer Site 2 ~ Route x
I Customer Site 1
r AS=64512 )
5
•••• ••• ,_....... I
CI) PE, ....... •

1 .
•
: ·
.•
BR 1 .....
- 2
... 0
C -
~•.: -t-- - '
3.. ••··•·• ..
p ..........
6
~

ASBR-
••.. 7 ....-.
• •••••
•
: -..........:.._, MP-EBGP •
\ IBGP Site 2 Internal ••••••• 4 ••••••••..Site 2 Internal IBGP
Route = x
~ Site 2 Internal Route Label 300 •••• • •••• Route Label 200
••
• 30 200
I ID~ X
300
DA=x
10 1
DA=x
101
DA=x
DA=x I DA XI I I DA X

Packet@ ASBR PE-2 swaps CE-2 pops label Packet delivered

CE-1 pushes PE-1 swaps top PHP by VRF label to subscriberx
addressed to x and sends packet
label 300 label and P router and sends to destination
pushes MPLS MPLS label
label 30 200 to CE

C,2020 Jun,perNetworl<S, Inc .All R,ghlS ReseM!<I.

Carrier-of-Carriers Data Forwarding

Th is slide uses step numbers to describe the forward ing operations between ASBR-1 and ASBR-2. The result is the need for
a two-level label stack in the provider's network.

Forwarding: Step by Step

The details of the forwarding operation shown on the slide are:

1. A packet addressed to externa l route x arrives at ASBR-1.

2. ASBR-1 forwards this unlabeled packet towards CE-1 using the IGP's shortest path.

3. CE-1 pushes Label 300 onto the packet and forwards it to PE-1.

4. PE-1 swaps the top label wit h the va lue received from PE-2, and pushes an MPLS label (30 in this example)
onto the stack. The P router pops this top label (PHP) such t hat PE-2 rece ives a packet with a single label.

5. PE-2 swaps the VRF label with the label advertised by CE-2 and forwards t he packet out the VRF interface to
CE-2.

6. CE-2 pops the MPLS label and routes the native packet using Site 2's interior gateway protocol (IGP).

7. ASBR-2 performs a longest-match lookup and routes the packet toward destination x.

www.j uniper.net lnterprovider VPNs • Chapter 7 - 13

Junos Layer 3 VPNs

Carrier-of-Carriers: Example
■ Sample network:
• AS 65512 provides carrier-of-carriers services to its customers in AS 10 and
AS 11
• LSP established between PE routers
• Policy exists on CE routers to advertise /32 loopback addresses to provider
• EBGP with labeled-unicast NLRI between CE and PE routers
• ASBR-1 and ASBR-2 routers establish a multihop EBGP session to advertise
external routes (200.0.0/24)
Provider Core 200.0.0/24
AS 65512
AS 10 OSPF Area 0 Site 2 As 1 1
OSPF Area 0 Site 1 OSPFArea 0

10.0.50.0/24 10.0.20.0/24' 1 72.22.220.0/24 172.22.222.0/24 10.0.21.0/ 24

~ -2 .1~ 2 . 1 ~.1 .2 ~ -2 .1~1...:
·1---;-:-:::-:-::"- ~:93.;.;·1=---~1c:t::
~ ~,E~/g
d... » e--1-/1-/4
- -~ g e-1/0/1 ,~ ~ , ge-1/ 0/4
"..f. - PE-1 P-1 PE-2/
loO 192.168.12.1 loO 192.168.2.1 loO 19 2 .168.2.2 loO 192.168.12.2
loO 192.168.12.3 loO 192.168.12.4

C2020 Jun,perNetworl<s, Inc . All Rights Resenie<I.

Carrier-of-Carriers Sample Network

Th is s lide provides a sample network; the following list provides the details of this network. The fol lowing sl ides show various
configuration-mode and operational-mode screen captures relat ing to t his network.

• Provider network: The provider's network is assigned AS 65512 and has already establ ished an LSP between
PE-1 and PE-2 using RSVP. The PE routers have a VRF table configured, along with the necessary VRF target
community and route distinguishers.

• Policy on CE routers: The CE routers are configured to run MP-EBGP with the PE routers and have a policy in
place to ensure that only internal prefixes are advertised to the PE routers.

• ASBR-1 and ASBR-2 routers exchange external routes: A multihop EBGP session is configured between the
ASBRs because the customer networks are assigned differing AS numbers. ASBR-2 advertises the external
route 200.0.0/ 24 to ASBR-1 using this EBGP session .

Chapter 7-14 • lnterprovider VPNs www.ju n iper .net

 Junos Layer 3 VPNs

Carrier-of-Carriers ASBR-2 Configuration

■ Redistributes external routes to internal and external peers using

multihop EBGP with loopback peering:

user@asbr-2# show protocols bgp user@asbr-2 # show policy-options

export 200 ; policy- statement 200 {
group int { term 10 {
type internal ; from {
local- address 192 . 168 . 12 .4; route- filter 200 . 0 . 0 . 0/24 exact ;
neighbor 192 . 168 . 12 . 2 ; }
} then accept ;
group ext { }
type external ; term 20 {
multihop; then reject;
local-address 192 . 168 . 12 . 4; }
peer- as 10; }
neighbor 192 . 168 . 12 . 3 ;
}

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

ASBR-2 Configuration
This slide lists the key aspects of ASBR-2's configu ration . An IBGP session is configured to CE-2, and a multihop EBGP
session is configu red for ASBR-1 at Site 1 .

The 2 oo po licy in ASBR-2 ensures that only external routes (200.0 .0/ 24 in th is example) are sent to ASBR-1. The default
IBGP po licy causes all external routes ASBR-2 learns through EBGP to be sent to CE-2.

This policy is rather simple and requires changes for each new externa l route. A more scalable solution involves an AS path
regex that blocks all internal routes and only accepts routes whose AS-path attribute does not begin with 11.

www .juniper.net lnterprovider VPNs • Chapter 7 - 15

Junos Layer 3 VPNs

Carrier-of-Carriers CE-2 Configuration

• Redistributes internal /32s to PE-2; family inet labe led-
unicast needed on EBGP peering session
user@ce - 2# show protocols bgp user@ce -2# show policy-options
group int { pol i cy- sta tement i nternal s I
type internal ; term 1 0 {
local - address 1 92 . 168 . 12 . 2 ; from I
e xport nhs ; route- f ilter 192 . 168 . 12 . 2/32 exact ;
nei ghbor 192 . 168 . 12 . 4; route- filter 192 . 168 . 12 . 4/32 exact ;
) }

group e xt I t he n accept ;
type externa l ; )
family i net { term 20 I
labeled- unicast ; t hen reject ;
) )
e xport i nt ernals ; }

peer- as 65512 ; policy- statement nhs {

neighbor 1 0 . 0 . 21 . 1; term 1 0 I
) then {
next-hop sel f;

C/2020 Juniper Networl<s, Inc .All Rights ReseM!<I.

CE-2 Configuration
This slide lists the key aspects of CE-2's configuration. An IBGP session is configured to ASBR-2, and an MP-EBGP session is
configured for communications with PE-2.

The MP-EBGP session has the labe l e d - u n i cast fami ly configured, which is required for the exchange of labeled routes
between CE and PE routers .

CE-2 has an EBGP export policy in place that causes it to only advertise the / 32 routes associated with Site 2 's loopback
addresses. The leaking of other internal routes (that is, OSPF and direct connect) are not strictly required but can aid in
troubleshooting. With this configuration, we must take care to source pings and traceroutes for the loopback add resses of
customer site routers.

Chapter 7-16 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

Carrier-of-Carriers PE-2 Configuration

• PE router's VRF table also supports inet
labeled-unicast family
user@pe - 2# show routing-instances user@pe - 21 show protocols mpls
vpn { label - switched- path pe2 - t o - pel {
instance - type vrf ; to 1 92 . 1 68 . 2 . 1 ;
i nterface ge - 1/0/4 . 0 ; no- cspf ;
route - distinguisher 1 92 . 168 . 2 . 2 : 100 ; }
vrf- target target : 655 12 : 100 ; interface all ;
p rotocols {
bgp {
group vpn {
type external;
family inet {
labeled-unicast ;
}
peer- as 11 ;
neighbor 10 . 0 . 21 . 2 ;
}
}
}
}

C 2020 Juniper Networks, Inc . All Rights Reserlle<I.

PE-2 Configuration
Th is slide lists the key aspects of PE-2's configuration. An MP-EBGP VRF routing instance is configured for communications
with CE-2. Also shown is an LSP that terminates on PE-1.

www .juniper.net lnterprovider VPNs • Chapter 7 -17

Junos Layer 3 VPNs

Carrier-of-Carriers Operation: CE-1 (1 of 2)

■ CE-1 receives labeled routes for Site 2' s internal routes:

user@ce -1> show route receive-protoco1 bgp 10.0.20.1 detai1

i net . O: 11 desti nations , 11 rout es (11 active , 0 holddown , 0 h idden )

* 192 . 168 . 12 . 2/32 (1 e ntry, 1 a nnounced )

Accepted
!Rout e Label : 300 11 2!
Nexthop : 10 . 0 . 20 . 1
AS path : 65512 11 I
Communi t ies : targe t : 65512 : 1 00

* 192 . 1 68 . 12 . 4/32 (1 e ntry , 1 a nnounced )

Accented
Route Label : 300 128
Ne xthop : 10 . 0 . 20 . 1
AS path : 655 12 11 I
Communi t i e s : targe t : 65512 : 1 00

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Carrier-of-Carriers Operation: CE-1

Th is slide shows that CE-1 is receiving the internal routes from Site 2 through its Multiprotocol Border Gateway Protocol
(MP-BGP) session to PE-1. These routes are labeled due to the provisioning of family label ed- un icast on the MP-EBGP
.
session.

Chapter 7-18 • lnterprovide r VPNs www.juniper.net

 Junos Layer 3 VPNs

Carrier-of-Carriers Operation: CE-1 (2 of 2)

■ CE-1 learns Site 2 ' s externals routes from ASBR-1:

u ser@ce - 1 > show route 2 00 . 0 . 0 . 0 detail

inet . 0 : 11 desti nati o n s , 11 routes (11 a cti ve , 0 holddown , 0 hidd en)

200 . 0 . 0 . 0/ 24 ( 1 entry , 1 an nounced )
*BGP Pr efe r e n c e : 170/ - 1 0 1
Ne xt h op t ype : I ndi r e ct
Next - hon reference count : 3
Sour ce : 1 92 . 168 . 1 2 . 3
Ne xt h op t ype : Ro ute r , Ne xt h op i nde x : 765
Ne xt hop : 10 . 0 . 20 . 1 via ge - 1 / 1 / 4 . 0 , selected
Lab e l operat ion : Pus h 300128
Pr o t oco l n e x t hop : 1 92 . 168 . 12 . 4
I ndi rec t n e x t hop : 2 7 964b0 1048577
State : <Active Int Ex t>
Local AS : 1 0 Peer AS : 10
Age : 18 : 0 4 Me t r i c2 : 0
Task : BGP 10 . 1 92 . 1 68 . 12 . 3+611 99
Announcement bits (2 ) : 0 - KRT 4-Resolve tree 1
AS pat h : 11 I
Accepted

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Carrier-of-Carriers Operation: CE-1

Th is slide shows t hat CE-1 learns about the externa l prefix 200.0 .0/ 24 from ASBR-1 th rough its IBGP peeri ng sessio n. Even
though t he rout e is learned f rom ASBR-1, t he next hop is ASBR-2 (192.168.12.4 ). The BGP next hop is associat ed with a
label and push operat ion. Thus, CE-1 rout es packets addressed t o 200.0 .0/ 24 by pushing label 300128 and f orwarding t he
labeled packet t o PE-1 (10.0.20.1) for ultimate delivery to ASBR-2.

www .j uniper.net lnterprovider VPNs • Chapt er 7 - 19

Junos Layer 3 VPNs

Carrier-of-Carriers Operation: PE-1

■ PE-1' s VPN MPLS forwarding table:
• Swap/push operations create two-level label stack in provider core
user@pe - 1> show r oute table vpn. mpls.O detail

vpn . mpls . O: 2 destinations , 2 routes (2 active , 0 holddown , 0 hidden)

300112 (1 entry, 1 announced)
*VPN Preference : 170
Next hop type : Indirect
Next-hop reference count : 2
Source : 192 . 168 . 2 . 2
Next hop type : Router , Next hop index : 776
Next hop : 172 . 22 . 221 . 2 via ge - 1/0/1 . 221 weight Oxl , selected
Label-switched-oath oel-to-oe2
!Label oneration : Swan 299904 , Push 302368(ton) I
Protocol next hop : 192 . 168 . 2 . 2
Swap 299904
Indirect next hop : 28aab40 1048583
State : <Active Int Ext>
Local AS : 65512
Age : 20 : 44 Metric2 : 4
Task : BGP RT Background
Announcement bits (1) : 0-KRT

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Carrier-of-Carriers Operation: PE-1

Th is slide shows a portion of PE-1's vpn. mpl s . O switching table for the VRF instance cal led vpn . When PE-1 receives a
packet with Label 300112, it swaps the top label with Label 299904 and then pushes an RSVP label (Label 302368) onto
the top of the stack.

After PHP, PE-2 receives a packet with Label 299904, which it swaps with the label learned from CE-2 (labeled unicast route)
before forward ing the singly labeled packet to CE-2.

Chapter 7-20 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

Carrier-of-Carriers Operation: ASBR Traceroute

■ Traceroute must be sourced from ASBR-1' s loopback address in this
example:
• If icmp - tunneling is not configured , P router hops are seen as traceroute
timeouts due to preservation of TTL in all MPLS headers
use r@asbr-1> traceroute 200 . 0.0 . 2 source 192.168 . 12.3
traceroute to 200 . 0 . 0 . 2 (200 . 0 . 0 . 2) from 192 . 168 . 12 . 3 , 30 hops max , 40 byte
packets
1 10 . 0 . 50 . 1 (10 . 0 . 50 . 1) 0 . 3 8 9 ms 0 . 302 ms 0 . 281 ms
2 10 . 0 . 20 . 1 (10 . 0 . 20 . 1) 0 . 402 ms 0 . 381 ms 0 . 365 ms
MPLS Lab e l = 300144 Co S= O TTL=l S= l
3 * * *
4 * * *
5 1 0 . 0 . 2 1 . 2 (10 . 0 . 21 . 2) 0 . 593 ms 0 . 465 ms 0 . 461 ms
MPLS Label=299776 CoS=O TTL=l S=l
6 10 . 0 . 60 . 2 (10 . 0 . 60 . 2) 0 . 409 ms !N 0 . 390 ms ! N 0 . 386 ms ! N

C2020 Juniper Networks, Inc .All Rights ReseM!<I. Jun1Per

.iETWOffKS
21

Carrier-of-Carriers Operation: ASBR Traceroute

This slide shows a successful traceroute from ASBR-1 to the external route 200.0.0/ 24 . Because only the /32 routes
associated with customer loopback addresses are leaked, we must source the traceroute from the loopback address of
ASBR-1.

In th is example, the external route is a static route on ASBR-2, so hops beyond ASBR-2 are not present. Also, because the
provider core routers (main routing instances) do not have routes associated with the customer networks, core router hops
show up as timeouts.

www .juniper.net lnterprovider VPNs • Chapter 7 - 21

Junos Layer 3 VPNs

Agenda:
lnterprovider Backbones for Layer 3 VPNs
■ Hierarchical VPN Models
■ Junos Support of Carrier-of-Carriers Model
➔ Junos Support of Carrier-of-Carriers VPN Applications
■ lnterprovider VPN Option C

C/2020 Juniper Networl<s, Inc .All Rights ReseM!<I. Jun1Per

.iETWOffKS
22

Junos Support of Carrier-of-Carriers VPN Applications

Th is slide high lights the topic we discuss next.

Chapter 7 -22 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

Carrier-of-Carriers VPN Operation (Option C)

Service
Customer Site 1 Customer Site 2
External Provider
External
Routes ASBR ASB
Routes
SBR ASB Cl) CI) CI) Cl) ASB
Cl) Cl) CI, PE-2 p PE-3

C -1 LSP p PE-

LSP
• Service provider routers:
• P routers maintain only P-internal routes
• PE routers maintain P-internal and C-internal routes
• Customer routers:
• CE routers maintain C-internal routes
• PE routers maintain both C-internal and C-external routes (VRF tables house
C-external routes)
• LSPs required between customer PE and CE routers
• ASBRs interconnect with other autonomous systems
• Three-level label stack in provider and customer networks
• MP-1/EBGP needed for labeled route exchange
C/2020 Juniper Networl<s, Inc .All R,ghlS Resenie<I.

Service Provider Routers

The service provider's P routers on ly maintain routes internal to the provider's network (P-routes). The PE routers maintain
both P-routes and customer internal routes (C-routes). The C-routes are housed in customer-specific VRF tables on the PE
routers and normally consist of at least the customer's / 32 loopback addresses. The provider's PE routers do not carry the
customer's external routes (C-externa l), which is a critical aspect of the overall sca lability of this model.

Customer Routers
The customer's routers must maintain both C-internal and C-external routes. External routes are those learned from the
customer's downstream subscribers and are now stored in site-specific VRF tables. Unlike the previous examples, the
support of VPN routes requires that LSPs be established between customer PE and CE routers. These can be established
using either RSVP or LDP. The use of LSP-based forward ing within the customer networks accommodates private/ local use
addressing.

ASBRs
ASBRs can be PE or CE routers and are used to connect with other autonomous systems. ASBRs advertise labeled routes
between autonomous systems and maintain switching tables that allow them to stitch together LSPs existing in adjacent
networks.

Continued on the next page.

www .juniper.net lnterprovider VPNs • Chapter 7- 23

Ju nos Layer 3 VPNs

Three-Level Label Stack Required

The presence of VRF-related labels results in the need to support three levels of label st acking in the provider and customer
networks. In the case of PE-1, the three labels have t he follow ing fu nctions:

1. The bottom label is the VRF label assigned using MP-BGP. This label does not change as the packet is
forwarded .

2. The middle label is assigned by the downstream ASBR (CE-1, in the case of PE-1) and is used by the ASBR to
associate the packet with the LSP leading to the next ASBR in the path.

3. The top label associates t he packet with t he LSP connecting PE-1 to CE-1 and is assigned by RSVP or LDP.

Because an LSP must be established across AS boundaries to interconnect customer PE routers, labels must be
commu nicated along with t he NLRI advertised by ASBRs. Although a protocol such as LDP cou ld be used f or th is purpose,
the Junos OS currently supports MP-BGP for this pu rpose.

RFC 3107, Carrying Label Information in BGP-4, specifies labeled routes. Labeled route advertisements use SAFI 4 and
differ f rom VPN-labe led routes in t hat there is no ro ute distinguisher or route t arget commu nit ies in the advertised NLRI.
Simply put, labeled routes allow the binding of an MPLS label to the advertised 1Pv4 NLRI. ASBRs use the advertised labels
t o build MPLS switch ing t ables t hat result in an end-to-end LSP spanning mu ltiple autonomous networks.

Within an AS, labeled routes are sent using MP-IBGP whi le MP-EBGP is used across AS boundaries.

Chapter 7-24 • lnterprovider VPNs www.j uniper.net

 Junos Layer 3 VPNs

Carrier-of-Carriers VPNs: Signaling

• Provider and customer networks require LSP signaling
• MP-BGP signaling between customer CE and provider PE routers
• Uses labeled-unicast address family
• IBGP/EBGP signaling between customer PE routers
• Full mesh among customer PE routers with common VPNs
• RR improves scalability-no-nexthop-ch ange command
• BGP sessions between customer PE routers are tunneled over LSP in
provider's backbone and use family inet-vpn
-·-
•
· -·- · -·
EBGP Multihop
· - · - · - M·P:isGP · - · - · - · - · - · - · - · - · I ~ 7
I Session _ __,, Site 2 Internal Route Label 1001 • \ To Site 1
• I (MP-EBGP)
Service 3 • External Route x
External I
Route • Provider C t s· 1 Route Label 1004
us omer 1te 2 •
X
I Customer Site 1
AS=64512 I 6
• AS=10
8 LSP e ~ - 4)
p
'-r-- -
2
-~~'----.-r,
~~ )
External
Route x
From
PE-1 CE-1 4 ----.._., -f_E-2 ~ PE-4 ~ Subscriber
LSP
5 MP-EBGP MP-EBGP \ 1
MP-IBG -
Site 2 Internal Site 2 Internal '<'.bs~ IGP Internals
Site 2 Internal Route Label 1020
Route Label 1020 Route Label 1007

C/2020 Juniper Networl<s, Inc .All Rights Resenie<I.

LSP Signaling Needed in Service Provider and Customer Networks

Because MPLS forwarding is now used end to end, LSPs must be signaled in both the cust omer and provider net works. The
LSP s ignaling protocol need not be t he same; t he customer can use LDP wh ile the provider uses RSVP.

MP-BGP Signaling Between Provider PE and Customer CE Routers

As wit h the previous application, t he customer's CE routers use EBGP with l abeled- uni cast NLRI to exchange labeled
routes with the provider's PE routers. The use of labeled routes al lows the provider to extend its LSPs to the customer CE
router and t hereby el iminat e the need to carry customer internal routes in its P rout ers.

IBGP/EBGP Signaling Between Customer ASBRs

Once the custome r's internal routes are exchanged across the provider's backbone, the ASBRs (PE-1 and PE-4) can
est ablish IBGP (same AS numbers) sessions or mu lti hop EBGP (d ifferent AS numbers) sessions th rough the provider's
backbone for the pu rposes of exchanging external routes. In t his case, the routes are exchanged using MP-BGP and are
labeled VPN routes.

To improve sca lability, t he customer net works can use route reflection. The two route reflectors peer using MP-EBGP. A
comma nd called no-nexthop-change is required to tell the route ref lectors to pass- u nchanged- t he third party next
hops to their clients.

Continued on the next page.

www .j uniper.net lnterprovider VPNs • Chapter 7- 25

Junos Layer 3 VPNs

Signaling: Step by Step

The details of the signaling exchanges shown on t he slide are:

1. The IGP at customer Site 2 exchanges internal reachability with CE-2. Externa l (VRF) routes are not sent to PE-3.

2. CE-2 selectively advertises Site 2 's internal routes to the provider's PE-3 router using MP-EBGP with the support
of l abe l ed-u ni cas t routes. The route to PE-4 is sent with a label value used to associate packets with the
LSP to PE-4 in Site 2 (1 020 in th is example).

3. PE-3 houses Site 2 's interna l routes in a VR F table and uses MP-IBGP to send labeled VPN-1 Pv4 routes to PE-2 .
The route to PE-4 is assigned Label 1001 in this example.

4. PE-2 uses M P-EBGP to send Site 2's internal routes to CE-1. Because PE-2 has changed the BGP next hop (as is
always the case with ASBRs), it must assign a new label to the prefix advertised (Label 1007 in this example).

5. After receiving the labeled route, CE-1 distributes Site 2's internal routes to PE-1 using MP-IBGP. Unlike the
carrie r-of-carriers application, this exchange involves labeled-unicast routes, and therefore requ ires MP-IBG P.
Because CE-1 is also an AS BR, it rewrites the BGP next hop and must the refore assign a new label (Label 1020
in this example).

At this point, the ASBRs (PE-1 and PE-4) establ ish an MP-EBGP multihop session through the provider's backbone. This BGP
session is tunne led through the LSP in the provider's network and is used to carry labeled VPN routes. This session should
be contrasted to the carrier-of-carriers application, in wh ich MP-1/ EBGP was not needed due to native IP forward ing within
the customer networks.

6. Here, PE-4 learns an external route x from one of its VPN subscribers.

7. The external route xis now advertised to PE-1 using the MP-EBGP session established at Step 5 . This NLRI
advertisement includes the VR F label that PE-4 expects to rece ive for routes associated with this particular VR F
instance.

8. PE-1 advertises the external route to its downstream VPN subscribers.

Chapter 7 - 26 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

Carrier-of-Carriers VPNs: Data Flow

I • External Route x
• ·t I Route Label 1004
I Customer Site 1 6 Customer S I e 2 •
AS=64512 I
' AS=10

1 ,2L~:,. ~-..~=j~
PE-1'. C
~i'; -,
MP-1 8 · MP-EBGP •
Site 2 Internal ••••• • ••• •·"
MP-EBGP
Site 2 Internal
--Ill!! bS~ --
IGP Intern als
9
Site 2 Internal
Route Label 1007 •• •• • .. ·" •• • Route Label 1020
Route Label 1020
5

I DA X I
1007
1004
1008
1001
1001
1004
1020
1004 1004 1004 I DA X I
DA=x 111114 DA=x DA=x DA=x DA=x Native packet
Packet@ PE1 delivered to
addressed to x CE1 Swaps DA=x PHPby PE3 swaps CE2 pops PE4 pops
subscriber x
top label P router top label top label VRF label
1020 PE2 swaps top
label, and (PHP) 8
1004
2 pushesMPLS
DA=x
label 1008
PE1 pushes
label 1004 and 1020 ■ Requires three-level label stack
(PHP = no top label)

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Carrier-of-Carriers VPN Data Forwarding

Th is slide uses steps to describe the forwarding operations between PE-1 and PE-4 in an interprovider VPN application. The
resu lt is the need for a three-level label stack.

Forwarding: Step by Step

The details of the forwarding operation shown on the slide are:

1. A packet addressed to externa l route x arrives at PE-1.

2. PE-1 pushes two labels onto the packet: the inner label is the VRF label assigned by PE-4, and a second label
assigned by CE-1 (to associate the packet with the LSP to PE-4). In this one-hop LSP example, PHP results in t he
absence of a third RSVP/ LSP label used to associate the packet with the LSP between PE and CE routers.
3. CE-1 receives the labeled packet and swaps the top label.

4. PE-2 receives the labeled packet and swaps the top label with the value received from PE-3 while also pushing
the MPLS label (Label 1008 in this example) onto the stack.

5. The P router pops the top label (PHP) so that PE-3 rece ives a packet with only two labels.

6. PE-3 also performs a swap on the top label before forwarding the packet to CE-2.

7. Being the penultimate router for the LSP to PE-4, CE-2 pops t he label stack and sends the resulting VR F-labeled
packet to PE-4.

8. PE-4 pops the VRF label and consults the corresponding VRF table to perform a longest-match lookup on the
now unlabeled packet.

9. The native packet is forwarded out PE-4 's VR F interface toward the subscriber to wh ich it is addressed .

www.j uniper.net lnterprovider VPNs • Chapter 7- 27

Junos Layer 3 VPNs

Carrier-of-Carriers VPN Example

■ AS 65512 provides carrier-of-carriers services to its customers in
AS 10 and AS 11
• LSP established between PE routers
■ Policy on customer PE routers to advertise internal routes to
provider
• EBGP with labeled-u n icast NLRI between CE device and PE routers
■ PE-1 and PE-4 routers establish a multihop MP-EBGP session to
advertise external (VPN) routes (172.16/16) using family ine t- v p n
172.16/1 6
Provider Core
AS 65512 _ _ _ _ CE-2A
OSPF Area 0 AS 11
CE-1A AS10 Site 2
Site 1 OSPF Area 0
OSPF Area 0

172.22.220.0/24 172.22.222.0/24 10.0.21 .0/24

.1 ~.1 .2~L_.2 _ _.1 ~.1 . ~-1 .2
t PE-1 CJ=,,~ge-1/ 1/4 ~ge-1 /0/ 1 ~ 'ilP
ge-1/0/4 '~
PE-2 P-1 PE-3 ~ E-2 PE-4 I/
~
loO 192.168.12.3

C> 2020 Juniper Networks, Inc All Rights Reserved

loO 192.168.12.1 loO 192.168.2.1

......_ -------- loO 192.1°68.2.2 loO 192.168.12.2 _/

loO 192.168.12.4

AS 65512 Provides Carrier-of-Carriers Services

Th is slide provides a sample network. The following s lides show various configuration-mode and operationa l-mode screen
captures relating to th is slide.

The provider's network is assigned AS 65512. It already has established an LSP between PE-2 and PE-3 using RSVP. The PE
routers have a VRF table configured, along with the necessary VR F ta rget and route distinguishers. PE-2 and PE-3 function
as ASBRs in this application .

Policy on CE Routers
The CE routers are configured to run MP-EBGP (family inet labeled-unicast) with the PE routers and have a policy
in place to ensure that only internal prefixes are advertised to the provider's PE routers .

PE-1 and PE-4 Routers Exchange External Routes

A multi hop MP-EBGP session is configured between the PE-1 and PE-4, because the customer networks are assigned
different AS numbers. The external route 172.16/16 is advertised as a labeled-VPN route by PE-4 to PE-1 using th is
MP-EBGP session. Customer routers CE-1 and CE-2 also f unction as ASBRs in th is example.

Chapter 7 -28 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

PE-1 Configuration

■ Redistributes external (VRF) routes to PE peers

■ Multihop EBGP-loopback peering with resolve-vpn
user@pe-1# show protocols bgp user@pe-1 # s how rou t i ng - i nsta nce s
group int { vpn-2 {
type internal ; i nstance-type vrf ;
local-address 192 . 168 . 12 . 3; interface ge-1/0/6 . 0 ;
family inet { route-distinguisher 192 . 168 . 12 . 3 : l ;
labeled-unicast { vrf-target target : 10 : 200 ;
resolve- vpn ; routing-options {
} static {
} route 172 . 15 . 0 . 0/16 next-hop 10 . 0 . 51 . 2 ;
neighbor 192 . 168 . 12 . 1 ; }
} }
group ext { }
type external ; user@pe-1# show protocols mpls
multihop; interface all ;
local-address 192 . 168 . 12 . 3;
family inet- vpn { user@pe-1# s ho w p r otocol s l dp
unicast ; interface all ;
}
family 12vpn {
signaling;
}
peer-as 11 ;
neighbor 192 . 168 . 12 . 4;
}

C2020 Juniper Networks, Inc . All Rights ReseM!<I.

PE-1 Configuration
This slide shows the key aspects of PE-1's configuration. Fami ly l a b e l ed-u ni cast is configured for its MP-IBGP session
to CE-1, and family inet-vpn is configured for the multihop MP-EBGP session to PE-4.

resolve-vpn
The r e sol ve-vp n option causes PE-1 to copy the l abe l ed-u n icas t routes it receives from CE-1 into i net . 3 , wh ich
allows VPN routes to resolve through the interprovider LSPs. Without this option, all the VPN routes received would be
hidden, due to unusable next hops.

www .juniper.net lnterprovider VPNs • Chapt er 7- 29

Junos Layer 3 VPNs

CE-1 Configuration
• Redistributes internal routes to PE-2; family inet labeled-
un i cast needed on BGP peering session
user@ce - 1# show p r otocol s

bgp {
group int {
type internal ;
local - address 192 . 168 . 12 . 1 ;
famil y inet {
!labeled- unicast 4
)
export nhs ;
neighbor 192 . 168 . 12 . 3 ;
)
group ext {
type external ;
familv inet f
~abeled-unicast ;
)
export internals ;
peer - as 65512 ;
neighbor 10 . 0 . 20 . 1;

C2020 Juniper Networks, Inc . All Rights Resenie<I.

CE-1 Configuration
Th is slide displays key portions of the configuration on CE-1. RSVP is enabled, and an LSP is defined back to PE-1 (not
shown). The MP-IBGP session to PE-1 has the l abe l ed- u n i cast fam ily configured. This configuration is needed so that
CE-1 can include l a b e l ed-un icast routes along with the advertisements for Site 2 's internal routes.

CE-1 also has an MP-EBGP session configured for its connection to PE-2. Th is session must also support
l abe l ed- u ni cast routes.
The following policy is applied to CE-i's MP-EBGP session to PE-2. This policy ensures that Site 1 sends on ly internal routes
to the provider:

user@ce- 1 # show policy-options

policy-statement intern als {
te r m 1 {
fr om protocol [ ospf di r ect ];
the n accep t;
}
te r m 3 {
the n rejec t;
}
}

Chapter 7 -30 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

Carrier-of-Carriers VPN Operation: VPN Routes

■ VRF routes are learned through MP-EBGP connection between

customer PE routers
user@pe - 1 > show route receive- protocol bgp 192.168 . 12 . 4

ine t . 0 : 8 dest i nati o n s , 8 rout es ( 8 acti ve , 0 h o l ddown , 0 h i dde n)

ine t . 3 : 4 dest i nati o n s , 4 rout es (4 acti ve , 0 h olddown , 0 h i dde n)

vpn - 2 . inet . 0 : 5 dest i na tio n s , 5 r out es (5 act ive , 0 holddown , 0 h i dde n)

Pre fix Ne xthop MED Lclpr e f AS path
* 10 . 0 . 61 . 0/24 1 92 . 168 . 1 2 . 4 11 I
* 172 . 16 . 0 . 0/ 1 6 1 92 . 168 . 12 . 4 11 I

mpls . 0 : 6 d e st i nati o n s , 6 rou t es ( 6 act i ve , 0 h o l ddown , 0 h i dde n)

b gp . 13vpn . O: 5 desti n a tio n s , 5 r o utes (5 acti ve , 0 holddown , 0 h i d den )

Pre f ix Nexthop MED Lclpre f AS path
192 . 168 . 1 2 . 4 : 1 : 10 . 0 . 6 1 . 0/24
* 192 . 1 68 . 12 . 4 11 I
192 . 168 . 1 2 . 4 : 1 : 172 . 16 . 0 . 0/16
* 192 . 168 . 12 . 4 11 I

~2020 Jun,per Networks, Inc .All Rights ReseM!<I.

Carrier-of-Carriers VPNs Operation: VPN Routes

Th is slide shows that PE-1 learns labeled VPN routes from PE-4 at Site 2. These routes are associated with a VRF label (not
shown) used by the advertising router (PE-4) to associate the packets w ith the correct VRF table.

www .j uniper.net lnterprovider VPNs • Chapter 7 -31

Junos Layer 3 VPNs

Carrier-of-Carriers VPN Operation: Internal Routes

■ Internal routes are learned through MP-IBGP connection between CE

and PE routers
• re sol ve - vpn copies labeled routes into inet . 3 for VPN route resolution
user@pe-1> show r oute r eceive-pr otocol bgp 192.168 . 12 . 1

inet . 0 : 8 destinations , 8 r o utes ( 8 act i ve , 0 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
* 1 0 . 0 . 21 . 0/24 192 . 1 68 .1 2 . 1 100 65512 I
* 192 . 168 . 12 . 2/32 192 . 168 . 12 . 1 100 65512 11 I
* 1 92 . 168 . 12 . 4/32 192 . 168 . 12 . 1 100 65512 11 I

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

Prefix Nexthop MED Lclpref AS path
* 10 . 0 . 21 . 0/24 192 . 168 . 12 . 1 100 65512 I
* 192 . 168 . 12 . 2/32 192 . 1 68 . 12 . 1 100 65512 11 I
* 192 . 168 . 12 . 4/32 192 . 168 . 12 . 1 100 65512 11 I

C 2020 Juniper Networks, Inc .All Rights ReseM!<I.

Carrier-of-Carriers VPN Operation: Internal Routes

This slide s hows that PE-1 learns about Site 2 's internal routes th ro ugh its M P-IBG P connection to CE-1 (an AS BR).

The l abele d - u n i cas t routes received by PE-1 are copied into the main routing table (i net . O) as well as the i net . 3
tab le. This copying is the result of the r e so l ve-vpn option on PE-1 and is critical to the operation of t his network.
Normally, VPN routes must resolve to an LS P that term inates on t he egres.s PE router. Beca use PE-1 does not have an LSP
terminating d irectly on PE-4, the VPN ro utes are un usable without the labe l ed- un icast entries to the remote PE routers
in i ne t. 3, w hich indicate a multinetwork LSP between PE-1 and PE-4 exists.

Chapter 7 - 32 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

Carrier-of-Carriers VPN Operation: PE-2

• PE-2' s VPN MPLS forwarding table
• Swap/push operations create three-level label stack in provider core
use r @pe - 2> show route table vpn.mpls.O detail

vpn . mp l s . O: 2 destinations , 2 routes (2 active , 0 holddown , 0 h idden )

300288 (1 en try , 1 announced)
*VPN Pre f erence : 170
Ne xt hop type : I nd irect
Next- hop reference coun t : 2
Source : 192 .1 68 . 2 . 2
Next hop type : Router , Next hop index : 7 69
Ne xt hop : 172 . 22 . 221 . 2 via ge - 1/ 0/1 . 221 weight Ox l , select ed
Label - switched- path pel - to - pe2
Label operation : Swap 300080 , Push 302 400 (top )
Protocol next hop : 192 . 168 . 2 . 2
Swap 300080
I ndirect next hop : 28aa l e0 10 48576
State : <Active Int Ext>
Local AS : 65512
Age : 1 : 13 : 50 Metric2 : 4
Task : BGP RT Background
Announcement bits (1 ) : 0-KRT

C 2020 Juniper Netwo11<s, Inc . All Rights Resenie<I.

Carrier-of-Carriers VPN Operation: PE-2

Th is slide s hows the VPN instance's mp l s . o table that exists on PE-2. Here, packets received with a label of 300288 have
their top label swapped . PE-2 pushes a new label (obtained from RSVP or LOP) onto the stack, creating a three-level label
stack (VR F-la bel-300080- 302400).

The top label is popped by the provider P router (PHP), such that PE-3 receives a packet with a two-leve l label stack. PE-3
swaps the top label with the va lue assigned to t he LSP to PE-4 by CE-2. PE-3 's label operation is shown here:

user@pe-3> show route table mpls.O

mp l s . 0 : 6 d est inat i o n s , 6 r o ut es ( 6 act i ve , 0 ho lddown, 0 h idden )

+ = Ac t ive Route , - = Last Ac t ive , * = Both

• • •

299904 * [VPN/ 1 70 ] 19 : 07 : 27
> to 1 0 . 0 . 2 1. 2 via ge- 1 /0/4 . 0 , Pop
299904(S= O) * [VPN/ 1 70 ] 19 : 07 : 27
> to 1 0 . 0 . 2 1. 2 via g e- 1 /0/4 . 0 , Pop
300080 * [VPN/ 1 70 ] 0 1: 15 : 43
> to 1 0 . 0 . 2 1. 2 via g e- 1 /0/4 . 0 , Swap 299872
The result is that CE-2 receives a packet with a two-level label stack (VRF-label- 299872). CE-2 then swaps t he top label with
the va lue it associates with the LSP to the egress PE router. In t his example, CE-2 pops the stack because it is the
penu ltimate router for th is LSP.

www .j uniper. net lnterprovider VPNs • Chapter 7 - 33

Junos Layer 3 VPNs

Carrier-of-Carriers VPN Operation: traceroute

■ traceroute operational command:
• Customer PE-to-PE VRF table:
user@pe- 1> t r acer oute 1 0.0.6 1.2 r ou t ing- instan ce vpn - 2
traceroute to 10 . 0 . 61 . 2 (10 . 0 . 61 . 2) , 30 hops max , 40 byte packets
1 * * *

5 * * *
6 10 . 0 . 60 . 2 (10 . 0 . 60 . 2 ) 0 . 797 ms 0 . 515 ms 0 . 502 ms
MPLS Label=299808 CoS=O TTL=l S=l
7 10 . 0 . 61 . 2 (1 0 . 0 . 61 . 2) 0 . 50 1 ms O. 5 0 7 ms O. 4 8 7 ms

• Customer PE-to-PE:
user@pe-1> t r a ceroute 192. 1 68. 12. 4 s ource 192.168.12.3
traceroute t o 192 . 168 . 12 . 4 (192 . 168 . 12 . 4) from 192 . 168 . 12 . 3, 30 hops max , 40 byte packets
1 10 . 0 . 5 0 . 1 (10 . 0 . 5 0 . 1 ) 0 . 510 ms O. 3 91 ms O. 3 61 ms
MPLS Label=299856 CoS=O TTL=l S=l
2 10 . 0 . 20 . 1 (10 . 0 . 20 . 1 ) 0 . 383 ms 0 . 379 ms 0 . 373 ms
MPLS Label=300208 CoS=O TTL=l S=l
3 * * *
4 * * *
5 10 . 0 . 21 . 2 (10 . 0 . 21 . 2) 0 . 606 ms 0 . 478 ms 0 . 466 ms
MPLS Label=299792 CoS=O TTL=l S=l
6 192 . 168 . 12 . 4 (1 92 . 168 . 12 . 4) 0 . 477 ms 0 . 475 ms 0 . 457 ms

C/2020 Juniper Networks, Inc .All R,ghlS Resenie<I.

Carrier-of-Carriers VPN Operation: tracerou te

This slide shows the results of a VRF table-to-VR F table trace r o ut e operational command as well as a t r aceroute
operational command from ingress PE router to egress PE router.

All other rout er hops in the c ustomer and provider netwo rks are seen as t racero ute timeouts.

The traceroute between PE-1 and PE-4 shows the outer MPLS label for the various hops in the path, except for t he provider's
routers, wh ich appear as t imeouts. The provider routers are not able to generate t raceroute responses, owing to their not
ca rrying customer externa l or internal rout es.

Chapter 7 - 34 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

Agenda:
lnterprovider Backbones for Layer 3 VPNs
• Hierarchical VPN Models
■ Junos Support of Carrier-of-Carriers Model

• Junos Support of Carrier-of-Carriers VPN Applications

➔ lnterprovider VPN Option C

C> 2020 Juniper Networks, Inc All Rights Reserved Jun1Per

N CTWOkl<S
35

lnterprovider VPN Option C

Th is slide high lights the topic we discuss next.

www .juniper.net lnterprovider VPNs • Chapter 7 - 35

Junos Layer 3 VPNs

lnterprovider L3VPN Operation (Option C)

■ Service provider routers:
• P routers maintain only AS-internal routes
• PE routers maintain AS-internal, AS-external and customer L3VPN routes
• ASBR routers maintain AS-internal, and AS-external routes
■ ASBRs interconnect with other autonomous systems
■ CE routers maintain only customer routes
■ Three-level label stack in provider networks
• MP-1/EBGP needed for labeled route exchange

AS100 AS200

e~ e e-,c;I-.- -e -,el- EB- e

CE-A1 P1 ASBR ASBR P2 CE-A2
LSP LSP

C> 2020 Juniper Networks, Inc All Rights Reserved Jun1Per

N£TW0AAS
36

Service Provider Routers

• P routers only maintain the internal routes f rom its own AS (AS-internal)

• PE routers mainta in the internal routes from its own AS (AS-internal), the loopback address from the other AS
PE's (AS-external), and the L3VPN routes.

• ASB R routers ma inta in the internal routes from its own AS (AS-internal), and the loopback addresses from the
other AS PE's (AS-external). It does not maintain L3VPN routes, which makes this sol ution scalable.

ASBR Routers
The ASB R routers interconnect t he providers. To ensure that the L3VPN traffic is sent labeled across the interprovider link
l abe l ed-u ni cast routes are exchanged across the EBGP session .

CE Routers
CE ro uters are unaware of the interprovider setup so just as for single provider L3VPNs they only care about their own ci rcu it
information and their loca l routing (if used at all).

Continued on the next page.

Chapter 7 -36 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

Three-Level Label Stack Required

The presence of L3VPN related labels resu lts in the need to support three levels of label stacking in the provider networks. In
the case of PE-1, the three labels have the following functions:

1. The bottom label is the L3VPN label assigned using multihop MP-EBGP. This label does not change as the
packet is forwarded .

2. The m iddle label is assigned by the downstream ASBR1 and is used by the ASBR1 to associate the packet with
the LSP lead ing to the remote PE This is a labeled unicast learned label.

3. The top label associates the packet with t he LSP connecting PE1 to ASBR1 and is assigned by RSVP or LOP.

Because an LSP must be established across AS boundaries to interconnect customer PE routers, labels must be
communicated along with t he NLRI advertised by ASBRs. Although a protocol such as LOP cou ld be used fo r th is purpose,
the Junos OS currently supports MP-BGP for this purpose.

RFC 3107, Carrying Label Information in BGP-4, specifies labeled routes. Labeled route advertisements use SAFI 4 and
differ from VPN-labeled routes in t hat there is no route distinguisher or route ta rget communities in the advertised NLRI.
Simply put, labeled routes allow the binding of an MPLS label to the advertised 1Pv4 NLRI. ASBRs use the advertised labels
to build MPLS switching tables that result in an end-to-end LSP spanning multiple autonomous networks.

Within an AS, labeled routes are sent using MP-IBGP while MP-EBGP is used across AS boundaries.

www .juniper.net lnterprovider VPNs • Chapter 7 - 37

Junos Layer 3 VPNs

lnterprovider L3VPNs: Signaling

■ Provider networks require LSP signaling
■ EBGP signaling between ASBR routers
■ IBGP signaling between ASBR and local PE's
• Uses labeled- unicast address family
■ EBGP signaling between PE routers
• Full mesh among customer PE routers with common VPNs
• RR improves scalability-no - nexthop - change command
• Uses family inet-vpn unicast
~--·-·-·-·-·-·-·-·-·-·-·-·-·-·1
I f MP-EBGP · h nn
EBGP Multi ~ .-. family inet- vpn unicast .-.... •
Session ~
1
ASiOO ,-... AS200 ------ I

Cf) Cf) Cf) Cf)

CE-Ai SBRi P2 CE-A2
Pi
MP-BGP
LSP family inet labeled-unicast LSP

C/2020 Juniper Networks, Inc .All Rights ReseM!<I. Jun1Per

~ETWORKS
38

LSP Signaling Needed in Service Provider Networks

Because MPLS forwarding is used each provider must signal an LSP. The LSP signaling protocols need not be the same; LDP
and/ or RSVP can be used.

MP-EBGP Signaling Between Provider ASBR Routers

The ASBR routers use EBGP with l a b e l ed- u n i cas t NLRI to exchange labeled routes across the interprovider connection.
The use of labeled routes allow the providers to extend its LSPs to each other by also carrying the loopback addresses of the
PE's from t he other AS.

MP-IBGP Signaling Between ASBR and Local PE Routers

Once the ASBR has learned the labeled unicast routes to the remote AS 's PE routers, it can propagate th is information using
an IBG P session to the local PE routers. This ensures that the PE routers learn the label towards the remote PE's loopback
add resses.

MP-EBGP Signaling between the PE Routers

To actua lly exchange inet-vpn routes, a multihop EBGP session is established between the relevant PEs. In small
deployments this can be done by full mesh PE peerings

To improve scalabi lity for large deployments, the provider networks can use route reflection. The two or more ro ute reflectors
peer using multhop M P-EBGP. A command called no-nexth o p -chan ge is required to te ll the route reflecto rs to pass-
unchanged- the third party next hops to t heir cl ients.

Chapter 7 -38 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

lnterprovider L3VPNs: Data Flow

· hnn
~--·-·-·-·-·-·-·-·-·-·-·-·-·-·1
I f MP-EBGP
EBGP Mult i ~ .--..... L3VPN Label 3004 .--. •
Session ~
1
AS100 --. .,,,-.. AS200 --. I
•• ••
....•••••• •• ••......
p CE-A2
MP-EBGP
MP-IBGP - -> ~ iL
US~P~ PE2 Label 2008
LS P
•
•• PE2 Label 2007
••
LOP LOP
•• ASBR1 Label 1020 PE2 Label 1010
••
••
••
•• 1020
•• -,,II J~
•• 2007 2007 1010
•• 3004
3004 3004 3004
I I DA I X DA=x
3004
DA=x DA=x DA=x DA=x I IDA X
Packet from A1 PE-1 pushes PHP by ASBR1 PHP by PE2 pops VPN
ASBR2
addressed to A2 label 3004 swaps top P router label and
P router swaps
(VPN). label label top label forwards out of
2007 (PE2 = towards to reach L3VPN CE-faci ng
NH). and 1020 PE2 PE2 interface
(ASBR1) as top
label
■ Requires three-level label stack
C> 2020 Juniper Networks, Inc All Rights Reserved

lnterprovider L3VPNs: Data Flow

Th is slide uses steps to describe the forwarding operations between PE1 and PE2 in an interprovider BGP L3VPN
application. The result is the need for a three-level label stack.

Forwarding: Step by Step

The details of the forwarding operation shown on the slide are:

1. A packet for the L3VPN between CE-Ai and CE-A2 arrives at PE1.

2. PE1 pushes three labels onto the packet: the inner label (3004) is t he L3VPN label assigned by PE2, and a
second label (2007) assigned by ASBR1 (to associate the packet with the extended LSP to PE2). The top label
(1020) is pushed to use the LOP LSP to reach ASBR1.

3. Pi receives the labeled packet and pops the top label (PHP).

4. ASBR1 receives the labeled packet and swaps the top label with the value rece ived from ASBR2 (2007
->2008)

5. ASBR2 receives the labeled packet and swaps the top label with the value of the LOP LSP towards PE2 (2008
-> 1010).

6. Being the penultimate router for the LOP LSP to PE2, P2 pops the label stack and sends the resulting
L3VPN-labeled packet to PE2.

7. PE2 pops the L3VPN label and consults the corresponding table to forward the traffic out of the correct
CE-facing interface.

8. The native packet is forwarded out PE2's L3VPN interface toward the CE to which it is addressed .

www.j uniper.net lnterprovider VPNs • Chapter 7 - 39

Junos Layer 3 VPNs

lnterprovider Option C L3VPN Example

■ Inter-AS L2VPN between AS65201 and AS65202
• LOP used for intra-AS LSP's
■ EBGP signaling between ASBR routers
■ IBGP signaling between ASBR and local PE's
• Uses labeled-unicast address family
■ PE-1 and PE-4 routers establish a multihop
MP-EBGP session to advertise external L3VPN routes using family
inet - vpn signaling
r-----. CE-2A
CE-1 AS 65201 Site 1 Site 2 As 65202
OSPF Area 0 OSPFArea 0

10.0 .50.0/ 24 10.0.20.0/ 24 10.0.2 .0/ 24 ~ -0/ 24 10.0 .60.0 24

~ -2 .1 ~ .2 .1 ~........._
.1 _ _.2 ~ .1 .2 ~ -1 .2 ~
~ ~ g e-1/ 1/ 4 ~ g e-1/ 0/ 1 ~ · ge-1/ 0/ 4 ~ · ~
~ Pi J/ ASBR1 ASB82 P2 PE2 '
loO 192.168.12.1 loO 192.168.2 .1 loO 192.168.2.2 ' loO 192.168.12.3 /'
loO 192.168.12.2 loO 192.168.12.4
C> 2020 Juniper Networks, Inc All Rights Reserved Jun1Per
NETWOAAS
40

lnterprovider L3VPN Between AS65201 and AS65202

Th is slide provides a sample network. The following slides show various configuration-mode and operational-mode screen
captures relating to th is slide.

Within each provider's network the IGP and LOP protocols already have been configured so that within each AS there is an
end-to-end LSP to each loopback.

E-BGP Signaling Between ASBR Routers

The ASBR route rs are configured to run MP-EBGP (family inet labe l ed-unicast) with each other. They have a
policy in place to ensure that only internal PE's loopback prefixes are advertised to the other provider's ASBR.

1-BGP Signaling Between ASBR and Local PE Routers

To distribute t he learned remote PE's loopback addresses the ASBR peers with the local PE's.

PE-1 and PE-2 Routers Exchange External Routes

A multihop MP-EBGP session is configu red between the PE1 and PE2, because the provider networks are assigned different
AS numbers. The L3VPN NLRI is advertised as a labeled-VPN route by PE2 to PE1 using th is MP-EBGP session.

Chapter 7 -40 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

PE1 Configuration

■ Multihop EBGP-loopback peering with remote PE2

• IBGP peering with ASBR1 with resolve - vpn
user@PEl# show protocol s bgp user@PEl# show rout ing- insta nces
group int { vpnl {
type internal ; i nstance-type vrf;
local- address 192 . 168 . 12 . 2 ; interface ge-1/0/6 . 620 ;
family inet { route-distinguisher 193 . 168 . 12 . 4 : 100 ;
labeled- unicast { vrf-target target : 65202 : 100 ;
resolve-vpn ; routing-options {
1 static {
} route 100 . 1 . 0 . 0/24 next-hop 10 . 1 . 0 . 2;
neighbor 192 . 168 . 2 . 1 ; }
} }
group ext { }
type external ;
multihop;
local- address 192 . 168 . 12 . 2 ;
family inet-vpn {
unicast ;
I
peer-as 65202 ;
neighbor 192 . 168 . 12 . 4; user@PEl# show protocols mpls
}
interface a l l ;

user@PEl# show protocols ldp

interface all ;

C> 2020 Juniper Networks. Inc All Rights Reserved

PE1 Configuration
Th is slide shows the key aspects of PE1's configuration. Fam ily l a b e l ed-u ni cast is configured for its MP-IBGP session to
ASBR1, and family i ne t -vpn un icast is configured for the multihop MP-EBGP session to PE2.

resolve-vpn
The re sol ve-vpn option causes PE1 to copy the labe l e d - un icast ro utes it receives from ASBR1 into i n e t. 3, which
allows L3VPN routes to resolve through the interprovider LSPs. Without this option, all the VPN routes received would be
hidden, due to unusable next hops.

The s lide also shows the L3VPN routing-instance configuration that is identical as used for s ingle provider L3VPNs.

www .juniper.net lnterprovider VPNs • Chapter 7 - 41

Junos Layer 3 VPNs

ASBR1 Configuration
• Redistributes internal routes to ASBR2; family inet labeled-
un i cast needed on BGP peering session
user@ASBRl# show protocols user@ASBRl# show prot ocols mpl s
traffic-engineering {
bgp { mpls- forwarding ;
group int ( }

type internal ; interface all ;

local - address 192 . 168 . 2 . 1; user@ASBRl# show prot ocols l dp
family inet { interface all ;
~ abeled- unicast ;j
)
export nhs ;
neighbor 192 . 168 . 12 . 2 ;
)
group ext {
type ext ernal ;
family inet {
!labe l ed-unicast 4
)
!export 1.n; ernal s ; I
peer - as 6 :>12 ;
neighbor 10 . 0 . 2 . 2 ;

~2020 Jun,per Networks, Inc .All Rights ReseM!<I.

ASBR1 Configuration
Th is slide shows the key aspects of ASBR1's conf iguration. Fami ly l abe l ed- u n i cas t is configured f or its MP-IBGP
session to ASBR1, and for its MP-EBGP session to ASBR2.

Notice the export policy called interna ls that cont ains the local PE's loopback addresses.

Chapter 7 -42 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

lnterprovider L3VPN Operation: L3VPN Routes

■ L3VPN routes are learned through multihop MP-EBGP connection

between PE routers
user@PE l > show route receive-protocol bgp 193.168.12 . 4
inet . 0 : 10 desti nations , 10 routes (1 0 active , 0 holddown , 0 hidden )

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

vpnl . inet . 0 : 5 destinations , 5 rou tes (5 active , 0 holddown , 0 hidden)

Prefix Nexthop MED Lclpref AS path
* 1 0 . 2 . 0 . 0 /2 4 193 . 1 68 . 12 . 4 65202 I
* 100 . 2 . 0 . 0/2 4 193 . 168 . 12 . 4 65202 I

rnpl s . 0 : 8 dest i nat i on s , 8 r outes (8 active, 0 holddown , 0 h idden)

bgp . 13vpn . O: 5 destinations , 5 routes (5 active , 0 ho l ddown , 0 hidden )

Prefix Ne xthop MED Lclpre f AS path
193 . 168 . 12 . 4 : 100 : 10 . 2 . 0 . 0/24
* 193 . 168 . 12 . 4 65202 I
1 93 . 168 . 12 . 4 : 100 : 100 . 2 . 0 . 0/2 4
* 193 . 1 68 . 12 . 4 65202 I

C> 2020 Juniper Networks, Inc All Rights Reserved

Layer 3 VPN Routes

Th is slide shows that PE1 learns labeled VPN routes from PE2 at Site 2. These routes are associated with a L3VPN label (not
shown) used by the advertising router (PE2 ) to associate the packets with the correct L3VPN table .

www .j uniper.net lnterprovider VPNs • Chapter 7 - 43

Junos Layer 3 VPNs

lnterprovider L3VPN: AS External Routes

■ AS External routes are learned through MP-IBGP connection

between PE and ASBR routers
• re sol ve - vpn copies labeled routes into inet . 3 for VPN route resolution

user@PEl> show route receive- protocol bgp 193.168.2.1

inet . O: 9 dest inat i ons , 9 rou tes ( 9 act i ve , 0 holddown , 0 hidden)

Pre f i x Nex thop MED Lclpref AS pat h
* 1 93 . 168 . 12 . 4/32 1 93 .1 68 . 2 . 1 2 100 65202 I

ine t . 3 : 3 des tinat i ons , 3 rou tes (3 act i ve , 0 holddown , 0 hidden)

Prefix Nex thop MED Lclpref AS path
* 1 93 . 168 . 12 . 4 /32 1 93 .1 68 . 2 . 1 2 100 65202 I

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

MP-BGP Peering Example

Th is slide shows that PE1 learns about Site 2 's internal routes through its MP-IBGP connection to ASBR1

The l abele d - u n i cas t routes received by PE1 are cop ied into the main routing table (i net . O) as wel l as the i net . 3
table. Th is copying is the result of the re so l ve-vpn option on PE1 and is critica l to the operation of this network. Normally,
L3VPN routes must resolve to an LSP that term inates on the egress PE router. Because PE1 does not have an LSP
terminating d irectly on PE2, the VPN routes are unusable without the l abe l ed-u ni cast entries to the remote PE routers
in i ne t. 3, which indicate a multinetwork LSP between PE1 and PE2 exists.

Chapter 7 -44 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

lnterprovider L3VPN Operation: PE-2

■ PE-2' s L3VPN MPLS forwarding table
• Swap/push operations create three-level label stack
user@PE2> show route 100.1.0.0/24

vpnl . inet . O: 5 destinations , 5 routes ( 5 active , 0 holddown , 0 hidden )

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

100 . 1 . 0 . 0/24 *[ BGP/1 70 ] 00 : 1 5 : 28 , localpref 100, from 193 . 168 . 12 . 2

AS path : 65201 I , validation - state : unveri fi ed
> t o 10 . 0 . 60 . 1 via ge - 1/1/5 . 0 , Push 299824 , Push 300064 ,
Push 299776 ( top)

■ Ping from CE2's loopback to CE 1's loopback

user@ PE2> ping 100.1.0.1 source 100 . 2.0.1

PING 100 . 1 . 0 . 1 (1 00 . 1 . 0 . 1) : 56 data bytes

64 bytes from 100 . 1 . 0 . 1 : icmp_ seq=O ttl =58 time=l . 272 ms
64 bytes from 100 . 1 . 0 .1 : icmp_ seq=l t t1=58 time=l . 085 ms
64 bytes from 100 . 1 . 0 . 1 : icmp_ seq=2 t t1=58 time=l . 092 ms

- - - 100 . 1 . 0 . 1 ping statistics ---

3 packets transmitted , 3 packets received , 0% packet loss
round- trip min/avg/max/stddev = l . 085/l . 150/1 . 272/0 . 087 ms
~2020 Juniper Networks, Inc .All Rights ReseM!<I.

lnterprovider L3VPN Operation: PE2

Th is slide shows the 100.1 .0 .0/ 24 route on PE2. It shows that traffic toward 100.1.0.0/ 24 will have 3 labels pushed upon it
to reach the network located on the remote CE device:

• Label 299776 (L3VPN label received from PE2 across MP-EBGP session )

• Label 300064 (Label received from the labeled unicast MP-IBGP sessio n with ASBR1)

• 299824 = Top label (Label received from P1 router using the LDP protocol )

To verify the data-plane connectivity you can use a pi ng from one CE toward the remote CE. As shown in the slide the ping is
successful.

www .j uniper.net lnterprovider VPNs • Chapter 7 - 45

Junos Layer 3 VPNs

Summary

■ In this content, we:

• Described Junos support for carrier-of-carriers
• Described Junos support for interprovider VPN applications
• Described lnterprovider VPN Option C

~2020 Jun,per Networks, Inc .All Rights ReseM!<I. Jun1Per

NETWORKS
46

We Discussed:
• Junos support for carrier of carriers;

• Ju nos support for interprovider VPNs; and

• lnterprovider VPN Option C.

Chapter 7 -46 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

Review Questions

1. What are two key differences between the carrier-of-carriers

application and interprovider VPNs?
2. What are the three different methods for providing interprovider VPN
service?
3. In carrier-of-carriers signaling, what BGP address family is used
between provider PE and customer CE routers?

~ 2020 Juniper Networks, Inc. All Rights Reserve<!. Jun1Per

~ETWORl(S
47

Review Questions
1.

2.

3.

www .juniper.net lnterprovider VPNs • Chapt er 7 - 4 7

Junos Layer 3 VPNs

Lab: Carrier-of-Carriers VPNs

■ Configure a Layer 3 VPN between service providers using carrier-of-

carriers VPN.

~2020 Jun,per Networl<s, Inc .All Rights Resenie<J. Jun1Per

NETWORKS
48

Lab: Carrier-of-Carriers VPNs

The slide provides the objective for this lab.

Chapter 7 -48 • lnterprovider VPNs www.juniper.net

 Junos Layer 3 VPNs

Answers to Review Questions

1.
In a carrier-of-carrier application the customer routers maintain both customer internal and external routes. In an
interprovider VPN, except for the ASBRs connect to VPN sites, the customer routers maintain customer internal routes on ly.
2.
Option A specifies the use of separate VRFs for every VPN on the ASBRs. Option B specifies the used of the EBGP exchange
of VPN routes between ASBRs. Option C specifies t he use of multi hop EBGP (or IBGP) to exchange VPN routes between PEs
in remote autonomous systems.

3.
The labeled-unica st address family is used between PE and CE.

www .juniper.net lnterprovider VPNs • Chapter 7 - 49

Junos Layer 3 VPNs

Chapter 7 -50 • lnterprovider VPNs www.juniper.net

 un1Pe[
NETWORKS
Education Services

Junos Layer 3 VPNs

Chapter 8: Troubleshooting Layer 3 VPNs

Engineering Simplicity
Junos Layer 3 VPNs

Objectives

■ After successfully completing this content, you will be able to:

• Use a structured approach to troubleshoot Layer 3 VPNs
• Become familiar with commands and tools to check both the signaling and the
forwarding plane
• Troubleshoot MVPNs

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Joniper8us1ness Use Onty
Jun1Per
.iETWOffKS
2

We Will Discuss
• Using a structured approach to troubleshoot Layer 3 VPN issues;

• Useful commands and tools to check both the signaling and the forwa rding plane; and

• Troubleshooting MVPN issues.

Chapter 8 - 2 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Agenda: Troubleshooting Layer 3 VPNs

➔ TroubleshootingOverview
■ Verifying PE-CE Routing Protocols
■ MPLS Transport and Label Distribution Protocols

■ MP-BGP

■ The Forwarding Plane

■ Troubleshooting MVPNs

~2020 Juniper Networks, Inc .All Rights ReseM!<I.

Joniper8us1ness Use Onty
Jun1Per
NETWORKS
3

Troubleshooting Overview
The slide lists the top ics we will discuss. We wi ll discuss t he highlighted topic first.

www .juniper.net Troubleshooting Layer 3 VPNs • Chapter 8-3

Junos Layer 3 VPNs

Troubleshooting Layer 3 VPNs (1 of 2)

■ A useful approach: separate signaling and forwarding planes

• Signaling plane
• PE-CE routing protocols
• Label distribution protocols
• MP-BGP
• Forwarding plane
• We follow this approach in the rest of this material
• The troubleshooting starting point is dri ven by the problem description

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8usinessUse Onty

A Useful Approach: Separating Signaling and Forwarding Plane

When troubleshooting Layer 3 VPN issues, a very usefu l approach is to use a structured approach : verifying the signaling
plane and the forward ing plane separately.

The Layer 3 VPN signaling plane includes such components as the PE-CE dynamic routing protocols, the MP-BGP IBGP
session used to advertise VPN routes to other PEs and the label distribution protocols used to signa l the transport LSPs.

Checking the forwarding plane, instead, typically means sending test traffic (even with tools such as ping mpls) to detect
forward ing problems.

Troubleshooting in many cases starts with checking the state of the signaling plane. The first steps are driven by the problem
description: for example, in case of tota l loss of connectivity between a single CE and all the others, a natural starting point
would be the PE-CE routing protocol used on the CE side. If a whole previously-working VPN suddenly goes down and no site
can reach any other site, a natura l starting point wou ld be the IBGP infrastructure (e.g. route reflectors) or the label
distribution protocols used.

Chapter 8-4 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Troubleshooting Layer 3 VPNs (2 of 2)

■ Some examples of Layer 3 VPN problems

• Typical signaling issues
• Missing routes or unreachable sites
• Routing loops or suboptimal routing
• Typical forwarding issues
• Partial or total packet loss between CEs
• Failure to forward multicast streams
• Signaling issues tend to be easier to troubleshoot
• Protocol-related commands usually help narrow down root causes
• Forwarding issues may be more complex than simple loss
• For exam ple, might involve Class of Service

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per 8us1ness Use Only

Some Examples of Layer 3 VPN Problems

It is difficult to conceive a complete classification of Layer 3 VPN issues, as there are too many possible causes and factors
that may play a role with Layer 3 VPNs. However, it is possible to think of a broad categorization of s igna ling and forwarding
.
issues.

Some typical signal ing issues are missing ro utes or unreachable sites. Even if the actual root cause is hardware, e.g. a failed
interface on the PE-CE link, the s ignaling plane will be able to help pinpoint where the problem is. More comp lex signa ling
issues are suboptimal routing or routing loops within a VPN. These problems are however not specific to Layer 3 VPNS, and
are essentially routing pol icy or redistribution issues.

When it comes to forwarding issues, some typical examples are partial or total packet loss between sites, or fa ilure to
forward multicast streams even when t he m ulticast s ignaling plane appears correct. These problems are generally more
complex to troubleshoot, and may involve other features and functionalities as Class of Service .

www .juniper.net Troubleshooting Layer 3 VPNs • Chapter 8 - 5

Junos Layer 3 VPNs

Checking the Layer 3 VPN Signaling Plane

■ Troubleshooting commands are protocol-specific

• We will look at useful commands for
• Getting an overview of the VPN routing state
• PE-CE dynamic routing protocols (BGP, OSPF, RIP)
• Label distribution protocols (LOP, RSVP, BGP-LU)
• The MP-BGP and the bgp.13vpn.O table

PE-CE routing _._ --. PE-CE routing

e protocol
+----------• •
-" _ - -
Labe:~~;ribution·, ;
_ ~ ,.,. protocol
+----------+ e
CE1 PE1 . Protocols I , -E2 CE2

Some useful checkpoints

C2020 Jun,perNetworl<s, Inc .All Rights ReseM!<I.

Jon1per ausiness use Onty

Troubleshooting Commands are Protocol-Specific

Some natural checkpoints for troubleshooting Layer 3 VPN problems are:

1. The PE-CE dynamic routing protocols

2. The inet-vpn IBGP infrastructure

3. The MPLS label-distribution protocols used for establish ing label-switched paths in the core

We will now look at several useful commands to check each of these components.

Chapter 8-6 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Agenda: Troubleshooting Layer 3 VPNs

• Troubleshooting Overview
➔ Verifying PE-CE Routing Protocols
• MPLS Transport and Label Distribution Protocols
• MP-BGP
• The Forwarding Plane
• Troubleshooting MVPNs

C2020 Juniper Networl<s, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
1

Verifying PE-CE Routing Protocols

The slide highlights the topic we discuss next.

www .j uniper.net Troubleshooting Layer 3 VPNs • Chapter 8-7

Junos Layer 3 VPNs

Checking Overall Routing

■ Useful general commands

•show route table <vpn>
•show route summary
user@router> show route summary
Autonomous system number : 60001

VPN-A . inet . O: 5 destinations , 5 routes (5 active , 0 holddown , 0 hidden)

Direct : 1 routes , 1 active
Local : 1 routes , 1 active
OSPF : 2 routes , 2 active
Static : 1 routes , 1 active

VPN- B . inet . 0 : 4127 destinations , 4127 routes ( 4127 active , 0 holddown , 0 hidden)
Direct : 1 routes , 1 active
Local : 1 routes , 1 active
RIP : 1 routes , 1 active
BGP : 4124 routes , 4124 active

Looking at this output, can you spot any problem?

C/2020 Juniper Networks, Inc .All Rights Resenie<I.
Jon1per8usiness Use Onty

Useful General Commands

A very useful command to check the overall routing state on all VPNs is s h ow rou t e summa r y.

Th is wil l summarize the amount of rout es present in each routing instance, divided by protocol, and it is often a good first
st ep t o check t he overall signaling plane. The command will also display the number of hidden rout es wh ich - in a Layer 3
VPN envi ronment- are typica lly caused by lack of MPLS reachability to remote PEs.

In the picture, you can see two VPNs (VPN-A and VPN-8). There are no hidden routes, but while the output for VPN-8 appears
normal, VPN-A does not show any BGP routes. This means no routes f rom remote PEs are being received, and could indicate
a target/ VRF policy problem.

Chapter 8-8 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

BGP as PE-CE Routing Protocol (1 of 2)

■ Useful commands
•show bgp summary
•show bgp neighbor <ce address>
•show route advertising-protocol bgp <ce address>
•show route receive-protocol bgp <ce address>
■ BGP commands show sessions in all VRFs
• No need to specify the instance name

C/2020 Jun,perNetworl<s, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Onty

BGP as PE-CE Routing Protocol: Useful Commands

The scalabi lity and ease of use of BGP make it a very common choice as a PE-CE routing protocol. The commands used to
check ordinary IBGP and EBGP sessions can also be used without any modification to check the state of PE-CE BGP
.
sessions.

BGP Commands Show All Sessions in All VRFs

One point to consider is that BGP-related commands show all sessions, regard less from the VRF they belong to. This can be
confusing with several VRFs on the same PE; the commands output makes it clear which routing instance a session belongs
to.

www .juniper.net Troubleshooting Layer 3 VPNs • Chapter 8-9

Junos Layer 3 VPNs

BGP as PE-CE Routing Protocol (2 of 2)

■ Advertising VPN routes using BGP

• Default policies
• Due to the BGP default policy, MP-BGP routes from remote PEs are advertised to local
CEs
• Export policies may still be needed when distributing routes between instances with auto-
export or rib-groups
• Watch for configured prefix- l imit
• CEs in the same AS
• Might need as- o v e rride when using EBGP as PE-CE protocol
• An alternative is i ndepende n t - doma i n and IBGP

e 1~~!'!~-~~~ • ·- -M-~:.~G
.:;.;=-~-~-r:-E+3-.. . ;+:_l~G--!'_!:__~G.....:_~- E ~
CE1 PE1 ---.,,.. CE2

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per 8us1ness Use Onty

Advertising VPN Routes Using BGP

The default BGP import policy is to accept all routes sent by a neighbor, and advertise to BGP neighbors the active BGP
routes. In the context of VPNs this means that routes received from remote PEs will be advertised using BGP to the local CE,
even without an explicit export policy.

BGP export policies are still needed when distributing routes between instances using a uto -expo rt or a rib-gro up, or
in general whenever you need to advertise any non-BGP route (e.g. statics) to the local CE.

CEs in The Same AS

When using BGP as PE-CE protocol, it is often the case that all CEs in a VPN are configured as part of the same Autonomous
System. To prevent routes from being d iscarded by the CE as an AS-PATH loop, several options are possible: if the customer
is using a private AS, the as-ove rride command is a common solution. If the customer is actually using a publ ic AS and is
connected to the Internet, then using IBGP with independent-domain may be a good alternative.

Chapter 8-10 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

OSPF as PE-CE Routing Protocol (1 of 3)

■ Useful commands
•show ospf interface instance <vpn>
•show ospf neighbor instance <vpn>
•show ospf database instance <vpn> • • •

■ Checking advertised routes

• show ospf database instance <vpn>
advertising-router self
• This command gives the list of LSAs, not prefixes. Each LSA can then be checked
individually

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1p er8usiness Use Only
Jun1Per
~ETWORKS
11

OSPF as PE-CE Routing Protocol

The lower scalabi lity compared to BGP makes OSPF a somewhat uncommon choice. All usual OSPF commands accept the
modifier instance, which allows to check the st at e of protocol runn ing within a routing instance.

Several Configuration Options are Possible

To improve sca lability of OSPF as PE-CE routing protocol, severa l configuration options are possible. Among the common ly
deployed ones is domain-id, that al lows to redist ribute VPN routes using export policies as Type-3 LSAs rather than Type-5.

A problem in VRF po licies or a wrong domain-id configuration ca n cause VPN routes to be advertised as Type-5 rather tha n
Type-3. Th is can potentially cause routing problems for multi-homed sites, due to t he different protocol preference of OSPF
externa l (150) and internal routes (10).

A second, less common configuration option is the use of sham-l inks, which behave similarly to virtual links, con necting
multiple parts of the same OSPF doma in through the provider MPLS infrastructure. Sham-links are typically used when a
Layer 3 VPN is used to extend an OSPF domai n, for example connecting multiple OSPF sites or regio ns.

Checking Advertised Routes

While using s ham-links, it is not trivial to ve rify wh ich routes are being advertised by a PE towards a CE router. The routes wi ll
be computed on the basis of the LSAs being received th rough t he sham lin ks.

Continued on the next page.

www .j uniper.net Troubleshoot ing Layer 3 VPNs • Chapter 8 -11

Junos Layer 3 VPNs

Checking Advertised Routes (contd.)

When using export policies instead (with or witho ut doma i n- id) it is possible to verify what is being advertised by checking
self-originated LSAs of Type-3 or Type-5, according to the domain-id matching rules.

However, the output of show ospf database needs to be interpreted, as it on ly returns LSAs, not prefixes. For example,
here is the output of show ospf database instance <VPN> external advertising-ro uter self on a PE
router:

user@PE> s ho w o spf database i nstance VPN-A external advertis i ng-ro uter self
OSPF AS SCOPE l i n k sta t e datab ase
Typ e ID Ad v Rt r Seq Age Op t Ck s u m Len
Ex t ern *1 0 . 3 . 0 . 0 1 0 . 1. 0 . 2 Ox80000 2 01 1 932 Ox a2 Oxf a6 1 36
Ex t er n *1 0 . 3 . 0 . 3 1 0 . 1. 0 . 2 Ox80000201 1 075 Ox a2 Oxca9 1 36
Ex t er n *1 0 . 3 . 0 . 255 1 0 . 1. 0 . 2 Ox80000201 15 03 Ox a2 Oxf a6 1 36
Ex t er n *1 0 . 3 .1. 0 1 0 .1. 0 . 2 Ox80000 2 01 646 Ox a2 Oxe f 6b 36
Ex t er n *1 0 . 3 . 2 . 0 1 0 .1. 0 . 2 Ox80000201 218 Ox a2 Oxe475 36
Ex t er n *1 0 . 3 . 3 . 0 1 0 .1. 0 . 2 Ox80000200 2 789 Ox a2 Oxdb7e 36
From this output alone it is not possible to f ind out which prefixes are being advertised. This requires examining each LSA in
detail and checking its network and netmask., as shown below:

user@PE> sho w o spf database i nstance VPN-A external lsa-id 10.3. 0 .0 detai l
OSPF AS SCOPE l i n k sta t e datab ase
Typ e ID Ad v Rt r Seq Age Op t Ck s u m Len
Ex t er n *1 0 . 3 . 0 . 0 1 0 .1. 0 . 2 Ox 80000 2 01 2654 Ox a2 Oxf a6 1 36
mask 255 .2 5 5 . 0 . 0
Top o l ogy de f a u lt ( I D 0)
Type : 2 , Me t r i c : 0 , Fwd addr: 0 . 0 . 0 . 0 , Tag: 2 08 . 0 .2 5 5. 23 2

user@PE> show o spf database instance VPN-A external lsa-id 10. 3 . 0 .255 detail
OSPF AS SCOPE l i nk sta t e datab ase
Typ e ID Ad v Rt r Seq Age Op t Ck s u m Len
Ex t er n *1 0 . 3 . 0 . 255 1 0 . 1. 0 . 2 Ox80000 2 01 2 233 Ox a2 Oxf a6 1 36
mask 255 .2 5 5. 2 5 5 . 0
Top o l ogy de f a u lt ( I D 0)
Type : 2 , Me t r i c : 0 , Fwd addr: 0 . 0 . 0 . 0 , Tag : 208 . 0 . 25 5 . 232

In th is example, the first LSA (Isa-id 10 .3 .0 .0) is for 1 0 .3 .0 .0/16, and the th ird (Isa-id 10 .3 .0 .255) is for the 10.0 .3 .0/ 24
prefix.

Chapter 8-1 2 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

OSPF as PE-CE Routing Protocol (2 of 3)

■ Advertising VPN routes using OSPF

• VPN routes from remote CEs are not advertised to local CEs by default: an
OSPF export policy is usually needed
• One exception is when using sham-links
• The type of LSAs can change
• Type-3 or Type-5
• Watch for configured LSDB size limit
• Standard practice in many networks

0 +--~~_P~-♦

CE1

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
13

Advertising VPN Routes Using OSPF

The default po licy for OSPF is not to add any external route to the link-st at e database, so MP-BG P routes will not be
advertised by default, and an export po licy will be typica lly needed. The type of LSAs used to advertise VPN routes t o CEs can
change according to the domain-id settings and the type of route (OSPF internal vs . OSPF external), and can be either a
Type-3 or a Type-5 .

One special case is the use of sham-links; in this case, the PEs will not re-distribute M P-BGP VPN routes into OSPF, but just
transport using sham-links OSPF LSAs generated by remote sites. When using sham-links, you cannot easily check which
routes you are advertis ing to the CE without examining in detail the link-state database . Still, you can check if the sham-link
is operating correctly with show ospf neighbor instance vpn.

LSDB Size Limit

When using OSPF as PE-CE protocol, it is generally considered good practice to configure a maximum link-state database
size, to prot ect the PE from configuration mistakes and wrong redistributions on the CEs. Exceeding this limit will cause OSPF
t o go down, and an error message to be logged.

Au g 1 13 : 29 : 43 mxA-1 PE- 1 :rp d[ 1 390 1 ] : RPD_ OSPF_ NBRDOWN : OSPF neighbo r 10 . 2 . 0 .1

(realm ospf-v2 ge-1/0/8 . 0 a r ea 0 . 0 . 0 . 0) stat e changed fr om Fu l l to Down due to
Ki llNb r (event reason: exceed ed database p r otect i on max i mum)

www .j uniper.net Troubleshooting Layer 3 VPNs • Chapter 8 - 13

Junos Layer 3 VPNs

OSPF as PE-CE Routing Protocol (3 of 3)

■ Checking advertised routes

user@PEl> show ospf database instance VPN-B advertising-router self
OSPF database , Area o.o.o.o
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *10 . 4 . 0 . 2 10 . 4 . 0 . 2 Ox80000002 215 Ox22 OxdOlf 36
I I
Summary *10 . 2 . 20 . 1 10 . 4 . 0 . 2 Ox80000001 182 Oxa2 Ox486 28
OSPF AS SCOPE l ink state database
Tvne ID Adv Rtr Seq Age Opt Cksum Len
Extern *10 . 2 . 0 . 0 10 . 4 . 0 . 2 Ox80000001 219 Oxa2 Oxe27c 36
Extern *10 . 2 . 0 . 255 10 . 4 . 0 . 2 Ox80000001 182 Oxa2 Oxf467 36

■ Examining LSAs in detail

user@PEl> show ospf database instance VPN-B lsa- id 10 . 2.0.255 detail
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *10 . 2 . 0 . 255 10 . 4 . 0 . 2 Ox80000001 692 Oxa2 Oxf467 36
mask 255 . 255 . 255 . 0
TopoJ.ogy cterauJ.t (ID 0)
Type : 2 , Metric: 0 , Fwd addr : 0 . 0 . 0 . 0 , Tag : 208 . 0 . 255 . 232

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Only

Checking Advertised Routes

When not using sham-links, you can verify your OSPF export policy by checking which self-generated LSAs are being
advertised to the CE. The slide shows an example where three addit ional prefixes are being advertised to the CE: two
externa l routes, and a summary LSA. The summary LSA and the two external LSAs reflect respectively OSPF-internal and
OSPF-external routes from remote CEs. Note that to get the details (e.g. metrics, prefix length) you will need to use the show
ospf database command with the modifier detail.

Chapter 8-14 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

RIP as PE-CE Routing Protocol

■ Useful commands
•show route advertising-protocol rip <local ip> instance
<vpn>
•show route receive-protocol rip <local ip> instance <vpn>
• RIP does not have the concept of "adjacency"
• Commands take the local interface address as argument
• The default policy is accept everything, advertise nothing
• Export policies are always needed

e +--~~---• e -, -~-~.~G
:.: . =.:.-;~-o-r:-"l~~.. . ;•:. ._-~
_--~----=-•-Ee~
CE1 PE CE2

C/2020 Juniper Networks, Inc .All R,ghlS Resenie<I.

Jon1per8us1ness Use Only

RIP as PE-CE Routing Protocol

RIP is still used as a PE-CE routing protocol, though rare. From the troubleshooting point of view, the most problematic aspect
of RIP is the fact that the protocol lacks a keepalive mechanism to verify the state of CEs.

RIP does not have the concept of "neighbor" or "adj acency", and because of this RIP-related commands are typical ly not very
intuitive. For example, the show rip neighbor instance <vpn>command takes as argument a local interface, not
a neighbor address as with other protocols.
•
user@ r outer> show rip neighbor instance VPN-B ge-1 /0/8 .0
Loca l Sou r ce Desti na t ion Send Receive In
Ne i g h bor State Address Address Mo d e Mode Met
-------- ----- ------- ----------- ---- ------- ---
ge-1/0/8 . 0 Up 10 . 2 . 0 . 2 224 . 0 . 0 . 9 mcast both 1
Note also that a neighbor in Up state just means your local end is up and RIP is running; but this does not tell you anything
about the state of the CE.

Finally, RIP by default advertises no route, so an export policy is always needed.

www .juniper.net Troubleshooting Layer 3 VPNs • Chapter 8 - 15

Junos Layer 3 VPNs

Agenda: Troubleshooting Layer 3 VPNs

■ Troubleshooting Overview
■ Verifying PE-CE Routing Protocols
➔ MPLS Transport and Label Distribution Protocols
■ MP-BGP

■ The Forwarding Plane

■ Troubleshooting MVPNs

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usiness Use Only
Jun1Per
.iETWOffKS
1s

MPLS Transport and Label Distribution Protocols

The slide highlights the topic we d iscuss next.

Chapter 8-1 6 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

MPLS Transport and Label Distribution Protocols

(1 of 2)
■ Layer 3 VPN forwarding requires LSPs between PEs
• Each PE's loopback address needs to be in inet.3
user@router> show r oute table inet.3

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

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

172 . 17 . 20 . 2/32 *[LDP/9) 03 : 55 : 48 , metric 1

> to 172 . 17 . 23 . 2 via ge - 1/0/5 . 0
172 . 17 . 20 . 3/32 *[LDP/9) 03 : 56 : 15 , metric 1
> to 172 . 17 . 23 . 6 via ge-1/0/6 . 0
172 . 17 . 20 . 4/32 *[ LDP/9] 03 : 55 : 48 , metric 1
> to 172 . 17 . 23 . 2 via ge-1/0/5 . 0 , Push 299824
172 . 17 . 20 . 5/32 *[ LDP/9] 03 : 56 : 14 , metric 1
> to 172 . 17 . 23 . 6 via ge-1/0/6 . 0 , Push 299808

• Using labeled-unicast routes to reach remote PEs can require resolve-vpn

• Other configuration options are also possible

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usiness Use Only

Layer 3 VPN Forwarding Requires LSPs Between PEs

MPLS Layer 3 VPNs requ ire a label-switched path to be established between PEs, or between the hub PE and spoke PEs in
hub-and-spoke configurations. On Junos routers, and easy way to check MPLS reachability is to look at the i n e t. 3 table,
the table of MPLS egress points, and verify that all remote PEs are present.

For destinations internal to the local AS, the LSPs between PE routers are usually created by the LDP or RSVP label
distribution protocol. Inter-domain applications instead typical ly use BGP labeled-unicast; in this case, the command
r e so l ve-vpn may be needed in order to get labeled-unicast routes installed also in inet.3 in addition to inet.O.
Using re so l ve-vpn is not the only way to install MPLS egress points in i ne t. 3 ad well as in i net . O. There are also
other possibilities, including changing the default Junos traffic engineering behavior by enabl ing t r a ffi c-e n g inee r i ng
mpl s- f o r wa rding at the [ edit protoco l s mpl s ] level. Still, the MP-BGP next-hops for i ne t -vpn routes need to
be reso lvable through an entry in i ne t. 3 . This makes checking this table a fundamenta l and useful troubleshooting step.

www .j uniper.net Troubleshooting Layer 3 VPNs • Chapter 8 - 17

Junos Layer 3 VPNs

MPLS Transport and Label Distribution Protocols

(2 of 2)
• Troubleshooting missing inet . 3 routes
• Troubleshooting commands are specific to the label distribution protocol used

• RSVP • LOP
• show rsvp interface •show ldp interface
•
• show rsvp session •show ldp neighbor
•
• show rsvp statistics •show ldp session
• show mpls lsp •show ldp statistics
• show ldp database

• Detailed RSVP and LOP troubleshooting are outside the scope of this
course

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
1a

Troubleshooting Missing inet . 3 Routes

Label-switched paths are established by label-distribution protocols (LDP and RSVP) or, for inter-domain applications, by
MP-BGP using labeled-unicast prefixes. On the s lide you can see some useful commands to check the correct operation of
both RSVP and LDP.

From troub leshooting the point of view, one advantage of RSVP is that it gives ingress routers fu ll visibility of the state of
LSPs, including errors along the path. With LDP it is easy to detect a LSP-down event, due to the missing route in inet . 3 .
However, f inding the root cause often means checking hop-by-hop from the ingress to the egress, until the fai lure is found .

Detailed RSVP and LDP troubleshooting is covered in other Juniper Education courses.

Chapter 8-18 • Troubleshooting Layer 3 VPNs www.ju n iper .net

 Junos Layer 3 VPNs

Agenda: Troubleshooting Layer 3 VPNs

■ Troubleshooting Overview
■ Verifying PE-CE Routing Protocols
■ MPLS Transport and Label Distribution Protocols

➔ MP-BGP
■ The Forwarding Plane
■ Troubleshooting MVPNs

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Onty
Jun1Per
~ETWORKS
19

MP-BGP
The slide highlights the topic we discuss next.

www .j uniper.net Troubleshooting Layer 3 VPNs • Chapter 8 - 19

Ju nos Layer 3 VPNs

Signaling Plane: MP-BGP (1 of 6)

■ Useful commands
show bgp summary
show bgp neighbor <neighbor>
show route table bgp.13vpn.O
show route receive-protocol bgp <neighbor>
show route advertising-protocol bgp <neighbor>

■ BGP next-hops need to be reachable using an LSP

• Routes will be marked hidden unless their next-hop can be resolved in the
inet . 3 table

C/2020 Juniper Networks, Inc .All Rights Reserlle<I.

Joniperausaness use Only
Jun1Per
.iETWORKS
20

MP-BGP: Useful Commands

Troubleshooting MP-BGP in a Layer 3 VPN environme nt is very s im ilar to ordinary BGP troub leshooting, and uses the same
BGP-related CLI commands . One point to keep in mind is that BGP next-hops need to be reachab le using an MPLS LSP in
order for a i ne t -vpn route to be usable.

Chapter 8-20 • Troubleshooting Layer 3 VPNs www.j uniper.net

 Junos Layer 3 VPNs

Signaling Plane: MP-BGP (2 of 6)

■ Reflectors and target communities

• Routes tagged with unknown targets are discarded, unless the router is a
route reflector
• show route receive-protocol bgp <neighbor> on a PE will not help in case of
target mismatch
• Route reflectors need to have MP-BGP next-hops in inet . 3
• Either establishing LSPs to remote PEs, or using a static 'dummy' route in inet . 3

~ - - -~ ..........
. . --8 ---..,. . . . .
Route Reflector ...........~ i-. _ _ _.,.
,~ --

'1, ~ MPLS Core Jiir ~

CE 1 PE1 J PE2 CE2

C2020 Juniper Networks, Inc .All R,ghlS Resenie<I.

Jon1per8us1ness Use Onty
Jun1Per
JIETWORKS
21

Reflectors and Target Communities

An MP-BGP speaker will discard inet-vpn routes tagged with unknown route-targets, unless the router is a route reflector.
Because of this, it is not possible to detect a target mismatch with the sho w r o ute rec eive-protocol bgp
command on a PE. Especia lly with complex VRF import and export policies, it is best to also check the remote side, using the
sho w r o u t e a dvert i sing-pro t ocol bgp command.
A second important point to consider is that a reflector wi ll not reflect hidden routes, which means the reflector needs to be
able to resolve inet-vpn BGP next-hops using label-switched paths. This means either establishing label-switched paths to all
PEs (even if those LSPs wi ll typically never be used for forwarding traffic) or - if the reflector is away from the forward ing path
- using a static "dummy" inet.3 route. Th is last option will also prevent a route from being dropped j ust because there is no
LSP from a PE to the reflector, even when there is full MPLS reachability between the PEs.

For examp le, to allow a reflector outside the MPLS domain to reflect VPN routes th is static entry could be added to the inet.3
table:

[ edi t r o ut i ng-opt i ons ]

use r @r oute- r e fl ector# sho w
r i b i net . 3 {
stat i c {
r oute <pr efi x-of-PEs-loopbacks> disca r d ;
}
}
• • •

The presence of a static route to MP-BGP next-hops is enough to al low the correct reflection of VPN routes.

www .j uniper.net Troubleshooting Layer 3 VPNs • Chapter 8 - 21

Junos Layer 3 VPNs

Signaling Plane: MP-BGP (3 of 6)

■ Checking IBGP peers

user@router> show bgp neighbor 172.17.20.2
Peer : 172 . 17 . 20 . 2+179 AS 65512 Local : 172 . 17 . 20 . 1+53888 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 : 172 . 17 . 20 . 1 Holdtime : 90 Preference : 170
Number of flaps : 0
Peer ID : 172 . 17 . 20 . 2 Local ID : 172 . 17 . 20 . 1 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
Restart flag received from the peer : Notification
• • •

ICan you spot any potential probl em? I

C2020 Juniper Networks, Inc .All R,ghlS Resenie<I.
Jon1per8us1ness Use Only

Checking IBGP Peers

The show bgp neighbo r command is the main command used to check the state of IBGP peers. Among other usefu l
information, this command will show the number of f laps since configuration and the reason of t he last flap.

On the slide, you can see a BGP neighbor in Established state. Apparently everything seems correct, but if you check the
add ress families advertised by each peer, you can see that the remote end (probably a route reflector) is advertising also
fami ly r o u te-ta r ge t, wh ile the loca l end only inet- u ni cast and inet-vp n - u ni cast. On a big setup, this means
that a large number of unnecessary updates can be sent from the reflecto r to the local ro uter, only to be discarded on
receipt.

Chapter 8-22 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Signaling Plane: MP-BGP (4 of 6)

• The bgp . 13vpn . O table
• Contains inet-vpn NLRls from remote PEs
• The format is route distinguisher:prefix
• Hidden routes typically are caused by no LSP to remote PEs
user@router> show route table bgp.13vpn.O !community target:65501:100 1

bgp . 13vpn . O: 10 destinations , 10 routes (10 active , 0 holddown , 0 hidden)

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

192 . 168 . 78 . 5 : 17 : 10 . 34 . 10 . 0/24

*[BGP/170] 10 : 16 : 32 , localpref 100 , from 192 . 168 . 78 . 5
AS path : I
> to 172 . 22 . 138 . 2 via ge-1/0/4 . 0 , label-switched-path to-Rl
192 . 168 . 78 . 5 : 17 : 10 . 34 . 11 . 0/24
*[BGP/170] 10 : 16 : 32 , localpref 100 , from 192 . 168 . 78 . 5
AS path : I
> to 172 . 22 . 138 . 2 via ge-1/0/4 . 0 , label-switched-path to-Rl
192 . 168 . 78 . 5 : 17 : 10 . 34 . 12 . 0/24

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per 8us1ness Use Onty

The bgp . 13vpn . 0 Table

The bgp . 13vpn. o table contains i net-vpn routes from remote PEs, regardless from the VPN they belong to. Whi le it is
not very common having to examine this table for troubleshooting purposes, any hidden route shows MPLS reachability
problems to advertising PEs.

One common misconception is that examining the bgp.13vpn.0 table can be used to detect policy problems, e.g. target
mismatch. Unfortunately this is not the case, as target mismatches will result in routes being dropped, not stored or hidden.
It is possible to override this behavior by configuring the keep-a ll keyword at the BGP neighbor level, but th is is typical ly
not recommended in any rea listic deployment due to its potential negative side effects (increased resource utilization).

www .juniper.net Troubleshooting Layer 3 VPNs • Chapter 8 - 23

Junos Layer 3 VPNs

Signaling Plane: MP-BGP (5 of 6)

■ Checking MP-BGP received routes

user@router> show route receive-protocol bgp 193.168.1.5

inet . 0 : 15 destinations , 15 routes (15 active , 0 hol ddown , 0 hidden)

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

vpnl . inet . O: 14 destinations , 14 routes (10 active , 0 holddown , 4 hidden)

Prefix Nexthop MED Lclpref AS path
* 10 . 0 . 33 . 0/24 193 . 168 . 1 . 5 100 I
* 10 . 0 . 34 . 0/24 193 . 168 . 1 . 5 2 100 I
* 193 . 168 . 1 . 7/32 193 . 168 . 1 . 5 1 100 I
* 193 . 168 . 1 . 13/32 193 . 168 . 1 . 5 100 I

bgp . 13vpn . O: 8 destinations , 8 routes (4 active , 0 holddown , 4 hidden)

Prefix Nexthop MED Lclpref AS path
193 . 168 . 1 . 5 : 32767 : 10 . 0 . 33 . 0/24
* 193 . 168 . 1 . 5 100 I
193 . 168 . 1 . 5 : 32767 : 10 . 0 . 34 . 0/24
. ..

ICan you spot the problem? I

C2020 Juniper Networks, Inc .All Rights ReseM!<I.
Jon1per 8us1ness Use Only

Checking MP-BG P Received Routes

The show route receiv e-pro toco l bgp will show any rece ived route, including i n et-vpn NLRI. Each prefix is
typically shown twice: once in the b gp . 13vpn. o table (in route-distingu isher:prefix format) and once (as a regular prefix) in
its VRF table, after passing the v r f- i mp o r t policy.

In the s lide, you can see a sample output showing four hidden routes; those should be investigated, as they usually indicate
MPLS reachability problem to one or several PEs

Chapter 8 - 24 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Signaling Plane: MP-BGP (6 of 6)

■ Troubleshooting hidden routes

lab@mxA- 1> show route receive- protocol bgp 193.168.1.S l hidden !

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

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

vpnl . inet . O: 14 destinations , 14 routes (10 active , 0 holddown , 14 hidden)!

Prefix Next hon MED Lcl pref AS path
10 . 0 . 22 . 0/24 193 . 168 . 1 . 4 100 I
10 . 0 . 23 . 0/24 193 . 168 . 1 . 4 2 100 I
193 . 168 . 1 . 6/32 193 . 168 . 1 . 4 1 100 I
.. ~93 . 168 . 1 . 12/32 193 . 168 . 1 . 4 \ 100 I

lab@mxA- 1> show route table inet.3 !193.168.1.4 !

lab@mxA-1>

C2020 Juniper Networl<s, Inc .All Rights ReseM!<I.

Jon1per8usiness Use Only

Troubleshooting Hidden Routes

To troubleshoot hidden routes, the first step is to check what their next-hops are. This can be done in several ways; the slide
shows how to display hidden routes next-hops with the show route receive-protocol bgp hidden command .
After th is, you can verify that the BGP next-hops are actually missing from the inet.3 table with show route table
inet. 3. Once the unreachable next-hops are identif ied, it is j ust a matter of troubleshooting the label-distribution protocol
that should have advertised them.

www .juniper.net Troubleshooting Layer 3 VPNs • Chapter 8 - 25

Junos Layer 3 VPNs

Agenda: Troubleshooting Layer 3 VPNs

■ Troubleshooting Overview
■ Verifying PE-CE Routing Protocols
■ MPLS Transport and Label Distribution Protocols

■ MP-BGP

➔ The Forwarding Plane

■ Troubleshooting MVPNs

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usiness Use Only
Jun1Per
~ETWORKS
2s

The Forwarding Plane

The slide highlights the topic we discuss next.

Chapter 8-26 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Layer 3 VPN: Forwarding (1 of 2)

■ Useful commands for Layer 3 VPN forwarding issues

• PE-CE communication
• ping and traceroute PE-to-CE (ping routing-instance) and CE-to-CE. Same as
normal unicast forwarding troubleshooting
• show arp on Ethernet
• MPLS forwarding plane
• ping mpls (ldp I rsvp)
• traceroute mpls (ldp I rsvp)
• ping mpls 13vpn VRF prefix x. x. x . x / y
is an extremely useful command
• traceroute CE-CE with ICMP tunneling can be misleading
( use with care)

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usinessUse Onty

Useful Commands for Layer 3 VPN Forwarding Issues

All forwarding troubleshooting typically involves sending some form of test traffic, and fo llowing it to detect problems. A
number of commands are avai lable for th is; which one to use depends on the specific problems, and on the components of
the path that needs to be tested.

To troubleshoot PE-CE commun ications, both the ping and the traceroute commands accept the
r o uting-instance modifier, and can be used in the same way as for ordinary IP forwarding troub leshooting. Similarly,
show arp can be used to verify IP-to-MAC resolution on Ethernet interfaces.
To troub leshoot the MPLS core, instead, you can use the ping mpls and traceroute mpls commands specific to your
label distribution protocol. In addition to these, you can also use the Layer 3 VPN specific command ping mpls 13vpn.

Finally, it is possible to enable i cmp-tu nne li ng to allow traceroute through the M PLS core from with in the VPN. It is
important to be aware of the limitations of th is functiona lity, as it can be very misleading. Specifically, if there is a forwarding
failure in the MPLS backbone anywhere between two PEs. traceroute originating from the CE will show a loss at the first hop,
regardless where the real problem is. This is because the TTL-expired ICMP messages need to be forwarded al l the way to the
remote PEs and then back. Any failure in the path will still be perceived as loss immediately after the local PE.

www .juniper.net Troubleshooting Layer 3 VPNs • Chapter 8 - 27

Junos Layer 3 VPNs

Layer 3 VPN: Forwarding (1 of 2)

• Detecting MTU bottlenecks with ping mpls
• Use the modifier s weep to find out the path MTU
user@ro uter> ping mpls 13vpn vpnl prefix 193.168.1.11/32 detail sweep
Request f or seq 1 , t o interface 385 , labels <16 , 299872> , packet size 96
Reply for seq 1 , return code : Egress-o k , time : 0 . 775 ms
Local transmit time : 2016-08-01 13 : 40 : 36 UTC 445 . 992 ms
Re mote receive time : 2016-08-01 13 : 40 : 36 UTC 446 . 767 ms
Request for seq 2 , to interface 385 , labels <16 , 299872> , packet size 5048
Timeout for seq 2
.. .
Reply for seq 13 , return code : Egress - ok , time : 1 . 198 ms
Local transmit time : 2016- 08 - 01 13 : 41 : 02 UTC 471 . 643 ms
Remote receive time : 2016- 08 - 01 13 : 41 : 02 UTC 472 . 841 ms
.. .
Request for seq 16, to interface 385 , labels <16 , 299872> , packet size 1492
Timeout for seq 16

--- lsp ping sweep result---

Maximum Transmission Unit (MTU) is 1488 bytes

C2020 Juniper Networl<s, Inc .All R,ghlS Resenie<I.

Jon1per8us1ness Use Only

Detecting MTU Bottlenecks with ping mpls

The ping mpls command can also be used to detect MTU bottleneck, wh ich can be especially problematic when they
affect a secondary path, bypass, or detour LSPs. In this case, everything seems to work correctly on the primary path, until
(for example a link failure) traffic is re-routed using the alternative, MTU-constrained path, triggering the problem.

This example shows a case where the core MTU of an Ethernet-based network was left as 1500 bytes. The ping mpls
command attempts to find the actual MTU by sending packets with different sizes, in an attempt to discover the larger
packet that can be sent on the MPLS path.

In th is example, the command reports a usable MTU of 1488, due to the 12 bytes being used for 3 labels (transport, VPN
and LDP tunneling/protection label).

Chapter 8-28 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Agenda: Troubleshooting Layer 3 VPNs

■ Troubleshooting Overview
■ Verifying PE-CE Routing Protocols
■ MPLS Transport and Label Distribution Protocols
■ MP-BGP

■ The Forwarding Plane

➔ Troubleshooting MVPNs

C/2020 Juniper Networks, Inc .All R,ghlS ReseM!<I.

Jon1per8us1ness Use Onty

Troubleshooting MVPNs
The slide highlights the topic we discuss next.

www .j uniper.net Troubleshoot ing Layer 3 VPNs • Chapter 8 - 29

Junos Layer 3 VPNs

The MVPN Signaling Plane (1 of 4)

■ The three components of the MVPN signaling plane

• The PIM customer domain
• MP-BGP family mvpn
• The inclusive and selective multicast service interfaces
• RSVP or LOP point-to-multipoint
• GRE tunnels (deprecated)

----------
'..'P-BGP fami ly n vpn""'",--.....

e : a --- e e
C-Multicast , ,.. .- ........ C-Multicast

PMSI ......

CE1 PE1 RSVP/LOP p2mp J PE2 CE2

...

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per 8usiness Use Only

The Three Components of MVPN Signaling Plane

MVPN troubleshooting has been left for last, as correct and stable unicast routing is a prerequ isite for it to work. In addition
to unicast routing, tro ubleshooting MVPNs may requ ire investigating three additional components:

1. The customer PIM domain

2. The MVPN BGP signaling

3. The inclusive (and selective, if used) provider multicast service interface

Th is last point is typically implemented with point-to-mu ltipoint LSPs (either with RSVP or LDP). The older, deprecated
draft-rosen version of MVPN used GRE tunne ls to multicast destinations as a multicast service interface, but t hese
architectures are typical ly plagued by several limitations and are today considered obsolete.

A natural way of approach ing tro ubleshooting MVPNs is to follow t his order, first verifying if the customer multicast domain is
working up until the PE, then checking if multicast state is correctly re layed by MP-BGP, and finally investigate the Provider
Multicast Service Interface, based on LDP or RSVP (next-generation MVPN) or PIM and GRE tunnels (the original, obsolete
draft-rosen). It is also worth mentioning that sometimes problems that appear at a first look to be forwarding issues are in
fact signaling issues in the PMSI. For example, a branch of a point-to-multipoint LSP flapping will result in intermittent packet
loss affecting on one or more PEs, but the actual root cause might be tied to RSVP, LDP or even the IGP.

Chapter 8-30 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

The MVPN Signaling Plane (2 of 4)

■ The customer multicast domain

• All usual PIM commands accept the instance keyword
•
• show p1.m interface
• • •
• show p1.m J 01.n
•
• show p1.m source
•
• show p1.m statistics
• Troubleshoot as regular PIM until the PE
• Then , check if PIM state is translated in the equivalent BGP signaling
• show mvpn c-mul ticast instance-name <vpn> shows additional details,
including the PMSI servicing a given multicast stream

C2020 Juniper Networks, Inc . All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
31

The Customer Multicast Domain

Troubleshooting the customer multicast domain is no d ifferent from troubleshooting PIM outside of VPNs: all operationa l
mode PIM-related commands accept the modifier i n stan ce <vpn>. The actual troub leshooting steps are driven by the
actual prob lem: for example, if no CE can rece ive traffic from a given source it is natural t o start with checking source
registration, whi le if a receiver cannot rece ive any source but every other CE can, it is probably useful t o start checking IGMP,
then move on to checking the RP tree.

In addit ion to PIM-related commands, the show mvpn c-mu l t i cast i ns t a n ce- n ame <vp n> can be used to check
customer multicast state on the PE. The use of th is command will be illustrated in the next slide.

www .j uniper.net Troubleshooting Layer 3 VPNs • Chapter 8 - 31

Junos Layer 3 VPNs

The MVPN Signaling Plane (3 of 4)

■ Checking c-multicast state

user@router> show mvpn c - multicast instance- name VPN- A e xtensive

MVPN instance :
Legend for provider tunnel
S- Selective provider tunnel
F- Flood NH forwarding NH
M- Multicast Composite NH
C- Cloned NH

Legend for c-multicast routes properties (Pr)

OS -- derived from (*, c - g) RM -- remote VPN route
Family : !NET

Instance : VPN-A
MVPN Mode : SPT - ONLY
MVPN Forwarding Entry uses hierarchical nexthop : No
MVPN Forwarding Entry share tunnel nexthop : Yes
C-mcast IPv4 r s : Gl Provider Tunne l St FwdNh
0 . 0 . 0 . 0/0 : 224 . 7 . 7 . 1/32 Primary unbound
10 . 0 . 101 . 2/32 : 224 . 7 . 7 . 1/32 RSVP- TE P2MP : 10 . 210 . 14 . l , 10441 , 10 . 210 . 14 . l M- OxO

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only

Checking c-multicast State

The show mvpn c-mul ti cast i ns t a n ce- name <vpn> can be used to check the Provider Multicast Service Interface
used by a given multicast stream. The example shows a MVPN running in SPT-on ly mode. The multicast distribution for
source 10.0 .101.2 sending to group 224. 7 .7 .1 is handled via a point-to-multipoint RSVP LSP, whi le the line immediately
above shows a join-to-RP ( * , g) state for group 224. 7. 7 .1. This command can be especially useful whi le using selective
provider tunnels, to f ind out the mapping between (source,group) pairs and PMSls.

Chapter 8-32 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

The MVPN Signaling Plane (4 of 4)

■ The BGP MVPN signaling plane

Type
1 1-PMSI Autodiscovery Sent by every PE
2 Inter-AS 1-PMSI AD Route Used for interdomain multicast
-
3 S-PMSI AD Route Sent by the root PE when creating a S-PMSI
-
4 S-PMSI leaf AD Route Sent by receiver PEs, to join a S-PMSI
-
5 Source Active AD Route Propagated information on active sources
-
6 Shared tree join route Equivalent to pimjoin( * ,g)
7 Source tree join route Equivalent to pim join(s,g)

■ Decoding show route table <vpn>.mvpn. 0 output requires

knowledge of the encoding of each route type
C/2020 Juniper Networks, Inc .All Rights ReseM!<I.
Jon1per8usiness Use Only

The BGP MVPN Signaling Plane

The second component of the MVPN signa ling plane is MP-BGP with f ami l y mvpn sign al ing . Th is address fami ly
includes seven different route types, each with different encod ing. In order to troubleshoot MVPN, it is important to be able
to decode and understand the role of each route type .

An initial check might involve verifying if every PE is advertising a type-1 route (1-PMSI autodiscovery). Types 5, 6 and 7 are a
translation of (respectively) PIM register source, j o in-to-RP and join-to-source messages. When running MVPN in SPT-only
mode, checking for type-5 routes is a good way to verify quickly if a PE has knowledge of sources registered elsewhere, while
types 6 and 7 are useful when following PIM state from the receiving CE towards the source CE (for type 7) or towards the RP
(for type 6 ). Finally, type 3 and 4 are useful for checking selective PMSls; a type-3 route should be advertised by each PE
which wants to set up a selective tree, and interested receiving PEs should 'answer' with a type-4 route in order to be
included in the multicast distribution tree .

For more information of the encodings and functions of the different MVPN route types, please see the document "NG-MVPN
route types and encodings " ava ilable on the Juniper Networks Knowledge Base with document-id TN-115.

www .juniper.net Troubleshooting Layer 3 VPNs • Chapter 8 - 33

Ju nos Layer 3 VPNs

The MVPN Forwarding Plane

■ Verifying multicast forwarding

user@router> show multicast route instance VPN-A extensive
Instance : VPN- A Family : INET

Group : 224 . 7 . 7 . 1
Source : 10 . 0 . 101 . 2/32
Upstream interface : lsi . 33554432
Downstream interface list :
ge-1/0/9 . 200
Number of outgoing interfaces : 1
Session descrintion : Unknown
Statistics : 138 kBps , 262 pps , 998294 packets
Next- hop ID : 1048579
Upstream protocol : MVPN
Route state : Active
Forwarding state : Forwarding
Cache lifetime/timeout : forever
Wrong incoming interface notifications : 0
Uptime : 01 : 03 : 27

I nstance : vpnl Family : INET6

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8usiness Use Onty

The MVPN Forwarding Plane

The mai n command to use f or troubleshooting the MVPN forwarding plane is show multicast route instance
<VPN> extensive.This not only shows the forwa rding state in terms of installed multicast rout es, but also provides traffic
count ers wh ich show how much multicast traffic is being forwarded. Very often troub leshooting multicast forwarding means
t o go from router t o router checking the traffic counters tied to a specific multicast (source, group) pair; having traffic
count ers makes this easy and non-disruptive, as it ca n be done without changing t he co nfiguration or enabling traceoptions.

The command also shows the number of packets discarded due to Reverse Path Forwarding Check Fai lure, in the line titled
''Wr ong i ncomi ng i nter f ace no t i fi cati o n".

Chapter 8 - 34 • Troubleshooting Layer 3 VPNs www.j uniper.net

 Junos Layer 3 VPNs

Summary

■ In th is content, we:
• Used a structured approach to troubleshoot Layer 3 VPNs
• Became familiar with commands and tools to check both the signaling and the
forwarding plane
• Troubleshot MVPNs

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Joniper8us1ness Use Onty
Jun1Per
.iETWOffKS
35

We Discussed:
• Using a structured approach to troubleshoot Layer 3 VPN issues;

• Usef ul commands and tools to check both the signaling and the forwarding plane; and

• Troubleshooting MVPN issues.

www .juniper.net Troubleshooting Layer 3 VPNs • Chapter 8 - 35

Junos Layer 3 VPNs

Review Questions

1. Which routing protocols used between PE and CE need an export

policy to advertise VPN routes?
2. Which command can be used to detect address family mismatch on
a BGP session?
3. What could be the cause of hidden routes in the bgp . 13vpn . o
table?

~ 2020 Juniper Networlcs, Inc . All Rights Reserve<!.

Juniper Business Use Onty
Jun1Per
~ETWORl(S
36

Review Questions
1.

2.

3.

Chapter 8-36 • Troubleshooting Layer 3 VPNs www.juniper.net

 Junos Layer 3 VPNs

Lab: Troubleshooting Layer 3 VPNs

■ Troubleshoot a simple Layer 3 VPN scenario.

C2020 Jun,perNetworl<s, Inc .All Rights ReseM!<I.

Jo niper8us1ness Use Only
Jun1Per
~ETWOffKS
37

Lab: Troubleshooting Layer 3 VPNs

The slide provides the objectives for th is lab.

www .j uniper.net Troubleshooting Layer 3 VPNs • Chapter 8 - 37

Junos Layer 3 VPNs

Answers to Review Questions

1.
An export policy is always needed with RIP, and are needed for OSPF when not using a sham-l ink.

2.
The show bgp neighbor command will display the address f amily configured on both the local and the remote end of
the BGP session.

3.
The typical cause of hidden routes in the bgp.13vpn.O table is the lack of a LSP to the advertising PE.

Chapter 8-38 • Troubleshooting Layer 3 VPNs www.juniper.net

 un1Pe[
NETWORKS
Education Services

Junos Layer 3 VPNs

Chapter 9: Multicast Review and Draft Rosen

Engineering Simplicity
Junos Layer 3 VPNs

Objectives

■ After successfully completing this content, you will be able to:

• Describe IP multicast traffic flow
• Identify the components of IP multicast
• Explain how multicast addressing works
• Describe the need for the RPF check in multicast networks
• Explain the role of IGMP
• Explain Draft Rosen and some of its drawbacks

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Jo niper8us1ness Use Only
Jun1Per
.iETWOffKS
2

We Will Discuss:
• IP multicast traffic flow;

• Components of IP multicast;

• How multicast addressing works;

• The need f or RPF check in multicast networks;

• The role of IGMP; and

• Draft-rosen multicast and some of the drawbacks.

Chapter 9-2 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Agenda: Multicast Review and Draft Rosen

➔ Multicast Overview
■ Reverse Path Forwarding
■ Internet Group Management Protocol
■ Draft Rosen Overview
■ Draft Rosen Limitations

C2020 Jun,perNetworl<s, Inc .All Rights Reserlle<I.

Joniper8us1ness Use Onty
Jun1Per
.iETWOffKS
3

Multicast VPN Overview

The slide lists the topics we will discuss. We will discuss the highlighted topic first.

www .juniper.net Multicast Review and Draft Rosen • Chapter 9-3

Junos Layer 3 VPNs

Address Types and Traffic Flows

■ Address types
• Unicast addresses: one-to-one
• Broadcast addresses: one-to-all
• Multicast addresses: one-to-many

Multicast: A single data stream from the server is needed to reach all clients

Single Data
.,_--. Strl m.---..c-- Network

-----
Server
Clients

Network devices replicate data stream toward

interested clients

C/ 2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per 8us1ness Use Only

Address Types
In IP networking three types of addressing are typ ically used for the communication between hosts:

• Unicast addressing: Unicast addresses are used when a host wants to send traffic to another specific host.
Each host requ ires its own unique IP address for this type of traffic.

• Broadcast addressing: Broadcast addresses are used when a host wants to send traffic to all hosts on a given
subnet. Each subnet has its own broadcast IP address. Traffic to the broadcast address is typica lly not
forwa rded by the router. Some types of broadcast traffic (for example, DHCP) might need to be forwarded to
other parts of the network.

• Multicast addressing: Multicast addresses are used when a host wants to communicate with a group of hosts
that are interested in t hat specific traffic. Different types of multicast applications exist, such as where one host
sends traffic to many interested receivers (one to many), and other applications that send traffic between all
the interested hosts (many to many).

A more recent type of addressing that is used in IP networking is the anycast address. The concept of anycast addressing is
that a group of receivers a ll share the same address. When traffic m ust be delivered to the anycast address, it is delivered to
the nearest member of the group. An example of where anycast addressing is used is Domain Name System (DNS) anycast.
In mu lticast it is also used in a featu re called anycast RP. An advantage of anycast addressing is that it provides a very fast
convergence in case one of the members of the group disappears.

Chapter 9 - 4 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Multicast Components (1 of 2)

■ Components:
• Source: Originator of multicast IP packets
• Multicast IP packet: An IP packet destined for a multicast group address
• Group address: An IP address in the range of 224/4
• Receivers: IP hosts interested in receiving data destined for a particular group
address (also called group members)
• DR: Router closest to the source that forwards multicast
IP packets

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8usiness Use Only

Multicast Components: Part 1

The slide describes some of the common terms used in multicast:

• Source: A multicast source is any device that originates multicast IP packets.

• Multicast IP packet: A multicast packet is any IP packet that is destined to a multicast group address. The same
packet should have a unicast source address. Generally, a multicast packet uses UDP, the Real-Time Transport
Protocol (RTP), or both as its transport protocols. No gua rantees exist t hat packets will be received by all
members of a group. One protocol, the Pragmatic General Multicast (PGM) protocol, has been developed to add
loss detection and retransmission capabilities to multicast.

• Group address : A multicast group address is an IP address in the range of 224/ 4 .

• Receivers: A multicast receiver is any host that is interested in receiving multicast packets. A receive r uses
IGMP to inform the directly connected router of its desire to receive multicast packets.

• Designated router (DR) : The DR is the router closest to the source that forwards multicast packets into the
network. If two or more routers are attached to the source, only one ever becomes the DR based on an election
algorithm t hat depends on the multicast ro uting protocol in use.

www .juniper.net Multicast Review and Draft Rosen • Chapter 9-5

Junos Layer 3 VPNs

Multicast Components (2 of 2)
Group
Network Membership
Protocol
._/
Source Multicast Routing Receivers
---:i....... Protocol
No special protocol
needed

■ Components (contd.):
• Group membership protocol: Protocol used by receivers to communicate
group membership to the closest attached router
• IGMP for 1Pv4
• Multicast routing protocol: Protocol used between routers in the network to
build and maintain the multicast forwarding trees between sources and
•
receivers
• PIM and DVMRP
C/ 2020 Juniper Networks, Inc .All Rights Resenie<I.
Jon1per 8us1ness Use Onty

Multicast Components: Part 2

The following list continues the list of the common terms used in multicast from the previous page:

• Group membership protocol: Receivers use a group membership protocol to inform the directly connected
router of their interest in receiving packets for one or more multicast group addresses. That is, the host receiver
is informing the router of its desire to become a member of a multicast group. IGMP is used by IP version 4
(1Pv4) hosts and routers for this purpose. Th is materia l focuses on 1Pv4 multicast.

• Multicast routing protocol: A multicast routing protocol is used between routers to build and maintain the
multicast forwarding trees between source and receiver. The fo llowing slides describe the basic functionality of
a multicast routi ng protocol. The two most common multicast routing protocols are Protocol Independent.

Chapter 9-6 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Multicast Terminology (1 of 4)
■ Service models:
• Any-source multicast:
• Supports one-to-many and many-to-many applications
• Source-specific multicast:
• Supports only one-to-many applications

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8usinessUse Only

Service Models
We use t he following terminology for multicast service models:

• Any-source multicast (ASM ): This delivery model was designed into the origina l specifications for multicast in
RFC 1 1 12. The model supports both one-to-many applications like Internet Protocol Television (IPTV), as well as
many-to-many applications like white boarding or video conferencing. ASM gets its name from receivers being
able to j oin a group without specifying from wh ich so urce they want to receive traffic, so they accept it from any
source.

• Sou rce-specific multicast (SSM): In SSM, the rece iver specifies the sources from which it wants to rece ive the
traffic. It can also specify from which sou rces it does not want to receive traffic. So for SSM to work, the source
information must be known . SSM makes deployment of multicast less complex and also makes allocating
mult icast addresses easier.

www .j uniper.net Multicast Review and Draft Rosen • Chapter 9- 7

Junos Layer 3 VPNs

Multicast Terminology (2 of 4)
■ Distribution modes:
• Dense mode:
• Flood and prune
• Prune signals no interest in receiving multicast traffic
• Graft overrides previous prune messages
• Sparse mode:
• Explicit subscriptions only
• Join message signals interest in receiving multicast traffic (subscribe)
• Prune sent to unsubscribe from multicast traffic
• Sparse-dense mode:
• Router interface performs either mode for individual multicast groups
• Uses dense-mode and sparse-mode rules

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Onty

Distribution Modes
We use t he following terminology for multicast distribution modes:

• Dense mode: In dense mode, traffic is forwa rded to all parts of the network (wh ich is known as flooding). The
parts of the network that are not interested in receiving the traffic send prune messages to thei r neighboring
routers asking them to stop forwarding traffic. In case a receive r subscribes after sending the prune, the router
sends a graft message asking for the traffic to be forwa rded again.
• Sparse mode: In sparse mode, traffic is forwarded only into parts of the network with interested receive rs. The
routers send j oin messages to indicate their wi llingness to receive traffic. If a receive r is no longer interested,
the ro uter sends prune messages to the neighbor asking it to stop forwarding the t raffic.

• Sparse-dense mode: Sparse-dense mode allows the router interface to operate on a per-group basis in either
sparse or dense mode. A group specified as dense is not mapped to an RP. Instead, data packets destined for
that group are forwarded by means of PIM dense-mode rules. A group specified as sparse is mapped to an RP,
and data packets are forwarded by means of PIM sparse-mode rules.

Chapter 9-8 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Multicast Terminology (3 of 4)

■ Distribution trees:
• Source tree or shortest-path tree
• Known source
• S, G forwarding state
• Used in dense mode and in sparse mode
• Shared tree or rendezvous point tree
• Unknown source
• *, G forwarding state
• Used only in sparse mode

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Only

Distribution Trees
We use the following terminology for multicast distribution trees:

• Source tree or shortest-path tree (SPn: A source tree is the forwarding path for the traffic from a specific source
all the way up to the router that is closest to the receiver. A source tree is the shortest path between source and
receiver and can on ly be used when the router next to the receiver knows about the source. The routers keep
the forwarding path from the receiver to the source in the follow ing state: S, G (S comma G) . S indicates source
address and G indicates group address. In dense mode a source tree is always used. In sparse mode a source
tree is used after the receiver router learns about the source.

• Shared tree or rendezvous point tree : If the source is not known, a source tree cannot yet be built. In the ASM
model, the receivers subscribe to a group address using IGMP. In the subscription request, they do not indicate
the source. The routers must build a tree toward an unknown source. The solution to this problem is to have a
meeting point for sources and receivers in the network. This meeting point is called a rendezvous point (RP).
The tree built from the receiver to the RP in the network is called a shared tree (because it is shared by all
receivers) . The routers keep the forwarding path from the receiver router to the RP in the following state: * ,G (*
comma G). The* indicates any source and the G indicates the group address.

www.juniper.net Multicast Review and Draft Rosen • Chapter 9 - 9

Junos Layer 3 VPNs

Multicast Terminology (4 of 4)

■ Multicast forwarding:
• Source is considered upstream (root of tree)
• Receiver is considered downstream (leaf on branch of tree)

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Only

Multicast Forwarding
In multicast forward ing, the path between source and receiver is called a tree. The source is the root of the tree. The tree
branches out into the network, and at the end of the branches are the receivers (or leaves). The source is considered
upstream and the receivers are downstream. Branches of the tree are created when receivers join, and are torn down when
receivers leave. In the case of a shared tree, the RP is considered upstream and the root of the tree .

Chapter 9-10 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Source Tree and Shared Tree in PIM Sparse Mode

Source
192.168.100.10

I
I
I
"- I RP
I
I 10.1.1.1

R3 R4
Source Tree
{S, G) State ~
Group: 224.7.7.7 Shared RPT Tree
Source: 192.168.100.10 f (
I (*,G) State
,..I I
I • Group: 224.7.7.7
•
'
♦ Source: *

Q Receiver
224.7 .7.7
---►

C2020 Juniper Networks, Inc . All Rights ReseM!<I.

Jon1per aus1ness use Only

Source Tree and Shared Tree in PIM Sparse Mode

In PIM sparse mode, the distribution trees have the following characteristics:

• Source Tree: The source tree, or shortest-path tree, bu ilds the forwarding path from source directly toward the
receiver. The forwarding state kept in the routers between source and receiver uses the S,G notation.

In dense mode, the shortest-path tree is always used between the source and any router in the network during
the f looding process. Any part of the network that does not have receivers prunes the distribution tree. The
resu lt is a source tree with branches to the parts of the network that actually have receivers.

To join a shortest-path tree in sparse mode, S,G join mes.s ages are exchanged . In case a rece iver is no longer
interested in receiving traffic from the source, S,G prune messages are sent by the router closest to the
'
receiver.

• Shared Tree : The shared tree is used if the source address is not known . In that case the only option is to
enable the forward ing state up to the RP. The forwarding state toward the rendezvous point uses the * ,G
notation.

Once the source starts sending traffic, the router closest to the source sends the traffic to the RP, and from
there it can be sent to the receiver. All routers in the network must agree on which router is the RP, so source
and receivers can be connected in the network.

The advantage of using shared trees is that they typically generate less state information in the network,
because it is not necessary to create a unique source tree for each session in the network. The disadvantage is
that the path between source and receiver across a shared tree is often not optima l. This issue is especially
important for delay-sensitive traffic.

www .juniper.net Multicast Review and Draft Rosen • Chapter 9 - 11

Junos Layer 3 VPNs

Agenda: Multicast Review and Draft Rosen

• Multicast Overview
➔ Reverse Path Forwarding
• Internet Group Management Protocol
• Draft Rosen Overview
• Draft Rosen Limitations

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usinessUse Only
Jun1Per
.iETWORKS
12

Reverse Path Forwarding

The slide highlights the topic we discuss next.

Chapter 9-12 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Multicast Forwarding Overview

■ Multicast forwarding overview:

• Unicast forwarding bases decisions on destination
IP address
• Forwards traffic to the next hop of the best route
• Multicast forwarding bases decisions on source IP address
• Forwards traffic away from the source along the distribution tree
• Forwards only traffic that passes RPF check
• RPF:
• Prevents looped and duplicated multicast packets
• Compares incoming interface of multicast packet with outgoing next-hop interface of
unicast route toward the source of the packet
- If interfaces are the same, the packet passes the RPF check
- If interfaces are different, the packet fails the RFP check

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Onty

Multicast Forwarding
When forwarding unicast traffic, the router is primarily concerned with the destination address. The goal of unicast
forwarding is to send the packet in the direction of the destination. A route lookup is performed to find the best route toward
the destination, and the packet is sent in that direction. Multicast forwarding is not initially concerned about the destination
address of a multicast packet.

Multicast forwarding bases its decisions primarily on the source address of the incoming packet. The goals of multicast
forwarding are to make sure traffic sent toward the receivers does not loop in the network and also to avoid packet
duplication. To make sure no loops or duplicated packets exist, multicast routing sends only a single packet down each
branch of the distribution tree .
To determine which incoming packets are sent down the distribution tree, multicast forwarding uses the reverse path
forwarding (RPF) check. The RP F mechanism basically selects packets to forward down the distribution tree only if the
packet was rece ived on the interface that is nearest to the source.

The RPF check looks into the routing table to determine the best route back to the source. The next-hop interface of that
route must be the incoming interface of the multicast packet. If the interfaces match, the packet pas.s es the RPF check and
can be forwarded down the tree. If the incoming interface does not match the route back to the source, the RPF check fa ils
and the packet is d iscarded.

www .juniper.net Multicast Review and Draft Rosen • Chapter 9 - 13

Junos Layer 3 VPNs

The RPF Check (1 of 2)

RPFTableat R1
user@Rl> show multicast rpf 192.168.100.10 Source 1
Multicast RPF table : inet . O , 16 entries 192.168.100.10
I
192 . 168 . 100 . 0/24 I
Protocol : OSPF
Interface : ge - 0/0/4 . 125
Neighbor: 172 . 18 . 1 . 1

172.18.1.1
·--.------·
••••••••••••••••••••••••••••••••
•
••
• •
•
••

ge-0/0/4.125

R1
Packet from Source 1 arrives on wrong interface: : •• ■ •••••• , -

RPF check fa ils. discard the packet! ••

Multicast Traffic
•••••••••••• ♦

I
C/2020 Juniper Networks, Inc .All Rights ReseM!<I.
Jon1per8us1ness Use Onty

The RPF Check: Part 1

In the example on the slide, a packet arrives at R1's interface ge-0/0/ 1 .0 from Source 1 . R1 checks the existing unicast
routing table and determ ines that this interface is not on the reverse path back to the source. Thus, the packet is discarded.

Chapter 9-1 4 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

The RPF Check (2 of 2)

RPFTab le at R1
Source 1
user@Rl> show multicast rpf 192.168.100.10 ..J
Multicast RPF table : inet . 0 , 16 entries 192.168.100.10
I

192 . 168 . 100 . 0/24 J

Protocol : OSPF :.JL.:
Interface : ge - 0/0/4 . 125
Neighbor : 172 . 18 . 1 . 1
~r:
172.18.1.1
·--------·
••••••••••••••••••••••••••••••••
•
•
•
• •
•
•
•

ge-0/0/4.1
◄· ..........
♦
♦

R1 ♦
••
•
Packet f rom Source 1 arrives on correct interface: ♦

forward out all outgoing interfaces.

♦
••
• •
:·········1
. .
♦
•• •
•• •
♦
•
••
Multicast Traffle
•••••••••••••

C/2020 Juniper Networks, Inc .All Rights Reserlle<I.

Jon1per 8us1ness Use Only

The RPF Check: Part 2

In th is example, R1 receives a packet from Source 1 on its ge-0/ 0/ 4 .125 interface and, once again, performs an RPF check.
R1 determines that the packet is coming in on an interface that is on t he reverse path back to the source. Thus, the RPF
check succeeds, and t he packet is forwarded to all int erfaces on the outgoing interface list. Initially, all interfaces other than
ge-0/ 0/ 4 .125 will be on the outgoing interface list.

www .j uniper.net Multicast Review and Draft Rosen • Chapter 9 - 15

Junos Layer 3 VPNs

Multicast Forwarding Terms

■ Multicast forwarding terms:
• Incoming interface or upstream interface
• Interface on which traffic is received that passes the RPF check
• Interface on which PIM join messages are sent
• Traffic that passes the RPF check can be forwarded
• If receiving router has knowledge of downstream receivers, the router receives IGMP
reports from directly connected receivers and also receives PIM join messages from
neighbors with downstream receivers
• Outgoing interface list or downstream interfaces
• Interfaces to which traffic must be forwarded down the distribution tree
• Forwarding decision is cached in the inet . 1 table

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per 8us1ness Use Only
Jun1Per
.iETWORKS
16

Multicast Forwarding Terminology

The RPF check mechanism is essential in multicast routing. It is used in both the forwarding plane as well as in the control
plane:

• Forwarding plane: A successful RPF check allows traffic from an incoming interface to be forwarded down the
distribution tree. The incoming interface is considered the upstream interface because the source is upstream.
The receivers are downstream on the tree so the interfaces to which the traffic can be forwarded are called
downstream interfaces. The group of interfaces with downstream receive rs is ca lled the outgoing interface list
(OIL). The result of a successful RPF check is cached in table i ne t. 1.

• Control plane: The RPF check is also used in the control plane. If a router must receive traffic because of
downstream receivers, it signa ls only to upstream routers on the interface that would pass the RPF check.
Therefore, join and prune messages are on ly exchanged with neighboring routers on the interface to the
upstream router nearest to the source. The receipt of IGMP or PIM join mes.sages moves those interfaces to the
OIL, so packets are forwarded to these interfaces toward the receivers.

Chapter 9-16 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Multicast Routing Tables

■ Multicast routing tables:

• i net . 0
• Default table used for RPF check lookups
• i net . 1
• Forwarding cache for successful RPF-checked traffic
• inet . 2
• Alternate table for RPF check lookups
• Multicast topology independent from unicast topology
• Use of RIB groups required

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8usinessUse Only

Route Tables for Multicast Routing

Multicast forwarding uses multiple route tab les related to the RPF check process:

• inet . o: The default table used by the RPF check process is the same as the unicast forward ing table. Thus,
the unicast topology and multicast topology are identical.

• inet . 1 : The results of successful RPF checks for forwardi ng traffic are cached in a separate i ne t. 1 table.
• inet . 2: If you must have a separate topology for multicast forwa rding, you can achieve this sepa rate topology
by changing the table the RPF check uses. Therefore, instead of looking in the default i net . o tab le, the RPF
check ca n be directed to look in i net . 2. The inet . 2 table must be fi lled with routing information to build the
alternate topo logy used by t he RPF check:

Routing protocols like multiprotocol BGP (M-BGP) and multi-topology IS-IS ca n place routes into ine t. 2
directly; or

Other protocols must use routing information base (RIB) groups to place routes into i ne t. 2 .

To direct the multicast routing protocols to use inet . 2 for t he RPF check, RIB groups are requ ired .

www.j uniper.net Multicast Review and Draft Rosen • Chapter 9 - 17

Junos Layer 3 VPNs

Alternate Multicast Topology (M-BGP)

Multicast Preferred
inet . 0 M ED= 100
ine t . 2 MED= 50
---------- , RPF

RPF

Unicast Preferred
i net . 0 MED= 50
AS 65011 AS 65013
inet . 2 MED = 100

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usinessUse Onty

Alternate Multicast Topology

The slide shows the use of MP-BGP to create two separate topologies. The two separate topologies allow a form of
load-sharing across links between unicast traffic and m ulticast traffic. On the slide, routes for t he same prefixes are
exchanged twice, once for unicast routing (i net . O) and once fo r multicast routing (i ne t. 2).

When AS 65013 sends unicast t raffic toward AS 65011, it prefers the bottom link. For the multicast traffic coming from AS
65011, the RPF check prefers the top link. If the multicast and unicast topo logies had been identical, the mu lticast RPF
check would have also preferred the bottom link.

Chapter 9-18 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Agenda: Multicast Review and Draft Rosen

■ Multicast Overview
■ Reverse Path Forwarding
➔ Internet Group Management Protocol
■ Draft Rosen Overview

■ Draft Rosen Limitations

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usiness Use Only
Jun1Per
.iETWOffKS
19

Internet Group Management Protocol

The slide highlights the topic we d iscuss next.

www .j uniper.net Multicast Review and Draft Rosen • Chapter 9 - 19

Junos Layer 3 VPNs

Multicast Groups and Routing

+- - - -+ Group Membership Protocol
Multicast Routin Protocol

Q Q[___II_I
---+

t t
I I
I I

Q I
-• ♦ - -4
I
I
Q
I

r:J T
I i

■ IGMP operates between receivers (hosts) and routers

• IGMP is not a routing protocol
C/2020 Juniper Networks, Inc .All R,ghlS ReseM!<I.
Jon1per8usiness Use Onty
Jun1Per
.iETWOffKS
20

Group Membership Protocols Versus Multicast Routing Protocols

Multicast routing protocols work in conjunction with IGMP. IGMP allows hosts to join and leave multicast groups; multicast
routing protocols allow multicast traffic to flow between networks. Common multicast routing protocols are DVMRP and PIM.

Normally, you do not have to run IGMP between routers because routers normally do not join multicast groups.

Chapter 9-20 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

IGMP Operation: Join Process

■ Report messages establish host membership for particular multicast

groups on a given network
• Reports are sent to the group address being reported
• Reports inform local router that a host wants to receive traffic associated with
the specified multicast group
Host 1

o ~---- Report:
OA=224.10.1.1
Group=224.10.1. 1

Querier Non-Querier

C2020 Juniper Networl<s, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only

IGMP Join Process

IGM P hosts interested in receiving traffic send an IGMP report message to the router. The destination address of the report
message is the multicast address of the requested group. After joining a group, the host now also must respond to the
router's IGMP query message to indicate that it is still interested in receiving traffic for that group. When the host wants to
receive traffic for a given group, it must also start listening for the corresponding MAC address.

The routers on the segment cache the IGMP report information to keep track of the receivers on that segment per multicast
group address.

www .juniper.net Multicast Review and Draft Rosen • Chapter 9 - 21

Junos Layer 3 VPNs

IGMP Query-Response Process

• Query-response process:
1. Querier router sends general query to all-hosts multicast group (224.0.0.1)
2. Host 2 sends its report for group 224.10.1.1 first
3. Host 1 hears the response from Host 2 and suppresses its report
4. Host 3 sends its report for the group 224.20.1.1

Host 1 Host 2 Host 3

Report
224.10.1.1
Suppressed
0 Report
224.10.1.1
Report
224.20.1.1

General
G) Query

Router A: :.JL.: Router B:

Querier ~r: Non-Querier

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per 8us1ness Use Only

IGMP Query-Response Process

For a given group, the multicast router puts an interface in its outgoing interface list if it received an IGMP report message
from at least one host. Thus, if more hosts are on a segment that is interested in receiving the same group traffic, the router
still only forwards one time.

The router must keep track of the receivers to make sure at least one receiver remains on any of the outgoing interfaces
because it is wasting resources if it is forwarding traffic to interfaces without downstream receivers. To check if the receivers
are still interested, the router sends periodic IGMP query messages asking if interested receivers still exist. The IGMP query
message is sent to 224 .0.0.1 (all systems). The goal of the query mes.sage is to receive a sol icited report message back from
at least one receiver per group. Therefore, it is not useful if more than one receiver responds per group as the router only
needs one to keep the interface in the outgoing interface list.

To avoid dupl icate answers to the query message, the response from the receivers is controlled by a randomized timer
mechanism. Each host waits a random time before sending a report message as an answer. In case another receiver in your
group has already answered (shorter timer), the other receivers in that group suppress their responses. Th is mechanism
results in one report answer per group to the query message from the router.

If more than one router exists on a given segment, the routers elect one active querier router. Each router starts out th inking
it must start querying, but as soon as it sees queries from another router with a lower IP address, it stops. These non-querier
routers that lose the querier election still keep track of the IGM P cache.

Chapter 9-22 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

IGMPv2 Group Leave

■ Process for leaving a group:

1. Host 2 sends leave message for 224 .10.1 .1 to the all-routers multicast group address
(224.0.0.2)
2. Querier router sends group-specific query for 224.10.1.1
3. Group 224.10.1.1 times out if no IGMP reports are received within ~3 seconds

Host 3
G)
Leave-group
Q
Group=224.10.1.1

Group-Specific
Query
Group=224.10.1. 1
Router A
(Querier) ....~ - - - - - -

C2020 Juniper Networks, Inc . All Rights Resenie<I.

IGMP Leave Process

In IGMP version 1, no expl icit leave process exists for c lients to indicate that they are no longer interested in receiving traffic.
When an IGMP version 1 client is no longer interested, it stops responding to the router's query message. Therefore, the
router must time-out receivers before it can stop forward ing out of that interface, which results in a long leave latency.

In IGMP version 2, this problem is solved by having a specific IGMP leave message that a host should send when it is no
longer interested in traffic for a specific group. The leave group mes.s age is sent to the group's multicast address. When a
router receives a leave message, it sends a group-specific query to find out if other receivers for that group are still on the
interface. The remaining receivers should respond to the group-specific query to indicate that there is at least one receiver
remaining on the interface. The advantage of this method is that the leave latency is greatly reduced because the timers in
use are much lower.

www .juniper.net Multicast Review and Draft Rosen • Chapter 9 - 23

Junos Layer 3 VPNs

Agenda: Multicast Review and Draft Rosen

■ Multicast Overview
■ Reverse Path Forwarding
■ Internet Group Management Protocol

➔ Draft Rosen Overview

■ Draft Rosen Limitations

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usinessUse Only
Jun1Per
~ETWORKS
24

Draft Rosen Overview

The slide highlights the topic we d iscuss next.

Chapter 9-24 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Model for Multiservice Network

Private IP ATM/FR Emulation
PSTN Bearer
and Signalling Ethernet Services
Internet

\ ,I
I

L3VPN
L2VPN VPLS ?•
(unicast only)

Signalling and Auto-Discovery (BGP)

Transport Infrastructure (MPLS LSPs)

Note: Legacy draft-rosen L3VPN multicast schem e does not conform to this model.

~2020 Juniper Networlcs, Inc .All Rights Reserve<!.

Juniper Business Use Only

Multiservice Network
Th is slide illust rates the general model for multiservice network.

www.j uniper.net Multicast Review and Draft Rosen • Chapter 9 - 25

Junos Layer 3 VPNs

Legacy Model for MVPN (Draft Rosen)

t-'tM adJacencres between t-'t:.s (per-
VRF) to exchange info about multicast
.
I 1\iers
L3VPN
(multicast)

Signalling and Auto-discovery (PIM)

Transport Infrastructure (multicast GRE tunnels)

Multicast trees across the core signalled by

PIM running in main routing instance

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only

Draft Rosen
There was a time when draft-Rosen was the standard by which multicast was transported between Layer 3 VPN (L3VPN)
sites. This method does not rely on either MPLS or BGP. Instead, not only does the customer need to run a multicast routing
protocol like Protocol Independent Multicast (PIM) but the service provider network must also use PIM to signal the end to
end path of the L3VPN multicast traffic. Also, MPLS is not used to transport the multicast data between sites, instead,
multicast generic routing encapsulation (GRE) tunnels are used.

Chapter 9-26 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Legacy Multic;ast Topology (Draft Rqsen) • •

•
. -customer PIM domain-: + - - - - - - - Provider's PIM domain - - - - - - : 4 Customer PIM domain -+

------
• •
•• ••
Source • •
.....
□
:

···········-
...........•
···········-
\
• P-RP
Provider Core
OSPF Area 0
PE-2
loO: 192.168.24.1

0
+--1.1.1.1 : •
■- ■ ■
• •
• •
•
••• •
••
• •• .............
............
............
PE-1 AS 65412
•
•
••
·-··
Rece1ver
1 loO: 192.168.16.1 ••
• •
•
239.1.1.1 1.1.1.1 224.7.7.7 M-cast Dal - - - ~f 1.1.1 1224 7 7 7 IM-cast Dal~
11.1.1.1 1224 7 7 7 E -cast Datf- -
SA DA :
- • 192.168.16.1
GRE-SA GRE-DA SA DA
•
: SA DA
•

• PE routers must participate in both customer's and provider's

multicast domain
• PIM/multicast traffic from customer instance of PIM encapsulated in
GRE using configured vpn - group - address on PE router (example
uses 239 .1 .1 .1)
• Multicast data, hellos, join/prunes, Bootstrap, Auto-RP, etc.
• PE-1 and PE-2 join configured vpn - group - address within provider's
domain using the provider RP
C/2020 Juniper Networks, Inc .All Rights Resenie<I.
Jon1per8usiness Use Only

PEs Participate in Customer and Provider Multicast

The slide shows the relationship between the customer sites and provider network in the draft-Rosen model. Within the
customer network (VPN routing and forwarding table [VRF] ), a provider edge (PE) must participate in the customer's PIM
doma in. Within the provider network (main routing instance), a PE must participate in the provider's PIM doma in.

PIM and Multicast Traffic Encapsulated in GRE

The provider must dedicate an individual multicast group to each customer that desires multicast service. This dedicated
group is specified within the VRF as a vpn-group-address on the PE router. The vpn-group-address is used as the
destination address of the GRE packets that tunnel customer multicast traffic across the provider network.

www .juniper.net Multicast Review and Draft Rosen • Chapter 9 - 27

Junos Layer 3 VPNs

Problem with Legacy Multicast in SP Core

■ Multicast not suitable to run natively over core
• Source address can be private address in customer VPNs
• No two customers can use same group IP
■ Run Multicast in GRE tunnels
• Lots of tunnels, N*(N-1 )/2, and administration

CE2 CE4

C2020 Juniper Networks, Inc . All Rights ReseM!<I.

Jon1per8usiness Use Only

Legacy Multicast Over ISP Core Problem

Customers cou ld run their Mult icast traffic as legacy Multicast from their connected C routers over the ISP Core network but
there are several problems associated to this approach. If customers are using IP addresses from the private address space
these addresses would not be possible to route over the ISP network. Customers cou ld not be able to use same Multicast
group IP addresses since these would no longer be individually associated to a single customer in the ISP Core. Core routers
could not be able to differentiate to which customer network a particular Multicast packet would belong to. A solution is to
run the Multicast traffic over GRE tunnels set up between all customers' CE routers in a full mesh fash ion. This approach can
be feasible in a very small customer CE base but the number of GR E tunnels increases with the number of CE routers with
N'(N-1)/2, where N = number of CE routers.

Chapter 9-28 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Draft Rosen Automatic GRE Tunnel Setup

• PE routers set up GRE tunnels automatically
• Source IP= loO of PE router
• Destination IP = Customer's Multicast IP address
• Tunnels called the MDT, Multicast Distribution Tree
• ISP Core must be configured for multicast routing
• Protocol Independent Multicast {PIM) in tunnel and SP Core

• CE3

• -
CE2 CE4

C2020 Juniper Networks, Inc . All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
29

Automatic GRE Tunnel Setup

Instead of the customer manually configuring the CE-to-CE router GRE tunnels, the PE routers will now automatical ly set up
the GRE tunnels between each other (where the customer's Multicast handling CE routers are connected to). Source
address for the GRE tunnel is the sourcing PE router's loopback IP address. Destination address is the Multicast group IP
address. We ca ll these GRE tunne ls the Multicast Distribution Tree (MDT). Of course this setup requires that the ISP core has
multicast routing configured.

www .juniper.net Multicast Review and Draft Rosen • Chapter 9 - 29

Junos Layer 3 VPNs

Draft Rosen Default MDT

■ L3 Multicast Virtual Private Network with SP tunnels
• Multicast enabled VPNs through the SP network
• Multicast enabled VRF corresponds to a Multicast Domain
• PE router attached to a VRF instance part of the MD
• Each MD has a default Multicast Distribution Tree (MDT)
• Multicast traffic sent over the MDT • • • • • • • • • • •· • • • • Multicast traffic
- - - - - - - - GRE tunnel

CE1 ••
••
•
♦

••
Multicast
Domain (M__
D_) Default MDT
239.10.11 .11
10.1.1.2

•• • •••• • •• • ••• • •
•• ••
CE3
••
MC Source •·•.
•• •• ... ...
... ......... MC Receiver
... ......
•• ••
•• ••• ---,-
----==--
-- --
••••••••••
• •• • •••
••• ••

CE2 CE4
MC Receiver

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Only

Draft Rosen Default

In a draft-rosen Layer 3 multicast virtual private network (MVPN) configured with service provider tunnels, the VPN is
multicast-enabled and configured to use the Protocol Independent Multicast (PIM) protocol within the VPN and within the
service provider (SP) network. A multicast-enabled VPN routing and forwarding (VRF) instance corresponds to a mu lticast
doma in (MD), and a PE router attached to a particular VRF instance is said to belong to the corresponding MD. For each MD
there is a default multicast distribution tree (MDT) through the SP backbone, wh ich connects all of the PE routers belonging
to that MD. Any PE router configured with a default MDT group address can be the multicast source of one default MDT.

Draft-rosen MVPNs with service provider tunnels start by send ing all mu lticast traffic over a default MDT, as described in
section 2 of the IETF Internet draft draft-rosen-vpn-mcast-06.txt and section 7 of the IETF Internet
draft draft-rosen-vpn-mcast-07.txt. Th is default mapping results in the delivery of packets to each provider edge (PE) router
attached to the provider router even if the PE router has no receive rs for the multicast group in that VPN. Each PE router
processes the encapsu lated VPN traffic even if the mu lticast packets are then discarded.

Let's say that the Customer in the diagram above having routers CE1, CE2, CE3, and CE4 has Multicast address
239.10.11.11 in the ISP Core. Each of the PE routers wi ll attempt to form a GRE tunnel with the other PE route rs. The PE
routers will also j oin the Mu lt icast group 239.10.11.11 in the ISP core. The result is that the PE routers now will send GRE
tunne led traffic which will end up at all other PE routers since the destination address is the Multicast IP address.

Multicast enabled GRE tunne ls:

• PE1 (10.1.1.1) to PE2 and PE3 (239.10.11.11)

• PE2 (10.1.1.2) to PE1 and PE3 (239.10.11.11)

• PE3 (10.1.1.3) to PE1 and PE2 (239.10.11.11)

Chapter 9-30 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Draft Rosen Data MDT Operation (1 of 4)

• CE1 sending over default MDT
• Exceeding traffic rate threshold
• PE1 creates a new data MDT
• Announces over default MDT to all default MDT peers
• MDT join TLV sent every 60 seconds
• Receivers cache the MDT join TLV with 180 second timeout value
MC Source • • • • • • • • • • • • • • • • Multicast traffic
- Exceeds transmit rate - - - - - - - - GRE tunnel
Default MDT Data MDT new group
Multicast 239.10.11.11 (NG)239.10.11.12 10-1 -1 ·2
••••
Domain (MD) OT • ••• "... . ••CE3
CE 1 nt over Default M UDP - - - • • ••
20.1.1.1 MDT loin TL'II se NG) (S,G)inVRFlnstance TLV_ - - - - - - MC Receiver
0.1.1.1 NewDataMOT (S, ' ____ - - - PE2

-~-----------,.- p
---- -- ~
PE1 New Data Mor"j;;; Tl-- - ~ ~- ;- ~- ;-
V sent ~
- - -~
_ ~ ~ ~~ 10.1.1.3
MDT (S,NG). (S,GJ. over Default MDT - - - - -
in VRF instance T!.V - - - - CE4
CE2 UDP
Not receiving

C/2020 Juniper Networl<s, Inc .All R,ghlS Resenie<I.

Jon1per 8us1ness Use Only
Jun1Per
.iETWORKS
31

Data MDT Basic Operations: Part 1

To provide optimal multicast routing, you can configure the PE routers so that when the multicast source within a site
exceeds a traffic rate threshold, the PE router to which the source site is attached creates a new data MDT and advertises
the new MDT group address. An advertisement of a new MDT group address is sent in a User Datagram Protocol (UDP)
type-length-va lue (TLV) packet cal led an MDT join TLV. The MDT join TLV identifies the source and group pair
(20.1.1.1,239.10.11.11) in the VRF instance as well as the new data MDT group address 239.10.11.12 used in the provider
space. The PE router to which the source site is attached sends the MDT join TLV over the default MDT for that VRF instance
every 60 seconds as long as the source is active. When the PE router to which the source s ite is attached sends a
subsequent MDT join TLV for the VR F instance over the default MDT, any existing cache entries for that VR F instance are
simply refreshed with a timeout value of 180 seconds.

www .juniper.net Multicast Review and Draft Rosen • Chapter 9 - 31

Junos Layer 3 VPNs

Draft Rosen Data MDT Operation (2 of 4)

■ Default MDT Peers cache MDT join TLVs

• Active receivers join the new group, optimal multicasting
• PE routers with no receivers just cache the MDT join TLVs
■ Multicast traffic now flows over an optimal path only to PE routers
having active receivers
MC Source
- Exceeds transmit rate •• •. •. • •••• • •• •. Multicast traffic
20.t.1.1 - - - - - - - - GRE tunnel
Default MDT Data MDT new group
Multicast 239.10.11.11 (NG) 239.10.11 .12 10-1 -1 ·2
••
•
•• ••
Domain (MD) ____ .,- ••
••• • •• •• • •CE3
•• ••
••••
••••• ______ - - - - -
--
p\l-A JoinlS,
)
PE2 MC Receiver
--------
~~::~:: . p
PE1 ------ - .:--:-:-
_ -:::-
---- -- -- --
_ ~ ~ ~ ~ ~ ~~ 10.1.1.3
_J-- -~
CE2
--- CE4
Not receiving

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usiness Use Onty

Data MDT Basic Operations: Part 2

All PE routers in the VRF instance receive the MDT join TLV because it is sent over the default MDT, but not all the PE routers
join the new data MDT group:

• PE routers connected to receivers in the VRF instance for the current multicast group cache the contents of the
MDT join TLV, adding a 180-second timeout value to the cache entry, and a lso j oin the new data MDT group.

• PE routers not connected to receivers listed in the VRF instance for the current multicast group also cache the
contents of the MDT j oin TLV, adding a 180-second timeout value to the cache entry, but do not join the new
data MDT group at this time.

When a remote PE router joins the new data M DT group, it sends a PIM j oin message for the new group directly to the source
PE router from the remote PE routers by means of a PIM (S,G) join.

Multicast Traffic Forwarding Over The Optimal Path

The source PE router starts encapsulating the multicast traffic for the VR F instance using the new data MDT group after
3 seconds, allowing t ime for the remote PE routers to join the new group. The source PE router then ha lts the flow of
multicast packets over the default MDT, and the packet flow for the VRF instance source shifts to the newly created data
MDT. After the source PE stops sending the multicast traffic stream over the default MDT and uses the new MDT instead,
only the PE routers that j oin the new group receive the multicast traffic for that group.

To display the information cached from MDT join TLV packets received by all PE routers in a PIM-enabled VRF instance, use
the show pim mdt data-mdt-joins operational mode command .

Chapter 9-32 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Draft Rosen Data MDT Operation (3 of 4)

■ Non joined PE receives a (S,G) for the new data MDT

• Uses cached (S,G) information, joins data MDT immediately

MC Source
- Exceeds transmit rate
• • • • • • • • • • • • • • • • Multicast traffic
- - - - - - - - GRE tunnel
Default MDT Data MDT new group
Multicast 239.10.11.11 (NG) 10.1.1.2
Domain (MD) •• ••
CE1
239.10.11 .12
-- -- - •
r .... ••
• • •••••• CE3

----- -- -- PE2
MC Receiver

---------- -- - ------
PE1
---- ---- ----
CE2

C/2020 Juniper Networl<s, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only

Data MDT Basic Operations: Part 3

If a PE router t hat has not yet j oined the new data MDT group rece ives a PIM j oi n message for a new rece iver for which (S,G)
traffic is already f lowing ove r the data MDT in t he provider core, then that PE router can obt ain t he new group address from
its cache and can j oi n the data MDT immed iately without waiting up to 59 seco nds for the next data MDT advertisement.

www .j uniper.net Multicast Review and Draft Rosen • Chapter 9 - 33

Junos Layer 3 VPNs

Draft Rosen Data MDT Operation (4 of 4)

■ PE 1 continuously monitors the traffic rate

■ PE 1 stops announcing the data MDT if
• Traffic rate drops below the set threshold
• Source of multicast stops sending traffic
MC Source:
• transmit rate under
threshold • • • • • • • • • • • • • • • • Multicast traffic
• Stops sending
- - - - - - - - GRE tunnel
20. t 1.1
Default MDT
Multicast 239.10.11.11 ef It 10.1.1.2
♦
Domain (MD) MDT join TLV sent over D ✓e •• ••••
• •• • •••• CE3
CE1 •
·•. ♦
New oataMDT {S,N
. ,nstance
_ ___ -
iLV
UDP
- - -
_ - -
----
PE2
·•••
MC Receiver

- - --- -- --
PE1
New Data

CE2

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per 8usiness Use Only

Data MDT Basic Operations: Part 4

The PE router monitors the traffic rate during its periodic statistics-collection cyc les. If the traffic rate drops below t he
threshold or the source stops sending multicast traffic, the PE router to wh ich the source site is attached stops announcing
the MDT join TLVs and switches back to sending on the default MDT for that VRF instance.

Chapter 9-34 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Draft Rosen ASM and SSM

■ The Junos OS provides two types of draft-rosen multicast VPNs:

• Any-source multicast (ASM) mode, also referred to as rosen 6 Layer 3 VPN
multicast
• Many-to-many model meaning that there may be multiple sources sending the multicast
stream to potentially many receivers
• Network responsible for source discovery
• Uses rendezvous points (RP)
• Source-specific multicast (SSM) mode, also referred to as rosen 7 Layer 3
VPN multicast
• One-to-many model meaning that receivers are aware of from which source to request
the multicast stream from

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Onty
Jun1Per
~ETWORKS
35

Two Types of Draft-Rosen Multicast VPNs

Juniper provides two types of draft-rosen multicast VPNs:

• Draft-rosen multicast VPNs with service provider tunnels operating in any-source multicast (ASM ) mode (also
referred to as rosen 6 Layer 3 VPN multicast)- Described in RFC 4364,BGP/ MPLS IP Virtua l Private Networks
(VPNs) and based on Section 2 of the IETF Internet draft draft-rosen-vpn-mcast-06.txt, Multicast in MPLS/ BGP
VPNs (expired April 2004).

• Draft-rosen multicast VPNs with service provider tunnels operating in source-specific multicast (SSM) mode
(also referred to as rosen 7 Layer 3 VPN multicast)- Described in RFC 4364,BGP/ MPLS IP Virtua l Private
Networks (VPNs) and based on the IETF Internet draft draft-rosen-vpn-mcast-07.txt, Multicast in MPLS/ BGP IP
VPNs. Draft-rosen multicast VPNs with service provider tunnels operating in SSM mode do not require that the
provider (P) routers maintain any VPN-specific Protocol-Independent Multicast (PIM) information .

www .juniper.net Multicast Review and Draft Rosen • Chapter 9 - 35

Junos Layer 3 VPNs

Any Source Multicast for Draft Rosen VPNs

■ Prerequisites:
• Functional routing protocols in provider network
• Functional VPN configuration
• VPN import and export policies
• Routers to support multicast tunnel (mt) interfaces
• PE routers
• P routers acting RP
• CE routers acting as a Source's DR or as a RP
• Check how many mt interfaces your tunnel capable PIC supports
- Default MDT uses 2 (encapsulation and decapsulation)

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usinessUse Only

ASM for Draft Rosen Requirements

Your routers' interfaces should be configured correctly to have full connectivity as desired to carry on the packet forwarding
in the network. Configure an interior gateway protocol or static routing in the SP Core and verify the functionality. Configure
your VPNs between the participating PE routers and verify the functionality.

Make sure that the routing devices support multicast tunnel (mt) interfaces for encapsulating and de-encapsulating data
packets into tunnels. For multicast to work on draft rosen Layer 3 VPNs, each of the following routers must have tunnel
interfaces:

• Each provider edge (PE) router.

• Any provider (P) router acting as the RP.

• Any customer edge (CE) router that is acting as a source's DR or as an RP. A receiver's designated router does
not need a Tunnel Services PIC.

Chapter 9-36 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

SSM for Draft Rosen VPNs (1 of 2)

■ Uses BGP signalling for PE autodiscovery

■ PEs send MDT subsequent address family identifier (MDT-SAFI)
containing
• Route distinguisher
• Unicast address of the PE router to which the source site is attached
• Multicast group address
• Route target extended community attribute
■ Remote PEs imports the MDT-SAFI advertisements
• The route target must match
• Joins the (S,G) tree rooted at each sourcing PE router

C2020 Juniper Networks, Inc . All Rights Resenie<I.

Jon1peraus1ness use Only
Jun1Per
~ETWORKS
37

Source Specific Multicast Draft Rosen Basics: Part 1

A draft-rosen MVPN with service provider tunne ls operating in SSM mode uses BGP signaling for autodiscovery of the PE
routers. These MVPNs are also referred to as Draft Rosen 7 .

Each PE sends an MDT subsequent address family identifier (MDT-SAFI) BGP network layer reachability information (NLRI)
advertisement. The advertisement contains the following information:

• Route distinguisher

• Unicast address of the PE router to which the source site is attached (usually the loopback)

• Multicast group address

• Route target extended community attribute

MDT-SAFI updates are BGP messages distributed between intra-AS internal BGP peer PEs. Thus, receipt of an MDT-SAFI
update enables a PE to autodiscover the identity of other PEs with sites for a given VPN and the default MDT {S,G ) routes to
join for each. Autodiscovery provides the next-hop address of each PE, and the VPN group address for the tunnel rooted at
that PE for the given route distinguisher ( RD) and route-target extended community attribute.

Each remote PE router imports the MDT-SAFI advertisements from each of the other PE routers if the route target matches.
Each PE router then joins the (S,G) tree rooted at each of the other PE routers.

After a PE router discovers the other PE routers, the source and group are bound to the VPN routing and forwarding (VRF)
through the multicast tunnel de-encapsulation interface.

www .juniper.net Multicast Review and Draft Rosen • Chapter 9 - 37

Junos Layer 3 VPNs

SSM for Draft Rosen VPNs (2 of 2)

■ Control plane must support autodiscovery

■ PIM is notified of the (S,G) addresses
• Binds the (S,G) state to mt interface
• Sends a join to the group
■ BGP-based MVPN control plane must be enabled

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
38

Source Specific Multicast Draft Rosen Basics: Part 2

The control plane of a draft-rosen MVPN with service provider tunne ls operating in SSM mode must be configured to support
autodiscovery. After the PE routers are discovered, PIM is notified of the multicast source and group addresses. PIM binds
the (S,G) state to the multicast tunnel (mt) interface and sends a join message for that group. Autodiscovery for a draft-rosen
MVPN with service provider tunnels operating in SSM mode uses some of the faci lities of the BGP-based MVPN control plane
software module. Therefore, the BGP-based MVPN control plane must be enabled. The BGP-based MVPN control plane can
be enabled for autodiscovery only.

Chapter 9-38 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

SSM for Draft Rosen VPNs

■ Prerequisites:
• Functional routing protocols in network
• BGP and IGP
• Functional VPN configuration
• VPN import and export policies
• Routers to support multicast tunnel (mt) interfaces
• PE routers
• P routers acting RP
• CE routers acting as a Source's DR or as a RP
• Check how many mt interfaces your tunnel capable PIC supports
- Default MDT uses 2 (encapsulation and decapsulation)
- Eventual data MDTs add on top of the default MDTs

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usinessUse Onty

SSM for Draft Rosen Requirements

Your routers' interfaces shou ld be configured correctly to have full connectivity as desired to carry on the packet forwarding
in the network. Configure an interior gateway protocol or static routing in the SP Core and verify the functionality. Configure
your VPNs between the participating PE routers and verify the functiona lity. Make sure that the routing devices support
multicast tunnel (mt) interfaces for encapsulating and de-encapsulating data packets into tunnels. For multicast to work on
draft rosen Layer 3 VPNs, each of the fol lowing routers must have tunnel interfaces:

• Each provider edge (PE) router.

• Any provider (P) router acting as the RP.

• Any customer edge (CE) router that is acting as a source's DR or as an RP. A receiver's designated router does
not need a Tunnel Services PIC.

www .j uniper.net Multicast Review and Draft Rosen • Chapter 9-39

Junos Layer 3 VPNs

Agenda: Multicast Review and Draft Rosen

■ Multicast Overview
■ Reverse Path Forwarding
■ Internet Group Management Protocol
■ Draft Rosen Overview
➔ Draft Rosen Limitations

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
40

Draft Rosen Limitations

The slide highlights the topic we d iscuss next.

Chapter 9-40 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Draft Rosen Limitations

■ Draft Rosen limitations

• Cannot be run in a logical system
• Sends multicast traffic over the default MDT
• At least one multicast tree/ customer in the SP Core
• Aggregation challenges
• Uses GRE tunnels to pass Customer PIM signaling
• Per customer PIM instances for PE-PE C route exchange
• Inter-AS challenges

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Only
Jun1Per
~ET'I-IORl(S
41

Draft Rosen Limitations

Draft Rosen multicast VPNs are not supported in a logical system environment even though the configuration statements
can be configured under the logical-systems hierarchy.

By sending the Multicast traffic by default over the default MDT forces all participating PE routers to rece ive the traffic no
matter whether they have active receivers or not. It also means that both control plane and data plane share the same
tunnel.

Since the Multicast trees in the SP Core are set up as default MDTs per customer there is a scalability issue in running a
large number of Multicast streams through the network. without a simple way of providing aggregation of the trees.

ASM uses GRE tunne ls for the Multicast distribution between the PE routers which adds on both protocol overhead and
encapsulation/ decapsulation. It a lso requires PICs supporting tunneling protocols.

One VRF on a PE router must mainta in PIM adjacencies with all other VRFs of that MVPN, i.e. PIM adjacency is maintained
per MVPN per PE, not j ust per PE. In addition to PE adjacencies the VR F also must maintain PIM adjacencies with all of its
locally connected CEs of the VR F's MVPN.

Inter-AS or inter-provider deployment requires PE routers in different ASs (provider networks) to have peering between the PE
routers and have at least one VPN in common.

www .juniper.net Multicast Review and Draft Rosen • Chapter 9 - 41

Junos Layer 3 VPNs

Summary

■ In this content, we:

• Described IP multicast traffic flow
• Identified the components of IP multicast
• Explained how multicast addressing works
• Described the need for the RPF check in multicast networks
• Explained the role of IGMP
• Explained Draft Rosen and some of its drawbacks

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Joniper8us1ness Use Onty
Jun1Per
.iETWOffKS
42

We Discussed:
• IP multicast traffic flow;

• Components of IP mult icast;

• How multicast addressing works;

• The need for RPF check in multicast networks;

• The role of IGMP; and

• Draft Rosen mult icast and some of the drawbacks.

Chapter 9 - 42 • Multicast Review and Draft Rosen www.juniper.net

 Junos Layer 3 VPNs

Review Questions

1. What type of distribution trees can multicast applications use?

2. What is the purpose of the RPF check in multicast routing?
3. What is the role of IGMP?

~2020 Juniper Networlcs, Inc . All Rights Reserve<!.

Ju niper Business Use Onty
Jun1Per
NETWORKS
43

Review Questions
1.

2.

3.

www .juniper.net Multicast Review and Draft Rosen • Chapter 9 -43

Junos Layer 3 VPNs

Answers to Review Questions

1.
Shortest path tree and rendezvous path tree .

2.
To verify that packets are received via the shortest path between the multicast source and the local router.

3.
IGMP is used to inform the directly connected routers that the local router desires to receive specific multicast packets.

Chapter 9-44 • Multicast Review and Draft Rosen www.juniper.net

 un1Pe[
NETWORKS
Education Services

Junos Layer 3 VPNs

Chapter 10: Next-Generation Multicast VPNs

Engineering Simplicity
Junos Layer 3 VPNs

Objectives

■ After successfully completing this content, you will be able to:

• Describe the flow of control traffic and data traffic in a
next-generation multicast VPN
• Describe the configuration steps for establishing a
next-generation multicast VPN
• Monitor and verify the operation of next-generation multicast VPNs
• Understand the function of MVPN Internet multicasting with ingress replication

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Only

We Will Discuss:
• The flow of control traffic and data traffic in a next-generation multicast virtual private network (MVPN);

• The configuration steps for establishing a next-generation MVPN;

• Monitoring and verifying the operation of next-generation MVPNs; and

• The function of MVPN Internet multicasting with ingress rep lication.

Chapter 10- 2 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Agenda: Next-Generation Multicast VPNs

➔ Multicast VPN Overview

■ Next-Generation MVPN Operation
■ Configuration

■ Monitoring

■ MVPN Internet Multicasting

C2020 Jun,perNetworl<s, Inc .All Rights Reserlle<I.

Joniper8us1ness Use Onty
Jun1Per
.iETWOffKS
3

Multicast VPN Overview

The slide lists the topics we will discuss. We will discuss the highlighted topic first.

www .juniper.net Next-Generation Multicast VPNs • Chapter 10- 3

Junos Layer 3 VPNs

Motivations Behind NG-MVPN

■ IETF motivations for a new MVPN scheme called

next-generation MVPN (RFC 6513)
• Increasing interest from customers of Layer 3 VPN services in having multicast
capability, in addition to unicast
• New mission-critical MVPN applications such as IPTV
• Point to multipoint MPLS LSPs provide multicast-like forwarding
• Realization that existing Rosen scheme for MVPN has fundamental
architectural limitations

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Onty

Motivations for Next-Generation MVPN

Over the last few years there has been an increasing interest in transporting mu lticast traffic over Layer 3 VPNs along with
unicast. For example, multicast is the logical solution for delivering Internet Protocol Television (IPTV). Broadcast television
providers have become increasingly interested in looking to the Internet to deliver content in a secure environment to their
customers.

MPLS forwarding has evolved as well. With the advent of the point-to-m ultipoint LSP, an MPLS-based network can provide
multicast-like forwarding capabi lities without the need for running multicast protocols.

The draft-Rosen method of delivering mu lticast content has some scaling limitations. For example, cons ider an example
where a PE has 1,000 VRFs, and each of these VR Fs co rresponds to an MVPN that is present on 100 PEs. The PE would
need to maintain 100,000 PIM adjacencies with other PEs. The rate of PIM Hellos that t he PE would need to process is
3,300 per second.

Chapter 10- 4 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Model for Next-Generation MVPN

Private IP ATM/FR emulation
PSTN bearer +
signalling
Ethernet Services
Internet

• I ' . ~

L3VPN
I tIPTV
• (unicast and L2VPN VPLS ?•
multicast)

Signalling and Auto Discovery (BGP)

Transport Infrastructure (MPLS LSPs)

Traffic Engineering, bandwidth guarantees, fast-

reroute ...

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Ju niper8us1ness Use Onty

Model for Next-Generation MVPNs

The slide shows the signaling and transport model of next-generation MVPNs. Next-generation MVPNs use the same MPLS
and BGP infrastructure as Layer 3 VPNs, Layer 2 VPNs, and VPLS.

www .juniper.net Next-Generation Multicast VPNs • Chapt er 10-5

Junos Layer 3 VPNs

Replacing PIM with BGP

■ BGP for PE-PE signaling

• Seven MP-BGP NLRI for MVPN
signaling (RFC 6514)
G PE1
• MVPN membership autodiscovery
-
• Autodiscovery for selective provider
tunnels
• Customer PIM join message conversion
• Active sources
• PE routers might need only a couple
of BGP sessions to route-reflectors e PE4 e PE3
• Can be the same as Layer 3 VPN r6tl r:9J
unicast scheme u LJLl

C2020 Juniper Networks, Inc . All Rights ReseM!<I.

Jon1per8us1ness Use Only

BGP for PE to PE Signaling

Next-generation MVPNs cal l for Multiprotocol Border Gateway Protocol (MP-BGP) as the signaling method for multicast trees.
Seven new network layer reachab ility information (NLRI) types have been standard ized in RFC 6514. The new NLRI types
perform functions like MVPN membership autodiscovery, selective tunnel autodiscovery, PIM join message conversion, and
active source advertisement.

The PIM adjacency problem between PEs that was found in draft-Rosen no longer exists. Instead, a PE router m ight on ly
need a few BGP neighbor relationships with route-reflectors, wh ich might also be the same route-reflectors used for the
L3VPN.

Chapter 10-6 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Next-Generation MVPN Terms

■ Terms
• PMSI: Type of tunnel to use to transport multicast data across the provider
core (also called provider tunnel)
• RSVP point to multipoint LSPs
• Provider instance PIM distribution trees (similar to draft-Rosen)
• MLDP
• 1-PMSI
• Multidirectional: All PEs in an MVPN can transmit multicast packets to all other PEs
participating in MVPN
• Unidirectional: Enables only a particular PE to transmit multicast packets to other PEs
• S-PMSI
• A particular PE can transmit multicast packets to a subset of PEs

C/2020 Juniper Networks, Inc .All R,ghlS Resenie<I.

Jon1per8usinessUse Only

Next-Generation MVPN Terms

There are some common terms you should know about next-generation MVPNs, including:

• Provider-Multicast Service Interface (PMSI): Tunnel used to transport multicast data from PE to PE. It is also
ca lled a provider tunnel. Provider tunnels can take several forms including RSVP-traffic engineered
point-to-multipoint label-switched paths (LSPs), provider instance PIM distribution trees, and Multipoint Label
Distribution Protocol (mLDP).

• Inclusive-PMS! (1-PMSI): There are two type of 1-PMSls.

Multidirectional 1-PMSI: Allows all PEs of a multicast VPN (MVPN) to transmit multicast data between
each other (one point-to-multipoint LSP from al l PEs to al l other PEs).

Unidirectional 1-PMSI: Allows a single PE to transmit multicast data to other PEs (one point-to-multipoint
LSP from a single PE to all other PEs).

• Selective-PMS! (S-PMSI): A PE can transm it multicast packets to on ly those PEs of an MVPN that have
expressed interest in being part of the multicast forwarding tree.

www .j uniper.net Next-Generation Multicast VPNs • Chapter 10- 7

Junos Layer 3 VPNs

Agenda: Next-Generation Multicast VPNs

• Multicast VPN Overview

➔ Next-Generation MVPN Operation
• Configuration
• Monitoring
• MVPN Internet Multicasting

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8usiness Use Only
Jun1Per
~ETWORKS
a

Next-Generation MVPN Operation

The slide highlights the topic we discuss next.

Chapter 10-8 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Next-Generation MVPN BGP Advertisements

■ RFC 6514 specifies ... IType ILength IRoute Type Specific

• MCAST-VPN NLRI format (1 bytes)(1 bytes) (variable length)

• AFI 1/SAFI 5
• Routes tagged with correct route target community are placed into the bgp . mvpn . o and
routing-instance . mvpn . 0 table
• New MVPN BGP attributes
• P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute

I Flags I T~;;:1 I MPLS Label I Tunnel ID I

(1 bytes)(1 bytes) (31~ ) (variable length)

...--
MP -----
........ ------
LS label that receiving PE should
expect as an inner label for incoming
RSVP Session ID or LOP P2MP
FEC for ooint to multiooint LSPs
MVPN traffic (0 = No label)

C,2020 Jun,perNelWOrl<S, Inc .All R,ghlS Resenie<I.

Jon1per8usinessUse Only

MCAST-VPN NLRI
The NLRI format fo r next-generation MVPN signal ing can be fo und in RFC 6514. The MCAST-VPN NLRI is carried in M P-BGP
extensions with an AFI of 1 and SAFI of 5 . When t hese type of routes are received from remote PEs and accepted by a policy
t hat matches on the route ta rget community (same as L3VPNs), the receiving PE will place the routes in t he MVPN routing
t able-IN cal led bgp. mvpn. O and then into the correspond ing VR Fs MVPN routing table, routing-instance . mvpn. 0.

Next-Generation MVPN Attributes

RFC 6514 defines a few new attributes. One important attribute is cal led the PMSI Tunnel attribut e. It carries label and
tunnel ID information allowing a receiving PE to know what data channel (LSP fo r examp le) to expect multicast traffic on.
Subsequent slides will describe its usage in more detail.

www .j uniper.net Next-Generation Multicast VPNs • Chapter 10 - 9

Junos Layer 3 VPNs

Next-Generation MVPN BGP NLRI Types (1 of 4)

■ Type 1: Intra-AS Inclusive MVPN Membership Discovery

• Sent by all PE routers participating in MVPN
• In the case of 1-PMSI using RSVP-TE, these routes determine where to
automatically build the point to multipoint LSPs
• Routes are tagged with PMSI Tunnel attribute 1: 10.1.1.1 :1:10.1.1.1
t
Type
I
t
Sending
I I
I
Sending
I

PE's RD PE's loO

■ Type 1: Intra-AS Inclusive MVPN Membership Discovery

• Sent by all PE routers participating in MVPN
• In the case of 1-PMSI using RSVP-TE, these routes determine where to
automatically build the point to multipoint LSPs 4:110. 1. 1. 1:1:16154 12 I
• Routes are tagged with PMSI Tunnel attribute T I
Type Sending
'
Sending
PE's RD PE's AS

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per 8us1ness Use Only
Jun1Per
~ETWORKS
10

Type 1 NLRI
The Intra-autonomous system (AS) 1-PMSI autodiscovery route is the initial route type that is advertised between PEs of the
same MVPN allowing them to autodiscover one another. It is distributed to other PEs that attach to sites of the MVPN. The
routes carry the sending PE's route distingu isher (RD), the sending PE's loopback address, and a route target community to
allow for import into a VRF. In the case of an inclusive provider tunnel, the route will also be tagged with the PMSI Tunnel
attribute.

Type 2 NLRI
The Inter-AS 1-PMSI autodiscovery route is used to discover members of an MVPN in different ASs. Inter-AS MVPNs are
outside the scope of this course.

Chapter 10-10 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Next-Generation MVPN BGP NLRI Types (2 of 4)

■ Type 3: Selective MVPN Autodiscovery Route

• Sent by the PE that initiates an S-PMSI
3: 10.255.170.100: 1 :32: 192.168.194.2:32:224.1.2.3: 10.255.170.100
t ..___________,, t _______, t
Type Sending
PE's RD C-S
C-S using S-
PMSI C-G
I f
C-G
using S-
·-----
Sending PE's
loO
Mask Mask PMSI

■ Type 3: Selective MVPN Autodiscovery Route

• Sent by the PE that initiates an S-PMSI

4 :3: 10.255.170.100: 1 :32: 192.168.194.2:32:224.1.2.3: 10.255.170.100: 10.255.170.98

t
Type Received Sending PE's loO
Type 3 Route

C/2020 Juniper Networks, Inc .All R,ghlS Resenie<J.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
11

Type 3 NLRI
Selective MVPN Autod iscovery rout es are used t o help build an S-PMSI. This route is advertised by the multicast source's PE
in response to rece ivi ng a Type 6 or Type 7 route (described in subsequent sl ides), which are essentially requests to join the
multicast forwarding tree (BGP version of a PIM join). The slide shows t he details of what is carried in the Type 3 route. Even
though the source PE learns that the remote PE wants to receive a particular multicast stream from a type 7 advertisement,
t he sou rce PE sends the type 3 as a request to the receiver PE to j oin the S-PMSI. The most important reason for th is
message is because it is tagged with the PMSI t unnel attribute al lowing the receive r PEs t o know the deta ils of the provider
t unnel.

Type 4 NLRI

The Selective MVPN autodiscovery route is sent by an interested receiver PE (in t he case of an RSVP-signalled LSP in the
data plane) in response to receiving a type 3 route from a source PE.

www .j uniper.net Next-Generat ion Multicast VPNs • Chapter 10- 11

Junos Layer 3 VPNs

Next-Generation MVPN BGP NLRI Types (3 of 4)

■ Type 5: Source Active Autodiscovery Route

• Sent by PE router that discovers an active multicast source
• Learned through PIM register messages (RP), MSDP source active messages, or a
locally connected source

5:10.255.170.100:1:32:192.168.194.2:32:224.1.2.3
t ....____ --..J t ,_________, t ■ f •
Type Sending C-S C-G
C-S C-G
PE's RD
Mask Mask

■ Type 6: Shared Tree Join Route

• Sent by receiver PE that receives PIM join (C-*,C-G) on VRF interface
6: 10.255.170.100:1:65000:32:10.12.53.12:32:224.1.2.3
1
T!pe RD of upstream PE AJ of c! RP C-RP Address c ! G I C-G I

(towards C-RP) upstream Mask Mask

PE
C2020 Juniper Networks, Inc .All Rights ReseM!<I.
Jon1per8us1ness Use Only
Jun1Per
.iETWORKS
12

Type 5 NLRI
The Source Active autodiscovery route is advertised by a PE that discovers a source that is attached to a locally connected
site. The PE learns of t he source either from Pl M register messages, Multicast Source Discovery Protocol (MSDP) source
active messages, or a locally connected source. The source PE sends this advertisement to all other PEs participating in the
MVPN.

Type 6 NLRI
The Shared Tree Join route is advertised by a receiver PE to al l other PEs partic ipating in the MVPN in response to receiving a
PIM (* ,G) join from the local CE. It serves a similar purpose to the Pl M (* ,G) join in that it is a request to join the shared
multicast tree .

Chapter 10-12 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Next-Generation MVPN BGP NLRI Types (4 of 4)

• Type 7: Source Tree Join Route

• Sent by receiver PE that receives PIM join (C-S,C-G) on VRF interface

7: 10.255.170.100: 1:65000:32: 192.168.194.2:32:224.1.2.3

I

r ! pe RD of upstream AJ of d-s C-S c!G C~G '

PE (towards C-RP) upstream Mask Mask
PE

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per 8us1ness Use Only
Jun1Per
.iETWOffKS
13

Type 7 NLRI
The Source Tree Join route is advertised by a receiver PE to all other PEs participating in the MVPN in response to receiving a
PIM (S,G) join from the local CE. It serves a similar purpose to the PIM (S,G) join in that it is a request to join the source
multicast tree .

www .juniper.net Next-Generation Multicast VPNs • Chapter 10- 13

Junos Layer 3 VPNs

Point-to-Multipoint LSP Concept

■ Point-to-multipoint LSPs can be used as the transport mechanism for

next-generation MVPN traffic across the core
• Traffic can be protected using standard methods like fast reroute and link protection

Can use MPLS FRR, Traffic

Engineering, Link Protection,
Core routers o nly need IGP Bandwidth Reservations
plus MPLS, no PIM needed!

P2

e
PE5

0PE4 0 PE3
C/2020 Juniper Networks, Inc .All Rights ReseM!<I.
Jon1per8us1ness Use Only

RSVP Point-to-Multipoint LSPs

One transport mechanism that can be used in next-generation MVPN scenario is point-to-multipoint LSPs. There are several
benefits to using point-to-multipoint LSPs in the service provider network:

1. The burden of data replication is taken off of the ingress PE. Instead, each router along the path of the LSP can
help in that responsibility.
2. Multicast traffic can be protected using the standard methods of MPLS protection like fast-reroute (RSVP only)
and link protection.

3. Certain levels of performance can be guaranteed with the use of traffic engineering and bandwidth reservation
(RSVP only).

4. The service provider network does not need to run PIM to support multicast routing. Multicast routing of
customer traffic can occur on the same IP/MPLS design that was used to build the un icast L3VPNs.

Chapter 10-14 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Next-Generation MVPN Inclusive Trees

■ Inclusive trees
• Each tree serves one MVPN only PE1
• All the multicast traffic in that
MVPN arriving at an ingress PE is
mapped to that same tree to get
from the ingress PE to all the
other PEs in the same MVPN
- -
PES PE2
• Analogous to default-MDT in
draft-Rosen
0PE4

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
15

Inclusive Trees
The simplest form of provider tunnel is the inclusive tree (1-PMSI). An inclusive tree serves an entire MVPN. In the diagram,
there is one inclusive tree that serves the blue VPN and one that serves the red VPN. Any mult icast traffic arriving at the
source PE (PE-1 ) wi ll be sent to all other PEs in the same MVPN. This works well when al l remote PEs need to receive the
multicast traffic but th is form of tree can be wastefu l of resources (bandwidth, packet processing, and so on ) when on ly a
few of the remote PEs need to receive multicast traffic. The solution to this problem is the use of selective trees described in
subsequent sl ides.

www .j uniper.net Next-Generation Multicast VPNs • Chapter 10- 15

Junos Layer 3 VPNs

Next-Generation MVPN Selective Trees

■ Selective trees
PE1
• Serves particular selected I
I
multicast groups from a given ,'- _Jielective Tre3
I
MVPN I
I

• Similar to data-MDT in draft-

Rosen
w
PE5 PE2

1'.'.?I~
; -: .:::.·

C2020 Juniper Networl<s, Inc .All Rights ReseM!<I.

Jon1per 8us1ness Use Only

Selective Tree
Selective trees can be used to forward traffic for particular source and group combinations to the remote PE that specifically
request to rece ive that traffic. The dotted line in the diagram shows that a point-to-multipoint LSP has been built to send
multicast traffic for the red VPN to PE2 and PE4 on ly.

Chapter 10-16 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

1-PMSI Signalling Example (1 of 5)

■ Example which shows the use of inclusive trees with P2MP LSPs
• Prior to enabling an MVPN, the PE routers have an existing L3VPN
established using LOP to signal LSPs
• The provider core does not have PIM enabled

•• ••
•
- customer PIM domai~: :+-
•
Customer PIM domain--+
•• •
•• ••
Source • •
•
•
••
Provider Core PE-2

---
••
• OSPFArea 0 loO: 192.168.2.1
• •
--1 0.0.101.2 .
:
•
•
•
••
•
• •
•

PE-1
AS 65512
1
,
loO: 192.168.6.1

C-RP
:
•
:
PE-3
•• 100: 192.168.2.2
• •
• •
• •

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Only
Jun1Per
.iETWOffKS
17

Inclusive Tree Example Initial State

The slide shows an example L3VPN prior to enabling next-generation MVPN.

Some things to note are:

1. The provider core is not running PIM;

2. There is an existing L3VPN between all customer sites using LDP to signal the un icast LSPs;

3. PE-1 will be acting as the customer rendezvous point (RP) (with in the VRF);

4. CE-A will be acting as the customer designated router (DR) closest to the source; and

5. CE-8 and CE-C will eventually have rece ivers attached.

www.j uniper.net Next-Generation Multicast VPNs • Chapter 10-17

Junos Layer 3 VPNs

1-PMSI Signaling Example (2 of 5)

■ MVPN is enabled on the PE routers (RSVP P2MP case)

• With no receivers or sources active, each PE router:
• Advertises a Inclusive MVPN A-D route to each other tagged with Route Target and
PMSI Tunnel Attribute
• Using RSVP PMSI , automatically builds a P2MP LSP to other PEs with itself as root and
no PHP (virtual tunnel interface or vrf-table-label)
• ••
: 1: 192.168.6 .1:1:192.168.6.1
~ Customer PIM -+: ♦ :+- Customer PIM
domain :------------
•
•
••
RSVP PMSI - RSVP Session ID, Label = 0 "" - - •
:•
•
domain

•
• Provider Core PE-2
••
•• OSPF Area 0
• •
• •
••
••• ••

•
PE-1 : •
loO: 192.168.6.1
AS 65512 •
•
•

"
•

:•: PE-3
C-RP loO: 192.168.2 .2
••
• •
• •
• •

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Only

Inclusive Tree Example Enabling the MVPN (RSVP case)

The following describes the case when RSVP-s ignaled P2MP LSPs are used for multicast data transport.

With no source and receivers in the network, an MVPN is enabled on all t hree PEs. Once enabled, each PE will advertise its
membership to the MVPN using a Type 1 route tagged with the PMSI tunnel attribute. Each PE will automatically bui ld an
RSVP-signaled point-to-multipoint LSP to all other PEs. In the network shown on t he slide, there will only ever be a single
source attached to PE-1. Because PE-2 and PE-3, will never be attached to a source site, the point-to-multipoint LSP that
each of them insta ntiated as themselves as ingress route rs will never be used. It is possible to configure PE-2 and PE-3 as
receiver-o nly sites so that they do not bu ild the unnecessary point-to-multipoint LSPs.

When PE-2 and PE-3 eventually receive multicast traffic from PE-1 using the point-to-multipoint LSP, they wi ll need to use the
incoming MPLS label encapsulating t he multicast packets to determine which VRF to use for forward ing. Normally a
point-to-multipoint LSP is signalled with a label of 3 on the penultimate hops meaning that there would be no label
encapsulating the incoming traffic. Therefore, a virtua l tunnel interface or vrf-table-label must be configured within the VRF
to allow for a non-implicit-null label to be used on the penultimate hops.

Chapter 10-18 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

1-PMSI Signaling Example (3 of 5)

■ MVPN is enabled on the PE routers (LOP P2MP case)

• With no receivers or sources active, each PE router:
• Advertises a Inclusive MVPN A-D route to each other tagged with Route Target and
PMSI Tunnel Attribute
• Using LOP PMSI , builds a P2MP LSP to the root as advertised in the PMSI

••
.,_Customer PIM --♦ l+- Customer PIM
•
domain :• domain
•
PE-2

CE
I

PE-1
•
•
.• ~
........
Label, LSP ID - t
•
•
••
A 1 loO: 192.168.6.1 Label, LSP ID •
•
Jl •
•
•
AS 65512 PE-3
C-RP ••
•
•
100: 192.168.2.2
• •
•• ••

C/2020 Juniper Networks, Inc .All Rights ReseMl<!.

Jon1per8us1ness Use Only

Inclusive Tree Example Enabling the MVPN (LDP case)

The following describes the case when LOP-signaled P2M P LSPs are used for multicast data transport.

With no source and rece ivers in the network, an MVPN is enabled on all t hree PEs. Once enabled, each PE will advertise the ir
membership to the MVPN using a Type 1 route tagged with the PMSI tunnel attribute. Each PE will automatically build an
LOP-signaled point-to-multipoint LSP to the source as advertised in the received Type 1 PMSI attribute. In the network shown
on the sl ide, there will only ever be a single source attached to PE-1. Because PE-2 and PE-3, wi ll never be attached to a
source site, the point-to-multipoint LSP that is built to each of them with t hemselves as ingress routers will never be used. It
is possible to configure PE-2 and PE-3 as receiver-only sites so that point-to-multipoint LSPs and not built to t hem .

When PE-2 and PE-3 eventually receive multicast traffic from PE-1 using the point-to-multipoint LSP, they will need to use the
incoming MPLS label encapsulating t he multicast packets to determine which VRF to use for forward ing. Normally a
point-to-multipoint LSP is signaled with a label of 3 on the penultimate hops meaning that the re would be no label
encapsulating the incoming traffic. Therefore, a virtual tunnel interface or vrf-table-label must be configured within the VRF
to allow for a non-implicit-null label to be used on the penultimate hops.

www .juniper.net Next-Generation Multicast VPNs • Chapter 10- 19

Junos Layer 3 VPNs

1-PMSI Signaling Example (4 of 5)

■ Source begins sending multicast traffic

• CE-A sends register messages to PE-1
• PE-1 is now aware of an active source
• PE-1 sends SA Autodiscovery Route to remote PEs
I s:192.168.6.1:1:32:10.o.101 .2:32:224.7.7.7 ~ - _ ..

•• •
• •
+ :• :+-
•
Customer PIM
•• : domain
• •
• •
••
••
Provider Core PE-2
•
•
•• OSPF Area 0 loO: 192.168.2 .1
•
•
•
•
•
••

PE-1
1 loO: 192.168.6.1 AS 65512
~ :•
----
PIM
Registers
C-RP
- -►
:
.••
•
•
•
••
PE-3
loO: 192.168.2 .2

C2020 Juniper Networks, Inc . All Rights ReseM!<I.

Jon1per8us1ness Use Only

Inclusive Tree Example Source Begins Sending Traffic

With the MVPN now established, the source attached to CE-A begins sending multicast traffic. As the customer PIM DR, CE-A
encapsulates the multicast traffic in register messages and un icasts that traffic to the customer RP (C-RP), PE-1. PE-1
learning of a new source in the customer's network advertises that source in the form of the Type 5 Source Active
autodiscovery route to all other PEs of the MVPN.

Chapter 10-20 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

1-PMSI Signaling Example (5 of 5)

■ Using IGMP, receivers join source specific group
• Receiver CEs send PIM (S,G) join upstream to PE-2 and PE-3
• Receiver PEs convert PIM join to MVPN Source Tree Join
• Source PE converts MVPN Source Tree Join to PIM (S,G) Join and sends it to
the DR to complete the multicast tree
.,_ i PIM (S,G)Join ! +- - _ ... !.,. 7
, 7-:1_9_2 _-16-8-.6-.1-:1 :-65- 5-12-:3-2-: 1-0.-0.-10_1_2:-32- :2_2_4 _-7_-7_-7 .... PIM (S,G)Join !
..-customer PIM
- ·-- n
.. ••
•
:•
•
•
••
•
•
:+-
•
:•
•
Customer PIM
domain
--+

••
•
CE
Provider Core PE-2

. B
•
···········-
.............
·-··
••
•• OSPF Area 0 loO: 192.168.2.1
~ 10.0.101.2

I
•
•
•••
•
•
•-
Receivers
CE PE-1
AS 65512
A 1 loO: 192.168.6.1

"
C-RP ::•
•
•
PE-3
100: 192.168.2.2
• •
• •
• •
C/2020 Juniper Networks, Inc .All Rights Resenie<I.
Jon1per8usiness Use Onty
Jun1Per
.iETWOffKS
21

Inclusive Tree Example Receivers Join

Using Internet Group Management Protocol (IGMP) version 3, the hosts attached to CE-Band CE-C report their membership
to a specific multicast source and group.CE-Band CE-C in turn send a PIM (S, G) join upstream toward the source. Upon
receiving the PIM joins, PE-2 and PE-3 send Type 7 Source Tree Join routes to the source PE, PE-1. Upon receiving the Type 7
advertisement from the remote PE, PE-1 sends a PIM (S, G) join upstream to the customer's DR router, CE-A. At the point the
multicast forwarding tree is complete and multicast traffic forwarded from the source to receivers.

www .juniper.net Next-Generation Multicast VPNs • Chapter 10- 21

Junos Layer 3 VPNs

1-PMSI Forwarding
■ After multicast forwarding tree is built
• CE-A sends native multicast packets to PE-1
• PE-1 encapsulates packets in a single MPLS header
• Outbound MPLS label is derived from the point to multipoint LSP
• P2 sends copies of packets to both PE-2 and PE-3
• Receiver PE's pop outer label and send traffic based on VRF
I S-IP , 224.7.7.7 I M-castData !
SA DA :
__ - + I Label
MPLS
I S-IP , 224.7.7.7 I M-castData l
SA DA
- - - ►
• SA
I S-I P , 224.7.7.7 I M-castData !
DA
.,_customer PIM domain -= •
•
•
l+- Customer PIM domain
•
•
-♦
•• •

□
• •
•• •
• Provider Core
• PE-2
•

-··..-
···········- •
·······--
···········-
· •• OSPF Area 0

~
•
••
♦ ..... s -l P=10.0.101 .2 •
•
•
••
Receivers

1
PE-1
loO: 192. 168.6.1
•
AS 65512
~
~ ••
C-RP • PE-3
•
• loO: 192.168.2.2
•
•• •
• ••

C/2020 Juniper Networl<s, Inc .All Rights ReseM!<I.

Jon1per8usiness Use Only

1-PMSI Forwarding
Now that the multicast forwarding tree is complete, mu lticast traffic can be sent from end to end. From the source to PE-1,
multicast packets are forwarded in the ir native format. From PE-1 to Pl, multicast packets are encapsulated in the MPLS
header that is associated with the point-to-multipoint LSP that uses PE-1 as the ingress router. Pl simply performs a label
swap. At P2, because of the behavior of point-to-multipoint LSP, the data traffic is repl icated, the label is swapped, and then
sent to both remote PEs. The receiving PEs pop the incoming label and use the label to determine the VRF to use for
forward ing. The receiving PE then sends the multicast traffic in its native format toward the receivers.

Chapter 10-22 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

S-PMSI Signalling Example (1 of 6)

■ Example which shows the use of selective trees with point to

multipoint LSPs
• Prior to enabling an MVPN, the PE routers have an existing L3VPN
established using LOP to signal LSPs
• The provider core does not have PIM enabled
•• ••
•
+-Customer PIM domain+: l+- Customer PIM domain ---+
•
• •
• ••
Source : •
•

~• I Provider Core PE-2

•
OSPF Area 0
-- 10.0.1 01 .2 :•
•
••
•

PE-1
1 loO: 192.168.6.1 AS 65512
JI :• PE-3
C-RP :
•
•
loO: 192.168.2.2
•• ••
• •

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1peraus1ness use Only

Selective Tree Example Initial State

The slide shows an example L3VPN prior to enabling next-generation MVPN.

Some things to note are:

1. The provider core is not running PIM;

2. There is an existing L3VPN between all customer sites using LDP to signal the un icast LSPs;

3. PE-1 will be acting as the customer RP (with in the VRF);

4. CE-A wi ll be acting as the customer DR closest to the source; and

5. Only CE-8 wil l eventually have a rece iver attached.

www.juniper.net Next-Generation Multicast VPNs • Chapter 10- 23

Junos Layer 3 VPNs

S-PMSI Signalling Example (2 of 6)

■ With no source or receivers for multicast traffic, an MVPN is enabled

on the PE routers
• Each PE router:
• Advertises a Inclusive MVPN A-0 route to each other tagged with Route Target
• P2MP LSPs (1-PMSI ) are built between PEs for flooding (when group address of received
packets are outside of selective range)
•
. -customer PIM domain -+l I 1:192.168.6.1:1:192.168.6.1
I- - - •
••
l+- Customer PIM domain
•
•
•
••

Provider Core PE-2

OSPF Area 0 loO: 192.168.2.1

PE-1 AS 65512
loO: 192.168.6.1
•

"
•
• PE-3
C-RP •
••
• loO: 192.1 68. 2.2
• •
• •
• •
C2020 Juniper Networks, Inc .All Rights ReseM!<I.
Jon1per8us1ness Use Onty

Selective Tree Example Enabling the MVPN

With no source and rece ivers in the network, an MVPN is enabled on all three PEs. Once enabled, each PE will advertise the ir
membership to the MVPN using a Type 1 route, however the Type 1 routes will not be tagged with the PMSI tunnel attribute.
In an S-PMSI scenario, a point-to-mult ipoint LSP is not built until at least one PE has a receiver attached.

Chapter 10-24 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

S-PMSI Signaling Example (3 of 6)

■ Source begins sending multicast traffic

• CE-A sends register messages to PE-1
• PE-1 is now aware of an active source
• PE-1 sends SA Autodiscovery Route to remote PEs
~1_5_:1_92_.
16_s _.
6._1:1_:3_2: 1_0_
.o._ _ 4_ .1_.1_.1 _ ___.~
10_1.2_ 3_2:n --+

•
•• ••
~ Customer PIM domain- : ;+- Customer PIM domain ...,.
•• •
•
•• ••
• •
•
• Provider Core
• PE-2
•

. ---10.0.101.2
••
•
••
•
•
•
OSPF Area 0

PE-1 AS 65512
1 lo0: 192.168.6.1

"
C-RP :;• PE-3

-1P
- IM- R-eg-ist-ers--1- - ► j loO: 192.168.2.2
•
•
•

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1peraus1ness use Only

Selective Tree Example Source Begins Sending Traffic

The source attached to CE-A begins sending multicast traffic. As the cust omer PIM DR, CE-A encapsulates t he mult icast
traffic in register messages and unicasts that traffic to the customer RP (C-RP), PE-1. PE-1 learning of a new source in the
customer's network advertises that source in the form of the Type 5 Source Active autodiscovery route t o all other PEs of the
MVPN.

www .j uniper.net Next-Generation Multicast VPNs • Chapter 10- 25

Junos Layer 3 VPNs

S-PMSI Signaling Example (4 of 6)

■ Using IGMP, receivers join source specific group

• Receiver CE-B sends PIM (S,G) join upstream to
• Receiver PE-2 converts PIM join to MVPN Source Tree Join
• No receiver attached to CE-C
◄- - - -I 7:192.168.6.1:1:65512:32:10.0.101 .2:32:224.7.7.7 !+- -f PIM (S,G) Join !
. . -customer PIM domain
. .
•
+ :
• •
•
:+- Customer PIM domain -+
•• •
••
• •
• •
•

~. I. Provider Core PE-2

OSPF Area 0 too: 192.168.2.1
•
--10.0.101.2 :
•
•
•
• Receiver
PE- 1 AS 65512
1 loO: 192.168.6.1

"
C-RP ::•
••
PE-3
loO: 192.168.2.2
• •
•• •
•

C2020 Juniper Networl<s, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only

Selective Tree Example Receivers Join

Using IGM P version 3, the host attached to CE-8 reports its membership to a specific multicast source and group. CE-8 in
turn sends a PIM (S, G) join upstream toward the source. Upon receiving the PIM j oins, PE-2 sends a Type 7 Source Tree Join
route to the source PE, PE-1.

Chapter 10- 26 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

S-PMSI Signaling Example (5 of 6)

■ Multicast forwarding tree completed (RSVP P2MP case)

• PE-1 sends S-PMSI Autodiscovery route remote PEs
• Only PE-2 responds with a Leaf Autodiscovery route
• PE-1 builds point to multipoint LSP to responding leaf PEs and sends PIM join
towards the DR 3:192.168.6.1:1:0 :0.0.0.0:32:224_7_7_7:1 92.168.6.1
0 RSVP PMSI - RSVP Session ID, Label = 0 - -+
-4 +-
•
•
..__ ________________
- - - - - - - - - - - - - - - - -_____.
-~2-- )
4:3:192.168.6.1 :1:0:0.0.0.0:32:224.7.7.7:192.168.6.1 : 192.168.2.1

- PIM (S,G) Join

••
•
••
•
l+- Customer PIM domain
•
••
---+
~ Customer PIM domain + :• ••

~• I Provider Core PE-2

• 0 OSPF Area 0
--10.0.101.2 :•
••
•
•
~
Receiver
PE- 1 AS 65512
loO: 192.168.6.1
JI :• PE-3
C-RP :
• loO: 192.168.2.2
•
••
•
••
•
C2020 Jun,perNetworl<s, Inc .All Rights Resenie<I.
Jon1perausiness use Only

Selective Tree Example Completing the Forwarding Tree (RSVP Case)

The following describes the case when RSVP-signaled P2MP LSPs are used for multicast data transport.

Upon receiving the Type 7 advertisement from the PE-2, PE-1 sends a Type 3 S-PMSI autod iscovery route tagged with PMSI
Tunnel attribute with t he leaf information required bit set. PE-2 now knows the RSVP session ID of the point-to-multipoint LSP
that will be used for forwarding. PE-2 then responds to PE-1 with a Type 4 Leaf autodiscovery route. PE-1 builds a
point-to-multipoint RSVP-signaled LSP to all PEs that responded with a Type 4 . In this case. PE-1 bui lds a point-t o-multipoint
LSP to a single end-point, PE-2. Finally, PE-1 sends a PIM (S, G) join upstream to the cust omer's DR router, CE-A. At the point
the mu lticast forwarding tree is complete and multicast traffic forwarded from the source to receivers.

www .juniper.net Next-Generation Multicast VPNs • Chapter 10- 27

Junos Layer 3 VPNs

S-PMSI Signaling Example (6 of 6)

■ Multicast forwarding tree is completed (LOP P2MP case)

• PE-1 sends S-PMSI Autodiscovery route to the remote PEs
• PE-2 initiates the building of an LOP P2MP LSP upstream toward the
advertised root (as received in the Type 3)
• Once the label is received by PE-1 for the P2MP LSP, PE-1 sends a PIM join
toward the DR 3:1 92.168.6.1 :1 :0:0.0.0.0:32:224.7.7. 7:192.168.6.1

+-
---- :
....
- - - -- - . •
PIM (S,G) Join : .0 ~--------~~---~-~ =
LOP PMSI -P2MP, Root IP Address (PE- 1), LSP ID
.+- Customer PIM domain --+
•
•
. -c ustomer PIM domain + : •
•
•
Provider Core PE-2
>oi::.
.
Label, LS~P~I
OSPF AreaO (D too: 192.168.2.1
- 10.0.1 01.2

~ - ~
Receiver
PE-1 Label, LSP ID
loO: 192.168.6.1 Label, LSP ID AS 65512

"
C-RP
:•:
•
PE-3
loO: 192.168.2.2
•
• ••
•
• •
C2020 Jun,perNetworl<s, Inc .All R,ghlS Resenie<I.
Jon1per8usiness Use Only

Selective Tree Example Completing the Forwarding Tree (LDP Case)

The following describes the case when LOP-signaled P2MP LSPs are used for multicast data transport.

Upon receiving the Type 7 advertisement from the PE-2, PE-1 sends a Type 3 S-PMSI autod iscovery route tagged with PMSI
Tunnel attribute which includes a PMSI type of P2MP, IP address of the root (PE-1), and the LSP ID. PE-2 now knows
everything it needs to know to build an LOP signa led point-to-multipoint LSP that will be used for multicast data forward ing.
PE-2 then responds by sending a P2MP FEC to its upstream neighbor in the direction of source. This process continues until
a complete P2MP lsp is setup fro PE-2 (an egress PE) to PE-1 (ingress and root PE for the LSP). Finally, PE-1 sends a PIM (S,
G) j oin upstream to the customer's DR router, CE-A. At the point the multicast forwarding tree is complete and mu lticast
traffic forwarded from the source to rece ivers.

Chapter 10-28 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Hardware Requirements for Next-Generation

MVPNs
■ Requires tunnel service PIC on certain routers
• Customer's first hop DR
• Customer's candidate RPs
• All PE routers participating in customer's multicast network
• Except when using vrf-table-label
• Tunnel services simply need to be enabled on the
MX Series DPC/MPCs
[edit]
user@pel# show chassis
fpc 1 {
pi e O {
t unnel - services {
bandwidth lg ;
}
}
}

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per aus1ness use Only

Tunnel Services
Assuming every router is runn ing the Ju nos OS, tunnel services must be enabled on certain routers. Some routers require a
Tunnel Service PIC or Adaptive Service PIC to provide tunnel services . In the case of the MX Series device, the feature j ust
needs to be enabled as shown on the slide.

Router types needing tunne l services:

• DR closest to source - Tunnel services are needed because the DR must encapsulate multicast traffic in unicast
messages ca lled register messages;

• Customer's cand idate RP - Tunnel services are needed because the RP must de-encapsulate the register
messages received from the DR; and

• All MVPN PE routers - Tunnel services are needed because it allows the PE to pop the incoming MPLS header
from the incoming multicast traffic, perform an RPF check on the multicast traffic, and then forward the traffic
out of the VRF interface. This is assuming that a virtual tunnel interface is used. Optionally,
v rf - t ab l e- l a b e l can be configured without the need for tunnel services.

www .juniper.net Next-Generation Multicast VPNs • Chapter 10- 29

Junos Layer 3 VPNs

Next-Generation MVPN Junos OS Support

■ Junos OS supports:
• Provider Tunnel Types
• Ingress Replication (using P2P LSPs)
• RSVP P2MP
• LOP P2MP
• PIM- ASM Tunnels
• PIM-SSM Tunnels
• Data MDT Tunnels
• PIM features
• Pl M Sparse Mode
• PIM Dense Mode
• Auto-RP
• Bootstrap Protocol
C/2020 Juniper Networks, Inc .All Rights Resenie<I.
Jon1per8us1ness Use Only
Jun1Per
.iETWOffKS
30

Junos OS Support
The slide shows the protocols that are supported when enabling next-generation MVPNs using Ju nos OS.

Chapter 10-30 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Agenda: Next-Generation Multicast VPNs

■ Multicast VPN Overview

■ Next-Generation MVPN Operation
➔ Configuration
■ Monitoring
■ MVPN Internet Multicasting

C/2020 Juniper Networl<s, Inc .All Rights ReseM!<I.

Jon1per8usinessUse Only
Jun1Per
~ETWORKS
31

Configuration
The slide highlights the topic we d iscuss next.

www .j uniper.net Next-Generat ion Multicast VPNs • Chapter 10- 31

Junos Layer 3 VPNs

Next-Generation MVPN Configuration (1 of 5)

■ PE to PE MP-BGP session must be configured to allow for MVPN

signaling
[edit ]
user@pel # show protocols bgp
family inet {
un icast ;
a ny ;
)
f amily inet- vpn {
a ny ;
)
f amily ine t - mvpn {
s i gnal i ng ;
)
group my- int - group {
type internal ;
local - address 192 . 168 . 6 . 1;
neighbor 192 . 168 . 2 . 2 ;
neighbor 192 . 168 . 2 . 1;
)

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Juniper Business Use Onty

MP-BGP Configuration
To allow for BGP neighbors to exchange the new MVPN NLRI, f a mil y inet-mvpn sign a ling must be enabled on all
participating PE routers.

Chapter 10-32 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Next-Generation MVPN Configuration (2 of 5)

• Configure P2MP LSP template for RSVP P2MP LSP
[edit ]
user@pel# s h o w p r otocol s mpl s
label - switched-path mvpn- e xample {
template ;
no - cspf ;
link- protection ;
p2mp ;
}

• Configure RSVP-TE LSP to be used as provider tunnel

[edit routing- instances mcas t - pe - vrf ]
user@pe l# show [edi t routing- in stances mcast- pe - vrf]
• • • user@pe l# show
provi der- t unne l {
rsvp- te { provider- t unnel {
label- switched- path- template { selective {
mvpn - example ; g r oup 224 . 7 . 7 . 0/24 {
} wildcard- source {
} rsvp- te {
} 1
~ 1-nc
_l_us-iv_e_P_r_
ov- id
_e_r_T _
u n_n_e_l(-R-eq_u_ir-e-d )~ I I Selective Provider Tunnel~abe l-switched- pat ... {
• • • default- template ;
vrf -table- label ;

C2020 Juniper Networl<s, Inc .All Rights ReseM!<I.

Jon1per8usiness Use Only

Optional Point-to-Multipoint LSP Template

You can optionally specify the requirements of t he point-to-multipoint LSP by creating a t emplate under [e dit p r otoco l s
mp l s J . You can specify protection requ irements, bandwidth requ irements, path information, and more.

Provider Tunnel Type

The example on the slide shows how to configure an RSVP-traff ic engineered point-to-multipoint LSP for use as an inclusive
provider tunnel and a selective provider tunnel. At a minimum, you must configure an inclusive provider tunnel (even when
selective is also configured) so that t he PE wi ll be able to f orward a multicast packets even when t hey do not match the
selective group range (the inclusive tunne l will act as the default method for multicast forwarding). You can use a configured
LSP template or just use the default template. To ensure that penultimate hop popping is not performed along the LSP, the
example shows the configuration of v r f-tab l e- l abe l . A vi rtual tunnel int erface could also have been used .

www .j uniper.net Next-Generat ion Multicast VPNs • Chapter 10- 33

Junos Layer 3 VPNs

Next-Generation MVPN Configuration (3 of 5)

■ Enable LOP P2MP LSP signaling on all routers

[edi t protocols ldp]
user@pe l# show
interface ge -1/ 0/6 . 100 ;
p2mp ;

■ Configure LOP P2MP LSP to be used as provider tunnel

Selective Provider Tunnel
Inclusive Provider Tunnel (Required) [edit routing- instances mcast- pe - vrf]
[edit r out ing-instances mcast-pe-vrf) user@pel# show
user@pel# show • • •

.. . provider- tunnel {
provider- tunnel { selective {
ldp- p2mp ; group 224 . 7 . 7 . 7/32 {
} source 10 . 0 . 103 . 2/32 {
• • •
l dp -p2mp ;
vrf- table- l abe l ; }
.. . }
}

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usinessUse Only

Enable P2MP Signaling

In order for a router to support the signa ling of LOP P2MP LSP, you must configure the p2mp option under [e dit
protocol s ldp J. Al l routers in the provider core shou ld have th is option configured.

LDP Provider Tunnels

The example on the slide shows how to configure LOP signa led point-to-multipoint LSP fo r use as an inclusive provider tunnel
and a se lective provider tunnel. At a minim um, you must configure an inclusive provider tunnel (even when selective is also
configured) so that the PE will be able to forward a multicast packets even when they do not match the selective group range
(the inclusive t unnel will act as t he defau lt method for multicast forwarding). To ensure that penultimate hop popping is not
performed along the LSP, t he example shows the configuration of vr f -tabl e- l abel . A virtua l t unnel interface could also
have been used.

Chapter 10 - 34 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Next-Generation MVPN Configuration (4 of 5)

■ Configure the VRF to participate in the C-PIM domain as well as the

MVPN [edit ]
use r @pel# show routi ng- instances mcast- pe -vrf
• • •
prot ocols {
• • •
pim {
rp {
local {
address 1 92 . 168 . 13 . 3 ;
}
}
in te rface all {
mode sparse ;
}
}
mvpn {
mvpn - mode {
spt- only ;
I

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usinessUse Only

Customer Pl M Configuration
Within the VR F, you must configure mult icast routing that is specific to the customer's multicast domain. This configuration is
shown as the PIM configuration in the s lide. Also, you must enable the mvpn using the mvpn statement. There are several
settings available under the mvpn hierarchy. The sl ide shows the configuration of the mvpn -mode. There are two options for
the mode. First is the sp t -on ly mode, which allows for only shortest path trees to be bui lt from receiver PEs toward the
source (Type 7s only). The second mode is r p t -spt mode which allows for both rendezvous point based trees and shortest
path trees to be built from receiver PE to source (Type 6s and Type 7s allowed ). Subsequent slides will show more options
that are available under the mvpn hierarchy.

www .juniper.net Next-Generation Multicast VPNs • Chapter 10- 35

Junos Layer 3 VPNs

Next-Generation MVPN Configuration (5 of 5)

■ Full VRF example configuration (1-PMSI )
[edi t r outing- instances mcast- pe - vrf)
user@pe l# show pim {
instance- type vrf ; rp {
interface ge-1/0/9 . 251 ; l ocal {
i nterface l o0 . 13 ; address 192 . 168 . 13 . 3 ;
provider- tunne l { l
rsvp-te { }
label- switched-path - template { interface all {
mvp n-e xample ; mode sparse ;
} }
l l
l mvpn {
vrf - target target : 65512 :1 00 ; mvpn - mode {
vrf - table - label ; spt - only ;
protocols { }
bgp { }
group external { }
type e xterna l ;
export exp-po l icy ;
neighbor 10 . 0 . 50 . 2 {
peer- as 65501 ;
}
}
• • •
~ 2020 Juniper Networks, Inc . All Rights ReseM!<I.
Joniper8us1ness Use Only

VRF Configuration
Th is slide shows the full, working VRF configuration for PE1.

Chapter 10-36 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Next-Generation MVPN Configuration Options

■ Provider tunnels
[edit routing-instances mcast-pe-vrf)
user@pel i s e t provider-tun nel ?
Possible completions :

> ingress-replication Ingress Replication Tunnel

> ldp- p2mp LDP point- to-multipoint LSP for flooding
> mdt Data MDT tunnels for PIM MVPN
> pim-asm PIM-SM provider tunnel
> pim-ssm PIM-SSM provider tunnel
> rsvp-t e RSVP-TE point-to-multipoint LSP for flood ing
> selective Selective t unnels

■ MVPN settings
[edit routing- instances mcast- pe- vrf]
user@peli set p r o tocols mvpn ?
Possible completions :

> autodiscovery-only Use MVPN exclusively for PE router autodiscovery

> mvpn-mode MVPN mode of operation
receiver - site MVPN instance has sites only with multicast receivers
> route- target Configure route- targets for MVPN routes
sender-site MVPN instance has sites only with multicast sources
> t raceopt ions Trace options for BGP-MVPN
unicast- umh- election Upstream Multicast Hop election based on unicast route preference
C2020 Juniper Networl<s, Inc .All R,ghlS Resenie<I.
Jon1per8us1ness Use Onty

Provider Tunnels
There are several options available for provider tunnels.

• i ngr ess-repl icat i on: point to point LSPs (RSVP or LDP) are used for multicast data transport. Ingress PE
performs all mu lt icast rep lication;

• l s p -p2mp: Used to configure an 1-PMSI between PEs using LDP point-to-multipoint LSPs;
• mdt: Used to configure Multicast Data Tunne ls as provider tunnels;
• p i m-asm: Used to configure PIM any source provider tunnels;
• p i m-s sm: Use t o configure PIM source specific provider tunnels;
• r svp-te : Used to configure an 1-PMSI between PEs using RSVP-traffic engineered point-to-multipoint LSPs;
and

• select i ve: Used to configure an S-PMSI between PEs using either RSVP or LDP point-to-multipoint LSPs.

MVPN Settings
It is under the MVPN settings that you can specify whether a s ite is a sender-only site or receiver-only site. By default, every
site is both a sender and rece iver site. You can also configure the MVPN mode, traceoptions, and the upstream multicast
hop settings.

www.j uniper.net Next-Generation Multicast VPNs • Chapter 10- 37

Junos Layer 3 VPNs

Agenda: Next-Generation Multicast VPNs

■ Multicast VPN Overview

■ Next-Generation MVPN Operation
■ Configuration
➔ Monitoring
■ MVPN Internet Multicasting

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
38

Monitoring
The slide highlights the topic we d iscuss next.

Chapter 10-38 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

View VRF PIM Status

■ Verify PIM status

user@pel> show pim join instance mcast-pe-vrf e x tensive
Instance : PIM . mcast- pe - vrf Family : INET
R = Rendezvous Point Tree , S = Sparse , W = Wildcard

Gro up : 224 . 7 . 7 . 7
Source : 10 . 0 . 101 . 2
Flags : sparse
Upstream interface : ge-1/0/9 . 251
Upstream neighbor : 10 . 0 . 50 . 2
Upstream state : Local RP , Join to source
Keepalive timeout :
Downstream neighbors :
I nte rface : Pseudo - MVPN

Instance : PIM . mcast - pe - vrf Family : INET6

R = Rendezvous Point Tree , S = Sparse , W - Wildcard

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Joniper8us1ness Use Onty

PIM Status
To verify the status of PIM within the customer network using the s h ow p i m commands using a modifier of instance
instance-name. The command on the slide shows the (S, G) state of the PE router.

www .juniper.net Next-Generation Multicast VPNs • Chapter 10- 39

Junos Layer 3 VPNs

Verify Multicast Packet Forwarding

■ Verify multicast traffic

user@pel> show multicast route extensive instance mcast-pe-vrf
Family : ! NET

Group : 224 . 7 . 7 . 7
Source : 10 . 0 . 101 . 2/32
Upstream interface : ge-1/0/ 9 . 251
Session description : Unknown
!statistics : 139 kBps , 263 pps , 532482 packets !
Next-hop ID : 3638
Upstream protocol : MVPN
Route state : Active
Forwarding state : Forwardi ng
Cache lifetime/timeout : fo rever
Wrong i ncoming interface not i fica t i on s : 0

Family : I NET6

~2020 Juniper Networks, Inc .All Rights ReseM!<I.

Juniper Business Use Onty

Is Multicast Traffic Flowing?

The command on the slide shows that PE1 is currently forward ing multicast traffic destined for 224.7.7.7 at a rate of 263
packets per second.

Chapter 10-40 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

MVPN RIB-IN

■ View MVPN routes learned from remote PEs

• Routes that populate this table have been accepted by
vrf-import policy (based on vrf-target matching)
user@pel> show route table bgp.mvpn.O

bgp . mvpn . O: 3 destinations , 3 routes (3 active , 0 h olddown , 0 hidden )

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

1 : 192 . 168 . 2 . 1 : 65535 : 192 . 1 68 . 2 . 1/240

*[BGP/170) 18 : 13 : 1 1 , localpref 1 00 , from 1 92 . 168 . 2 . 1
AS path : I
> to 172 . 22 . 250 . 2 via ge- 1/0/4 . 250 , Push 299888
1 : 192 . 168 . 2 . 2 : 65535 : 192 . 1 68 . 2 . 2/240
*[BGP/170) 18 : 26 : 13 , localpref 100 , from 1 92 . 168 . 2 . 2
AS path : I
> to 172 . 22 . 250 . 2 via ge-1/0/4 . 250 , Push 299808
7 : 192 . 168 . 6 . 1 : 5 : 65512 : 32 : 10 . 0 . 101 . 2 : 32 : 224 . 7 . 7 . 7/240
*[BGP/170) 00 : 18 : 13 , localpref 100 , from 192 . 168 . 2 . 1
AS path : I
> to 172 . 22 . 250 . 2 via ge- 1/0/4 . 250 , Push 299888

~2020 Juniper Networks, Inc .All Rights ReseM!<I.

Juniper Business Use Onty

Next-Generation MVPN Routing Table-IN

The bgp . mvpn. o table is the routing table-IN for MVPN routes. The command on the slide shows the routes that are
currently popu lating the bgp. mvpn. o table. Routes wi ll only show up in this tab le if they have been accepted by VRF
import policy that matches on the correct target communities.

www .j uniper.net Next-Generation Multicast VPNs • Chapter 10- 41

Junos Layer 3 VPNs

VRF Specific MVPN Routes

■ VRF Specific MVPN Routes

use r @pel> show route table mcast- pe - vr£ . mvpn.0

mcast - pe - vrf . mvpn . 0 : 5 desti na tion s , 6 r out es (5 act ive , 1 holddown, 0 h i dde n)
+ =Act i ve Route , - = La st Active , * = Both
l : 192 . 1 68 . 2 . l : 65535 : 1 92 . 168 . 2 . l /240
*[ BGP/170] 18 : 13 : 29 , l ocalpr ef 100 , from 192 . 168 . 2 . 1
AS path : I
> to 172 . 22 . 250 . 2 via ge - 1/0/4 . 250 , Push 2998 88
l : 192 . 1 68 . 2 . 2 : 65535 : 1 92 . 168 . 2 . 2/2 40
* (BG P/ 170] 18 : 26 : 31 , l oca l pref 100 , from 192 . 168 . 2 . 2
AS path : I
> to 172 . 22 . 250 . 2 via ge - 1 /0/ 4 . 250 , Pu sh 299808
l : 192 . 168 . 6 . 1 : 5 : 19 2 . 168 . 6 . l /2 40
* [MVPN / 70 ) 00 : 4 1 : 29 , me tric2 1
I ndirect
5 : 192 . 168 . 6 . l : 5 : 32 : 10 . 0 . 10 1 . 2 : 32 : 224 . 7 . 7 . 7 /2 40
* [ PI M/ 10 5) 1 8 : 2 3 : 21
Mul t i cas t ( IPv 4)
7 : 192 . 1 68 . 6 . l : 5 : 65512 : 32 : 10 . 0 . 1 01 . 2 : 32 : 224 . 7 . 7 . 7/240
*[ PI M/ 105] 00 : 1 8 : 31
Mul t icas t ( IPv4)
[BGP/ 170 ] 00 : 1 8 : 31 , l oca l pref 100 , from 192 . 168 . 2 . 1
AS path : I
> to 172 . 22 . 250 . 2 via ge - 1 /0/ 4 . 250 , Pu sh 2998 88

~ 2020 Juniper Networlcs, Inc . All Rights Reserve<!.

Joniper ausaness Use Only

VRF Specific MVPN Routes

The command on the slide shows the MVPN routes that relate to a specific MVPN.

Chapter 10-42 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Verify Provider Tunnel

■ View status of point to multipoint LSP

user@pel> show rsvp session
Ingress RSVP : 2 sessions
To Fro m Sta te Rt Style Labelin Labe l out LSPname
192 . 168 .2 . 1 192 . 168 . 6 . 1 Up 0 1 SE 300096 192 . 168 . 2 . 1 :192 . 168 . 6 . 1 : 5 : mvpn :mcast - pe-vrf
192 . 168 .2 .2 192 . 168 . 6 . 1 Up 0 1 SE 300096 192 . 168 . 2 . 2 : 192 . 168 . 6 . 1 : 5 : mvpn :mcast - pe-vrf
Total 2 displayed , Up 2 , Down 0

user@pel> show ldp database

Input labe l databa8e , 193 . 168 . 1 . 1 :0--193 . 168 . l . 2 : 0
Label Prefix

300208 P2MP root-addr 193 . 168 . 1 . 1 , l sp-id 16777224

■ View status of point to multipoint LSP

use r@pel> show route forwarding-table destination 22 4 .7.7.7 e x tensive
Routing table : mcast - pe-vrf . inet [ Index SJ
Internet :

Destination : 224 . 7 . 7 . 7 . 10 . 0 . 101 . 2/64

Route type : user
Ro ute r efer e nce : 0 Ro u te int e rface- index : 223
Flags : cached, check incomi ng inte r face , accou nting , sent t o PFE
Next-hop type : flood Index : 3638 Re f e r ence : 2
Nexthop : 1 72 . 22 . 250 . 2
Next-hop type : Push 300096 I ndex : 3625 Reference : 1
Next-hop interface : ge - 1/0/4 . 250

C2020 Jun,perNetworks, Inc . All R,ghlS ReseM!<I.

Jon1per8us1ness Use Only

Point-to-Multipoint LSP
Use the sho w rsvp sessio n or sho w ldp database com mand to determ ine the st at us of t he point-t o-m ult ipoi nt LSP.
In t he output of t he RSVP comm and, you can see t hat t he outbound label for t he point-t o-multipoint LSP is 300096. For the
LDP com mand, t he output shows t hat t he outbound label for t he P2M P LSP is 300208.

Forwarding Table
The co mmand on the slide shows t he ro utes in PE1's f orwarding t able associat ed wit h the mult icast group of 224.7 .7 .7 with
a source of 10.0.101.2 . Notice t hat all mult icast packet s of th is type will be sent out of t he ge-1/ 0/ 4 .250 interf ace with a
single MPLS label of 300096.

www .juniper.net Next-Generat ion Mult icast VPNs • Chapt er 10- 43

Junos Layer 3 VPNs

Agenda: Next-Generation Multicast VPNs

■ Multicast VPN Overview

■ Next-Generation MVPN Operation
■ Configuration

Monitoring
➔ MVPN Internet Multicasting

C2020 Juniper Networl<s, Inc .All R,ghlS ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
44

MVPN Internet Multicasting

The slide highlights the topic we discuss next.

Chapter 10-44 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

MVPN Internet Multicast

■ Internet Multicast basic functions

• Uses BGP for the control plane
• Uses Ingress Replication for the data plane
• Unicast tunnels for multicast distribution tree
• mpls-inte r net-mul t i cast non-forwarding routing instance
• For control plane
• No interfaces
• One per logical system
• Configured only for the Master routing instance
• Configured under Pl M protocol hierarchy

C2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per 8usiness Use Only

Internet Multicast Basic Functions

When using ingress replication for IP multicast, each participating router must be configured with BGP for contro l plane
procedures and with ingress replication for the data provider tunnel, wh ich forms a full mesh of MPLS point-to-point LSPs.
The ingress replication tunnel can be selective or inclusive, depending on the configuration of the provider tunnel in the
routing instance.

The i ng r ess- r e plica t ion provider tunnel type uses unicast tunnels between routers to create a multicast distribution
tree .

The mp l s- i nter net-mu l t icast routing instance type uses ingress replication provider tunnels to carry IP multicast
data between routers through an MPLS cloud, using MBGP (or Next Gen)MVPN. Ingress replication can also be configured
when using MVPN to carry multicast data between PE routers.

The mpl s- inte rnet-mul t i cas t routing instance is a non-forwarding instance used on ly for control plane procedures. It
does not support any interface configurations. Only one mpls-internet-multicast routing instance can be defined for a logical
system . All multicast and unicast routes used for IP multicast are associated only with the default routing instance
(i net . 0), not with a configured routing instance. The mp l s- inte r ne t -mul t i cas t routing instance type is configured
for the default master instance on each router, and is also included at the [e dit p r otoco l s pim J hierarchy level in the
default instance.

www .juniper.net Next-Generation Multicast VPNs • Chapter 10- 45

Junos Layer 3 VPNs

Ingress Replication

■ Basic configuration
• For each mpls - internet - mul ti cast routing instance
• ingress-replication statement required under
• provider - tunnel statement
• [edit routing-instances routing-instance-name provider-tunnel
selective group source] hierarchy
• A new destination can be added in two ways
• Create a new tunnel
• Use an LSP template

C/2020 Juniper Networks, Inc .All Rights Resenie<J.

Jon1per8us1ness Use Only

Ingress Replication Basic Configuration

For each mpls-int ernet-multicast routing instance, t he ingress-replication statement is requ ired under the provider-t unnel
st atement and also under the [edit routing-instances routing-instance-name provider-tunnel selective group source]
hierarchy level.

When a new destination needs to be added to the ingress replication provider tunnel, the resulting behavior diff ers
depending on how the ingress replication provider tunnel is configured :

• c r ea t e- n ew- u cast- t u n nel : When t his statement is configured, a new unicast tunne l to the destination is
created, and is deleted when the destination is no longer needed. Use t his mode for RSVP LSPs using ingress
rep Iication.

• l a b e l -switched-p a t h- t emp l a te : When this statement is configured, an LSP template is used f or the for
the point-to-multipoint LSP for ingress replication .

Chapter 10-46 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Internet Multicast Topology

■ Internet multicast topology components

• IP routers
• Border routers
• IP interface toward multicast senders/receivers
• MPLS interface towards provider Multicast Core
- Full mesh IBGP for control plane

traffic
e
- Replication tunnels for data plane
Multicast ........
.., ...,
................ ....~ -.. Multicast traffic in
IP 7 -~ ~ , Unicast LSP tunn-,, el_s ....... ~ - '- IP
Router 1 / "'- /,-'_, B , "'- Router 3
Border MPLS .. , -,.-:; order

e. /
Ip
, t rf Router 1 , t rf - - ----- , ivt i PrfLS Router 3 , lrfP
me ace me ace 1..,.... 1n e ace 1nte ace
,,,l ................ ............

~ --
-- e ------------- ~ MPLS Core ..........................'. __-:_

Multicast ◄ -----
traffic
---
·---- ----- Border
Router 2
Border
Router 4
--------~@·---+ Multicast
traffic
IP IP
Router2 Router4

C 2020 Juniper Networks. lnc , AII Rights ReseM!<I,

Jon1per aus1ness use Onty

Internet Multicast Topology Components

The IP t opology consists of routers on the edge of the IP multicast domain. Each router has a set of IP interfaces conf igured
t oward the MPLS cloud and a set of inte rfaces conf igured toward the IP routers. Internet multicast traffic is carried between
the IP routers, th rough the MPLS c loud, using ingress replication tu nnels fo r the data plane and a fu ll-mesh IBGP session for
the cont rol plane.

www .j uniper.net Next-Generation Mult icast VPNs • Chapter 10- 4 7

Junos Layer 3 VPNs

Internet Multicast Configuration

■ Main configuration steps in the Border router

• Enable MPLS
• Configure a signaling protocol, such as RSVP or LOP
• Configure a full-mesh of IBGP peering sessions
• Configure the multi protocol BGP-related settings so that the BGP sessions
carry the necessary NLRI
• For 1Pv4/1Pv6: unicast, vpn, and mvpn signaling
• Configure IGP and eventual traffic engineering parameters
• Configure a global PIM instance on the interface facing the edge device. Not
toward the MPLS Core!
• Configure the ingress replication provider tunnel settings

~2020 Juniper Networlcs, Inc .All Rights Reserve<!.

Juniper Business Use Onty
Jun1Per
NETWORKS
48

Configuration Steps on The Border Router

This slide provides a list of the main configuration steps required on the Border router.

Chapter 10-48 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Internet Multicast Verification (1 of 2)

■ What to check for proper functionality?

• The Ingress Replication Status on Border Router
• Verify that the ingress replication is using a point-to-point LSP, and is in the Up state on
both ingress and egress side of the tunnel
• The Routing Table for the MVPN Routing Instance on Border Router
• Verify that the expected routes are present in the
routing-instance . mvpn routing table
• The MVPN Neighbors on Border Router
• To see that all expected neighbors are visible
• The PIM Join Status on Border Router at the receiver side
• To verify (Source, Group) information on expected Multicast flow

~2020 Juniper Networl<s, Inc .All Rights Reserve<!.

Juniper Business Use Onty
Jun1Per
NETWORKS
49

Configuration Steps on The Border Router

Th is slide provides a list of the main configuration steps required on the Border router.

www .j uniper.net Next-Generation Multicast VPNs • Chapter 10- 49

Junos Layer 3 VPNs

Internet Multicast Verification (2 of 2)

■ What to check for proper functionality? cont.

• The Multicast Route Status on Border Router
• To verify the presence of upstream neighbor and protocol , downstream interface
list/number of outgoing interfaces, (S,G) information, and forwarding state

~2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jo niper 8us1ness Use Only
Jun1Per
NETWORKS
50

Verifying Proper Functionality: Part 2

Th is slide provides some additiona l verification steps on the Border router.

Chapter 10-50 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Summary
■ In this content, we:
• Described the flow of control traffic and data traffic in a
next-generation multicast VPN
• Described the configuration steps for establishing a
next-generation multicast VPN
• Monitored and verified the operation of next-generation multicast VPNs
• Described the function of MVPN Internet Multicasting with Ingress Replication

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Onty
Jun1Per
.iETWOffKS
s1

We Discussed:
• The flow of control traffic and data t raffic in a next-generation MVPN;

• The configuration steps for establishing a next-ge neration MVPN;

• Monitoring and verifying the operation of next-generation MVPNs; and

• The function of MVPN Internet multicasting with ingress rep lication.

www .juniper.net Next-Generation Multicast VPNs • Chapter 10- 51

Junos Layer 3 VPNs

Review Questions

1. What is the primary difference between the

draft-Rosen approach to multicast VPNs and the
next-generation MVPN approach?
2. Name and briefly describe two of the seven MVPN NLRI types.
3. In a next-generation multicast VPN network what devices require a
tunnel services interface?

~2020 Jun,perNetworlcs, Inc . All Rights Reserve<!.

Juniper Business Use Onty
Jun1Per
HETWORl(S
s2

Review Questions
1.

2.

3.

Chapter 10-52 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Lab: MVPNs

■ Establish a multicast Layer 3 VPN (MVPN) between provider edge

(PE) routers.
■ Configure both inclusive and selective provider tunnels using the
point to multipoint (P2MP) LSPs.

~2020 Juniper Networlcs, Inc .All Rights Reserve<!.

Juniper Business Use Onty
Jun1Per
NETWORKS
53

Lab: MVPNs
The slide provides the objectives for th is lab.

www .j uniper.net Next-Generation Multicast VPNs • Chapter 10- 53

Junos Layer 3 VPNs

Answers to Review Questions

1.
The draft-Rosen required that the provider network be running PIM for signaling. The next-generation approach uses BGP to
signal the providers network and does not requ ire PIM be configured in the core.

2.
Type 1: Intra-AS Inclusive MVPN Membership Discovery

Type 2: Inter-AS Inclusive MVPN Membership Discovery

Type 3 : Selective MVPN Autodiscovery Route

Type 4 : Selective MVPN Autodiscovery Route for Leaf

Type 5: Source Act ive Aut odiscovery Route

Type 6 : Shared Tree Join Route

Type 7: Source Tree Join Route

3.
The first hop designated router, the candidate rendezvous point s, and all PE routers participating in t he multicast network,
unless using vrf-table-label option, requ ire the use of a tunne l services interface.

Chapter 10-54 • Next-Generation Multicast VPNs www.juniper.net

 Junos Layer 3 VPNs

Resources to Help You Learn More

Pathfinder http://pathfinder.juniper.net

http://www.ju n iper. net/tech pubs/content-

Content Explorer
a ppl i cations/content-explorer

Feature Explorer http://pathfinder.juniper. neVfeature-explorer

Learning Bytes www.juniper.neVlearningbytes
Installation and
www.juniper.neVcourses
configuration courses
http://forums.juniper.neVt5jTraining-Certification-
J-Net Forum
and/bdp/ Training_and_Certification
Certification program www.juniper.neVcertification
Courses http://www.juniper.net/training/technical_education
Translation tools http://www.juniper.net/customers/supporV#task

C2018 Juniper Networ1<s, Inc.All Rights Reserved. Jun1Per

N£T'o\ORl(S

Resources to Help You Learn More

The s lide lists on line resources available to lea rn more about Juniper Networks and technology. These resources include the
fo llowing sites:

• Pathfinder: An information experience hub that provides centralized prod uct details.
• Content Explorer: Ju nos OS and ScreenOS software feature information to find t he right software release and
hardware platform for yo ur network.

• Feature Explorer: Technical documentation for Junos OS-based products by product, task, and software
release, and downloadable documentation PDFs.

• Learning Bytes: Concise tips and instructions on specif ic features and functions of Jun iper technologies.

• Installation and configuration courses: Over 60 f ree Web-based t raining co urses on product installation and
configuration Uust choose eLearn ing under Delivery Modality).

• J-Net Forum: Train ing, certification, and career topics to discuss with your peers.

• Juniper Networks Certification Program: Complete details on the certification program, including tracks, exam
details, promotions, and how to get started.

• Technical courses : A complete list of instructor-led, hands-on courses and se lf-paced, eLearning courses.

• Translation tools: Several online translation tools to help s implify migration tasks.

www.juniper.net
Junos Layer 3 VPNs

www.juniper.net
 un1Pe[
NETWORKS
Education Services

Junos Layer 3 VPNs

Appendix A: Layer 3 VPN Egress Protection

Engineering Simplicity
Junos Layer 3 VPNs

Objectives

■ After successfully completing this content, you will be able to:

• Describe Layer 3 VPN Egress Protection Methods

~2020 Jun,per Networks, Inc .All Rights Resenie<I.

Jo niper8us1ness Use Only
Jun1Per
NETWORKS
2

We Will Discuss:
• Ju nos OS support for different types of egress protection.

Appendix A-2 • Layer 3 VPN Egress Protection www.juniper.net

 Junos Layer 3 VPNs

Agenda: Layer 3 VPN Egress Protection

➔ Layer 3 VPN Egress Protection

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Onty
Jun1Per
.iETWOffKS
3

Layer 3 VPN Egress Protection

The slide lists the topic we will discuss.

www .juniper.net Layer 3 VPN Egress Protection • Append ix A- 3

Ju nos Layer 3 VPNs

Layer 3 VPN Egress Protection

■ Egress Protection can be separated into three different categories

• Stub Link
• Cannot mitigate failure in all topologies (e.g no LFA to Backup/protector node)
• Can run on older SW
• Stub Alias
• Addresses lack of LFA coverage and can operate with both RSVP and LOP
• Requires SW upgrade of the routers
• Stub Proxy
• Addresses lack of LFA coverage and can operate with both RSVP and LOP
• Does not require SW upgrade of the Core routers

~ 2020 Juniper Networlcs, Inc . All Rights Reserve<!.

Juniper Business Use Onty

Egress Protection Alternatives

The slide highlights the th ree topics with in Layer 3 VPN egress protection we discuss next.

Appendix A-4 • Layer 3 VPN Egress Prot ection www.j uniper.net

 Junos Layer 3 VPNs

Stub Link: Layer 3 VPN Egress Protection

■ Provides for fast restoration of Layer 3 VPN services to a multihomed
CE router
• Requires protector PE to keep learned Site 2 routes from protected PE
• VPN labels received from protected PE allow protector PE to associate packets from PLR
to the correct routing table during a failure situation
• PLR must have pre-calculated an LFA to the context ID (an anycast like
address belonging to PE2 and PE3)
Protected PE
loO 193.168.2.2 e2
Site 1 l 10 0 ~- e -ge:;/0/4- - - -
< ·
CE-
.

loO 193. 168.11.1

.,.. . -12.0
124
~
9e. 1101
s
tIS ·
PE1
_Data Path
- - - -
- ~
· ·
- .,..
:=- - - . EP~E_3
.,..::EE ._.110.0.13.0/24
2
,---.
_ . · . loO 193.168.11.2
loO 193.168.2.1 P (PLR) 1
-----=-..-J Provider Core
~
1--~- loO 193.168.2.3
ISIS Level 2 Protector PE

~2020 Juniper Networlcs, Inc .All Rights Reserved.

Juniper Business Use Onty

Stub Link: Egress Protection Scenarios

The slide shows the two egress protection scenarios.

www .j uniper.net Layer 3 VPN Egress Protection • Append ix A- 5

Junos Layer 3 VPNs

Stub Link: Egress Protection Topology

■ CE-2 is multihomed to PE2 and PE3

• Layer 3 VPN established between PE routers
• Core IGP is ISIS Level 2
• EBGP as PE-CE protocol
• LOP is used as signaling protocol for LSPs
• L3VPN routes from PE2 advertised with Local Pref= 300

C/2020 Juniper Networl<s, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Onty

Fast Restoration
Link and node protection works well on transit routers of MPLS LSPs. However, it doesn't work so well in the context of a
Layer 3 VPN when dealing with the failure of an egress PE router. As you know, it is the PE routers that store the VPN routing
and forwarding information. It is obviously not an easy task to protect against a PE node failure in a Layer 3 VPN scenario.
The Junos OS supports the protection of a Layer 3 VPN egress PE. The scenario on the slide shows a multihomed CE. It is
connected to PE2, ca lled the Protected PE, as all traffic between sites traverses PE2 . PE3 provides a backup path to site 2 . It
will be PE3 that will need to receive and store Layer 3 VPN state from PE2. PE3 wil l be referred to as the Protector PE. It will
be the P router that will f irst detect a failure in PE2 . The router wi ll act as the Point of Local Repair (PLR). To perform this
function, the PLR must have precalculated a loop free alternate (LFA) path to an anycast address (called the context ID) that
will be shared by both the Protected and Protector PE routers.

Appendix A- 6 • Layer 3 VPN Egress Protection www.juniper.net

 Junos Layer 3 VPNs

Stub Link: PLR Configuration

■ Configuration
• Node-link protection
• Per prefix calculation for backup paths
• Load balancing per-packet
[edit) [edit]
user@p2i s h o w protocols user@p2# show policy- options
mpls { policy-statement load-balance {
interface all ; term 10 {
} then (
isis { load-balance per-packet ;
""'jb...
a -,
ck_u_p - s-p ,f..._-o..,
p t-.
i -on_s_ p_e_r - p-r -e f...i-x-- c-a .,..
lc_u.,..
l a..,.t...
io---.
nJ
accept ;
level 1 disable ; ~ )
interface all { )
I n ode-link-protecti on ; )
}
I [ ed it]
ldp { user@p2t show routing - options f orwar di ng - table
track- igp-met ric ; I export load- balance ;
interface all ;
)

IGP can calculate an LFA path Lowest cost next hop as well as
to all learned destinat ions LFA nexthop installed in forwarding table

C/ 2020 Juniper Networks, Inc .All R,ghlS ReseM!<I.

Jon1per8usiness Use Only
Jun1Per
~ ETWORKS
7

Stub Link: PLR Configuration

The slide shows the configuration of the PLR router. In the slide, you can see that LDP is being used as the signa ling protocol.
As you know LDP relies on the IGP (ISIS in th is case) to determine the best path for an LSP. By configuring
node-link-protection under ISIS, the router will compute a backup path for ISIS learned routes. In order to install the backup
next hop in the forward ing table, you need to configure the router to perform per-packet load ba lancing. Once ISIS has
determined a backup path, LDP wi ll also have a backup path.

It is important to keep in m ind that Junos LFA is per-prefix by default but that the configuration option
backu p-spf-op t ion s pe r -p r e fi x-ca l c u la t ion is needed to allow calculation of backup next hops for non-best
prefix originators in combination with node-link-protection LFA.

The next few slides will show the change in forwarding table due to th is configuration .

www .j uniper.net Layer 3 VPN Egress Protection • Append ix A- 7

Junos Layer 3 VPNs

Stub Link: Context Identifier (1 of 2)

■ Context Identifier has two purposes

1. Anycast address advertised into IGP
• Allows IGP and LOP to find a two paths to same destination
[edit protocols mpls) [edit protocols mplsJ
user@pe2 i show 1..-
P -ro- t-e c
_ t_e_d _P_E...,I user@pe3 # show 1..-
Pr - o-te
_ c_t_o _r P
_ _E ..I
i nterface all ; _ _ inter face al l; _ _
egress-protecti on { egress- protection {
context- identifier !l0 . 0 . 0 . 3l { context- identifier ! 10 . o . o . 31 {
primary ; protector;
} }
} }

~
user@p2> s h ow isis d ataba se e x tensive
IS - IS leve l 2 link- state database :

pe2 . 00-00 Sequence : Ox9 , Checksum : Ox88 94 , Lifetime : 909 secs

IS neighbor : pe2 . 02 Metric : 10
Two -way fragment : pe2 . 02-00 , Two -way first fragment : p e2 . 02-00
IP prefix : 10 . 0 . 0 . 3/32 ! Me t ric : l ! Interna l Up

pe3 . 00-00 Sequence : Ox9, Checksum : Oxf7df , Lifet ime : 862 secs
I S neighbor : pe3 . 02 Metric : 10
Two-way fragment : pe3 . 02-00, Two-way first fragment : p e3 . 02-00
IP prefix : 10 . 0 . 0 . 3/32 ! Me tric : 63 I Internal Up

~ 2020 Juniper Networks, Inc . All Rights ReseM!<I.

Juniper8us1ness Use Onty
Jun1Per
I\IETWOffKS
8

Anycast Address
The slide shows how to configure the context ID to be used as an anycast address by both the Protected and Protector PE. As
a result of this configuration, the PE2 and PE3 will use ISIS to advertise that this network is attached to it. The slide shows
the resu lting ISIS database on the P2 router.

Appendix A-8 • Layer 3 VPN Egress Protection www.juniper.net

 Junos Layer 3 VPNs

Stub Link: Context Identifier (2 of 2)

• Context Identifier has two purposes (contd.)

2. All VRF routes advertised by protected router have a BGP next hop of the
context identifier (next hop self)
• Protector router builds a special routing table for protected routes (those routes with BGP
next hop of context identifier)
j Protected PE j j Protector PE j
[edit protocols bgp] [edit policy-options]
user@pe2# show user@pe3# show
g r oup int { policy-statement ep-remote {
from community custlOO ;
family inet- vpn { then accept ;
unicast { }
egress-nrotect ion { community custlOO members target : 65512 : 100;
context-identifier {
10 . 0 . 0 . 3 ; [edit pr otocols bgp)
user@pe3# show
group int {
[edit routing-ins tances vpnl]
user @pe2f show family inet-vpn {
instance-type vrf; unicast {
egress- orotection I egress- p r otection {
context-identifier { keep- impor t .-! ;!
e-p -- r-em-o-te....
10 . 0 . 0 . 3 :

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Onty
Jun1Per
.iETWOffKS
9

Next-Hop-Self
The configuration of the PE2 router (the Protected PE) causes the router to begin advertising its VRF routes with a BGP next
hop of the context identifier (10.0.0.3 ). The configuration of the PE3 router causes it to treat any rece ived L3VPN routes in a
special manner if the BGP next hop is the same as the configured context identifier (these are called protected routes). The
next few slides wi ll show how PE3 treats protect ed routes from PE2 in a special way. You can optionally configure an import
policy t o f ilter the protected routes.

www.juniper.net Layer 3 VPN Egress Protection • Append ix A-9

Junos Layer 3 VPNs

Stub Link: P2's Forwarding Table

■ P2 has a backup next hop to reach the context ID

user@p2> show ldp database
Inpu t l abel database , 193 . 168 . 1 . 3 : 0--193 . 168 . 1 . 2 : 0
Label Prefix
299792 10 . 0 . 0 . 3/32

user@p2> s h o w route f orwarding -table fami l y mp l s e x tensive d estin ati o n 299792

Routing table : default . mpls [ Index 8]
MPLS :

!
Destination : 299792 (S=O ) !
Route type : use r
Route reference : 0 Route interf ace- i ndex : 0
Flags : sent to PFE, rt nh decoupled
Next -hop type : u nili s t Inde x : 10 48575 Refe r e nce : 2
r.N~e~xt
nh~o::::
p~: -,1~ .u
.u:"" . ;:,~o . :lr-- - - - - - - - - - - - - - - - - - , .- - Towards PE2
l'I"'""!
Next - hop type : Pop Index : 1030 Reference : 1
Next -hon i nterface : ne -1 /0/8 . 300 We iaht : Ox l
Nexthop : l U. U. ~o . 2
Next - hop type : Swap 299776 Index : 1017 Reference : 2..--- Backup towards PE3
Next-hop i nterface : fo e-1/0/8 . 100 Weight : OxfOOO
/
Remember this label for later!!!

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1peraus1ness use Only

P2's Forwarding Table

The slide shows how P2 has installed two next hops in its mpls.O forwarding table for packets resolving to 10.0 .0.3 (VPN
routes). Notice that because of the weight value, only the next hop that goes towards PE2 wil l be used unless there is a
failure along that path. Remember that the label used to reach PE3 is 299776. This will be the outer label on prot ected
packets at the time of fai lure. PE3 wil l need to be able to properly route packets that arrive with an out er label of 299776.

Appendix A-10 • Layer 3 VPN Egress Prot ect ion www.juniper.net

 Junos Layer 3 VPNs

Stub Link: PE2 Advertises Protected Routes

■ PE2 sets next hop of L3VPN routes to the context ID

• Includes VPN label as usual
• Protector (PE3) will use the advertised labels to build routing tables to deal with protected
data
user@pe2 > show route advertising - p rotocol b gp 193.168.1.5 extensive

vpnl . inet . O: 6 destinations , 8 routes (6 active , 0 holddown , 0 hidden)

* 10 . 0 . 22 . 0/2 4 (2 entries , 1 announced)
BGP group int type Internal
n~,-~- n;~ ,- ;--,, ,-.... r : 193 . 168 . 1 . 4 : 19
VPN Labe l : 16
Nexthop : 1 0 . 0 . 0 . 3 If accepted by import policy on Protector PE,
Flags : Nexthop Change these routes are stored in bgp.13vpn.O table
Localpref : 300
AS path : ( 65512) I Two other tables are built from these routes:
Communities : target : 65512 : 100

* 193 . 168 . 11 . 2/32 (1 entry, 1 announced) _ 10.0.0.3_ .mpls.O

BGP group int type Inte rnal
Route Distinaui sher : 193 . 168 . 1 .4: 19 And
VPN Label : 16
Nexthop : 10 . 0 . 0 . 3 _ 10.0.0.3-vpn 1_ .inet.0
Flags : Nexthop Cha nge
Localpref : 300
AS path : (65512) 65102 I
Communities : target : 65512 : 100

~ 2020 Juniper Networks, Inc . All Rights ReseM!<I.

Joniper8us1ness Use Onty

PE2's Routes
The slide shows the protect ed routes being advertised by PE2 . Notice that the next hop is the context identifier. Also, notice
that the label is 16. This will be the inner label of all VPN packets sent from PE1. It is important for PE3 to be aware of this
label so that it wi ll be able to deal with protected traffic (inner label 16) during a fa ilure.

www .j uniper.net Layer 3 VPN Egress Protection • Append ix A- 11

Junos Layer 3 VPNs

Stub Link: Protector PE's mpls . O table

■ Advertised LOP label for 10.0.0.3 is mapped to protected MPLS table

l Protector PE I
user@pe3> show route t able mpls.O

mpls . O: 11 destinations , 11 rou tes (11 active , 0 ho lddown , 0 hidden)

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

0 *[MPLS/0] 00 : 18 : 17 , metric 1
Receive
1 *[MPLS/0] 00 : 18 : 17 , metric l
Receive
2 *[MPLS/0] 00 : 18 : 17 , metric 1
Receive
13 *[MPLS/0] 00 : 18 : 17 , metric l
Receive
16 *[VPN/OJ 00 : 18 : 13
to table vpnl . inet . O, Pop
299776(S=O) *[MPLS/0] 00 : 15 : 53
During Failure
to table _ 10 . 0 . 0 . 3_ . mpls . O
...__ Label is popped, leaving one more
label, and packet is directed to another
table fo r lookup on inner label

C2020 Jun,perNetworl<s, Inc .All Rights Reserlle<I.

Jon1peraus1ness use Onty

PE3's mpls . Otable

Even before a fa ilure, we can see that PE3 is able to forward MPLS packets that arrive with an outer label of 299776
(protected packets). Packets that arrive with this label will have their outer label popped and then have the singly, labeled
packetdirectedtothe context - i d . mp l s . O table.

Appendix A-12 • Layer 3 VPN Egress Protection www.juniper.net

 Junos Layer 3 VPNs

Stub Link: Protected Routes on Protector

■ Protector performs a label lookup, pop, and then one last IP routing
table lookup
I Protector PE I
user@pe3 > show route table _10 . 0.0.3_.mpls.O

_ 10 . 0 . 0 . 3_ . mpls . O: 1 destinations , 1 routes (1 active , 0 holddo wn , 0 hidden)

+=Active Route , - = Last Active , *=Both
During Failure
'11~6, - - - - - - ; -
* [E
r,;:::;
g -::-:
r e~s:':
s ~ P~r:-:::
o-;:-:
te~c:;:-
t "io::::n":i
;T 1 770';; 376 - , . . _ Label is popped, leaving no more
] -:onroi'.',71 aA°',.:"::i
1 to table 10 • o • o •3- vpnl_. inet · o labels, and packet is directed to another
VPN label as advertised in table for lookup on IP header
L3VPN routes from Protected PE
user@pe3> show route table _10.0.0.3 - vpnl_.inet.0

_ 10 . 0 . 0 . 3-vpnl_ . inet . O: 2 destinations , 2 r outes (2 active , 0 holddown , 0 hidden)

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

10 . 0 . 22 . 0/ 24 *[Egr ess- Pr otection/170] 00 : 21 : 27

> to 10 . 0 . 23 . 2 via ige - 1/0/ 5 . 0 ! ~
193 . 168 . 11 . 2/32 *[Egress- Protection/17 0 00 : 21 : 27 "
~
> t o 10 . 0 . 23 . 2 via e -1 /0/5 . 0 Protector PE·svRF interface

Received L3VPN routes from

Protected PE

C 2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jo niper8us1ness Use Onty

Final Lookups
Remember, that all of these tables are set up prior to a failure. The sl ide shows t hat PE3 performs a lookup on the singly
labeled packet, pops the last label leaving an IP packet, and directs the packet to an IP based ro uting table f or a final lookup.
The final IP lookup wil l cause t he router to finally send the rema ining IP packet out of the VRF interface.

www .j uniper.net Layer 3 VPN Egress Protection • Append ix A- 13

Junos Layer 3 VPNs

Stub Link: Enhanced Egress Protection

■ Enhanced Egress Protection

• Support starting in Junos OS Release 13.3
• Enables the IGP to advertise egress protection availability
• Addresses the lack of LFA coverage
• Two possible modes to configure for the context ID

[edit .. . egress-protection context-identifier context-identifier]

user@lab # set advertise - mode (stub- alias I stub-proxy)

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per 8usiness Use Only
Jun1Per
.iETWOffKS
14

Stub Link: Enhanced Egress Protection

Starting in Junos OS Release 13.3, enhanced point-of-local-repair (PLR ) functionality is available, in which the PLR reroutes
service traffic during an egress fai lure. Previously, if the PLR was not directly connected to the protector router, the loop-free
alternate (LFA) route did not find the backup path to the protector.

A new configuration statement, adve rti se-mode, enables you to set the method for the interior gateway protocol (IGP) to
advertise egress protection availability

Appendix A-14 • Layer 3 VPN Egress Protection www.juniper.net

 Junos Layer 3 VPNs

Stub Alias: Advertise Mode (1 of 2)

■ Advertise Mode stub-alias Requires JU NOS upgrade in the core in

PLR devices
• Uses IGP & TED to calculate and set up the LSP to Protector
• IS-IS advertises context ID/Label into the TED via TLV149
• Protector TLV routes => inet.5 as IS-IS routes in PLR, Protocol NH = Protector
RID. If TLV has a label, it is added to inet.5 for LOP to use
• CSPF uses the TL V IP address for tunnel endpoint calculation
• RSVP preferred if network does not support 100°/o per-prefix LFA coverage
otherwise LOP is fine

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
15

Stub Alias: Advertise Mode

In the stub alias method, the LSP end-point address has an explicit backup egress node where the backup can be learned or
configured on the penultimate hop node of a protected LSP. With this model, the penultimate hop node of a protected LSP
sets up the bypass LSP tunnel to back up the egress node by avoiding the primary egress node. This model requ ires a Ju nos
OS upgrade in core nodes, but is flexible enough to support al l traffic engineering constraints. The PLR learns that the
context ID has a protector. When the primary context ID goes down, packets are rerouted to the protector by way of a
pre-programmed backup path . The context ID and protector mapping are configured or learned on the PLR and signaled in
the IGP from the protector. A routing table cal led inet.5 on the PLR provides the configured or !GP-learned details.

IS-IS advertises context IDs into the TED through an IP address TLV. IS-IS imports this TLV into the TED as extended
information. IS-IS advertises the protector TLV routes in the inet.5 route for the context ID with protocol next hop being the
protector's router ID. If the protector TLV has a label, the label is added to the route in the inet.5 routing table for LDP to use.

CSPF considers the IP address TLV for tunnel endpoint computation .

With the stub alias model, the protector LSP setup does not require any changes in any nodes. But bypass LSP setup for
node protection requires changes in the penultimate-hop router and the protector router.

LDP is useful in the case when the network supports 100 percent LFA coverage but does not support 100 percent per-prefix
LFA coverage. LDP sets up a backup path with the protector with the context label advertised by the protector to the service
point. In networks in which 100 percent LFA coverage is not available, it is useful to have backup LSP LFAs with RSVP-based
tunnels.

www .juniper.net Layer 3 VPN Egress Protection • Append ix A- 15

Junos Layer 3 VPNs

Stub Alias: Advertise Mode (2 of 2)

■ PLR to Protector tunneling

• Protector announces context ID and a Label in IS-IS
• Possible PLR routers store this in inet.5 table
• PLR pushes 2 labels for protected traffic
• TLV149 label= bottom , LOP to Protector= top
• Protector pops the top label on packet arrival
• TLV149 label contains the protected traffic context ID
IS-IS
TLV149:
ContextlD I
and Label

PLR candidate
PLR candidate

C2020 Jun,perNetworl<S, Inc .All Rights Resenie<J.

Jon1per8usiness Use Only

Stub Alias: PLR to Protector Tunneling

The protector router puts a label and the context ID IP prefix in the ISIS DB (inside TLV type 149, the SID/ Label Binding TLV).
The protector stops announcing the context-id by LDP or ISIS as an attached address.

Based on this information, all routers that might be a PLR in the network create routing entries in inet.5. The bottom label of
this entry is the label advertised in TLV 149 and the top is the LDP label used at the PLR to reach the protector. So we are
tunneling the 149 label in LDP.

PLR pushes the TLV149 label on the traffic and then another LDP label on top that gets the traffic to the protector node. This
second label (the LDP one) is picked from the LDP database based on it being a label able to reach the protector node
announcing the context id with TLV149. in the stub-link style the LDP label would be toward the context ID IP. In an LFA
topo logy with coverage problems this label would not exist. The PLR on the other hand will always have an LDP label towards
any other routers' router ID.

When the traffic gets to the protector node and the LDP label is popped, the remaining TLV149 label lets the protector node
understand wh ich context ID the protected traffic relates to and should be forwarded by.

Appendix A-16 • Layer 3 VPN Egress Protection www.juniper.net

 Junos Layer 3 VPNs

Stub Alias: Advertise Mode Example

■ CE-2 is multihomed to PE2 and PE3

• Layer 3 VPN established between PE routers
• Core IGP is ISIS Level 2
• RSVP is used as signaling protocol for LSPs
• PE3 is the Protector protecting PE2

loO 193.168.1 1. 1
'
1
'
CE1
,.., ;J.O.o_ 7-, 0
<.~
....
9e-11016 - - -
PE1
_ _,,,-
~ ·t15- -ge-0101-2
-

- - -
e-- -....
-

p
loO 193.168.1. 1 -

~2020 Juniper Networks, Inc .All Rights ReseM!<I.

Juniper Business Use Only
Jun1Per
I\IETWORKS
17

Stub Alias: Example Topology

The slide shows the example topology for the fol lowing examples.

www .j uniper.net Layer 3 VPN Egress Protection • Append ix A-17

Junos Layer 3 VPNs

Stub Alias: Advertise Mode Configuration

■ Configuration of PE2 and PE3

! Protected PE ! ! Protector PE !
[edit protocols] [edit protocols]
user@pe2i show user@pe3il show
rsvp rsvp
interface all { interface all {
link-pro tection ; link-protection;
) }
interface fxp0 . 0 { interface fxpO . O {
disable ; disable ;
} )
} )
mpls mpls

egress-protection { egress-protection {
context-identifier 6 . 6 . 6 . 6 { context-identifier 6 . 6 . 6 . 6 {
primary; protector ;
advertise-mode stub-alias ; advertise-mode stub-alias;
)
) )
) )
bgp
[edit routing - instances vpn] group int {
user@pe2i show
instance - type vrf ; family inet-vpn {
egress-protection { u nicast {
context-identifier { egress-protection;
6 . 6 . 6 . 6;

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Onty

Required Configuration for PE2 and PE3

Configure the stub-alias mode in both the Protected PE router and the Protector PE router under hierarchy [edit
protocol s mp l s egress-pr otect i on contex t-identifier context-identifier] .Underthesame
hierarchy, configure the Protected PE as prima r y and the Protector PE as p r otector.

Appendix A-18 • Layer 3 VPN Egress Protection www.juniper.net

 Junos Layer 3 VPNs

Check the Failover to Backup LSP

user@PEl> show route 10.10.50 extensive table vpn.inet.O
vpn . inet . O: 6 destinations , 7 routes (6 active , O holddown, O hidden)
10 . 10 . 50 . 0/24 (2 entries, l announced)

Path 10 . 10 . 50 . 0 from 10 . 255 . 162 . 96 vector len 4. Val : 1

*BGP Preference : 170/-101

Next hop type : Router, Next hop index : 635

Next hop : 10 . 10 . 10 . 2 via ae-0/0/2 . 0 . se l ected
Labe l operati on: Push 16 , Push 300064(top)

user@PE2> show route table _ 6.6 . 6.6_.mpls.O

6 . 6 . 6 . 6_ . mpls . O: 1 destinations , 1 routes (1 active , O holddown , O hidden)
+=Active Route , - = Last Active , *=Both

*[Egress-Protection/170] 00 : 22 : 57
to table _ 6 . 6 . 6 . 6-vpn_ . inet . O

user@PE2> show route table _ 6.6.6.6 - vpn_ .inet.0

_ 6 . 6 . 6 . 6-vpn_ . inet . O: 2 destinations , 2 r out es (2 act ive , 0 holddown , 0 hidden)
+ = Active Route , - = Last Active , * = Both

10 . 10 . 30 . 0/2 4 *[Egress-Pr otection/170 ] 00 : 02 : 11

t o table vpn . ine t . O
( 10 . 10 . 50 . 0/2 4 1 *[Egress-Protection/170] 00 : 02 : 11
> to 10 . 10 . 30 . 2 via ge-3/2/4 . 0

C2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usiness Use Only

The Backup LSP

During a break on the primary connection, the protector PE is routing the prefixes related to the context ID (10.10.50.0/24).
PE3 is the Protected PE and PE2 is the Protector PE.

• Checking the route to 10.10.50/24 in PE1 revea ls an active route using the ge-0/0/2.0 interface pushing label
16 on the packet and an additional label 300064 on top.
• Checking the PE2 router's label space we can find out that label 16 can be found in the context ID's LSP table
_6.6 .6 .6_.mpls.O. It shows being used for Egress Protection having its next hop to table
_6.6 .6 .6-vpn_.inet.O.

Table _6.6 .6 .6-vpn_.inet.O is for the routing instance vpn protected routes and it shows that destination 10.10.50.0/24
can now be reached using PE2 's ge-3/ 2/4.0 interface using next hop 10.10.30.2, which is the PE2 facing interface on router
PE3.

www.juniper.net Layer 3 VPN Egress Protection • Append ix A- 19

Junos Layer 3 VPNs

... and the IGP Routing

user@PEl> s how r oute 6 .6 . 6 .6

inet . O: 47 destinations , 47 routes (46 active , 0 holddown , 1 hidden)
+=Active Rou te , - = Last Active , *=Both

6 . 6 . 6 . 6/32 *[IS-IS/15] 00 : 04 : 08 , metric 31

> to 10 . 10 . 10 . 2 via ge- 0/0/2 . 0

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

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

6 . 6 . 6 . 6/32 * [LDP/9] 00 : 04 : 08 , metric 1

> t o 10 . 10 . 10 . 2 via ge-0/0/2 . 0 , Push 300064

l+ -
ine t . 5 : t1 destinations ,
Ac t ive Route , - =
1 r outes (1 active , 0 ho l ddown , 0 hidde n)
Last Active, *= Both

6 . 6 . 6 . 6/32 * [ IS-IS/15] 00 : 04 : 08 , metric 31 , metric2 1

> to 10 . 10 . 10 . 2 via ge- 0/0/2 . 0 , Push 299856, Push 299920(top)

~ 2020 Jun,per Networks, Inc . All Rights ReseM!<I.

Joniper8us1ness Use Only

Checking the Routing Functionality

Checking the route to the context ID in PE1 we can notice the presence of routing table inet.5 having the IGP route for the
protected context ID and also LDP labels added from the received TLVs.

Appendix A-20 • Layer 3 VPN Egress Protection www.juniper.net

 Junos Layer 3 VPNs

Stub Proxy: Advertise Mode (1 of 2)

■ Advertise Mode stub-proxy

• Does not require JUNOS upgrade in the core devices
• No TLV149, does not build inet.5 in PLR node
• Can only use RSVP, not LOP due to inflated metric advertised in the IGP
• Primary and Protector nodes announce a link to a virtual proxy node
• The Primary egress node advertises the Context ID node into the IS-IS and TE
• Proxy node announces the Proxy ID with TLV135
• Stub link, no transit node = overload in IS-IS LSDB
• Primary nodes penultimate node can behave as PLR

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
~ETWORKS
21

Stub Proxy: Advertise Mode

A stub proxy mode is one that only appears at the end of an AS path, which means it does not provide transit service. In this
mode, known as the virtual or proxy mode, the LSP end-point address is represented as a node with bidirectional links, with
the LSP's primary egress node and backup egress node. With this representation, the penultimate hop of the LSP primary
egress point can behave like a PLR in setting up a bypass tunnel to back up the egress by avoiding the primary egress node.
This model has the advantage that you do not need to upgrade Junos OS on core nodes and wi ll thereby help operators to
deploy this technology.

In RSVP, the behavior changes are only in the protector and primary routers. RSVP terminates the LSP and the bypass LSP to
the context ID. If the context ID is the protector, a non-null label is signaled. Otherwise, it will be based on the configuration or
the requested label type. RSVP verifies the Explicit Route Object (ERO) from the path for itself and the context ID. RSVP sends
the Resv message with two Record Route Object (RRO) obj ects-one for the context ID and one for itself. Th is simulates the
penultimate-hop router to do node protection with the protector for the primary for context ID LSP. As the fast reroute
(FRR)-required bypass, the LSP has to merge back to the protector LSP penultimate-hop router setup bypass to context ID
through the protector by avoiding the primary.

LDP cannot use the stub proxy method due to the inflated metric advertised in the IGP.

The context ID is represented as a node in the traffic engineering (TE) and IGP databases. The primary PE device advertises
the context node into the IGP and TE databases. The primary PE device and the protected PE device support one link to the
context node with a bandwidth and a TE metric. Other TE characteristics of TE links are not advertised by Junos OS.

www.juniper.net Layer 3 VPN Egress Protection • Append ix A- 21

Junos Layer 3 VPNs

Stub Proxy: Advertise Mode (2 of 2)

■ PLR to Protector Tunneling

• Virtual Proxy node in IS-IS LSDB
• Protected and Protector nodes announce links to Proxy node
- Protected node's link has lower metric than Protector's link
• Protector node announces the context ID in TLV135
• PLR candidates have now 2 paths to context ID IP
• PLR creates RSVP LSPs to both Protected and Protector nodes
,.--- - - - - - - - - - - - - - - - - - - - -- F'FOtected
IS-IS ~ PLR andidate
TLV135: ~ Stub f Context ID IP
ContextlD IP
reachability
l."""" Ink
ow ~"i'h""...,.. Virtual
~ Node
v ia 2 alternate C
,,,
paths
to,,¢"~,c
e s\~ -'~
,, ~~~

PLR candidate
PLR cand idate
- _,,,. Protector

C2020 Juniper Networks, Inc . All Rights Resenie<I.

Jon1per8us1ness Use Only

Stub Proxy: PLR to Protector Tunneling

Instead of trying to reach the context ID, the PLR is trying to reach it via the Protected or the Protector nodes. Instead, both
primary and protector announce themselves connected to a fake context ID node, which is a virtual node handling the proxy
node function.

The virtual node in the IS-IS LSDB announces the context ID with a TLV 135, e.g. the same used in the stub-link style.

Now all PLR routers (candidates to eventually handle PLR function depending on how the network topology might change)
see two paths to the context ID. One via the low metric virtual link between Protected node and the virtual context ID node
and another high metric path between the Protector node and the virtual context ID node.

It is important to note that virtual context ID node is set to overload in ISIS, it is fake so it would not be much good to forward
any traffic.

The reason LOP doesn't work here is because we are not doing any tunneling. If there is a coverage problem and the PLR
path to the protector goes back on itself then the path to the protector is still infeasible for LFA, so no LOP label will be
available, so RSVP is the on ly option.

RSVP can tunne l the traffic instead. Because the context ID the PLR node is trying to get to is no longer advertised as
attached to the Protected (primary PE) but instead appear to be attached to the virtual context ID node reachable behind the
Protected or the Protector nodes the PLR can do RSVP bypass (node protection) LSP to reach it. Basically the PLR builds a
node protection bypass LSP that goes to the virtual context ID node via the protector, ready for the failure of the Protected.

Appendix A-22 • Layer 3 VPN Egress Protection www.juniper.net

 Junos Layer 3 VPNs

Stub Proxy: Advertise Mode Example

■ CE-2 is multihomed to PE2 and PE3

• Layer 3 VPN established between PE routers
• Core IGP is ISIS Level 2
• RSVP is used as signaling protocol for LSPs
• PE3 is the Protector protecting PE2
loO 172.16.0.2
..,......__ loO 172.16 .0.1 Protected PE
Primary Data Path loO 172.1 6.183.56
10 , - - ~~ ,. ~ g e~ rrr2 - - - AD\
~ 10 .8.0.0124 .2 ~

" ' ·e • e-
. 1.0 01,, • _.,.
. < 4 2 .-. ~ , ,. 2
::::eE ,.1 .--,_..· E2
10 2 0124
9e' 11<10 - - -- ~ -- - - - 10 .7 .0 .0/24 .......... 17.10 C)\'2;0. ----
PE1 ·2 -; P E 3 ~ 9,e·' ,09.0 ·
10 5
100172.16.1 83.55 P1 · - .o.0;24 2~ 1
..__ ...., ~ o 112.1 6.0 .39 _,,.. ~ _
1 183 59
_
Protector PE

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per 8us1ness Use Only

Stub Proxy: Example Topology

In addit ion to egress protection, this example demonstrates an enhanced PLR funct ion, in which the PLR reroutes service
traffic during the egress fai lure. This enhancement is supported in Ju nos OS Release 13.3 and later. In th is example, Device
P1 (the PLR) is direct ly connected to Device PE3 (the protector). Using the configuration statement, adve r tise-mo d e
stu b-p r oxy, enables you to set the method for the interior gateway protocol (IGP) to advertise egress protection
availability.

www .juniper.net Layer 3 VPN Egress Protection • Append ix A- 23

Junos Layer 3 VPNs

Stub Proxy: Advertise Mode Configuration

■ Configuration of PE2 and PE3

! Protected PE ! ! Protector PE j
~
[edit protocols )
user@ PEl i show
[edit protoco l s ] [edit protocol s ] rsvp
user@PE21 show user@PE31 show i nter f ace a ll ;
rsvp r svp inter f ace fxpO . O (
i nte rface all ; interface a l l ;
disab l e ;
interface fxpO . O { )
mpls d i s ab l e ; }
)
mpls
label - s witched- path toPE26 . 6. 6. 6 { }
to 6 . 6 . 6 . 6; mpls label- s witched- path toPE26 . 6. 6 . 6 {
egress-protecti on; to 6 . 6 . 6 . 6;
I egress-protection ( egress-protection;
egress - protecti on ( context - identifier 6 . 6 . 6 . 6 (
I
context- i dent i f i er 6 . 6 . 6 . 6 ( protector;
p rimary ; advertise-mode stub-pr oxy ; ldp (
a dver t i se-mode s tub-proxy ; )
track- i gp - metri c ;
I )
i nterface all ;
} )
i nterface fxpO . O {
} bgp disab l e ;
bgp group ibgp I )
group ibgp { type internal ; }
type internal; fami ly inet-vpn {
f ami l y i net-vpn ( unicast
uni cast egress- protecti on (
egress-protection ( keep- import remote-vrf;
con text-identi f ier {
6 . 6 . 6 . 6; l dp {
t rack-igp- met ric;
ldp {
track- igp-metric;

C2020 Juniper Networl<s, Inc .All Rights ReseM!<I.

Juniper8us1ness Use Only
Jun1Per.iETWOffKS
24

Stub Proxy: Configuration of the PE Routers

Configure the stub-alias mode in both the Protected PE router and the Protector PE router under hierarchy [edit
protocol s mp l s egress-pr otect i on contex t-identifier context-identifier] .Underthesame
hierarchy, configure the Protected PE as prima r y and the Protector PE as p r otector.

Appendix A-24 • Layer 3 VPN Egress Protection www.juniper.net

 Junos Layer 3 VPNs

Check the IS-IS and TED DB

user@PEl> show isis database
IS-IS l evel l link-state database :
0 LSPs

IS-IS level 2 link-state database :

LSP ID Sequence Checksum Lifetime Attributes
Pl . 00-00 Ox46b Ox1924 590 Ll L2
Pl . 02-00 Ox465 Oxe67a 523 Ll L2
PE2-6 . 6.6 . 6 . 00-00 OxdOe Ox6b8d 1086 Ll L2 overload
PEl . 00-00 Ox46f Oxa8b 992 Ll L2

user@Pl> show ted database

PE2-6 . 6 . 6 . 6 . 00(6 . 6 . 6 . 6) Rtr 345 2 2 IS-IS(2)

To: PE2 . 00(172 . 16 . 183 . 56) , Local: 0 . 0 . 0 . 0 , Remote : 0 . 0 . 0 . 0
Local interface index : 1 , Remote interface index : 2147618817
To : PE3 . 00(172 . 16 . 183 . 59) , Local : O. O. O. O, Remote : O. O. O. O
Local interface index : 2, Remote interface index : 2147618818

PE2 . 00( 172.16.183.56) Rtr 353 3 3 IS-IS (2)

To : PE3 . 02 , Local : 10 . 7 . 0 . 1, Remote : 0 . 0 . 0 . 0

Local interface index : 153 , Remote interface index : 0
To : PE2-6 . 6 . 6 . 6 . 00(6 . 6 . 6 . 6) , Local: 0 . 0 . 0 . 0 , Remote : 0 . 0 . 0 . 0
Local interface index : 2147618817, Remote interface index : 1

PE3. 00(172 . 16 . 183 . 59) Rtr 435 3 3 IS-IS (2)

To : PE3.03 , Local : 10 . s . o . 2, Remote: o . o . o . o

Local interface index : 158, Remote interface index: 0
To : PE2-6 . 6 . 6 . 6 . 00(6 . 6 . 6 . 6), Local : 0 . 0 . 0 . 0, Remote : 0 . 0 . 0 . 0
Local interface index : 2147618818 , Remote interface index: 2

C2020 Juniper Networks, Inc. All Rights ReseM!<I.

Jon1per8us1ness Use Only
Jun1Per
.iETWOffKS
25

Checking the IS-IS and TED Databases

Output from the IS-IS LSDB displays PE2-6 . 6 . 6 . 6 . oo-o o as overloaded announced by PE2, the Protected Primary node.
TED DB in PE1 shows the PE2-6 . 6 . 6 . 6 . oo ( 6 . 6 . 6 . 6) reachable using both PE2 (Protected ) and PE3 (Protector).

www.juniper.net Layer 3 VPN Egress Protection • Appendix A- 25

Junos Layer 3 VPNs

Verifying the Egress Protection

[edit pol i cy-opti ons)
user@PE3t show
policy-statement remote - vrf {
from community [ rsitel rsite24 ) ;
then accept ;
)
community rsitel members target : 1 : 1;
community rsite24 members target : 100 : 1023 ;

user@PE3> show mpls e gres s-p rotection d e t ail

Instance Type Protection - Type
rsitel remote-vrf Protector
Route Target 1 : 1
rsite24 remote- vrf Protector
Route Target 100 : 1023

user@PE3> show bgp neig hbor

Peer : 172 . 16 . 183 . 55+179 AS 64510 Local : 172 . 16 . 183 . 59+61747 AS 64510
Type : Internal State : Established Flags : <Sync>
Last State : OpenConfirrn Last Event : RecvKeepAlive
Last Error : None
Options : <Preference LocalAddress AddressFamily Rib- group Refresh>
Address families configured : inet-vpn-unicast
Local Address : 172 . 16 . 183 . 59 Holdtime : 90 Preference : 170
NLRI configured with egress- protection : inet- vpn- unicast
Egress- protection NLRI inet- vpn- unicast , keep- import : [ rernote- vrf J

C/2020 Juniper Networks, Inc .All Rights Resenie<I.

Jon1per8usiness Use Only

Checking the Egress Protection

Policy remote-vrf with the configured route target communities [ rs i te l rs i t e 2 4 ] was referred to under the BGP
stanza appl ied in the eg r ess-p r otecti o n keep - i mport statement. The effect of this configuration is that BGP keeps
all these routes in the VPN routing table. The protector PE router scans the policy and builds the remote instance with the
configured community name from the pol icy.

Egress protection details indicate the following:

• Instance: Indicates the community name

• Type: Shows the type of the VRF. It can be either the local-vrf or remote-vrf

• Route Target: Shows the route target associated with the routing instance

NLRI configured with egres.s protection shows the BGP family configured with egress protection. The Egr ess-protection
NLRI inet-vpn - uni cast , keep- i mport : [ remote-vr f ] shows the egress protection routing policy for the BGP
group.

Appendix A-26 • Layer 3 VPN Egress Protection www.juniper.net

 Junos Layer 3 VPNs

Check the Failover to Back-up LSP (1 of 2)

user@ PEl> s ho w mpls lsp e x tensive
Ingress LSP : l sessions

6. 6. 6 .6
From : 172 . 16 . 183 . 55 , State : Up, ActiveRoute : O, LSPname : toPE26 . 6 . 6 . 6
ActivePath : (primary)

*Primary State : Up

Co uted ERO (S [L] denotes strict [loose ] h ops ) : (CSPF metric : 16777234 )
10 . 2 . 0 . 2 S 10 . 5 . 0 . 2 S 6 . 6 . 6 . 6 S (l ink-id=2 )

user@ Pl> show mpls lsp e x tensive

Transit LSP : 3 sessions

6. 6. 6 .6
From : 172 . 16 . 183 . 55 , LSPstate : Up , ActiveRoute : 0
LSPname : t oPE26 . 6 . 6 . 6 , LSPpath : Primary
Suggested label received : - , Su ested label sent : -
Recovery label received : - , Recovery label sent : 299920
Resv s tyle : 1 FF, Labe l in : 299904 , Labe l out : 299920
Time left : 141 , Since : Mon Jun 10 13 : 10 : 11 2013
Tspec : rate Obps size Obps peak Infbps m 20 M 1500
Port number : sender 2 receiver 17060 protocol 0
Attrib flags : Non-PHP 00B
PATH rcvfrom : 10 . 2 . 0 . l (ge-1/2/1 . 0 ) 106 pkts
Adspec : r eceived MTU 1500 sent MTU 1500
!PATH sentto : 10 . 5 . 0 . 2, (ge-1/2/2 . 0 ) 105 pkt s
RESV rcv f rom : l0 . 5.0. 2 (ge-1/2/2 . 0 ) 105 pkts
Explct route : 10 . 5 . 0 . 2 6 . 6 . 6 . 6 (link-id=2 )
Record r out e : 10 . 2 . 0 . 1 <sel f > 10 . 5 . 0 . 2

C2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1peraus1ness use Onty

Verifying the Failover LSP, Part 1

As the output shows PE1 has an Ingress LSP to 6.6.6.6 active path through P1 (10.2.0.2) and PE3 (10.5.0.2).

Checking the Transit LSP in P1 router shows us the above mentioned LSP transiting P1 router. We can also see t hat a
Recovery label was sent from P1, which was the case when a failure occurs (penultimate ro uter would signal for a bypass
path to avoid the primary context ID router).

www.juniper.net Layer 3 VPN Egress Protection • Append ix A- 27

Junos Layer 3 VPNs

Check the Failover to Back-up LSP (2 of 2)

user@PE3> show mpls lsp e x tensive
Egress LSP : 2 sessions

6.6.6.6
From : 172 . 16 . 183 . 55 , LSPstate : Up , ActiveRoute : 0
LSPname : toPE26 . 6 . 6 . 6 , LSl?path : Primary
Suggested label received : - , Suggested label sent : -
Recovery label received : - , Recovery label sent : -
Resv styl e : 1 FF, Label in : 299920, Label out : 3
Time left : 141 , Since : Mon Jun 10 13 : 10 : 11 2013
Tspec : rate Obps size Obps peak Infbps m 20 M 1500
Port number : sender 2 receiver 17060 protocol 0
Attrib f l ags : Non-PHP 00B
PATH rcvfrom: 10 . 5 . 0 . 1 (ge- 1/2/2 . 0) 105 pkts
Adspec : received MTU 1500
PATH sentto : localclient
RESV rcvfrom : localclient
Record route : 10 . 2 . 0 . 1 10 . 5 . 0 . 1 <self>

6.6.6.6
From : 172 . 16 . 183 . 56 , LSPstate : Up , ActiveRoute : O
LSPname : toPE26 . 6 . 6 . 6 , LSl?path : Primary
Suggested l abel received : - , Suggested l abe l sent : -
Recovery l abe l received : - , Recovery l abe l sent : -
Resv styl e : 1 FF, Label in : 299936, Label out : 3
Time le f t : 152 , Since : Mon Jun 10 13 : 10 : 11 2013
Tspec : rate Obps size Obps peak Infbps m 20 M 1 500
Port number : sender 2 receiver 59957 protocol 0
Attrib flags : Non-PHP 00B
PATH rcvfrom : 10 . 7 . 0 . 1 (ge-1/2/1 . 0) 106 pkts
Adspec : received MTU 1500
PATH sentto : l ocalclient
RESV rcvfrom : localclient
Record route : 10 . 7 . 0 . 1 <se l f>
Total 2 d i spl ayed, Up 2 , Down 0

~2020 Juniper Networks, Inc .All Rights ReseM!<I.

Joniper8us1ness Use Only
Jun1Per
N ETWORKS
28

Verifying the Failover LSP, Part 2

This slide shows the PE3 router's Egress LSPs. First one is the rerouted recovery LSP through P1 for context ID 6.6.6.6. The
second one is the LSP from PE2 router to PE3.

Appendix A-28 • Layer 3 VPN Egress Protection www.juniper.net

 Junos Layer 3 VPNs

Layer 3 VPN Egress Protection Summary

■ Egress Protection Summary

• Stub-alias and stub-proxy address lack of LFA coverage
• No need to directly connect to Protector node as in stub-link alternative
• Stub-alias uses TL V149 and can use both RSVP & LOP LSPs
• Stub-proxy uses TLV135 and supports only RSVP LSPs
• Cannot use LOP even with fail free operations
• Stub-proxy virtual context ID node(s) increase the IS-IS LSDB size and may
cause scalability issues
• Stub-alias requires software upgrade in the Core routers, stub-proxy does not
require software upgrades

~2020 Juniper Networks, Inc .All Rights Reserve<!.

Joniper8us1ness Use Onty
Jun1Per
NETWORKS
29

Egress Protection Technologies Summary

Th is slide summarizes the alternative methods for egress protection and also some Pros and Cons for each of the
techn iques.

www .j uniper.net Layer 3 VPN Egress Protection • Append ix A- 29

Junos Layer 3 VPNs

Layer 3 VPN Egress Protection Summary Protocol

Support
■ Routing protocol support for LSP signaling protocols

PROTOCOL STUB-LINK STUB-ALIAS STUB-PROXY

RSVP IS-IS '
IS-IS IS-IS
OSPF OSPF OSPF
LOP IS-IS IS-IS IS-IS
OSPF OSPF OSPF

C/2020 Juniper Networks, Inc .All Rights ReseM!<I.

Jon1per8us1ness Use Onty
Jun1Per
.iETWOffKS
30

Routing Protocol Support for LSP Signaling Protocols

This slide summarizes the protocol support for both LSP signa ling protocols.

Appendix A- 30 • Layer 3 VPN Egress Protection www.juniper.net

 Junos Layer 3 VPNs

Summary

■ In th is content, we:
• Described Layer 3 VPN Egress Protection

~2020 Jun,per Networks, Inc .All Rights Resenie<I.

Jo niper8us1ness Use Only
Jun1Per
NETWORKS
31

We Discussed:
• Ju nos OS support for different types of egress protection.

www.juniper.net Layer 3 VPN Egress Protection • Append ix A-31

Junos Layer 3 VPNs

Appendix A-32 • Layer 3 VPN Egress Protection www.juniper.net

 un1Pe[
NETWORKS
Education Services

Junos Layer 3 VPNs

Appendix B: Lab Diagrams

Engineering Simplicity
Junos Layer 3 VPNs

Management Network Diagram

emxA

e
Virtual Desktop
Console and
VNC Connections
mxB

Physical
Desktops

e mxD
Student
Management Addressing

e
customer
Virtual Environment mxA:
mxB:
mxC:
mxD:
customer:
Virtual
Desktop:

Note: Your instructor will provide address and access information.

C> 2020 Juniper Networks, Inc All Rights Reserved

Lab Diagram: Network Management

The slide diagram is referenced in the lab.

Lab: Layer 3 VPN with Static and BGP Routing

customer customer
••••••••••••••••••••••• mxB mxC • ••••••••••••••••••••••
••• •• ••• ••
•
:
:
...
' --~~~~~
CE2~
AS65532
VPN-8
~ ................ .:
:
:
••
P2
lo0.2 172.17.20.2
ge-01014 ge-01014
172.17.23.12/30
P4
lo0.4 172.1 7.20.4
•
:
,: ______ . CE2·2
AS65532
VPN-8
•• •••••••••••••••••••••
•
••
•
••

~""
.13 .14
• .. lo,
..,.,S ' ,9$ ~
0
. .. lo,
~

-'>'% oo
AS 65512 N
.., 'b Q) ~
Q.
C, !SIS level 2 .,.> o,q Q.
C,
.«'.; ,9(9 0

-
CXl Area 49.451O CXl
w ·s=? V MM
w
%>?~ a~
..'
00

mxA N Q)
~ v
~ 7
~o
VPN-A Q~
oo
PE-1
target:65512:1 ., <'i.
'N
PE-2
VPN-8 Q)
lo0.1 172.17.20.1 N lo0.6 172.17.20.6
target:65512:2 M ,._;
0
- N
""".
N 'i' ....
.,
2i ~
"' mxD
-o
.,_
'i'M
c,,0
•,S "'
q

•
!
__ __
.• •....................
CE1·1
~

~.; ....... ..
•
•
:
P3
ge-0/0/5 ge-0/0/5
172.17.23.16/30
P5 ••
:
__ __
.·········••I J ••········.
.........._
~

CE1·2 :
••

•• • lo0.3 172.1 7.20.3 .17 .18 lo0.5 172.1 7.20.5 • ••

VPN-A • : VPN-A

·------ ·
•
I
••••••••••••••••••••••••
customer
•
•
·------ ·.
;
•
• •••••••••••••••••••••••
customer

<O 2020 Juniper Networks. Inc All Rights Reserved

Lab Network Diagram: Layer 3 VPN with Static and BGP Routing
The slide diagram is referenced in the lab.

8 - 2 • Lab Diagrams www.jun iper.net

 Junos Layer 3 VPNs

Lab: LDP over RSVP Tunnels and Public Internet

Access, Part 1-2
customer customer
••
•
•
:
•••••••••••••••••••••••
CE2~
AS65532
••
•
•
:
,,;.===z=~
mxB
.,,.,... .----·-·--...... .
ge-0/0/4 ge-0/0/4
--
,,;.==:::?•====:::~
mxC
•
•
••
:
• ••••••••••••••••••••••
CE2·2
AS65532
•
••
•
••
172.17.23.12/30
P2 P4

·'·.-.-..-.-..-.....-.-..-.-..-."'...:
: VPN-B : : VPN-8 :
lo0.2 172.17.20.2 lo0.4 172.1 7.20.4

~
g
-... Route Reflector i,, ·
13
-- ...._······
.................. ....
.14
Route Reflector

. . -~ ' •
:.

.,. _ ••
00
en q
(")
a.
(!)
\ 0,

,l •••
'
· ••~ •••
,
•••
AS 65512
ISIS level 2
...

.. ...
♦
...... ♦

••
.....
t'I
••
••
•
•
••
.$'
•• a.
(!)

':: ... ' •

q en ••
-9..-.
(") N
oo
w Area 49.4510
•• '
en
w

mxA ..
en
"!
~ .•• ~

~o •
•
Q!2 •
qo •
•
PE-1 Q> N • PE-2
en,..; ••
lo0.1 172.17.20.1 l "!
(") ,-..
•• lo0.6 172.17.20.6
•
I 0 ~ •
~
g
qo
N
I •
••• VPN-A '
.•• target:65512:1 \
VPN-8
- N
q ,-..
.,en - •
•
•
•
••
~<s ~
., ~',
05 'V
~
N mxD
.. SQ I target:65512:2 •
•

,~ §l'" '\.'V
en q •' \
0 I •• VPN-C ••
• • ~'),"
••
target:65512:3 \ ••

___ __
.• •......... - . ""' .•
I
-
0 ••
,.
•
\
.. t
N
N
f ........... ~-..........
r
..._
~--········ ge-0/0/5 ge-0/0/5
172.17.23.16/30 ' ••
·
• ,.;.;.;.;.;.;.;;.;a;.;;.;.;.;.;.;.;.;,;: •
•

- _____.,
•
••
•• P3 P5 •
CE1·1 • lo0.3 172.1 7.20.3 : CE1~ :
• •• .17 .18 lo0.5 172.17.20.5 •
••
. ....._ VPN-A
. • VPN-A :
:•
customer
.
•••••••••••••••••••• •••
• ....
VPN-C VPN-C ·-------
•
' ·.
• •••••••••••••••••••••••
customer
•

C> 2020 Juniper Networks, Inc All Rights Reserved

Lab Network Diagram: LDP over RSVP Tunnels and Public Internet Access, Part 1-2
The slide diagram is referenced in the lab.

Lab: LDP over RSVP Tunnels and Public Internet

Access, Part 3
customer customer
••••••••••••••••••••••• mxB mxC • ••••••••••••••••••••••
•:• CE2~
••
•
••• CE2·2
••
• ge- ge- • ••

-..-.--..-.-.-....
: AS65532
: AS65532 :
P2 172.17.23.12/30 P4 ••
: VPN-8 : : VPN-8 :
'•••••• • •••• lo0.2 172.17.20.2
.13 .14
lo0.4 172.17.20.4
~-'..-.-..-.-.-.. ,:

a.
'l,
Route Reflector

, ' •• •• ••••
•••••••••••••••••
•••• ..
Route Reflector

-
N
a.
(!)
en •• •••• LSP P2-to-P4 •• • ••• • • (!)
I ••••••••••••• ♦ en

mxA
w
I I
I LSP P4-to-P2
' \
•
w

N I RSVP-TE \ N
Core ~o
g SQ
oo
PE•1 .,
' N.
PE•2
en <'i
lo0.1 172.1 7.20.1

2i
N
AS 65512
ISIS level 2
Area 49.451 O
--
(") r.:
Q
.. -
q~
en
N

I
lo0.6 172.17.20.6

~ mxD
-q o(")
., _ •
enO \ LSP P3-to-PS
q
•
\ LSP PS-to-P3
\

·._._.._._._.......-._._.·-·----·,·.
N
"!
•••••••••••
••
••••••••• •
••
ge-0/0/5 ge-0/0/5
172.17.23.16/30
..·~
•
~

• P3
•• CE1·1 • P5 •• CE1·2 •••

______
•• • lo0.3 172.1 7.20.3 lo0.5 172.1 7.20.5 ••
• .17 .18 ••

·-------·
VPN-A VPN-A
•
• ••• , •
• _, .••
•••••••••••••••••••••••• VPN-C VPN-C • • ••••••••••••••••••••••
customer customer

<O 2020 Juniper Networks, Inc All Rights Reserved

Lab Network Diagram: LDP Over RSVP Tunnels and Public Internet Access, Part 3
The slide diagram is referenced in the lab.

www .juniper.net Lab Diagrams • B-3

Junos Layer 3 VPNs

Lab: LDP over RSVP Tunnels and Public Internet

Access, Part 4
customer customer
••
•
•
:
• ••••••••••••••••••••••
CE2~
AS65532
••
•
:
•
/,===:::2=~,
mxB
_.,--
. ---- ·-· ._ /,::=:
. -- : :•:::::===~."'\
ge-0/0/4 ge-0/0/4
mxC
•
•
••
:
• ••••••••••••••••••••••
CE2-2
AS65532
•
••
•
••
: VPN-B : P2 172.17.23.12/30 P4 : VPN-8 :
I
••••••• lo0.2 172.17.20.2 lo0.4 172.17.20.4

--..........~-....:··-······
••••••••
--
N-
0
9
.
0
., 1:2
O>o
z
a.. Oo
> O>o.
.,,- -.
-.,,,.,-
0
Route Reflector

\
0)
· 111 •••
'
i,.

•••
-
13

AS 65512
- .14

._ -...••
Route Reflector

•
..•

a..'
0
CJ .., ~
~
- .. ••
1••••• '
\
ISIS level2
Area 49.451 O •
•••• .._, ""

-- •
(')
o en ao ~
-g_
.,
'i'
w
.,
'i' ,i .. ••
•• •
' .• ••

"'~ "'~ "'····· \

' ....·· •

--
♦

l5g
PE-1
" ; •••
"'-
JJt ···
..
/f •• aaN o~
ci,~
O)(f')
'' '

•
, •••
••· ,
••
oo
' N•
<I)
"'<"i
•
•
•
•
•
• PE-2
lo0.1 172.17.20.1 t ••• lo0.6 172.17.20.6
--
N • N
("') ,..._ .• (') ..:
a- 'I"".:N •
I
mXA C:!
g
q~
N

·,S
o9c9
? '0~
?. ?.>";,
QN
.,
"'
-
'i' .....
I "
•••VPN-A \,
.•• target:65512:1 ,
VPN-8
9,-...
<I) -
"'
••
••
•
•
•
"' mxD
., '-' •.,, o9c9
I target:65512:2 ••
•
"'CC!
0 i.i'V. -q
:.;:,o 7
I
I
••
♦

••
VPN-C
target:65512:3 ' '\
••
•••
..
,. ••

•··········· ~-········ •.•

. 6'
'- -
0
♦

ge-0/0/5 ge-0/0/5
172.17.23.16/30
\
◄ N
N
___ ___
.• ···········..._~-·-········
. . •

. ______ .
•
• • P3 P5 • •
• CE1-1 •• : CE1~ :
• • lo0.3 172.1 7.20.3 .17 .1 8 lo0.5 172.17.20.5
•
••
I
VPN-A
•
•
••
:
•
••
VPN-A
., • :
•
♦
•••••••••••••••••••••• •• VPN-C •••••••••••••••••••••••
customer customer

C> 2020 Juniper Networks, Inc All Rights Reserved

Lab Network Diagram: LDP Over RSVP Tunnels and Public Internet Access, Part 4
The slide diagram is referenced in the lab.

Lab: GRE Tunnels and Route Redistribution, Part

1-2
customer
••••••••••••••••••••••• mxB mxC customer
• ••••••••••••••••••••••
••• •• ••• ••
• CE2·1 • ge-0/0/4 ge-0/0/4 • CE2-2 ••
•• ••

-..-.-.....-.-.-....
AS65532 172.17.23.12/30 : AS65532 •
•• ••
•• VPN-8 : VPN-8
~.'..-.-..-.-.-..
• P2 P4 •
lo0.2 172.17.20.2 .13 .14 lo0.4 172. 17.20.4 ,:
'\,
AS 65512
ISIS level 2 a..
CJ
Area 49.451 O en
w
•••••••••••••••••••••••••••••
mxA N •••••
••• • • • ••• • • • MP-BGP •• • • • • • • • •.

f ;::==:t:==:::;i<." .....••••..... ..... • •••.....

•••••

PE•1
····· ( GRE Tunnel ( )
·--~ PE-2
lo0.1 172.1 7.20.1 lo0.6 172.17.20.6

N
mxD
2i o
-'i' (') VPN-A
N

.,c,0_ target:65512: 1
VPN-8
--
-q ~
CC!
oo.
target:65512:2

.•·------,
•••
.,
....."'.... -.·........ .·
~
•
• •• r
___ ___
.·········••I..._J-••········.
•
•

!•
•, _______, . CE1·1
VPN-A

••••••••••••••••••••••••
••
••
•
•
••
••
,••
♦
CE1·2

_______, .
VPN-A

••••••••••••••••••••••
•
:
:
••

customer customer

<O 2020 Juniper Networks, Inc All Rights Reserved

Lab Network Diagram: GRE Tunnels and Route Redistribution, Part 1-2
The slide diagram is referenced in the lab.

8-4 • Lab Diagrams www.jun iper.net

 Junos Layer 3 VPNs

Lab: GRE Tunnels and Route Redistribution, Part 3

customer customer
•••
••••••••••••••••••••• • mxB mxC ••
• •••••••••••••••••••• •
•• • •
••
•• CE2-1 • ge-0/0/4 ge-0/0/4 •• CE2-2
• • • •
• AS65532 • 172.17.23.12/30 • AS65532 •
• • • •
•• ••
..'.-..-.-..-.-.-.•.-.-..-.-..-.-'...:
• VPN-B P2 P4 • VPN-B
lo0.2 172.17.20.2 .13 .14 lo0.4 172.17.20.4 :
~
g
.,. _
00
(") AS 65512
en q a. a.
(!) ISIS level 2 (!)
q
-q ..-.
<'>N
oo
CD
w Area 49.451 o CD
w

mxA
..
en
VPN-A
target:65512: 1
PE-1 PE-2
VPN-B
lo0.1 172.17.20.1 lo0.6 172.17.20.6
target:65512:2

N N
~
g mxD
qo
., SQ Management
en q
0 Station

Q El
~---········•• .•..,.......... ~.·...........
•••••••••••
.
;;.;.;.;.;.;.;.;;.;.;.;.;.;.;.;.;.,:
.
•
• •• M-1 •
• CE1-1 ••

.' , ______, •..•

• • lo0.3 172.1 7.20.3 CE1-2 :
••• VPN-A •
•
•
• VPN-A :
••• .... •
=••••••••••••••••••••
•
-------•••
• • ••••••••••••••••••••••
customer customer

C> 2020 Juniper Networks, Inc All Rights Reserved

Lab Network Diagram: GRE Tunnels and Route Redistribution, Part 3

The slide diagram is referenced in the lab.

Lab: Carrier of Carriers

, , --------------------------------------------- ' ...•····.. ·· . ·······•···..·....·...........................
mxB '.I .' mxA mxD '. /
:
mxC \:
• I I : :
pe-0/0/0 ge-01010 /j ~ ge-0/0/5 ge-0/0/5 r;J!3-0IOIO ge-0/0/~
C-CE1 9i 172.17.23.8/30 :1011 P-PE 1 111 172.17.24./30 .2 P-PE2 1Gl 172.17.25.8/30 19 C-CE2
lo0.1 172.17.20.1 ,
1
lo0.1 172.17.21.1 ~ IBGP . lo0.1 172.17.21.2 , lo0.1172.17.22.1
""'- EBGP-LU I me1-vpn , .:_
• ._ • _. • Ii,.- ------- ..... ._ _ _ _ _ _ _ , - - - - - - -
----- - ------°' , I .
•• I \' I
••
••
••
.i ' •- - - - - - - - - - - - - ,
:
AS 65514
ISIS level 2
:- - - - - - - - - - - - - -
•
-
,...................................
•
••
,-.i... ' - · - ·-·-·- · •
• AS 65513 :, ••
:• :,
--!
' AS 65512 ' Area
,I. _ _ _ 49.0055
__________ : ,4

ISIS level 2 ...J •

' ISIS level 2 ' • •
• Q.
Area 49.0586
Q. ••
' Area 49.0573 I ..........................,........ Cl
.-
•
:
•
(!)
CD L. ·r·-·-·-•-·• CD ••
••
•• Route
•
: Reflector - ____
- - - -_
I EBGP inet-vpn
Route ••
•

-- - -- - -
Reflector ••

C-P1
lo0.2 172.17.20.2
•

J.
1
.
-- --
- - ,..no-nexthop-change L
---- -- -- - - --- •

C-P2
lo0.2 172.1 7.22.2

•• .I ••
- •• .
I • ~-
-"' .
~

~ - •• ••
oo
a• SQ ••
.
I
••
oO
o• -O
(")
0
"'en..,
. •• .
I
••
N ••
:,
-t ~
C:
.
I ..,• ~
'")
•••
en.,,
"!
--
<') ,.._
0 .
•••
• Q. •
Cl-
co!
.
I

.'
a. .t-
c.,
- t
••
•• --
<') ,.._

o- N·

"' -
-0 ,.._
N
., - •• - .
I
CD
••
0 ,.._
•
•• .
I
en N. •• enN.
•• . ••
I

~ge-0/0/1 ge-01011 ge-0/0/1 ge-0/011)

.1 10.1.0.0/30 .2 .2 10.1.4.0/30 . 'le

______
C-PE1 I S-CE1 S-CE2 C•PE2
lo0.3 172.17.20.3 . AS65532 AS65532 lo0.3 172.1 7.22.3
.
I

..... ,.
I
•i\ ..... ,...1
' ·•........................... , ............ , ...............·
--·-·-·- -·-·-·-·-·--

<O 2020 Juniper Networks, Inc All Rights Reserved

Lab Network Diagram: Carrier of Carriers

The slide diagram is referenced in the lab.

www .juniper.net Lab Diagrams • B-5

Junos Layer 3 VPNs

Lab: Troubleshooting Layer 3 VPNs

customer customer
~·····················~• mxB mxC •••• ••••••••••••••••• ••
•• •• ••
CE2·1 ••
• ge-0/0/4 ge-0/0/4 ••• CE2·2
•
•
: AS65532 : 172.17.23.12/30 •• AS65532 :
: VPN-8 ! P2 P4 VPN-B
•l _ _ _ ,...._ _, ;
:

..
l •
• ••• ■■■■■■■ I !" ■ ■ ■ ■ ■ ■ ■■ ■■ • lo0.2 172.1 7.20.2 .13 .14 lo0.4 172.17.20.4 ••••••••••• •••••••••••
C!
~
, ..,
-. ' A ~

- .,.
. ;s, ' ,9<!>
,,._,,'0~
<')

-
0
- A ~
00
Q) -
o,q
q
a.
(!)
0,
AS 65512
!SIS level 2
N
. ,.>'t]
. ,,._,, !~ a.
(!)

-a- m ·,.>.,;, ,9<!> C

MN w Area 49.451 o m
oo. -~~% t:? "" w
, 0 'tJ ~~
'
mxA Q)
O>
Q)
O>
"!
~
v'mxD
VPN-A . ..:!
15'
target:65512: 1
PE-1 VPN-B PE-2
lo0.1 172.17.20.1 target:65512:2 lo0.6 172.17.20.6

~
- o
'i' <')
Q) -
o,O u. u.
0 a. a.

.
(/) (/)
0 0

.,,
-
. , - - -....---~
N
"!
'
••••••••••• ••••••••••• ge-0/0/5 ge-0/0/5 ••••••••••• • •••••••••••
172.17.23.1 6/30 •• •

______., .
• • P3
: CE1-1 : lo0.3 172.17.20.3
P5 •• •••
CE1-2
•
• VPN-A •• .17 .18 lo0.5 172.17.20.5 •• VPN-A ••
•• •
I
••• •I ••
••••••••••••••••••••••• • ••••••••••••••••••••••••
customer customer

C> 2020 Juniper Networl<s. Inc All Rights Reserved

Lab Network Diagram: Troubleshooting Layer 3 VPNs

The slide diagram is referenced in t he lab.

Lab: MVPNs
~

I \
I S ource 1 source2 ISource VM
I
' I N -
..,.
- cir' -- J
•Q
:
:
:
·• -,:tece,ver
······$·····································~
10.0.23.0/24
ge-0/0/1
CE2
lo0.2 172.17.20.6
VPN-A
:'
: .~
ge-0/0/3 ge-0/0/3 "-
10.0.22.0/24 VPN-A
lo0.12172.17.20.12
• •
C!
- - - - - - -•••
l• •••• •••••••••••••••••••••••••••••••••••••••••••
--' -.
q
<O
o_
Oo. customer
PE-2
lo0.4172.1 7.20.4

-
0
Q)
O>-

VPN-A
lo0.11172.17.20.11
ge-01010 ge-01010 ge-0/0/4 ge-0/0/4
172.17.23.0/30 172.17.23.12/30
PE-1 P2
lo0. 1 172.17.20.1 lo0.2 172.17.20.2
.1 .2 .13 .1 4

mxA mxB

PE-3
: •. "R8C8ive8r3•••••••••••••••••••••••••••••••••••• ••. ge•0/0/4 ge-01012 lo0.5172.17.20.5

:•
.••
:
,
---.
10.0.34.0/24 CE3

______ .
1-- ~ - - - - 1 lo0.3172.17.20.7
ge-0/0/2 VPN-A

•••••••••••••••••••••••••••••••••••••••••••••••• •
:•
., .: ·-
•
10.0.33.0/24

.
VPN-A
lo0.13 172.17.20.13

customer
mxD

Q 2020 Juniper Networl<s. Inc All Rights Reserved

Lab Network Diagram: MVPNs

The slide diagram is referenced in t he lab.

8 - 6 • Lab Diagrams www.juniper.net

 Acronym List

ABR • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • area border router

• • • • •

ARP • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Ad dress Resolution Protocol

AS • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . . . .. autonomous system
ASB R • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • .autonomous syst em boundary routers

ATM • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . . . . . . . . Asynchronous Transfer Mode

CapEx • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . . capital expenses
CCC .. • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • circuit cross-connect

CE • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • cust omer edge

CLI • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • .command-line interface

cos • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . class-of-service

CSPF • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Constra ined Shortest Path First

DLCI • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • .data-link connection identifier

DPC • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Dense Port Concentrat or

DR • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . designated router
FPC • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Flexible PIC Concentrator
GRE • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • .generic routing encapsulation

GUI • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • .. graphical user interface

HDLC • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . . High-Level Dat a Link Control
IBGP • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • .. . . . . . . . . . internal BG P
ICM P • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Int ernet Control Message Protocol
IGM P • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Internet Group Management Protocol

IGP. • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • interior gateway protocol

1-PMSI • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Incl usive-PMSI

1Pv4 . • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . IP version 4

JNCP • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Juniper Networks Certification Program

LLDP-MED. • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Link Layer Discovery Protocol - Media Endpoint Discovery

LSA • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • link-state advertisement
LSP • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • labe l switched path

LSR • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Label Switching Routing

MAC . • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . . media access co ntrol

M P-BGP. • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Multiprotocol Border Gateway Protocol

MP-EBGP. • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Multiprotocol external BGP

MSDP • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Multicast Source Discovery Protocol

MVPN • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . multicast vi rtu a I private network

NAT • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Network Address Translation

NLRI • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • network layer reachability information

NSSA • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . . no-so-stubby area

OSPF • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • ...... . . . . . Open Shortest Pat h First
p • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . . . . . . .. provider
PE • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . provider edge
PHP • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . . . penu ltimate-hop popping
POP • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . point of presence
PP-VPN • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • provider-provisioned VPN

PVC • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • permanent virtua l connection

RD • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • route d istinguisher
RED • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • random early detection
RID • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • rout er ID

RP • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • rendezvous point
SA • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • security assoc iation
• •

SAFI • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . subsequent address fami ly identifier

S-PMSI • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . . . Selective-PMS!
TCC • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . translational cross-connect

VLAN • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • .virtua l LAN

VPLS • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • virtual private LAN service

VPN • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • . virtual private network

www.juniper.net Acronym List • ACR- 1

 VRF ........... . ... . ............ . ........................... . ....... . ........ . ....... VPN route and forwarding
WRR .............. . ............ . ................ . .................. . ............ . ....... weighted round-robin

ACR - 2 • Acronym List www.j uniper.net

 un1Per NETWORKS
Education Services

Corporate and Sales Headquarters

Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA 94089 USA
Phone: 888.JUNIPER (888.586.4 737)
or 408. 7 45.2000
Fax: 408.745.2100
www.juniper.net

APAC and EMEA Headquarters

Juniper Networks International B.V.
Boeing Avenue 240
1110 PZ SCHIPHOL-RIJK
Amsterdam, Netherlands
Phone: 31.0.207.125.700
Fax: 31.0.207.125.701

Engineering
Simplicity
EDU-JUN-JL3V, Revision V19A