L Use Only - Do Not Share: Junos Layer 3 Vpns

E
AR
SH
Junos Layer 3 VPNs
T
NO
V-16.a
O
-D Student Guide
LY
Volume 2
ON
E
US
Worldwide Education Services

AL
1133 Innovation Way

Sunnyvale, CA 94089
USA
RN
408-745-2000
www.juniper.net
TE
Course Number: EDU-JUN-JL3V

IN
E
This document is produced by Juniper Networks, Inc.
This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks Education
Services.
AR
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The
Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service
marks are the property of their respective owners.
Junos Layer 3 VPNs Student Guide, Revision V-16.a
Copyright © 2017 Juniper Networks, Inc. All rights reserved.
SH
Printed in USA.
Revision History:
Revision 15.a—November 2016
Revision V-16.a—March 2017
The information in this document is current as of the date listed above.
T
The information in this document has been carefully verified and is believed to be accurate for software Release 16.1R3.10. 
Juniper Networks assumes no responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special,
exemplary, incidental, or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
NO
O
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
-D
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known
time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement
executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its
LY
license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain
prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.
ON
E
US
AL
RN
TE
IN
Contents
E
AR
Chapter 6: Layer 3 VPNs—Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Exchanging Routes Between VRF Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
SH
Hub-and-Spoke Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Layer 3 VPN CoS Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23
Layer 3 VPN and GRE Tunneling Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-30
Layer 3 VPN and IPsec Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-34
Layer 3 VPN Egress Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-38
T
BGP PIC Edge for MPLS Layer 3 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-66
NO
Provider Edge Link Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-72
Lab: GRE Tunnels and Route Redistribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-79
Chapter 7: Interprovider VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Hierarchical VPN Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
O
Junos Support of Carrier-of-Carriers Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Junos Support of Carrier-of-Carriers VPN Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
-D
Interprovider VPN Option C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-37
Lab: Carrier-of-Carriers VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-52
Chapter 8: Troubleshooting Layer 3 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

LY
Troubleshooting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Verifying PE-CE Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7
MPLS Transport and Label Distribution Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16
MP-BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
ON
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

E
Multicast VPN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

Distribution Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8
US
Reverse Path Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12

Internet Group Management Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19
Draft Rosen Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24
Draft Rosen Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-50
AL
Chapter 10: Next-Generation Multicast VPNs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Multicast VPN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3
Next-Generation MVPN Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8
RN
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-31
Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-38
MVPN Internet Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-44
Lab: MVPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-53
TE
Acronym List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACR-1

IN
www.juniper.net Contents • iii

E
AR
SH
T
NO
O
-D
LY
ON
E
US
AL
RN
TE
IN
iv • Contents www.juniper.net
Course Overview
E
This three-day course is designed to provide students with MPLS-based Layer 3 virtual private network (VPN) knowledge
AR
and configuration examples. The course includes an overview of MPLS Layer 3 VPN concepts, scaling Layer 3 VPNs,
Internet access, Interprovider Layer 3 VPNs, and Multicast for Layer 3 VPNs. This course also covers Junos operating
system-specific implementations of Layer 3 VPNs.
The concepts are put into practice with a series of in-depth hands-on labs, which will allow participants to gain
SH
experience in configuring and monitoring Layer 3 VPNs on Junos OS devices. These hands-on labs utilize Juniper
Networks vMX Series devices using the Junos OS Release 16.1R3.10, but are also applicable to other MX Series devices.
Course Level
Junos Layer 3 VPNs (JL3V) is an advanced-level course.
T
Intended Audience
NO
This course benefits individuals responsible 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;
O
• Experience configuring MPLS label-switched paths using Junos;
-D
• 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.
Objectives
LY
After successfully completing this course, you should be able to:
• Describe the value of MPLS VPNs.
ON
• 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.
E
• Describe the format of the BGP routing information, including VPN-IPv4 addresses and route distinguishers.
US
• Describe the propagation of VPN routing information within 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
AL
import/export routes from a routing instance using route distinguishers/route targets.

• Describe the purpose of BGP extended communities, configure extended BGP extended communities, and
use BGP extended communities.
RN
• List the steps necessary for proper operation of a PE-CE dynamic routing protocol.
• List the troubleshooting and monitoring techniques for routing instances.
• Explain the difference between the bgp.l3vpn table and the inet.0 table of a routing instance.
TE
• Monitor the operation of a CE-PE dynamic routing protocol.

• Explain the operation of a PE multi-access interface in a Layer 3 VPN and list commands to modify that
behavior.
IN
• 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.
E
• Describe the flow of control traffic and data traffic in a hub-and-spoke Layer 3 VPN.
• Describe QoS mechanisms available in L3VPNs.
AR
• Configure L3VPN over GRE tunnels.
• Describe the RFC 4364 VPN options.
• Describe the carrier-of-carriers model.
SH
• 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 draft-rosen multicast VPN.
T
• Monitor and verify the operation of draft-rosen multicast VPNs.
NO
• 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.
O
• Describe the configuration steps for enabling Internet multicast using MVPNs.
• Monitor and verify the operation of MVPN Internet multicast.
-D
LY
ON
E
US
AL
RN
TE
IN
vi • Course Overview www.juniper.net

Course Agenda
E
Day 1
AR
Chapter 1: Course Introduction
Chapter 2: MPLS VPNs
Chapter 3: Layer 3 VPNs
SH
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
T
Lab 2: LDP over RSVP Tunnels and Public Internet Access
NO
Day 2
Chapter 6: Layer 3 VPNs – Advanced Topics
Lab 3: GRE Tunnels and Route Redistribution
Chapter 7: Interprovider Backbones for Layer 3 VPNs
O
Lab 4: Carrier-of-Carriers VPNs
Chapter 8: Troubleshooting Layer 3 VPNs
Day 3
Lab 5: Troubleshooting Layer 3 VPNs
Chapter 9: Multicast Review and Draft Rosen

-D
LY
Chapter 10: Next-Generation Multicast VPNs
Lab 6: MVPNs
ON
E
US
AL
RN
TE
IN
www.juniper.net Course Agenda • vii

Document Conventions
E
CLI and GUI Text
AR
Frequently throughout this course, we refer to text that appears in a command-line interface (CLI) or a graphical user
interface (GUI). To make the language of these documents easier to read, we distinguish GUI and CLI text from chapter
text according to the following table.
SH
Style Description Usage Example
Franklin Gothic Normal text. Most of what you read in the Lab Guide
and Student Guide.
Courier New Console text:
T
commit complete
• Screen captures
NO
• Noncommand-related Exiting configuration mode
syntax
GUI text elements:
Select File > Open, and then click
• Menu names Configuration.conf in the
O
Filename text box.
• Text field entry
-D
Input Text Versus Output Text
You will also frequently see cases where you must enter input text yourself. Often these instances will be shown in the
context of where you must enter them. We use bold style to distinguish text that is input versus text that is simply
displayed.
LY
Normal CLI No distinguishing variant. Physical interface:fxp0,

Enabled
ON
Normal GUI
View configuration history by clicking
Configuration > History.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
E
config.ini in the Filename field.

US
Defined and Undefined Syntax Variables

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

already assigned.
RN
GUI Variable Click my-peers in the dialog.
CLI Undefined Text where the variable’s value is Type set policy policy-name.
the user’s discretion or text where
ping 10.0.x.y
the variable’s value as shown in
TE
GUI Undefined the lab guide might differ from the Select File > Save, and type
value the user must input filename in the Filename field.
according to the lab topology.
IN
viii • Document Conventions www.juniper.net

Additional Information
E
Education Services Offerings
AR
You can obtain information on the latest Education Services offerings, course dates, and class locations from the World
Wide Web by pointing your Web browser to: http://www.juniper.net/training/education/.
About This Publication
SH
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 consult the documentation and release notes for the
version of code you are running before reporting errors.
This document is written and maintained by the Juniper Networks Education Services development team. Please send
T
questions and suggestions for improvement to training@juniper.net.
Technical Publications
NO
You can print technical manuals and release notes directly from the Internet in a variety of formats:
• Go to http://www.juniper.net/techpubs/.
• Locate the specific software or hardware release and title you need, and choose the format in which you
want to view or print the document.
O
Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.
-D
Juniper Networks Support
For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or at 1-888-314-JTAC
(within the United States) or 408-745-2121 (outside the United States).
LY
ON
E
US
AL
RN
TE
IN
www.juniper.net Additional Information • ix

E
AR
SH
T
NO
O
-D
LY
ON
E
US
AL
RN
TE
IN
x • Additional Information www.juniper.net

E
AR
SH
Junos Layer 3 VPNs
T
NO
Chapter 6: Layer 3 VPNs—Advanced Topics
O
-D
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
We Will Discuss:
• How the auto-export command and routing table groups can be used to support communications between sites
E
attached to a common provider edge (PE) router;

US
• The flow of control and data traffic in a hub-and-spoke topology;

• The various Layer 3 virtual private network (VPN) class of service (CoS) mechanisms supported by the Junos
operating system;
• Junos OS support for generic routing encapsulation (GRE) and IP Security (IPsec) tunnels in Layer 3 VPNs. and
AL
• Junos OS support for different types of egress protection.

RN
TE
IN
Chapter 6–2 • Layer 3 VPNs—Advanced Topics www.juniper.net

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Exchanging Routes Between VRF Tables

The slide lists the topics we will discuss. We discuss the highlighted topic first.
E
US
AL
RN
TE
IN
www.juniper.net Layer 3 VPNs—Advanced Topics • Chapter 6–3

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Allowing Communication
At this point, you should be well versed in the procedures used to populate VPN routing and forwarding tables (VRFs) with routes
E
learned from local customer edge (CE) devices and with the routes learned from remote PE routers. However, what if you want to
allow communications between two different VPN sites that attach to the same PE router?
US
A common example why this might 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 this dilemma by
simply combining the two VRF tables into one VRF table by placing both CE routers into the same VPN. Unfortunately, this
straightforward solution 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 suddenly merge into one VPN.
AL
VRF policy does not solve this problem either. VRF policy normally only affects routes exchanged between PE routers.
Because the sites shown on the slide are attached to the same PE router, no Multiprotocol Border Gateway Protocol
(MP-BGP) session exists to which you could even apply VRF policy. However, if you configure the auto-export command in
RN
each VRF table, the import and export VRF policies are evaluated without the need for MP-BGP sessions to exist, as
described in the following pages.
Using Routing Table Groups

TE
Another solution to this problem involves routing table groups. Routing table groups allow the linking of different routing tables
within the router so that routes can be exchanged between them. The use of routing table groups to solve this problem is
demonstrated as well in following pages.
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
auto-export Example
This slide provides an example of how to use the auto-export command to leak routes between VRF tables in the same PE
E
router. The drawing on the slide shows the PE router that now has CE-B attached to its ge-0/0/3 interface. In each VRF table on
the PE, the auto-export command is enabled. This command causes the router to analyze some combination of the
US
vrf-import policy, vrf-export policy, and the vrf-target statements of each VRF table that has the auto-export
command configured. Any routes with the correct target communities are then copied between these VRF tables.
In the example on the slide, because both VRF tables use the same import and export VRF target, all routes in the vpn-a
table are copied into the vpn-b table, and vice versa.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
code snippet begins with the creation of two routing table groups under the [edit routing-options] hierarchy. In this
example, the a-to-b routing table group is told to place its routes into its own instance (vpn-a.inet.0) and into the routing
US
table associated with the vpn-b.inet.0 instance. The same effect is configured for the opposite direction with the b-to-a
routing table group.
When listing the import-rib variables, the first routing table listed is considered the owner of the routing table group.
Therefore, the vpn-a.inet.0 is listed before the vpn-b.inet.0 in the a-to-b routing table group. This order prevents the
a-to-b routing table group from functioning if it is applied later to the vpn-b routing instance.
AL
The next code snippet shows the relevant portions of the vpn-a VRF table. While the VRF table configuration for vpn-b is
not shown, that instance requires similar configuration steps. In this case, the VRF instance has its routing-options
configured to place the VRF interface routes into the a-to-b routing table group. This configuration is required so that the
RN
interface routes associated with each VRF table are copied into the VRF tables of the other sites with which it is to
communicate. If the VRF 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.
Continued on the next page.
TE
IN

Junos Layer 3 VPNs
VRF Routing Table Group Example (contd.)
E
The last relevant portion of vpn-a’s VRF configuration is the need to link the CE-PE routing protocol to the a-to-b routing
table group. This step causes the BGP routes learned from CE-A to be copied into both the vpn-a and vpn-b VRF tables. EBGP,
AR
OSPF, and RIP 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 Junos OS also allows the use of policy to control the exchange of routes between routing table groups. To use this feature,
include the import-policy option when defining the routing table groups:
SH
user@PE# show routing-options
rib-groups {
a-to-b {
import-rib [ vpn-a.inet.0 vpn-b.inet.0 ];
T
import-policy rib-policy;
...
NO
O
-D
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Verifying the Results

To verify the results, we issued a command to display the VRF table associated with the vpn-b routing instance. The display
E
confirms that the interface and BGP routes contained in the 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 the vpn-b VRF
US
table.
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 policy is not used in this routing table group example, both routes are
copied from the vpn-a VRF table to the vpn-b VRF table even though only the direct route is currently active in the vpn-a VRF
table.
AL
Although not shown on the slide, the configuration steps performed under the vpn-b routing instance cause the interface and
BGP routes in the vpn-b VRF table to be copied into the vpn-a VRF table.
RN
Site A and Site B Can Communicate

Because both VPN sites now have routes for each other’s site, the two locations can now communicate freely through the PE
router.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
vpn-b’s Modified VRF Export Policy: The Final Step

Now that we have the two VRF tables sharing routes, the question might arise as to how we can keep these routes from being
E
sent to remote PE routers. Assuming this is a problem, the answer is making an easy modification to the VRF export polices of
the affected VRF tables.
US
The example shows vpn-b’s VRF export policy, which now includes an interface condition in term 1’s from clause. The
result is that only routes learned from the ge-0/0/3 interface are accepted for export to remote PE routers. This result
prevents the vpn-b instance from advertising routes leaked from the vpn-a VRF table.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Hub-and-Spoke Topologies
The slide highlights the topic we discuss next.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Reduces the Number of BGP Sessions and LSPs Required

Layer 3 VPNs can be deployed in a hub-and-spoke topology in which remote sites communicate through the hub site CE router.
E
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
US
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

AL
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.
RN
Two VRF Interfaces Required at Hub

A separate VRF interface is required to back up each VRF instance in the hub PE router. In practice, this interface is normally
one physical interface with two logical units.
TE
IN

Junos Layer 3 VPNs
Two Route Targets Needed
E
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
AR
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. This 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.
SH
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)
loops on the hub PE router might be required, even when using as-override and remove-private.
The use of OSPF as the hub PE-CE routing protocol can present problems due to the up/down bit that prevents link-state
T
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
NO
domain-vpn tag 0. 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 multiple spokes attached to the same PE router, or a spoke site attached to the hub PE router, requires
O
additional configuration steps to ensure the hub CE device is transited for spoke-to-spoke communications.
-D
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Signaling Flow Between Spoke Locations

This slide highlights the flow of signaling (routing protocol exchanges) between two spoke locations. The result is that spokes
E
learn each other’s routes through the hub PE router, thereby causing the hub CE router to act as a transit point for all traffic
between spoke locations.
US
The following list provides details of the signaling flow shown on the 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.
AL
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 router’s hub instance using the ge-0/0/0.1 VRF interface.
RN
5. The hub instance in the hub PE router advertises this route to the 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).
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Data Flow Between Spoke Locations

This slide highlights the flow of data (forwarding plane) between two spoke locations. The following list provides the details of
E
this flow:
US
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.
AL
4. The hub CE router has learned about Site 1’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.
RN
6. Spoke PE-1 forwards the packet to CE-1.

TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Sample Spoke VRF Table

This slide provides an example of a spoke PE router’s VRF table configuration. Only one instance is required for spoke sites.
E
In this example, the PE-CE routing protocol is EBGP.

US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
sends to the hub PE router.

US
This example also shows the extended community definitions, including both a hub and a spoke route target.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Sample Hub Configuration: VRF Interfaces

This portion of the hub PE router’s configuration shows that two virtual LAN (VLAN)-tagged logical interfaces are provisioned
E
to support the two routing instances required by the hub PE router.

US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
interface and is configured for EBGP routing exchange with the hub CE router.
US
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.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Sample Hub Configuration: Spoke Instance

This slide displays the hub PE router’s spoke VRF table configuration. This instance is tied to the hub PE router’s ge-0/0/0.0
E
VRF interface and also is configured for EBGP routing exchange with the hub CE router.
US
Because the hub site’s hub VRF instance advertises spoke routes, the spoke instance is using a null VRF export policy. As
shown on subsequent slides, this policy requires that a policy statement named null be configured with a single then
reject statement.
Because EBGP is used on the hub’s PE-CE link, AS-path loop detection is a problem. In this case, the use of the as-override
knob prevents loop detection problems as the spoke routes are delivered to the hub CE router through the spoke instance.
AL
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 guideline:
• Do not use EBGP at the hub site.
RN
• Configure AS loops 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.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Sample Hub Configuration: VRF Policy

This slide displays the hub PE router’s VRF policy and extended BGP community definitions. The hub’s spoke-in policy
E
matches the routes with the spoke route target, while the 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
US
routes learned from the hub community for received routes.

AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Most Problems Relate to Signaling Exchanges

Because the signaling plane is more complex than the forwarding plane, and because forwarding cannot work when signaling is
E
broken, you should approach hub-and-spoke troubleshooting by first verifying proper signaling flows.
US
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 (VRF export) or the hub PE router’s reception (VRF import).
By examining the hub PE router’s spoke VRF instance first, you can verify nearly one half of the total signaling exchange in one
step. Eliminating half of all possible causes with each test is a prime way of expediting the fault isolation process.
AL
Because of the requirement for two route targets, and the likelihood 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

RN
When a traceroute between two spoke locations fails, 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
TE
CE device operation, as it would relate to the re-advertisement of the spoke routes.

IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Layer 3 VPN CoS Options

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Filtering and CoS Functions Available at Ingress

The full range of filtering and CoS functions are available at the ingress PE router. The functions include firewall filtering, rate
E
limiting, queue selection, and IP precedence mapping.

US
Filtering and CoS Functions Available at Egress

You can also employ filtering and CoS functions at the egress PE router when certain conditions are met. These functions
allow for Address Resolution Protocol (ARP) operations, egress rate limiting, and firewall filtering.
AL
VRF Label Experimental Bits

The EXP bits in the VRF label can be set based on firewall classification, IP precedence bits, or ingress interface.
RN
RSVP Label Experimental Bits

The EXP bits of the RSVP label can be set with a static CoS value. Or, with the Enhanced Flexible PIC Concentrator (FPC), the
RSVP or LDP label can have its EXP field set to the value used by the VRF label.
TE
classifiers exp Setting on Transit LSRs

Setting the classifiers 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 classifier results in all labeled packets being
placed into output queue 0 by default. With Enhanced FPC hardware, you can create custom EXP to output queue mappings,
IN
but an exp classifiers statement is still necessary to effect EXP-based output queue selection for queues 1–3.

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Layer 3 VPN CoS Example

This slide provides an example of how you can use firewall filters to classify packets for queuing, and how you can configure
E
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
US
(ICMP) traffic into queue 2 with all other traffic going into queue 0 (the default queue).
With an Enhanced FPC, both labels can be written independently. Thus, the queuing decisions made by the ingress PE router
can be mirrored in the transit LSRs and at the egress PE router.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
carrying the static CoS value associated with the LSP itself.
US
Bottom Label Has Firewall-Based Classification

The bottom (VRF) label in this example is carrying a CoS value set by the firewall-based classification of the packet at
ingress. With a B2 FPC, the firewall-based classification is overwritten by the outer label’s EXP value. Therefore,
differentiated queuing is only possible at the ingress PE router. With the Enhanced FPC, the values are set independently. By
AL
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.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Load Balancing
You can load-balance VPN traffic across multiple LSPs by applying a load-balancing policy to the main forwarding instance.
E
Mapping Traffic to Specific LSPs

US
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 deploying LSPs between PE routers having differing performance
characteristics.
The most common technique for prefix-to-LSP mapping involves routing policy at the LSP ingress node. This policy maps
AL
traffic to a particular LSP using community-based match criteria. This technique assumes that the LSP egress node tags VPN
prefixes with the correct community value as the routes are advertised to PE routers using multiprotocol IBGP. Note that this
technique currently does not support route filter match conditions at the LSP ingress node.
RN
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 resolves some of the VPN routes to one of the BGP
next hops and the remaining routes to the other BGP next hop. When the LSP egress node resolves these BGP next hops
through its inet.3 routing table, it selects the LSP that matches the route’s BGP next hop for installation in the forwarding
TE
table.
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Prefix Mapping Example

This slide demonstrates the technique of mapping prefixes to LSPs using routing policy, which matches communities at the
E
LSP ingress node.

US
The policy uses the install-nexthop lsp action modifier to direct matching routes to a specific RSVP session. Term 3
accepts all nonmatching routes for the default action of per-prefix load balancing across equal-cost LSPs.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
must be applied to the main instance’s forwarding table. The slide shows this application.
US
The Results…
After applying and committing the prefix mapping policy, you can verify the results 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),
while traffic to the 192.168 routes is mapped to a different LSP (top label set to 100030).
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Layer 3 VPN and GRE Tunneling Integration

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
PE-PE GRE Tunnels

The Junos OS supports the GRE tunneling of VPN traffic between PE routers. As shown, this support allows an interprovider
E
VPN application when the provider’s backbone does not support MPLS.
US
To support GRE tunnels, a tunnel services must be enabled as described in previous slides. GRE-encapsulated packets are
not forwarded over MPLS tunnels.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
PE-PE GRE Tunnel Configuration

This slide highlights the key aspects of a PE-to-PE GRE tunnel configuration. Use of a GRE tunnel has no impact on the PE
E
router’s VRF 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.
US
On the slide, unit 0 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 values assigned to the PE router’s loopback interfaces. This
example shows an unnumbered GRE tunnel, and therefore no IP address is specified. Because this tunnel will be used to
support MPLS, family mpls must also be specified.
AL
As illustrated on the slide you need to configure a static route with the next-hop of the GRE interface in the inet.3
routing table. This is route is configured under the [edit routing-options rib inet.3] hierarchy.
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
RN
encapsulating interface.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
PE-CE GRE Tunnels

The Junos OS supports GRE tunnels for PE-CE connections. As shown, this support allows the interconnection of a remote CE
E
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.
US
To support GRE tunnels, tunnel services must be enable on routers running the Junos OS. The new routing-instance
configuration is used to place a GRE tunnel into the correct routing instance:
gr-1/0/0 {
unit 0 {
AL
tunnel {
source 192.168.9.98;
destination 192.168.9.97;
routing-instance {
RN
destination vrf-name;
}
}
}
}
TE
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.
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Layer 3 VPN and IPsec Integration

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
IPsec and Layer 3 VPN Integration

The Junos OS supports the integration of provider-provisioned Layer 3 VPNs and IPsec protocols. This application most likely
E
will be used to support the secure exchange of information between the local PE router and a CE router that is remotely
connected through an IP cloud.
US
• PE-CE IPsec tunnel termination: The Junos OS offers support for the termination of IPsec tunnels between the
PE and CE routers.
• CE-CE tunnels: As shown, the CE routers 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
AL
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 the encapsulating interface is not listed in the PE router’s
VRF table, because this causes dynamic SAs to fail.
RN

TE
IN

Junos Layer 3 VPNs
IPsec and Layer 3 VPN Integration (contd.)
E
• Hardware required: To support PE-CE IPsec tunnels, both the PE and CE routers require the presence of either
an AS PIC, ES PIC, or a service Dense Port Concentrator (DPC).
AR
• 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 highlight 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 traffic for encryption. We also discuss PE-PE configuration over GRE and
SH
IPsec.
T
NO
O
-D
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
IPsec Between PE Routers Instead of MPLS

A conventional Layer 3 BGP/MPLS VPN requires the configuration of MPLS LSPs between the PE routers. When a PE router
E
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
US
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, while the destination address has the
BGP next hop, the address of the egress PE router.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Layer 3 VPN Egress Protection

The slide highlights the three sub-topics we discuss next.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Egress Protection Alternatives

The slide highlights the three topics within Layer 3 VPN egress protection we discuss next.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Stub Link: Egress Protection Scenarios

The slide shows the two egress protection scenarios.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
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.
US
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, called 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 will be referred to as the Protector PE. It will
be the P router that will first detect a failure in PE2. The router will 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
AL
will be shared by both the Protected and Protector PE routers.

RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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 signaling protocol.
E
As you know LDP relies on the IGP (ISIS in this 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
US
next hop in the forwarding table you need to configure the router to perform per-packet load balancing. Once ISIS has
determined a backup path, LDP will also have a backup path.
It is important to keep in mind that Junos LFA is per-prefix by default but that the configuration option
backup-spf-options per-prefix-calculation is needed to allow calculation of backup next hops for non-best
prefix originators in combination with node-link-protection LFA.
AL
The next few slides will show the change in forwarding table due to this configuration.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
a result of this configuration, the PE2 and PE3 will use ISIS to advertise that this network is attached it. The slide shows the
resulting ISIS database on the P2 router.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
hop of the context identifier (10.0.0.3). The configuration of the PE3 router causes it to treat any received 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
US
next few slides will show how PE3 treats protected routes from PE2 in a special way. You can optionally configure an import
policy to filter the protected routes.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
P2’s Forwarding Table

The slide shows how P2 has installed two next hops in it mpls.0 forwarding table for packets resolving to 10.0.0.3 (VPN
E
routes). Notice that because of the weight value, only the next hop that goes towards PE2 will 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 protected
US
packets at the time of failure. PE3 will need to be able to properly route packet that arrive with an outer label of 299776.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
PE2’s Routes
The slide shows the protected routes being advertised by PE2. Notice that the next hop is the context identifier. Also, notice
E
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 will be able to deal with protected traffic (inner label 16) during a failure.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
PE3’s mpls.0 table

Even before a failure, we can see that PE3 is able to forward MPLS packets that arrive with an outer label of 299776
E
(protected packets). Packets that arrive with this label will have their outer label popped and then have the singly, labeled
packet directed to the __context-id__.mpls.0 table.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Final Lookups
Remember, that all of these tables are setup prior to a failure. The slide shows that PE3 performs a lookup on the singly
E
labeled packet, pops the last label leaving an IP packet, and directs the packet to an IP based routing table for a final lookup.
The final IP lookup will cause the router to finally send the remaining IP packet out of the VRF interface.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
service traffic during an egress failure. 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.
US
A new configuration statement, advertise-mode, enables you to set the method for the interior gateway protocol (IGP) to
advertise egress protection availability
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
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 requires a Junos
US
OS upgrade in core nodes, but is flexible enough to support all 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 called inet.5 on the PLR provides the configured or IGP-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
AL
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.
RN
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
TE
point. In networks in which 100 percent LFA coverage is not available, it is useful to have backup LSP LFAs with RSVP-based
tunnels.
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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).
E
The protector stops announcing the context-id by LDP or ISIS as an attached address.
US
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 get 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
AL
announcing the context id with TLV149. in the stub-link style the LDP label would be towards the context ID IP. In a LFA
topology with coverage problems this label would not exist. The PLR on the other hand will always have a 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
RN
understand which context ID the protected traffic relates to and should be forward by.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Stub Alias: Example Topology

The slide shows the example topology for the following examples.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
protocols mpls egress-protection context-identifier context-identifier]. Under the same

hierarchy configure the Protected PE as primary and the Protector PE as protector.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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).
E
PE3 is the Protected PE and PE2 is the Protector PE.

US
• Checking the route to 10.10.50/24 in PE1 reveals 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.0. It shows being used for Egress Protection having its next hop to table
__6.6.6.6-vpn__.inet.0.
AL
Table __6.6.6.6-vpn__.inet.0 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.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
protected context ID and also LDP labels added from the received TLVs.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
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
US
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 will 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
AL
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) objects—one for the context ID and one for itself. This 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
RN
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
TE
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.
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
primary and protector announce themselves connected to a fake context ID node which is a virtual node handling the proxy
node function.
US
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.
AL
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 LDP doesn't work here is because we are not doing any tunneling. If there is a coverage problem and the PLR
RN
path to the protector goes back on itself then the path to the protector is still infeasible for LFA, so no LDP label will be
available, so RSVP is the only option.
RSVP can tunnel 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
TE
Protected or the Protector nodes then 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.
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Stub Proxy: Example Topology

In addition to egress protection, this example demonstrates an enhanced PLR function, in which the PLR reroutes service
E
traffic during the egress failure. This enhancement is supported in Junos OS Release 13.3 and later. In this example, Device
P1 (the PLR) is directly connected to Device PE3 (the protector). Using the configuration statement, advertise-mode
US
stub-proxy, enables you to set the method for the interior gateway protocol (IGP) to advertise egress protection
availability.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
protocols mpls egress-protection context-identifier context-identifier]. Under the same

hierarchy configure the Protected PE as primary and the Protector PE as protector.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Checking the IS-IS and TED Databases

Output from the IS-IS LSDB displays PE2-6.6.6.6.00-00 as overloaded announced by PE2, the Protected Primary node.
E
TED DB in PE1 shows the PE2-6.6.6.6.00(6.6.6.6) reachable using both PE2 (Protected) and PE3 (Protector).
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Checking the Egress Protection

Policy remote-vrf with the configured route target communities [ rsite1 rsite24 ] was referred to under the BGP
E
stanza applied in the egress-protection keep-import 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
US
configured community name from the policy.

Egress protection details indicate following:
• Instance - Indicates the community name
• Type - Shows the type of the VRF. It can be either the local-vrf or remote-vrf
AL
• Route Target - Shows the route target associated with the routing instance
NLRI configured with egress protection shows the BGP family configured with egress protection. The Egress-protection
NLRI inet-vpn-unicast, keep-import: [remote-vrf] shows the egress protection routing policy for the BGP
RN
group.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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).
E
Checking the Transit LSP in P1 router shows us the above mentioned LSP transiting P1 router. We can also see that a
US
Recovery label was sent from P1, which was the case when a failure occurs (penultimate router would signal for a bypass
path to avoid the primary context ID router).
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
second one is the LSP from PE2 router to PE3.

US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Egress Protection Technologies Summary

This slide summarizes the alternative methods for egress protection and also some Pros and Cons for each of the
E
techniques.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Routing Protocol Support for LSP Signaling Protocols

This slide summarizes the protocol support for both LSP signaling protocols.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
BGP PIC Edge for MPLS Layer 3 VPN

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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.
E
Although the interior gateway protocol (IGP) can provide fast convergence, in certain instances, the time to resolve a link
failure and provide an alternate route can be time consuming. For example, a provider edge (PE) router might be configured
US
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. This already installed path
is used until global convergence through the IGP is resolved. Using the alternative VPN route for forwarding until global
convergence is complete reduces traffic loss.
AL
BGP PIC Edge supports multiprotocol BGP IPv4 or IPv6 VPN network layer reachability information (NLRI) resolved using any
of these IGP protocols:
• OSPF
RN
• IS-IS
• LDP
BGP PIC Edge does not support multicast traffic.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Example Topology
This example shows two customer edge (CE) routers, Device CE1 and Device CE2. Devices PE1, PE2, and PE3 are PE routers.
E
Device P1 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.
US
For testing, the address 172.16.1.5/24 is added as a loopback 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.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Example Configuration
Before the BGP PIC Edge in an MPLS Layer 3 VPN configuration make sure you have configured
E
1. Configure LDP
US
2. Configure an IGP, either OSPF or IS-IS

3. Configure a Layer 3 VPN
4. Configure multiprotocol BGP for either an IPv4 VPN or an IPv6 VPN
5. Enable BGP PIC Edge:
AL
[edit routing-instances routing-instance-name routing-options]

user@PE1# set protect core
RN
6. Configure per-packet load balancing:

[edit policy-options]
user@PE1# set policy-statement policy-name then load-balance per-packet
TE
7. Apply the per-packet load balancing policy to all routes exported from the routing table to the forwarding table
[edit routing-options forwarding-table]
user@PE1# set export policy-statement-name
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Verification of Protection
BGP routing information displays load balancing availability to the destination via both PE2 and PE3.
E
The Indirect next hop output lines that contain weight follow next hops that the software can use to repair paths where a link
US
failure occurs.
The next-hop weight has one of the following values:
• 0x1: indicates active next hops
• 0x4000: indicates passive next hops
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Checking the Forwarding and Routing Tables

The forwarding table shows the ulist index (262147) used by the Packet Forwarding Engine.
E
The OSPF route output shows the tracked session IDs for the loopback interface addresses on Devices PE2 and PE3.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Provider Edge Link Protection

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
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
US
[edit routing-instances instance-name protocols bgp family inet unicast] or [edit

routing-instances instance-name protocols bgp family inet6 unicast] 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.
AL
A protection path can be selected only if the best path has already been installed by BGP in the forwarding table. This is
because a protection path cannot be used as the best path. There are two conditions under which the protection path will
not work:
RN
• When configured for an internal BGP peer; and

• When configured with external and internal BGP multipath.
Provider edge link protection is configured only for external peers.
TE
Note: The option vrf-table-label must be configured under the [routing-instances instance-name]
hierarchy for the routers that have protected PE-CE links. This applies to Junos OS Releases 12.3 through 13.2 inclusive.
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Example Topology
This example shows the customer edge CE2 router being dual homed to PE2, and PE3 routers. Device P is a provider core
E
router. Only Device PE3 has the Provider Edge Link Protection configured.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
PE2 Router Configuration

The protection statement indicates that protection is required on prefixes received from a particular neighbor or family. After
E
protection is enabled for a given family, group, or neighbor, protection entries are added for prefixes or next hops received
from the respective peer.
US
To minimize packet loss when the protected path is down, also use the per-prefix-label statement at the [edit
routing-instances instance-name protocols bgp family inet labeled-unicast] hierarchy level.
Configure this statement on every PE router within the AS containing the protected path.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Verification of the Protection

The show route 1.1.1.6 output confirms that a route on router CE2 is advertised to router PE3, directly and through
E
router PE2.If the route is advertised correctly, you will see multiple paths for the route. The output verifies the presence of
multiple paths from router PE3 to the destination route, 1.1.1.6, on router CE2. The first path is directly through the PE3-CE2
US
link (10.1.1.26). The second path is through the provider core and PE2 (10.1.1.17).
The show route 1.1.1.6 extensive output verifies that the protection path is correctly configured by confirming that
the weight for the active path being protected is 0x1 (lower), and the weight for the protection candidate path is 0x4000
(greater).
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
We Discussed:
• How the auto-export command and routing table groups can be used to support communications between sites
E
attached to a common provider edge (PE) router;

US
• The flow of control and data traffic in a hub-and-spoke topology;

• The various Layer 3 virtual private network (VPN) class of service (CoS) mechanisms supported by the Junos
operating system;
• Junos OS support for generic routing encapsulation (GRE) and IP Security (IPsec) tunnels in Layer 3 VPNs; and
AL
• Junos OS support for different types of egress protection.

RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Review Questions
1.
E
US
2.
3.
AL
4.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Lab: GRE Tunnels and Route Redistribution

The slide provides the objectives for this lab.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
Answers to Review Questions
E
1.
AR
To place routes from one routing table into a second routing table, you must first create a routing table-group that lists both
routing tables as an import routing table 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 routing-options
interface-routes] level of the hierarchy. Apply the routing table-group at this level of the hierarchy will take the local
SH
and direct routes found in the primary table (the first table in the list) and ensure they exist in both tables. For routes learned
by routing protocols, these routes can be applied to the routing table-group at the [edit protocols protocol-name]
level of the hierarchy.
2.
T
Routes from Spoke PEs and CEs are received by and accepted by the Spoke instance on the Hub PE. The HUB PE passes
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
NO
advertises those routes to the Spoke sites.
3.
The Junos OS supports firewall filtering and rate limiting. It also support the setting of the experimental bits on both the inner
and outer headers of an MPLS packet.
O
4.
GRE and IPsec tunnels are support from CE to CE, PE to PE, and CE to PE using the Junos OS.
-D
LY
ON
E
US
AL
RN
TE
IN

E
AR
SH
Junos Layer 3 VPNs
T
NO
Chapter 7: Interprovider VPNs
O
-D
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
We Will Discuss:
• Junos operating system support for carrier of carriers;
E
• Junos support for interprovider virtual private networks (VPNs); and

US
• Configuring Layer 3 VPNs for interprovider Option C.

AL
RN
TE
IN
Chapter 7–2 • Interprovider VPNs www.juniper.net

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Hierarchical VPN Models

E
US
AL
RN
TE
IN
www.juniper.net Interprovider VPNs • Chapter 7–3

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Carrier-of-Carriers Model
This model allows service provider A to offer a backbone service to the customer, another service provider. Assume the
E
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 from the
US
service provider A to interconnect its sites making the customer 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.
Interprovider VPN
AL
This model allows for a Layer 3 VPN, BGP Layer 2 VPN, or a BGP virtual private LAN service (VPLS) to extend between
autonomous system or service providers.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Carrier-of-Carriers VPN
This model is a combination of the two models discussed on the previous slide. In this model, the customers of service
E
provider A will be providing VPN service to its own customers. The details of this model are described in subsequent slides.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Option A
RFC 4364 describes three methods of providing multiple AS backbones. Option A is the least scalable of the options. This
E
option requires that the 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 this option is supported by the Junos
US
OS, it is not a recommended solution.

AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Option B
With option B, the ASBRs does not need to maintain separate VRF instances for each VPN. However, the ASBR will still have
E
to keep VPN routes in a single routing table, bgp.l3vpn.0 for L3VPN routes. Through an EBGP session between one another,
the ASBRs will then exchange VPN routes as label routes. The EBGP advertised labels are used stitch together the
US
label-switched paths (LSPs) that terminate between provider edge (PE) and ASBR.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Option C
This option is generally accepted as the most scalable solution for interprovider VPNs. This option allows the PE routers in
E
different autonomous systems to exchange VPN routes (Layer 3 VPN, BGP Layer 2 VPN, or BGP VPLS) using a multihop BGP
session. The ASBRs do not need to store any VPN routes in this case. Instead, the ASBRs will exchange the internal networks
US
of each service provider (most importantly the loopback addresses of the PEs) using labeled IP version 4 (IPv4) 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.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Junos Support of Carrier-of-Carriers Model

This slide highlights the topic we discuss next.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Service Provider Routers

The service provider’s P routers only maintain routes internal to the provider’s network. The PE routers maintain both
E
provider internal routes and customer internal 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
US
do not carry the customer’s external routes, which is critical to the overall scalability of this model.
Customer Routers
The customer’s routers must maintain both customer internal and external routes. The customer’s external routes are those
AL
learned from the customer’s downstream subscribers.

RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
can be established with RSVP or LDP signaling. In this example, the LSP is established using RSVP; PE-1 is assigned MPLS
label 30 by the P router.
US
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
AL
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.
RN
TE
IN

Junos Layer 3 VPNs
I/EBGP Signaling Between Customer ASBRs
E
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 multihop EBGP (different AS numbers) sessions through the provider’s backbone for
AR
the purposes of exchanging external routes. A full IBGP 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, only 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.
SH
Signaling: Step by Step
The details of the signaling exchanges shown on the slide are:
1. The IGP at customer Site 2 exchanges internal reachability with CE-2. ASBR-2 establishes an IBGP neighbor
T
relationship with CE-2.
2. CE-2 selectively advertises Site 2’s internal routes to the provider’s PE-2 router using multiprotocol EBGP
NO
(MP-EBGP) with support of labeled-unicast routes. These routes are advertised with a valid label, which is
200 in this example.
3. PE-2 houses Site 2’s internal routes in a VRF table and uses MP-IBGP to send labeled VPN-IPv4 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
O
assign a new label to the prefix advertised (Label 300 in this example).
5. After receiving the labeled route, CE-1 distributes Site 2’s internal routes to ASBR-1 using IBGP. No labels are
6.
in the provider’s network. -D
needed, because conventional IP forwarding is used within the customer sites. At this point, the ASBRs can
establish an EBGP multihop session through the provider’s backbone. This session is tunneled through the LSP
ASBR-2 learns an external route x from one of its subscribers. IBGP conveys external routes from ASBR-2 to
LY
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.
ON
8. External route x is advertised by ASBR-1 to its downstream subscribers as well as to CE-1.

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Carrier-of-Carriers Data Forwarding

This slide uses step numbers to describe the forwarding operations between ASBR-1 and ASBR-2. The result is the need for
E
a two-level label stack in the provider’s network.

US
Forwarding: Step by Step

The details of the forwarding operation shown on the slide are:
1. A packet addressed to external route x arrives at ASBR-1.
AL
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 with the value received from PE-2, and pushes an MPLS label (30 in this example)
RN
onto the stack. The P router pops this top label (PHP) such that PE-2 receives a packet with a single label.
5. PE-2 swaps the VRF label with the label advertised by CE-2 and forwards the 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).
TE
7. ASBR-2 performs a longest-match lookup and routes the packet towards destination x.
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Carrier-of-Carriers Sample Network

This slide provides a sample network; the following list provides the details of this network. The following slides show various
E
configuration-mode and operational-mode screen captures relating to this network.

US
• Provider network: The provider’s network is assigned AS 65512 and has already established 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.
AL
• 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.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
ASBR-2 Configuration
This slide lists the key aspects of ASBR-2’s configuration. An IBGP session is configured to CE-2, and a multihop EBGP
E
session is configured for ASBR-1 at Site 1.

US
The 200 policy in ASBR-2 ensures that only external routes (200.0.0/24 in this example) are sent to ASBR-1. The default
IBGP policy 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 external 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.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
configured for communications with PE-2.

US
The MP-EBGP session has the labeled-unicast family 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 addresses of
AL
customer site routers.

RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
PE-2 Configuration
This slide lists the key aspects of PE-2’s configuration. An MP-EBGP VRF routing instance is configured for communications
E
with CE-2. Also shown is an LSP that terminates on PE-1.

US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Carrier-of-Carriers Operation: CE-1

This slide shows that CE-1 is receiving the internal routes from Site 2 through its Multiprotocol Border Gateway Protocol
E
(MP-BGP) session to PE-1. These routes are labeled due to the provisioning of family labeled-unicast on the MP-EBGP
session.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Carrier-of-Carriers Operation: CE-1

This slide shows that CE-1 learns about the external prefix 200.0.0/24 from ASBR-1 through its IBGP peering session. Even
E
though the route is learned from ASBR-1, the next hop is ASBR-2 (192.168.12.4). The BGP next hop is associated with a
label and push operation. Thus, CE-1 routes packets addressed to 200.0.0/24 by pushing label 300128 and forwarding the
US
labeled packet to PE-1 (10.0.20.1) for ultimate delivery to ASBR-2.

AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Carrier-of-Carriers Operation: PE-1

This slide shows a portion of PE-1’s vpn.mpls.0 switching table for the VRF instance called vpn. When PE-1 receives a
E
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.
US
After PHP, PE-2 receives a packet with Label 299904, which it swaps with the label learned from CE-2 (labeled unicast route)
before forwarding the singly labeled packet to CE-2.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
associated with customer loopback addresses are leaked, we must source the traceroute from the loopback address of
ASBR-1.
US
In this 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.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Junos Support of Carrier-of-Carriers VPN Applications

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON

The service provider’s P routers only maintain routes internal to the provider’s network (P-routes). The PE routers maintain
E
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
US
customer’s external routes (C-external), which is a critical aspect of the overall scalability 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
AL
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 forwarding within the customer networks accommodates private/local use
addressing.
RN
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
TE
networks.
IN

Junos Layer 3 VPNs
Three-Level Label Stack Required
E
The presence of VRF-related labels results in the need to support three levels of label stacking in the provider and customer
networks. In the case of PE-1, the three labels have the following functions:
AR
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
SH
associate the packet with the LSP leading to the next ASBR in the path.
3. The top label associates the packet with the 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
communicated along with the NLRI advertised by ASBRs. Although a protocol such as LDP could be used for this purpose,
the Junos OS currently supports MP-BGP for this purpose.
T
RFC 3107, Carrying Label Information in BGP-4, specifies labeled routes. Labeled route advertisements use SAFI 4 and
NO
differ from VPN-labeled routes in that there is no route distinguisher or route target communities in the advertised NLRI.
Simply put, labeled routes allow the binding of an MPLS label to the advertised IPv4 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.
O
-D
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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 customer and provider networks. The
E
LSP signaling protocol need not be the same; the customer can use LDP while the provider uses RSVP.
US
MP-BGP Signaling Between Provider PE and Customer CE Routers

As with the previous application, the customer’s CE routers use EBGP with labeled-unicast 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 and thereby eliminate the need to carry customer internal routes in its P routers.
AL
I/EBGP Signaling Between Customer ASBRs

Once the customer’s internal routes are exchanged across the provider’s backbone, the ASBRs (PE-1 and PE-4) can
RN
establish IBGP (same AS numbers) sessions or multihop EBGP (different AS numbers) sessions through the provider’s
backbone for the purposes of exchanging external routes. In this case, the routes are exchanged using MP-BGP and are
labeled VPN routes.
TE
IN

Junos Layer 3 VPNs
I/EBGP Signaling Between Customer ASBRs (contd.)
E
To improve scalability, the customer networks can use route reflection. The two route reflectors peer using MP-EBGP. A
command called no-nexthop-change is required to tell the route reflectors to pass—unchanged—the third party next
AR
hops to their clients.
Signaling: Step by Step

The details of the signaling exchanges shown on the slide are:
SH
1. The IGP at customer Site 2 exchanges internal reachability with CE-2. External (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 support of
labeled-unicast 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 (1020 in this example).
T
3. PE-3 houses Site 2’s internal routes in a VRF table and uses MP-IBGP to send labeled VPN-IPv4 routes to PE-2.
NO
The route to PE-4 is assigned Label 1001 in this example.
4. PE-2 uses MP-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
carrier-of-carriers application, this exchange involves labeled-unicast routes, and therefore requires MP-IBGP.
O
Because CE-1 is also an ASBR, it rewrites the BGP next hop and must therefore assign a new label (Label 1020
in this example).
-D
At this point, the ASBRs (PE-1 and PE-4) establish an MP-EBGP multihop session through the provider’s backbone. This BGP
session is tunneled 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 which MP-I/EBGP was not needed due to native IP forwarding within
the customer networks.
6. Here, PE-4 learns an external route x from one of its VPN subscribers.
LY
7. The external route x is now advertised to PE-1 using the MP-EBGP session established at Step 5. This NLRI
advertisement includes the VRF label that PE-4 expects to receive for routes associated with this particular VRF
instance.
ON
8. PE-1 advertises the external route to its downstream VPN subscribers.

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Carrier-of-Carriers VPN Data Forwarding

This slide uses steps to describe the forwarding operations between PE-1 and PE-4 in an interprovider VPN application. The
E
result is the need for a three-level label stack.

US

1. A packet addressed to external route x arrives at PE-1.
AL
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 the
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.
RN
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 receives a packet with only two labels.
TE

IN

Junos Layer 3 VPNs
Forwarding: Step by Step (contd.)
E
6. PE-3 also performs a swap on the top label before forwarding the packet to CE-2.
AR
7. Being the penultimate router for the LSP to PE-4, CE-2 pops the label stack and sends the resulting VRF-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.
SH
9. The native packet is forwarded out PE-4’s VRF interface towards the subscriber to which it is addressed.
T
NO
O
-D
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
AS 65512 Provides Carrier-of-Carriers Services

This slide provides a sample network. The following slides show various configuration-mode and operational-mode screen
E
captures relating to this slide.

US
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 VRF target and route distinguishers. PE-2 and PE-3 function
as ASBRs in this application.
Policy on CE Routers
AL
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

RN
A multihop 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 this
MP-EBGP session. Customer routers CE-1 and CE-2 also function as ASBRs in this example.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
PE-1 Configuration
This slide shows the key aspects of PE-1’s configuration. Family labeled-unicast is configured for its MP-IBGP session
E
to CE-1, and family inet-vpn is configured for the multihop MP-EBGP session to PE-4.
US
resolve-vpn
The resolve-vpn option causes PE-1 to copy the labeled-unicast routes it receives from CE-1 into inet.3, which
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.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
CE-1 Configuration
This slide displays key portions of the configuration on CE-1. RSVP is enabled, and an LSP is defined back to PE-1 (not
E
shown). The MP-IBGP session to PE-1 has the labeled-unicast family configured. This configuration is needed so that
CE-1 can include labeled-unicast routes along with the advertisements for Site 2’s internal routes.
US
CE-1 also has an MP-EBGP session configured for its connection to PE-2. This session must also support
labeled-unicast routes.
The following policy is applied to CE-1’s MP-EBGP session to PE-2. This policy ensures that Site 1 sends only internal routes
to the provider:
AL
user@ce-1# show policy-options

policy-statement internals {
term 1 {
RN
from protocol [ ospf direct ];

then accept;
}
term 3 {
then reject;
TE
}
}
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Carrier-of-Carriers VPNs Operation: VPN Routes

This slide shows that PE-1 learns labeled VPN routes from PE-4 at Site 2. These routes are associated with a VRF label (not
E
shown) used by the advertising router (PE-4) to associate the packets with the correct VRF table.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Carrier-of-Carriers VPN Operation: Internal Routes

This slide shows that PE-1 learns about Site 2’s internal routes through its MP-IBGP connection to CE-1 (an ASBR).
E
The labeled-unicast routes received by PE-1 are copied into the main routing table (inet.0) as well as the inet.3
US
table. This copying is the result of the resolve-vpn option on PE-1 and is critical to the operation of this network.
Normally, VPN routes must resolve to an LSP that terminates on the egress PE router. Because PE-1 does not have an LSP
terminating directly on PE-4, the VPN routes are unusable without the labeled-unicast entries to the remote PE routers
in inet.3, which indicate a multinetwork LSP between PE-1 and PE-4 exists.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Carrier-of-Carriers VPN Operation: PE-2

This slide shows the VPN instance’s mpls.0 table that exists on PE-2. Here, packets received with a label of 300288 have
E
their top label swapped. PE-2 pushes a new label (obtained from RSVP or LDP) onto the stack, creating a three-level label
stack (VRF-label—300080—302400).
US
The top label is popped by the provider P router (PHP), such that PE-3 receives a packet with a two-level label stack. PE-3
swaps the top label with the value assigned to the LSP to PE-4 by CE-2. PE-3’s label operation is shown here:
user@pe-3> show route table mpls.0
AL
mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
...
RN
299904 *[VPN/170] 19:07:27

> to 10.0.21.2 via ge-1/0/4.0, Pop
299904(S=0) *[VPN/170] 19:07:27
> to 10.0.21.2 via ge-1/0/4.0, Pop
300080 *[VPN/170] 01:15:43
TE
> to 10.0.21.2 via ge-1/0/4.0, Swap 299872

IN

Junos Layer 3 VPNs
Carrier-of-Carriers VPN Operation: PE-2 (contd.)
E
The result is that CE-2 receives a packet with a two-level label stack (VRF-label—299872). CE-2 then swaps the top label with
the value it associates with the LSP to the egress PE router. In this example, CE-2 pops the stack because it is the
AR
penultimate router for this LSP.
SH
T
NO
O
-D
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Carrier-of-Carriers VPN Operation: traceroute

This slide shows the results of a VRF table-to-VRF table traceroute operational command as well as a traceroute
E
operational command from ingress PE router to egress PE router.

US
All other router hops in the customer an provider networks are seen as traceroute timeouts.
The traceroute between PE-1 and PE-4 shows the outer MPLS label for the various hops in the path, except for the provider’s
routers which appear as timeouts. The provider routers are not able to generate traceroute responses, owing to their not
carrying customer external or internal routes.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Interprovider VPN Option C

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON

• P routers only maintain the internal routes from its own AS (AS-internal)
E
• PE routers maintain the internal routes from its own AS (AS-internal), the loopback address from the other AS
US
PE’s (AS-external), and the L3VPN routes.

• ASBR routers maintain 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 solution scalable.
ASBR Routers
AL
The ASBR routers interconnect the providers. To ensure that the L3VPN traffic is sent labeled across the interprovider link
labeled-unicast routes are exchanged across the EBGP session.
RN
CE Routers
CE routers are unaware of the interprovider setup so just as for single provider L3VPNs they only care about their own circuit
information and their local routing (if used at all).
TE
IN

Junos Layer 3 VPNs
Three-Level Label Stack Required
E
The presence of L3VPN related labels results 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:
AR
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 middle label is assigned by the downstream ASBR1 and is used by the ASBR1 to associate the packet with
SH
the LSP leading to the remote PE This is a labeled unicast learned label.
3. The top label associates the packet with the LSP connecting PE1 to ASBR1 and is assigned by RSVP or LDP.
Because an LSP must be established across AS boundaries to interconnect customer PE routers, labels must be
communicated along with the NLRI advertised by ASBRs. Although a protocol such as LDP could be used for this purpose,
the Junos OS currently supports MP-BGP for this purpose.
T
RFC 3107, Carrying Label Information in BGP-4, specifies labeled routes. Labeled route advertisements use SAFI 4 and
NO
differ from VPN-labeled routes in that there is no route distinguisher or route target communities in the advertised NLRI.
Simply put, labeled routes allow the binding of an MPLS label to the advertised IPv4 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.
O
-D
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
and/or RSVP can be used.

US
MP-EBGP Signaling Between Provider ASBR Routers

The ASBR routers use EBGP with labeled-unicast 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 the other AS.
AL
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 this information using
RN
an IBGP session to the local PE routers. This ensures that the PE routers learn the label towards the remote PE’s loopback
addresses.
MP-EBGP Signaling between the PE Routers

TE
To actually 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
IN

Junos Layer 3 VPNs
MP-EBGP Signaling between the PE Routers (contd.)
E
To improve scalability for large deployments, the provider networks can use route reflection. The two or more route reflectors
peer using multhop MP-EBGP. A command called no-nexthop-change is required to tell the route reflectors to pass—
AR
unchanged—the third party next hops to their clients.
SH
T
NO
O
-D
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Interprovider L3VPNs: Data Flow

This slide uses steps to describe the forwarding operations between PE1 and PE2 in an interprovider BGP L3VPN
E
application. The result is the need for a three-level label stack.

US

1. A packet for the L3VPN between CE-A1 and CE-A2 arrives at PE1.
AL
2. PE1 pushes three labels onto the packet: the inner label (3004) is the 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 LDP LSP to reach ASBR1.
3. P1 receives the labeled packet and pops the top label (PHP).
RN
4. ASBR1 receives the labeled packet and swaps the top label with the value received from ASBR2 (2007
-->2008)
5. ASBR2 receives the labeled packet and swaps the top label with the value of the LDP LSP towards PE2 (2008
TE
--> 1010).
IN

Junos Layer 3 VPNs
Forwarding: Step by Step (contd.)
E
6. Being the penultimate router for the LDP LSP to PE2, P2 pops the label stack and sends the resulting
L3VPN-labeled packet to PE2.
AR
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 towards the CE to which it is addressed.
SH
T
NO
O
-D
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Interprovider L3VPN between AS65201 and AS65202

This slide provides a sample network. The following slides show various configuration-mode and operational-mode screen
E
captures relating to this slide.

US
Within each provider’s network the IGP and LDP 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 routers are configured to run MP-EBGP (family inet labeled-unicast) with each other. They have a
AL
policy in place to ensure that only internal PE’s loopback prefixes are advertised to the other provider’s ASBR.
I-BGP Signaling Between ASBR and Local PE Routers

RN
To distribute the 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 configured between the PE1 and PE2, because the provider networks are assigned different
TE
AS numbers. The L3VPN NLRI is advertised as a labeled-VPN route by PE2 to PE1 using this MP-EBGP session.
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
PE1 Configuration
This slide shows the key aspects of PE1’s configuration. Family labeled-unicast is configured for its MP-IBGP session to
E
ASBR1, and family inet-vpn unicast is configured for the multihop MP-EBGP session to PE2.
US
resolve-vpn
The resolve-vpn option causes PE1 to copy the labeled-unicast routes it receives from ASBR1 into inet.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.
AL
The slide also shows the L3VPN routing-instance configuration that is identical as used for single provider L3VPNs.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
ASBR1 Configuration
This slide shows the key aspects of ASBR1’s configuration. Family labeled-unicast is configured for its MP-IBGP
E
session to ASBR1, and for its MP-EBGP session to ASBR2.

US
Notice the export policy called internals that contains the local PE’s loopback addresses.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Layer 3 VPN Routes

This slide shows that PE1 learns labeled VPN routes from PE2 at Site 2. These routes are associated with a L3VPN label (not
E
shown) used by the advertising router (PE2) to associate the packets with the correct L3VPN table.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
MP-BGP Peering Example

This slide shows that PE1 learns about Site 2’s internal routes through its MP-IBGP connection to ASBR1
E
The labeled-unicast routes received by PE1 are copied into the main routing table (inet.0) as well as the inet.3
US
table. This copying is the result of the resolve-vpn option on PE1 and is critical to the operation of this network. Normally,
L3VPN routes must resolve to an LSP that terminates on the egress PE router. Because PE1 does not have an LSP
terminating directly on PE2, the VPN routes are unusable without the labeled-unicast entries to the remote PE routers
in inet.3, which indicate a multinetwork LSP between PE1 and PE2 exists.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Interprovider L3VPN Operation: PE2

This slide shows the 100.1.0.0/24 route on PE2. It shows that traffic towards 100.1.0.0/24 will have 3 labels pushed upon it
E
to reach the network located on the remote CE device:

US
• Label 299776 (L3VPN label received from PE2 across MP-EBGP session)
• Label 300064 (Label received from the labeled unicast MP-IBGP session with ASBR1)
• 299824 = Top label (Label received from P1 router using the LDP protocol)
To verify the data-plane connectivity you can use a ping from one CE toward the remote CE. As shown in the slide the ping is
AL
successful.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
We Discussed:
• Junos support for carrier of carriers;
E
• Junos support for interprovider VPNs; and

US
• Interprovider VPN Option C.

AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Review Questions
1.
E
US
2.
3.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Lab: Carrier-of-Carriers VPNs

The slide provides the objective for this lab.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
1.
AR
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 only.
2.
Option A specifies the use of separate VRFs for every VPN on the ASBRs. Option B specifies the used of the EBGP exchange
SH
of VPN routes between ASBRs. Option C specifies the use of multihop EBGP (or IBGP) to exchange VPN routes between PEs
in remote autonomous systems.
3.
The labeled-unicast address family is used between PE and CE.
T
NO
O
-D
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
E
US
AL
RN
TE
IN

E
AR
SH
Junos Layer 3 VPNs
T
NO
Chapter 8: Troubleshooting Layer 3 VPNs
O
-D
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
We Will Discuss
• Using a structured approach to troubleshoot Layer 3 VPN issues;
E
• Useful commands and tools to check both the signaling and the forwarding plane; and
US
• Troubleshooting MVPN issues.

AL
RN
TE
IN
Chapter 8–2 • Troubleshooting Layer 3 VPNs www.juniper.net

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Troubleshooting Overview
E
US
AL
RN
TE
IN
www.juniper.net Troubleshooting Layer 3 VPNs • Chapter 8–3

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
A Useful Approach: Separating Signaling and Forwarding Plane

When troubleshooting Layer 3 VPN issues, a very useful approach is to use a structured approach: verifying the signaling
E
plane and the forwarding plane separately.

US
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 signal the transport LSPs.
Checking the forwarding plane, instead, typically means sending test traffic (even with tools such as ping mpls) to detect
forwarding problems.
Troubleshooting in many cases starts with checking the state of the signaling plane. The first steps are driven by the problem
AL
description: for example, in case of total 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 natural starting point would be the IBGP infrastructure (e.g. route reflectors) or the label
distribution protocols used.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
that may play a role. However, it is possible to think of a broad categorization of signaling and forwarding issues.
US
Some typical signaling issues are missing routes or unreachable sites. Even if the actual root cause is hardware, e.g. a failed
interface on the PE-CE link, the signaling plane will be able to help pinpoint where the problem is. More complex signaling
issues are suboptimal routing or routing loops within a VPN. These problems are however are not specific to Layer 3 VPNS,
and are essentially routing policy or redistribution issues.
When it comes to forwarding issues, some typical examples are partial or total packet loss between sites, or failure to
AL
forward multicast streams even when the multicast signaling plane appears correct. These problems are generally more
complex to troubleshoot, and may involve other features and functionalities as Class of Service.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Troubleshooting Commands are Protocol-Specific

Some natural checkpoints for troubleshooting Layer 3 VPN problems are:
E
1. The PE-CE dynamic routing protocols

US
2. The inet-vpn IBGP infrastructure

3. The MPLS label-distribution protocols used for establishing label-switched paths in the core
We will now look at several useful commands to check each of these components.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Verifying PE-CE Routing Protocols

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
f
E
AR
SH
T
NO
O
-D
LY
ON
Useful General Commands

A very useful command to check the overall routing state on all VPNs is show route summary.
E
This will summarize the amount of routes present in each routing instance, divided by protocol, and it is often a good first
US
step to check the overall signaling plane. The command will also display the number of hidden routes which - in a Layer 3
VPN environment - are typically caused by lack of MPLS reachability to remote PEs.
In the picture, you can see two VPNs (VPN-A and VPN-B). There are no hidden routes, but while the output for VPN-B appears
normal, VPN-A does not show any BGP routes. This means no route from remote PEs are being received, and could indicate
a target/VRF policy problem.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
BGP as PE-CE Routing Protocol: Useful Commands

The scalability and ease of use of BGP make it a very common choice as a PE-CE routing protocol. The commands used to
E
check ordinary IBGP and EBGP sessions can also be used without any modification to check the state of PE-CE BGP
sessions.
US
BGP Commands Show All Sessions in All VRFs

One point to consider is that BGP-related commands show all sessions, regardless 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
AL
to.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
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.
US
BGP export policies are still needed when distributing routes between instances using auto-export or a rib-group, or
in general whenever you need to advertise any non-BGP route (e.g. statics) to the local CE.
CEs in The Same AS

AL
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 discarded by the CE as an AS-PATH loop, several options are possible: if the customer
is using a private AS, the as-override command is a common solution. If the customer is actually using a public AS and is
connected to the Internet, then using IBGP with independent-domain may be a good alternative.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
OSPF as PE-CE Routing Protocol

The lower scalability compared to BGP makes OSPF a somewhat uncommon choice. All usual OSPF commands accept the
E
modifier instance, which allows to check the state of protocol running within a routing instance.
US
Several Configuration Options are Possible

To improve scalability of OSPF as PE-CE routing protocol, several configuration options are possible. Among the commonly
deployed ones is domain-id, that allows to redistribute VPN routes using export policies as Type-3 LSAs rather than
Type-5.
AL
A problem in VRF policies or a wrong domain-id configuration can cause VPN routes to be advertised as Type-5 rather than
Type-3. This can potentially cause routing problems for multi-homed sites, due to the different protocol preference of OSPF
external (150) and internal routes (10).
RN
A second, less common configuration option is the use of sham-links, which behave similarly to virtual links, connecting
multiple part of the same OSPF domain through the provider MPLS infrastructure. Sham-links are typically used when a
Layer 3 VPN is used to extend an OSPF domain, for example connecting multiple OSPF sites or regions.
Checking Advertised Routes

TE
When using sham-links, it is not trivial to verify which routes are being advertised by a PE towards a CE router. The routes will
be computed on the basis of the LSAs being received via the sham links.
IN

Junos Layer 3 VPNs
Checking Advertised Routes (contd.)
E
When using export policies instead (with or without domain-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.
AR
However, the output of show ospf database needs to be interpreted, as it only returns LSAs, not prefixes. For example,
here is the output of show ospf database instance <VPN> external advertising-router self on a PE
router:
SH
user@PE> show ospf database instance VPN-A external advertising-router self
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *10.3.0.0 10.1.0.2 0x80000201 1932 0xa2 0xfa61 36
Extern *10.3.0.3 10.1.0.2 0x80000201 1075 0xa2 0xca91 36
Extern *10.3.0.255 10.1.0.2 0x80000201 1503 0xa2 0xfa61 36
T
Extern *10.3.1.0 10.1.0.2 0x80000201 646 0xa2 0xef6b 36
NO
Extern *10.3.2.0 10.1.0.2 0x80000201 218 0xa2 0xe475 36
Extern *10.3.3.0 10.1.0.2 0x80000200 2789 0xa2 0xdb7e 36
From this output alone it is not possible to find out which prefixes are being advertised. This requires examining each LSA in
detail and checking its network and netmask., as shown below:
user@PE> show ospf database instance VPN-A external lsa-id 10.3.0.0 detail
O
Extern *10.3.0.0 10.1.0.2 0x80000201 2654 0xa2 0xfa61 36
-D
mask 255.255.0.0
Topology default (ID 0)
Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 208.0.255.232
user@PE> show ospf database instance VPN-A external lsa-id 10.3.0.255 detail
LY
Extern *10.3.0.255 10.1.0.2 0x80000201 2233 0xa2 0xfa61 36
mask 255.255.255.0
ON
Topology default (ID 0)

Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 208.0.255.232
In this example, the first LSA (lsa-id 10.3.0.0) is for 10.3.0.0/16, and the third (lsa-id 10.3.0.255) is for the 10.0.3.0/24
prefix.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Advertising VPN Routes Using OSPF

The default policy for OSPF is not to add any external route to the link-state database, so MP-BGP routes will not be
E
advertised by default, and an export policy will be typically needed. The type of LSAs used to advertise VPN routes to CEs can
change according to the domain-id settings and the type of route (OSPF internal vs. OSPF external), and can be either a
US
Type-3 or a Type-5.
One special case is the use of sham-links; in this case, the PEs will not re-distribute MP-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 advertising 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.
AL
LSDB Size Limit

When using OSPF as PE-CE protocol, it is generally considered good practice to configure a maximum link-state database
RN
size, to protect the PE from configuration mistakes and wrong redistributions on the CEs. Exceeding this limit will cause OSPF
to go down, and an error message to be logged.
Aug 1 13:29:43 mxA-1 PE-1:rpd[13901]: RPD_OSPF_NBRDOWN: OSPF neighbor 10.2.0.1
(realm ospf-v2 ge-1/0/8.0 area 0.0.0.0) state changed from Full to Down due to
TE
KillNbr (event reason: exceeded database protection maximum)

IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Checking Advertised Routes

When not using sham-links, you can verify your OSPF export policy by checking which self-generated LSAs are being
E
advertised to the CE. The slide shows an example where three additional prefixes are being advertised to the CE: two
external routes, and a summary LSA. The summary LSA and the two external LSAs reflect respectively OSPF-internal and
US
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.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
of RIP is the fact that the protocol lacks a keepalive mechanism to verify the state of CEs.
US
RIP does not have the concept of “neighbor” or “adjacency”, and because of this RIP-related commands are typically 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@router> show rip neighbor instance VPN-B ge-1/0/8.0
Local Source Destination Send Receive In
AL
Neighbor State Address Address Mode 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
RN
about the state of the CE.

Finally, RIP by default advertises no route, so an export policy is always needed.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
MPLS Transport and Label Distribution Protocols

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Layer 3 VPN Forwarding Requires LSPs Between PEs

MPLS Layer 3 VPNs require a label-switched path to be established between PEs, or between the hub PE and spoke PEs in
E
hub-and-spoke configurations. On Junos routers, and easy way to check MPLS reachability is to look at the inet.3 table,
the table of MPLS egress points, and verify that all remote PEs are present.
US
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 typically use BGP labeled-unicast; in this case, the command
resolve-vpn may be needed in order to get labeled-unicast routes installed also in inet.3 in addition to inet.0.
Using resolve-vpn is not the only way to install MPLS egress points in inet.3 ad well as in inet.0. There are also
AL
other possibilities, including changing the default Junos traffic engineering behavior by enabling traffic-engineering
mpls-forwarding at the [edit protocols mpls] level. Still, the MP-BGP next-hops for inet-vpn routes need to
be resolvable through an entry in inet.3. This makes checking this table a fundamental and useful troubleshooting step.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Troubleshooting Missing inet.3 Routes

Label-switched paths are established by label-distribution protocols (LDP and RSVP) or, for inter-domain applications, by
E
MP-BGP using labeled-unicast prefixes. On the slide you can see some useful commands to check the correct operation of
both RSVP and LDP.
US
From troubleshooting the point of view, one advantage of RSVP is that it gives ingress routers full 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, finding the root cause often means checking hop-by-hop from the ingress to the egress, until the failure is found.
Detailed RSVP and LDP troubleshooting is covered in other Juniper Education courses.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
MP-BGP
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
MP-BGP: Useful Commands

Troubleshooting MP-BGP in a Layer 3 VPN environment is very similar to ordinary BGP troubleshooting, and uses the same
E
BGP-related CLI commands. One point to keep in mind is that BGP next-hops need to be reachable using an MPLS LSP in
order for a inet-vpn route to be usable.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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.
E
Because of this, it is not possible to detect a target mismatch with the show route receive-protocol bgp
command on a PE. Especially with complex VRF import and export policies, it is always best to check also the remote side,
US
using the show route advertising-protocol bgp command.

A second important point to consider is that a reflector will 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 will typically never be used for forwarding traffic) or - if the reflector is away from the forwarding path
- using a static “dummy” inet.3 route. This last option will also prevent a route from being dropped just because there is no
AL
LSP from a PE to the reflector, even when there is full MPLS reachability between the PEs.
For example, to allow a reflector outside the MPLS domain to reflect VPN routes this static entry could be added to the inet.3
table:
RN
[edit routing-options]
user@route-reflector# show
rib inet.3 {
static {
TE
route <prefix-of-PEs-loopbacks> discard;

}
}
...
IN
The presence of a static route to MP-BGP next-hops is enough to allow the correct reflection of VPN routes.

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Checking IBGP Peers

The show bgp neighbor command is the main command used to check the state of IBGP peers. Among other useful
E
information, this command will show the number of flaps since configuration and the reason of the last flap.
US
On the slide, you can see a BGP neighbor in Established state. Apparently everything seems correct, but if you check the
address families advertised by each peer, you can see that the remote end (probably a route reflector) is advertising also
family route-target, while the local end only inet-unicast and inet-vpn-unicast. On a big setup, this means
that a large number of unnecessary updates can be sent from the reflector to the local router, only to be discarded on
receive.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
The bgp.l3vpn.0 Table

The bgp.l3vpn.0 table contains inet-vpn routes from remote PEs, regardless from the VPN they belong to. While it is
E
not very common having to examine this table for troubleshooting purposes, any hidden route shows MPLS reachability
problems to advertising PEs.
US
One common misconception is that examining the bgp.l3vpn.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-all keyword at the BGP neighbor level, but this is typically
not recommended in any realistic deployment due to its potential negative side effects (increased resource utilization).
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Checking MP-BGP Received Routes

The show route receive-protocol bgp will show any received route, including inet-vpn NLRI. Each prefix is
E
typically shown twice: once in the bgp.l3vpn.0 table (in route-distinguisher:prefix format) and once (as a regular prefix) in
its VRF table, after passing the vrf-import policy.
US
In the slide, 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
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
shows how to display hidden routes next-hops with the show route receive-protocol bgp hidden command.
After this, you can verify that the BGP next-hops are actually missing from the inet.3 table with show route table
US
inet.3. Once the unreachable next-hops are identified, it is just a matter of troubleshooting the label-distribution protocol
that should have advertised them.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
The Forwarding Plane

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Useful Commands for Layer 3 VPN Forwarding Issues

All forwarding troubleshooting typically involves sending some form of test traffic, and following it to detect problems. A
E
number of commands are available for this; which one to use depends on the specific problems, and on the components of
the path that need to be tested.
US
To troubleshoot PE-CE communications, both the ping and the traceroute commands accept the
routing-instance modifier, and can be used in the same way as for ordinary IP forwarding troubleshooting. Similarly,
show arp can be used to verify IP-to-MAC resolution on Ethernet interfaces.
To troubleshoot the MPLS core, instead, you can use the ping mpls and traceroute mpls commands specific to your
AL
label distribution protocol. In addition to these, you can also use the Layer 3 VPN specific command ping mpls l3vpn.
Finally, it is possible to enable icmp-tunneling to allow traceroute through the MPLS core from within the VPN. It is
important to be aware of the limitations of this functionality, 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,
RN
regardless where the real problem is. This is because the TTL-expired ICMP messages need to be forwarded all 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.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Detecting MTU Bottlenecks with ping mpls

The ping mpls command can also be used to detect MTU bottleneck, which can be especially problematic when they
E
affect a secondary path, a bypass or a detour LSPs. In this case, every seems to work correctly on the primary path, until
(due for example to a link failure) traffic is re-routed using the alternative, MTU-constrained path, triggering the problem.
US
The example shows a case where the core MTU of an Ethernet-based network was left as 1500 bytes. The ping mpls
command try to find out 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 this example, the command reports a usable MTU of 1488, due to the 12 bytes being used for 3 labels (transport, VPN
AL
and LDP tunneling/protection label).

RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Troubleshooting MVPNs
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
The Three Components of MVPN Signaling Plane

MVPN troubleshooting has been left for last, as correct and stable unicast routing is a prerequisite for it to work. In addition
E
to unicast routing, troubleshooting MVPNs may require investigating also three additional components:
US
1. The customer PIM domain

2. The MVPN BGP signaling
3. The inclusive (and selective, if used) provider multicast service interface
This last point is typically implemented with point-to-multipoint LSPs (either with RSVP or LDP). The older, deprecated
AL
draft-rosen version of MVPN used GRE tunnels to multicast destinations as a multicast service interface, but these
architectures are typically plagued by several limitations and are today considered obsolete.
A natural way of approaching troubleshooting MVPNs is to follow this order, first verifying if the customer multicast domain is
working up until the PE, then checking if multicast state is correctly relayed by MP-BGP, and finally investigate the Provider
RN
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.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
The Customer Multicast Domain

Troubleshooting the customer multicast domain is no different to troubleshooting PIM outside of VPNs: all operational mode
E
PIM-related commands accept the modifier instance <vpn>. The actual troubleshooting steps are driven by the actual
problem: for example, if no CE can receive traffic from a given source it is natural to start with checking source registration,
US
while if a receiver cannot receive any source but every other CE can, it is probably useful to start checking IGMP, then move
on to checking the RP tree.
In addition to PIM-related commands, the show mvpn c-multicast instance-name <vpn> can be used to check
customer multicast state on the PE. The use of this command will be illustrated in the next slide.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Checking c-multicast State

The show mvpn c-multicast instance-name <vpn> can be used to check the Provider Multicast Service Interface
E
used by a given multicast stream. The example shows a MVPN running in SPT-only 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, while the line immediately
US
above shows a join-to-RP (*,g) state for group 224.7.7.1. This command can be especially useful when using selective
provider tunnels, to find out the mapping between (source,group) pairs and PMSIs.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
The BGP MVPN Signaling Plane

The second component of the MVPN signaling plane is MP-BGP with family mvpn signaling. This address family
E
includes seven different route types, each with different encoding. In order to troubleshoot MVPN, it is important to be able
to decode and understand the role of each route type.
US
An initial check might involve verifying if every PE is advertising a type-1 route (I-PMSI autodiscovery). Types 5, 6 and 7 are a
translation of (respectively) PIM register source, join-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 PMSIs; a type-3 route should be advertised by each PE
AL
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
RN
route types and encodings” available on the Juniper Networks Knowledge Base with document-id TN-115.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
The MVPN Forwarding Plane

The main command to use for troubleshooting the MVPN forwarding plane is show multicast route instance
E
<VPN> extensive.This not only shows the forwarding state in terms of installed multicast routes, but provides also traffic
counters which show how much multicast traffic is being forwarded. Very often troubleshooting multicast forwarding means
US
to go from router to router checking the traffic counters tied to a specific multicast (source, group) pair; having traffic
counters makes this easy and non-disruptive, as it can be done without changing the configuration or enabling traceoptions.
The command also shows the number of packets discarded due to Reverse Path Forwarding Check Failure, in the line titled
“Wrong incoming interface notification”.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
We Discussed
• Using a structured approach to troubleshoot Layer 3 VPN issues;
E
• Useful commands and tools to check both the signaling and the forwarding plane; and
US
• Troubleshooting MVPN issues.

AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Review Questions
1.
E
US
2.
3.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Lab: Troubleshooting Layer 3 VPNs

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
1.
AR
An export policy is always needed with RIP, and are needed for OSPF when not using a sham-link.
2.
The show bgp neighbor command will display the address family configured on both the local and the remote end of the
BGP session.
SH
3.
The typical cause of hidden routes in the bgp.l3vpn.0 table is the lack of a LSP to the advertising PE.
T
NO
O
-D
LY
ON
E
US
AL
RN
TE
IN

E
AR
SH
Junos Layer 3 VPNs
T
NO
Chapter 9: Multicast Review and Draft Rosen
O
-D
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
We Will Discuss:
• IP multicast traffic flow;
E
• Components of IP multicast;
US
• How multicast addressing works;

• The need for RPF check in multicast networks;
• The role of IGMP; and
• Draft-rosen multicast and some of the drawbacks.
AL
RN
TE
IN
Chapter 9–2 • Multicast Review and Draft Rosen www.juniper.net

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Multicast VPN Overview

E
US
AL
RN
TE
IN
www.juniper.net Multicast Review and Draft Rosen • Chapter 9–3

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Address Types
In IP networking three types of addressing are typically used for the communication between hosts:
E
• Unicast addressing: Unicast addresses are used when a host wants to send traffic to another specific host.
US
Each host requires 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 typically not
forwarded by the router. Some types of broadcast traffic (for example, DHCP) might need to be forwarded to
other parts of the network.
AL
• Multicast addressing: Multicast addresses are used when a host wants to communicate with a group of hosts
that are interested in that 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).
RN
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 all share the same address. When traffic must 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 multicast it is also used in a feature called anycast RP. An advantage of anycast addressing is that it provides a very fast
TE
convergence in case one of the members of the group disappears.

IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Multicast Components: Part 1

The slide describes some of the common terms used in multicast:
E
• Source: A multicast source is any device that originates multicast IP packets.

US
• 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 guarantees exist that 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.
AL
• 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 receiver uses
IGMP to inform the directly connected router of its desire to receive multicast packets.
RN
• 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 that depends on the multicast routing protocol in use.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Multicast Components: Part 2

The following list continues the list of the common terms used in multicast from the previous page:
E
• Group membership protocol: Receivers use a group membership protocol to inform the directly connected
US
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
(IPv4) hosts and routers for this purpose. This material focuses on IPv4 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 following slides describe the basic functionality of
AL
a multicast routing protocol. The two most common multicast routing protocols are Protocol Independent.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Service Models
We use the following terminology for multicast service models:
E
• Any-source multicast (ASM): This delivery model was designed into the original specifications for multicast in
US
RFC 1112. 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 join a group without specifying from which source they want to receive traffic, so they accept it from any
source.
• Source-specific multicast (SSM): In SSM, the receiver specifies the sources from which it wants to receive the
AL
traffic. It can also specify from which sources 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
multicast addresses easier.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Distribution Modes
We use the following terminology for multicast distribution modes:
E
• Dense mode: In dense mode, traffic is forwarded to all parts of the network (which is known as flooding). The
US
parts of the network that are not interested in receiving the traffic send prune messages to their neighboring
routers asking them to stop forwarding traffic. In case a receiver subscribes after sending the prune, the router
sends a graft message asking for the traffic to be forwarded again.
• Sparse mode: In sparse mode, traffic is forwarded only into parts of the network with interested receivers. The
routers send join messages to indicate their willingness to receive traffic. If a receiver is no longer interested,
AL
the router sends prune messages to the neighbor asking it to stop forwarding the traffic.
• 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,
RN
and data packets are forwarded by means of PIM sparse-mode rules.

TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Distribution Trees
We use the following terminology for multicast distribution trees:
E
• Source tree or shortest-path tree (SPT): A source tree is the forwarding path for the traffic from a specific source
US
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 only 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 following 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.
AL
• 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).
RN
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.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Multicast Forwarding
In multicast forwarding, the path between source and receiver is called a tree. The source is the root of the tree. The tree
E
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
US
receivers leave. In the case of a shared tree, the RP is considered upstream and the root of the tree.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Source Tree and Shared Tree in PIM Sparse Mode

In PIM sparse mode, the distribution trees have the following characteristics:
E
• Source Tree: The source tree, or shortest-path tree, builds the forwarding path from source directly toward the
US
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 flooding process. Any part of the network that does not have receivers prunes the distribution tree. The
result 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 messages are exchanged. In case a receiver is no longer
AL
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
RN
enable the forwarding 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
TE
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 optimal. This issue is especially
IN
important for delay-sensitive traffic.

Junos Layer 3 VPNs
f
E
AR
SH
T
NO
O
-D
LY
ON
Reverse Path Forwarding

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Multicast Forwarding
When forwarding unicast traffic, the router is primarily concerned with the destination address. The goal of unicast
E
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
US
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.
AL
To determine which incoming packets are sent down the distribution tree, multicast forwarding uses the reverse path
forwarding (RPF) check. The RPF mechanism basically selects packets to forward down the distribution tree only if the
packet was received on the interface that is nearest to the source.
RN
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 passes 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 fails
and the packet is discarded.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
routing table and determines that this interface is not on the reverse path back to the source. Thus, the packet is discarded.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
The RPF Check: Part 2

In this example, R1 receives a packet from Source 1 on its ge-0/0/4.125 interface and, once again, performs an RPF check.
E
R1 determines that the packet is coming in on an interface that is on the reverse path back to the source. Thus, the RPF
check succeeds, and the packet is forwarded to all interfaces on the outgoing interface list. Initially, all interfaces other than
US
ge-0/0/4.125 will be on the outgoing interface list.

AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
plane:
US
• 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 receivers is called the outgoing interface list
(OIL). The result of a successful RPF check is cached in table inet.1.
AL
• Control plane: The RPF check is also used in the control plane. If a router must receive traffic because of
downstream receivers, it signals only to upstream routers on the interface that would pass the RPF check.
Therefore, join and prune messages are only exchanged with neighboring routers on the interface to the
upstream router nearest to the source. The receipt of IGMP or PIM join messages moves those interfaces to the
RN
OIL, so packets are forwarded to these interfaces toward the receivers.

TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Route Tables for Multicast Routing

Multicast forwarding uses multiple route tables related to the RPF check process:
E
• inet.0: The default table used by the RPF check process is the same as the unicast forwarding table. Thus,
US
the unicast topology and multicast topology are identical.

• inet.1: The results of successful RPF checks for forwarding traffic are cached in a separate inet.1 table.
• inet.2: If you must have a separate topology for multicast forwarding, you can achieve this separate topology
by changing the table the RPF check uses. Therefore, instead of looking in the default inet.0 table, the RPF
check can be directed to look in inet.2. The inet.2 table must be filled with routing information to build the
AL
alternate topology used by the RPF check:

– Routing protocols like multiprotocol BGP (M-BGP) and multi-topology IS-IS can place routes into inet.2
directly; or
RN
– Other protocols must use routing information base (RIB) groups to place routes into inet.2.
To direct the multicast routing protocols to use inet.2 for the RPF check, RIB groups are required.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Alternate Multicast Topology

The slide shows the use of MP-BGP to create two separate topologies. The two separate topologies allow a form of
E
load-sharing across links between unicast traffic and multicast traffic. On the slide, routes for the same prefixes are
exchanged twice, once for unicast routing (inet.0) and once for multicast routing (inet.2).
US
When AS 65013 sends unicast traffic 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 topologies had been identical, the multicast RPF
check would have also preferred the bottom link.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Internet Group Management Protocol

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
routing protocols allow multicast traffic to flow between networks. Common multicast routing protocols are DVMRP and PIM.
US
Normally, you do not have to run IGMP between routers because routers normally do not join multicast groups.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
IGMP Join Process

IGMP hosts interested in receiving traffic send an IGMP report message to the router. The destination address of the report
E
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
US
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.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
from at least one host. Thus, if more hosts are on a segment that are interested in receiving the same group traffic, the
router still only forwards one time.
US
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 message is to receive a solicited 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
AL
needs one to keep the interface in the outgoing interface list.

To avoid duplicate 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
RN
group already answered (shorter timer), the other receivers in that group suppress their responses. This 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 thinking
it must start querying, but as soon as it sees queries from another router with a lower IP address, it stops. These non-querier
TE
routers that lose the querier election still keep track of the IGMP cache.
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
IGMP Leave Process

In IGMP version 1, no explicit leave process exists for clients to indicate that they are no longer interested in receiving traffic.
E
When a 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 forwarding out of that interface, which results in a long leave latency.
US
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 message 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
AL
use are much lower.

RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Draft Rosen Overview

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Multiservice Network
This slide illustrates the general model for multiservice network.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Draft Rosen
There was a time when draft-Rosen has been the standard by which multicast was transported between Layer 3 VPN
E
(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
US
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.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
customer network (VPN routing and forwarding table [VRF]), a provider edge (PE) must participate in the customers PIM
domain. Within the provider network (main routing instance), a PE must participate in the providers PIM domain.
US
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
AL
destination address of the GRE packets which tunnel customer multicast traffic across the provider network.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Legacy Multicast Over ISP Core Problem

Customers could run their Multicast traffic as legacy Multicast from their connected C routers over the ISP Core network but
E
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 could not be able to use same Multicast
US
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 customer’s CE routers in a full mesh fashion. This approach can
be feasible in a very small customer CE base but the number of GRE tunnels increases with the number of CE routers with
N’(N-1)/2, where N = number of CE routers.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Automatic GRE Tunnel Setup

Instead of the customer manually configuring the CE-to-CE router GRE tunnels, the PE routers will now automatically set up
E
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
US
address. We call these GRE tunnels the Multicast Distribution Tree (MDT). Of course this setup requires that the ISP core has
multicast routing configured.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Draft Rosen Default

In a draft-rosen Layer 3 multicast virtual private network (MVPN) configured with service provider tunnels, the VPN is
E
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 multicast
US
domain (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, which 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 sending all multicast 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
AL
draft draft-rosen-vpn-mcast-07.txt. This 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 receivers for the multicast group in that VPN. Each PE router
processes the encapsulated VPN traffic even if the multicast packets are then discarded.
RN
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 will attempt to form a GRE tunnel with the other PE routers. The PE
routers will also join the Multicast group 239.10.11.11 in the ISP core. The result is that the PE routers now will send GRE
tunneled traffic which will end up at all other PE routers since the destination address is the Multicast IP address.
TE
Multicast enabled GRE tunnels:

• 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)
IN
• PE3 (10.1.1.3) to PE1 and PE2 (239.10.11.11)

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
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)
US
type-length-value (TLV) packet called 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 site is attached sends a
subsequent MDT join TLV for the VRF instance over the default MDT, any existing cache entries for that VRF instance are
AL
simply refreshed with a timeout value of 180 seconds.

RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON

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
E
join the new data MDT group:

US
• 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 also join 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 join TLV, adding a 180-second timeout value to the cache entry, but do not join the new
data MDT group at this time.
AL
When a remote PE router joins the new data MDT group, it sends a PIM join 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

RN
The source PE router starts encapsulating the multicast traffic for the VRF instance using the new data MDT group after
3 seconds, allowing time for the remote PE routers to join the new group. The source PE router then halts the flow of
multicast packets over the default MDT, and the packet flow for the VRF instance source shifts to the newly created data
TE
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 join 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.
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON

If a PE router that has not yet joined the new data MDT group receives a PIM join message for a new receiver for which (S,G)
E
traffic is already flowing over the data MDT in the provider core, then that PE router can obtain the new group address from
its cache and can join the data MDT immediately without waiting up to 59 seconds for the next data MDT advertisement.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON

The PE router monitors the traffic rate during its periodic statistics-collection cycles. If the traffic rate drops below the
E
threshold or the source stops sending multicast traffic, the PE router to which the source site is attached stops announcing
the MDT join TLVs and switches back to sending on the default MDT for that VRF instance.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Two Types of Draft-Rosen Multicast VPNs

Juniper provides two types of draft-rosen multicast VPNs:
E
• Draft-rosen multicast VPNs with service provider tunnels operating in any-source multicast (ASM) mode (also
US
referred to as rosen 6 Layer 3 VPN multicast)—Described in RFC 4364,BGP/MPLS IP Virtual 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 Virtual Private
AL
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.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
ASM for Draft Rosen Requirements

Your routers’ interfaces should be configured correctly to have full connectivity as desired to carry on the packet forwarding
E
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.
US
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.
AL
• 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.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
ASM Configuration
This slide illustrates the example network used in the next few slides.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
PE Router Configuration
The slide highlights the key components for configuring the ASM PE router:
E
• interface lo0.1: Configures an additional unit on the loopback interface of the PE router. For
US
the lo0.1 interface, assign an address from the VPN address space. Add the lo0.1 interface to the following
places in the configuration:
– VRF routing instance
– PIM in the VRF routing instance
AL
– IGP and BGP policies to advertise the interface in the VPN address space
• In multicast Layer 3 VPNs, the multicast PE routers must use the primary loopback address (or router ID) for
sessions with their internal BGP peers. If the PE routers use a route reflector and the next hop is configured as
self, Layer 3 multicast over VPN will not work, because PIM cannot transmit upstream interface information for
RN
multicast sources behind remote PEs into the network core. Multicast Layer 3 VPNs require that the BGP
next-hop address of the VPN route match the BGP next-hop address of the loopback VRF instance address.
• protocols pim interface - Configures the interfaces between each provider router and the PE routers.
TE
• protocols pim mode sparse - Enables PIM sparse mode on the lo0 interface of all PE routers. You can
either configure that specific interface or configure all interfaces with the interface all statement.
• protocols pim rp static - On all PE routers, configure the address of the router acting as the RP
statically since in this example we have chosen to use static RP configuration. RP is the P1 router.
IN

Junos Layer 3 VPNs
PE Router Configuration (cont.)
E
• routing-options rib-groups - Configures the multicast routing group. This group configuration results
in using inet.2 when doing RPF checks. However, if you are using inet.0 for multicast RPF checks, this step
AR
will prevent your multicast configuration from working. You can use inet.0 only and skip the inet.2 which is
just an option not a mandatory configuration step.
• group-address - In a routing instance, configure multicast connectivity for the VPN on the PE routers.
Configure a VPN group address on the interfaces facing toward the router acting as the RP. The PIM
SH
configuration in the VPN routing and forwarding (VRF) instance on the PE routers needs to match the master
PIM instance on the CE router. Therefore, the PE router contains both a master PIM instance (to communicate
with the provider core) and the VRF instance (to communicate with the CE routers).
• VRF instances that are part of the same VPN share the same VPN group address. For example, all PE routers
containing multicast-enabled routing instance VPN-A share the same VPN group address configuration. In
T
figure on previous page the shared VPN group address configuration is 239.1.1.1.
NO
• routing-instances VPN-A protocols pim rib-group - Adds the routing group to the VPN's VRF
instance ands activates it in the instance.
Note that imports and exports confide because the rib group is reused between both pim and interface routes:
• export for pim routes and
O
• import for interface routes
-D
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Static RP Configuration in Local Router

To enable static RP, configure the protocols pim rp local on all routers acting as the RP, configure the address of
E
the local lo0 interface. The P router acts as the RP router in this example.

US
On router CE1 you need to configure PIM statically to use CE2 as the RP for VPN-A
user@CE1# show protocols
pim {
rp {
static {
AL
address 10.255.254.91;
...
interface all {
mode sparse;
RN
version 2;
...
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Verification of The Configuration of ASM Draft Rosen

Display multicast tunnel information and the number of neighbors by using the show pim interfaces instance
E
VPN-A command from the PE1 or PE2 router.

US
Display multicast tunnel interface information, DR information, and the PIM neighbor status between VRF instances on the
PE1 and PE2 routers by using the show pim neighbors instance VPN-A command from either PE router.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Source Specific Multicast Draft Rosen Basics: Part 1

A draft-rosen MVPN with service provider tunnels operating in SSM mode uses BGP signaling for autodiscovery of the PE
E
routers. These MVPNs are also referred to as Draft Rosen 7.

US
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)
AL
• 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
RN
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.
TE
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.
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Source Specific Multicast Draft Rosen Basics: Part 2

The control plane of a draft-rosen MVPN with service provider tunnels operating in SSM mode must be configured to support
E
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
US
MVPN with service provider tunnels operating in SSM mode uses some of the facilities 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.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
SSM for Draft Rosen Requirements

Your routers’ interfaces should be configured correctly to have full connectivity as desired to carry on the packet forwarding
E
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
US
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.
AL
• 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.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Configuration Steps for SSM Draft Rosen: Part 1

When a draft Rosen multicast VPN is used over an SSM provider core, there are no PIM RPs to provide rendezvous and
E
autodiscovery between PE routers. Therefore, draft-rosen-vpn-mcast-07 specifies the use of a BGP network layer reachability
information (NLRI), called MDT sub address family identifier information (MDT-SAFI) to facilitate autodiscovery of PEs by
US
other PEs. 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.
set protocols bgp group group-name family inet-mdt signaling
AL
Enables MDT-SAFI signaling in BGP.

set routing-instance instance-name protocols mvpn family inet autodiscovery-only
RN
intra-as inclusive
Enables the multicast VPN to use the MDT-SAFI autodiscovery NLRI.
set routing-instance instance-name protocols pim mvpn
Specifies the SSM control plane. When pim mvpn is configured for a VRF, the VPN group address must be specified with
TE
the provider-tunnel pim-ssm group-address statement.

set routing-instance instance-name protocols pim mvpn family inet autodiscovery
inet-mdt
IN
Enables PIM to learn about neighbors from the MDT-SAFI autodiscovery NLRI.

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Configuration Steps for SSM Draft Rosen: Part 2

Configures the provider tunnel that serves as the control plane and enables the provider tunnel to have a static group
E
address. Unlike draft-rosen multicast VPNs with ASM provider cores, the SSM configuration does not require that each PE for
a VPN use the same group address. This is because the rendezvous point assignment and autodiscovery are not
US
accomplished over the default MDT tunnels for the group. Thus, you can configure some or all PEs in a VPN to use a different
group, but the same group cannot be used in different VPNs on the same PE router.
set routing-instance instance-name provider-tunnel pim-ssm group-address
multicast-address
AL
Configures the VRF export policy. When you configure draft Rosen multicast VPNs with provider tunnels operating in
source-specific mode and using the vrf-target statement, the VRF export policy is automatically generated and automatically
accepts routes from the vrf-name.mdt.0routing table.
RN
set routing-instances ce1 vrf-target target:community-id

When you configure draft Rosen multicast VPNs with provider tunnels operating in source-specific mode and using the
vrf-export statement to specify the export policy, the policy must have a term that accepts routes from the
vrf-name.mdt.0 routing table. This term ensures proper PE autodiscovery using the inet-mdt address family.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
SSM Draft Rosen Verification: Part 1

The show pim mdt command shows the tunnel type and source PE address for each outgoing and incoming MDT. In
E
addition, because each PE might have its own default MDT group address, one incoming entry is shown for each remote PE.
Outgoing data MDTs are shown after the outgoing default MDT. Incoming data MDTs are shown after all incoming default
US
MDTs.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON

For the default MDT, the show pim mdt instance <vpn-name> command displays details about the incoming and
E
outgoing tunnels established by the local PE router for specific multicast source addresses in the multicast group using the
default MDT and identifies the tunnel mode as PIM-SSM. For the data MDTs initiated by the local PE router, the command
US
identifies the multicast source using the data MDT, the multicast tunnel logical interface set up for the data MDT tunnel, the
configured threshold rate, and current statistics. The output also provides the details for the following fields:
• C-Group: IPv4 group address in the address space of the customer’s VPN-specific PIM-enabled routing
instance of the multicast traffic destination. This 32-bit value is carried in the C-group field of the MDT join TLV
packet.
AL
• C-Source: IPv4 address in the address space of the customer’s VPN-specific PIM-enabled routing instance of
the multicast traffic source. This 32-bit value is carried in the C-source field of the MDT join TLV packet.
• P-Group: IPv4 group address in the service provider’s address space of the new data MDT that the PE router
RN
will use to encapsulate the VPN multicast traffic flow (C-Source, C-Group). This 32-bit value is carried in the
P-group field of the MDT join TLV packet.
• Data tunnel interface: Multicast data tunnel interface that set up the data-MDT.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON

The show pim mdt data-mdt-joins instance <vpn-name> command output displays the information cached
E
from MDT join TLV packets received by all PE routers participating in the specified VRF instance, including the current
timeout value of each entry. The output provides the following information:
US
• P-Source: IPv4 address of the PE router.

• Timeout: Timeout value, in seconds, remaining for this cache entry. When the cache entry is created, this field
is set to 180 seconds. After an entry times out, the PE router deletes the entry from its cache and prunes itself
off the data MDT.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Draft Rosen Limitations

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Draft Rosen Limitations

Draft Rosen multicast VPNs are not supported in a logical system environment even though the configuration statements
E
can be configured under the logical-systems hierarchy.

US
By sending the Multicast traffic by default over the default MDT forces all participating PE routers to receive 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.
AL
ASM uses GRE tunnels for the Multicast distribution between the PE routers which adds on both protocol overhead and
encapsulation/decapsulation. It also requires PICs supporting tunneling protocols.
One VRF on a PE router must maintain PIM adjacencies with all other VRFs of that MVPN, i.e. PIM adjacency is maintained
RN
per MVPN per PE, not just per PE. In addition to PE adjacencies the VRF also must maintain PIM adjacencies with all of its
locally connected CEs of the VRF’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.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
We Discussed:
• IP multicast traffic flow;
E
• Components of IP multicast;
US
• How multicast addressing works;

• The need for RPF check in multicast networks;
• The role of IGMP; and
• Draft Rosen multicast and some of the drawbacks.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Review Questions
1.
E
US
2.
3.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
1.
AR
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.
SH
3.
IGMP is used to inform the directly connected routers that the local router desires to receive specific multicast packets.
T
NO
O
-D
LY
ON
E
US
AL
RN
TE
IN

E
AR
SH
Junos Layer 3 VPNs
T
NO
Chapter 10: Next-Generation Multicast VPNs
O
-D
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
We Will Discuss:
• The flow of control traffic and data traffic in a next-generation multicast virtual private network (MVPN);
E
• The configuration steps for establishing a next-generation MVPN;

US
• Monitoring and verifying the operation of next-generation MVPNs; and

• The function of MVPN Internet multicasting with ingress replication.
AL
RN
TE
IN
Chapter 10–2 • Next-Generation Multicast VPNs www.juniper.net

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Multicast VPN Overview

E
US
AL
RN
TE
IN
www.juniper.net Next-Generation Multicast VPNs • Chapter 10–3

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Motivations for Next-Generation MVPN

Over the last few years their has been increasing interest in transporting multicast traffic over Layer 3 VPNs along with
E
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
US
customers.
MPLS forwarding has evolved as well. With the advent of the point-to-multipoint LSP, an MPLS-based network can provide
multicast-like forwarding capabilities without the need for running multicast protocols.
The draft-Rosen method of delivering multicast content has some scaling limitations. For example, consider an example
AL
where a PE has 1,000 VRFs, and each of these VRFs corresponds 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 the PE would need to process is
3,300 per second.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Model for Next-Generation MVPNs

The slide shows the signaling and transport model of next-generation MVPNs. Next-generation MVPNs use the same MPLS
E
and BGP infrastructure as Layer 3 VPNs, Layer 2 VPNs, and VPLS.

US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
BGP for PE to PE Signaling

Next-generation MVPNs call for Multiprotocol Border Gateway Protocol (MP-BGP) as the signaling method for multicast trees.
E
Seven new network layer reachability information (NLRI) types have been standardized in RFC 6514. The new NLRI types
perform functions like MVPN membership autodiscovery, selective tunnel autodiscovery, PIM join message conversion, and
US
active source advertisement.

The PIM adjacency problem between PEs that was found in draft-Rosen no longer exists. Instead, a PE router might only
need a few BGP neighbor relationships with route-reflectors, which might also be the same route-reflectors used for the
L3VPN.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Next-Generation MVPN Terms

There are some common terms you should know about next-generation MVPNs, including:
E
• Provider-Multicast Service Interface (PMSI): Tunnel used to transport multicast data from PE to PE. It is also
US
called 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-PMSI (I-PMSI): There are two type of I-PMSIs.
– Multidirectional I-PMSI: Allows all PEs of a multicast VPN (MVPN) to transmit multicast data between
AL
each other (one point-to-multipoint LSP from all PEs to all other PEs).
– Unidirectional I-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).
RN
• Selective-PMSI (S-PMSI): A PE can transmit multicast packets to only those PEs of an MVPN that have
expressed interest in being part of the multicast forwarding tree.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Next-Generation MVPN Operation

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
MCAST-VPN NLRI
The NLRI format for next-generation MVPN signaling can be found in RFC 6514. The MCAST-VPN NLRI is carried in MP-BGP
E
extensions with an AFI of 1 and SAFI of 5. When these type of routes are received from remote PEs and accepted by a policy
that matches on the route target community (same as L3VPNs), the receiving PE will place the routes in the MVPN routing
US
table-IN called bgp.mvpn.0 and then into the corresponding VRFs MVPN routing table, routing-instance.mvpn.0.
Next-Generation MVPN Attributes

RFC 6514 defines a few new attributes. One important attribute is called the PMSI Tunnel attribute. It carries label and
AL
tunnel ID information allowing a receiving PE to know what data channel (LSP for example) to expect multicast traffic on.
Subsequent slides will describe its usage in more detail.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Type 1 NLRI
The Intra-autonomous system (AS) I-PMSI autodiscovery route is the initial route type that is advertised between PEs of the
E
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 distinguisher (RD), the sending PE’s loopback address, and a route target community to
US
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
AL
The Inter-AS I-PMSI autodiscovery route is used to discover members of an MVPN in different ASs. Inter-AS MVPNs are
outside the scope of this course.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Type 3 NLRI
Selective MVPN Autodiscovery routes are used to help build an S-PMSI. This route is advertised by the multicast source’s PE
E
in response to receiving a Type 6 or Type 7 route (described in subsequent slides) which are essentially requests to join the
multicast forwarding tree (BGP version of a PIM join). The slide shows the details of what is carried in the Type 3 route. Even
US
though the source PE learns that the remote PE wants to receive a particular multicast stream from a type 7 advertisement,
the source PE sends the type 3 as a request to the receiver PE to join the S-PMSI. The most important reason for this
message is because it is tagged with the PMSI tunnel attribute allowing the receiver PEs to know the details of the provider
tunnel.
AL
Type 4 NLRI
The Selective MVPN autodiscovery route is sent by an interested receiver PE (in the case of an RSVP-signalled LSP in the
data plane) in response to receiving a type 3 route from a source PE.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Type 5 NLRI
The Source Active autodiscovery route is advertise by a a PE that discovers a source that is attached to a locally connected
E
site. The PE learns of the source either from PIM 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
US
MVPN.
Type 6 NLRI
The Shared Tree Join route is advertised by a receiver PE to all other PEs participating in the MVPN in response to receiving
AL
a PIM (*,G) join from the local CE. It serves a similar purpose to the PIM (*,G) join in that it is a request to join the shared
multicast tree.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
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.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
benefits to using point-to-multipoint LSPs in the service provider network:

US
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
AL
(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 unicast L3VPNs.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Inclusive Trees
The simplest form of provider tunnel is the inclusive tree (I-PMSI). An inclusive tree serves an entire MVPN. In the diagram,
E
there is one inclusive tree that serves the blue VPN and one that serves the red VPN. Any multicast traffic arriving at the
source PE (PE-1) will be sent to all other PEs in the same MVPN. This works well when all remote PEs need to receive the
US
multicast traffic but this form of tree can be wasteful of resources (bandwidth, packet processing, and so on) when only 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 slides.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Selective Tree
Selective trees can be used to forward traffic for particular source and group combinations to the remote PE that specifically
E
request to receive 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 only.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Inclusive Tree Example—Initial State

The slide shows an example L3VPN prior to enabling next-generation MVPN.
E
Some things to note are:

US
1. The provider core is not running PIM;

2. There is an existing L3VPN between all customer sites using LDP to signal the unicast LSPs;
3. PE-1 will be acting as the customer rendezvous point (RP) (within the VRF);
4. CE-A will be acting as the customer designated router (DR) closest to the source; and
AL
5. CE-B and CE-C will eventually have receivers attached.

RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Inclusive Tree Example—Enabling the MVPN (RSVP case)

The following describes the case when RSVP-signaled P2MP LSPs are used for multicast data transport.
E
With no source and receivers in the network, an MVPN is enabled on all three PEs. Once enabled, each PE will advertise their
US
membership to the MVPN using a Type 1 route tagged with the PMSI tunnel attribute. Each PE will automatically build an
RSVP-signaled point-to-multipoint LSP to all other PEs. In the network shown on the 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 instantiated as themselves as ingress routers will never be used. It is possible to configure PE-2 and PE-3 as
receiver-only sites so that they do not build the unnecessary point-to-multipoint LSPs.
AL
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 the multicast packets to determine which VRF to use for forwarding. 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 virtual tunnel interface or vrf-table-label must be configured within the VRF
RN
to allow for a non-implicit-null label to be used on the penultimate hops.

TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Inclusive Tree Example—Enabling the MVPN (LDP case)

The following describes the case when LDP-signaled P2MP LSPs are used for multicast data transport.
E
US
membership to the MVPN using a Type 1 route tagged with the PMSI tunnel attribute. Each PE will automatically build an
LDP-signaled point-to-multipoint LSP to the source as advertised in the received Type 1 PMSI attribute. In the network shown
on the 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 is built to each of them with themselves 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 them.
AL
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 the multicast packets to determine which VRF to use for forwarding. Normally a
point-to-multipoint LSP is signaled with a label of 3 on the penultimate hops meaning that there would be no label
encapsulating the incoming traffic. Therefore, a virtual tunnel interface or vrf-table-label must be configured within the VRF
RN
to allow for a non-implicit-null label to be used on the penultimate hops.

TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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
E
encapsulates the multicast 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
US
autodiscovery route to all other PEs of the MVPN.

AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Inclusive Tree Example—Receivers Join

Using Internet Group Management Protocol (IGMP) version 3, the hosts attached to CE-B and CE-C report their membership
E
to a specific multicast source and group. CE-B and CE-C in turn send a PIM (S, G) join upstream towards 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
US
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.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
I-PMSI Forwarding
Now that the multicast forwarding tree is complete, multicast traffic can be sent from end to end. From the source to PE-1,
E
multicast packets are forwarded in their native format. From PE-1 to P1, 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. P1 simply performs a label
US
swap. At P2, because of the behavior of point-to-multipoint LSP, the data traffic is replicated, 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
forwarding. The receiving PE then send the multicast traffic in its native format towards the receivers.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Selective Tree Example—Initial State

The slide shows an example L3VPN prior to enabling next-generation MVPN.
E
Some things to note are:

US
1. The provider core is not running PIM;

2. There is an existing L3VPN between all customer sites using LDP to signal the unicast LSPs;
3. PE-1 will be acting as the customer RP (within the VRF);
4. CE-A will be acting as the customer DR closest to the source; and
AL
5. Only CE-B will eventually have a receiver attached.

RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Selective Tree Example-—Enabling the MVPN

E
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-multipoint LSP is not built until at least one PE has a receiver attached.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Selective Tree Example—Source Begins Sending Traffic

The source attached to CE-A begins sending multicast traffic. As the customer PIM DR, CE-A encapsulates the multicast
E
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 to all other PEs of the
US
MVPN.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Selective Tree Example—Receivers Join

Using IGMP version 3, the host attached to CE-B reports its membership to a specific multicast source and group. CE-B in
E
turn sends a PIM (S, G) join upstream towards the source. Upon receiving the PIM joins, PE-2 sends a Type 7 Source Tree
Join route to the source PE, PE-1.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
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.
E
Upon receiving the Type 7 advertisement from the PE-2, PE-1 sends a Type 3 S-PMSI autodiscovery route tagged with PMSI
US
Tunnel attribute with the 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 builds a point-to-multipoint
LSP to a single end-point, PE-2. Finally, 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.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Selective Tree Example—Completing the Forwarding Tree (LDP Case)

The following describes the case when LDP-signaled P2MP LSPs are used for multicast data transport.
E
Upon receiving the Type 7 advertisement from the PE-2, PE-1 sends a Type 3 S-PMSI autodiscovery route tagged with PMSI
US
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 LDP signaled point-to-multipoint LSP that will be used for multicast data forwarding.
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) 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.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Tunnel Services
Assuming every router is running the Junos OS, tunnel services must be enabled on certain routers. Some routers require a
E
Tunnel Service PIC or Adaptive Service PIC to provide tunnel services. In the case of the MX Series device, the feature just
needs to be enabled as shown on the slide.
US
Router types needing tunnel services:

• DR closest to source - Tunnel services are needed because the DR must encapsulate multicast traffic in unicast
messages called register messages;
• Customer’s candidate RP - Tunnel services are needed because the RP must de-encapsulate the register
AL
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
RN
out of the VRF interface. This is assuming that a virtual tunnel interface is used. Optionally,
vrf-table-label can be configured without the need for tunnel services.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Junos OS Support
The slide shows the protocols that are supported when enabling next-generation MVPNs using the Junos OS.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Configuration
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
MP-BGP Configuration
To allow for BGP neighbors to exchange the new MVPN NLRI, family inet-mvpn signaling must be enabled on all
E
participating PE routers.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Optional Point-to-Multipoint LSP Template

You can optionally specify the requirements of the point-to-multipoint LSP by creating a template under [edit
E
protocols mpls]. You can specify protection requirements, bandwidth requirements, path information, and more.
US
Provider Tunnel Type

The example on the slide shows how to configure an RSVP-traffic 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 the PE will be able to forward a multicast packets even when they do not match the
AL
selective group range (the inclusive tunnel 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 vrf-table-label. A virtual tunnel interface could also have been used.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Enable P2MP Signaling

In order for a router to support the signaling of LDP P2MP LSP, you must configure the p2mp option under [edit
E
protocols ldp]. All routers in the provider core should have this option configured.
US
LDP Provider Tunnels

The example on the slide shows how to configure LDP signaled 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 the PE will be able to forward a multicast packets even when they do not match the selective group range
AL
(the inclusive tunnel will act as the default method for multicast forwarding). To ensure that penultimate hop popping is not
performed along the LSP, the example shows the configuration of vrf-table-label. A virtual tunnel interface could also
have been used.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Customer PIM Configuration

Within the VRF, you must configure multicast routing that is specific to the customer’s multicast domain. This configuration is
E
shown as the PIM configuration in the slide. Also, you must enable the mvpn using the mvpn statement. There are several
settings available under the mvpn hierarchy. The slide shows the configuration of the mvpn-mode. There are two options for
US
the mode. First is the spt-only mode which allows for only shortest path trees to be built from receiver PEs towards the
source (Type 7s only). The second mode is rpt-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.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
VRF Configuration
This slide shows the full, working VRF configuration for PE1.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Provider Tunnels
There are several options available for provider tunnels.
E
• ingress-replication: point to point LSPs (RSVP or LDP) are used for multicast data transport. Ingress PE
US
performs all multicast replication;

• lsp-p2mp: Used to configure an I-PMSI between PEs using LDP point-to-multipoint LSPs;
• mdt: Used to configure Multicast Data Tunnels as provider tunnels;
• pim-asm: Used to configure PIM any source provider tunnels;
AL
• pim-ssm: Use to configure PIM source specific provider tunnels;

• rsvp-te: Used to configure an I-PMSI between PEs using RSVP-traffic engineered point-to-multipoint LSPs;
and
RN
• selective: Used to configure an S-PMSI between PEs using either RSVP or LDP point-to-multipoint LSPs.
MVPN Settings
TE
It is under the MVPN settings that you can specify whether a site is a sender-only site or receiver-only site. By default, every
site is both and sender and receiver site. You can also configure the MVPN mode, traceoptions, and the upstream multicast
hop settings.
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Monitoring
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
PIM Status
To verify the status of PIM within the customer network using the show pim commands using a modifier of instance
E
instance-name. The command on the slide shows the (S, G) state of the PE router.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Is Multicast Traffic Flowing?

The command on the slide shows that PE1 is currently forwarding multicast traffic destined for 224.7.7.7 at a rate of 263
E
packets per second.

US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Next-Generation MVPN Routing Table-IN

The bgp.mvpn.0 table is the routing table-IN for MVPN routes. The command on the slide shows the routes that are
E
currently populating the bgp.mvpn.0 table. Routes will only show up in this table if they have been accepted by VRF
import policy that matches on the correct target communities.
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
VRF Specific MVPN Routes

The command on the slide shows the MVPN routes that relate to a specific MVPN.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Point-to-Multipoint LSP
Use the show rsvp session or show ldp database command to determine the status of the point-to-multipoint LSP.
E
In the output of the RSVP command, you can see that the outbound label for the point-to-multipoint LSP is 300096. For the
LDP command, the output shows that the outbound label for the P2MP LSP is 300208.
US
Forwarding Table
The command on the slide shows the routes in PE1’s forwarding table that are associated with the multicast group of
224.7.7.7 with a source of 10.0.101.2. Notice that all multicast packets of this type will be sent out of the ge-1/0/4.250
AL
interface with a single MPLS label of 300096.

RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
MVPN Internet Multicasting

E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Internet Multicast Basic Functions

When using ingress replication for IP multicast, each participating router must be configured with BGP for control plane
E
procedures and with ingress replication for the data provider tunnel, which 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
US
routing instance.
The ingress-replication provider tunnel type uses unicast tunnels between routers to create a multicast distribution
tree.
The mpls-internet-multicast routing instance type uses ingress replication provider tunnels to carry IP multicast
AL
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 mpls-internet-multicast routing instance is a non-forwarding instance used only for control plane procedures. It
does not support any interface configurations. Only one mpls-internet-multicast routing instance can be defined for a logical
RN
system. All multicast and unicast routes used for IP multicast are associated only with the default routing instance
(inet.0), not with a configured routing instance. The mpls-internet-multicast routing instance type is configured
for the default master instance on each router, and is also included at the [edit protocols pim] hierarchy level in the
default instance.
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Ingress Replication Basic Configuration

For each mpls-internet-multicast routing instance, the ingress-replication statement is required under the provider-tunnel
E
statement and also under the [edit routing-instances routing-instance-name provider-tunnel selective group source]
hierarchy level.
US
When a new destination needs to be added to the ingress replication provider tunnel, the resulting behavior differs
depending on how the ingress replication provider tunnel is configured:
• create-new-ucast-tunnel: When this statement is configured, a new unicast tunnel to the destination is
created, and is deleted when the destination is no longer needed. Use this mode for RSVP LSPs using ingress
AL
replication.
• label-switched-path-template: When this statement is configured, an LSP template is used for the for
the point-to-multipoint LSP for ingress replication.
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Internet Multicast Topology Components

The IP topology consists of routers on the edge of the IP multicast domain. Each router has a set of IP interfaces configured
E
toward the MPLS cloud and a set of interfaces configured toward the IP routers. Internet multicast traffic is carried between
the IP routers, through the MPLS cloud, using ingress replication tunnels for the data plane and a full-mesh IBGP session for
US
the control plane.

AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Configuration Steps on The Border Router

This slide provides a list of the main configuration steps required on the Border router.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Verifying Proper Functionality: Part 1

This slide highlights some of the main verification steps for the Border router.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Verifying Proper Functionality: Part 2

This slide provides some additional verification steps on the Border router.
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
We Discussed:
• The flow of control traffic and data traffic in a next-generation MVPN;
E
• The configuration steps for establishing a next-generation MVPN;

US
• Monitoring and verifying the operation of next-generation MVPNs; and

• The function of MVPN Internet multicasting with ingress replication.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Review Questions
1.
E
US
2.
3.
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Lab: MVPNs
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
1.
AR
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 require PIM be configured in the core.
2.
Type 1: Intra-AS Inclusive MVPN Membership Discovery
SH
Type 2: Inter-AS Inclusive MVPN Membership Discovery
Type 3: Selective MVPN Autodiscovery Route
Type 4: Selective MVPN Autodiscovery Route for Leaf
T
Type 5: Source Active Autodiscovery Route
Type 6: Shared Tree Join Route
NO
Type 7: Source Tree Join Route
3.
The first hop designated router, the candidate rendezvous points, and all PE routers participating in the multicast network,
unless using vrf-table-label option, require the use of a tunnel services interface.
O
-D
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
Resources to Help You Learn More

The slide lists online resources available to learn more about Juniper Networks and technology. These resources include the
E
following sites:
US
• Pathfinder: An information experience hub that provides centralized product details.

• Content Explorer: Junos OS and ScreenOS software feature information to find the right software release and
hardware platform for your network.
• Feature Explorer: Technical documentation for Junos OS-based products by product, task, and software
release, and downloadable documentation PDFs.
AL
• Learning Bytes: Concise tips and instructions on specific features and functions of Juniper technologies.
• Installation and configuration courses: Over 60 free Web-based training courses on product installation and
configuration (just choose eLearning under Delivery Modality).
RN
• J-Net Forum: Training, 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.
TE
• Technical courses: A complete list of instructor-led, hands-on courses and self-paced, eLearning courses.
• Translation tools: Several online translation tools to help simplify migration tasks.
IN
www.juniper.net
Junos Layer 3 VPNs
E
AR
SH
T
NO
O
-D
LY
ON
E
US
AL
RN
TE
IN
www.juniper.net
Acronym List
E
AR
ABR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . area border router
ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Resolution Protocol
AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .autonomous system
SH
ASBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .autonomous system boundary routers
ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asynchronous Transfer Mode
CapEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .capital expenses
CCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . circuit cross-connect
CE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . customer edge
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .command-line interface
T
CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . class-of-service
CSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Constrained Shortest Path First
NO
DLCI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .data-link connection identifier
DPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dense Port Concentrator
DR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .designated router
FPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flexible PIC Concentrator
GRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .generic routing encapsulation
O
GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .graphical user interface
HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . High-Level Data Link Control
IBGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . internal BGP
-D
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Control Message Protocol
IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Group Management Protocol
IGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . interior gateway protocol
I-PMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inclusive-PMSI
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP version 4
LY
JNCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juniper Networks Certification Program
LLDP-MED. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link Layer Discovery Protocol–Media Endpoint Discovery
LSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link-state advertisement
LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . label switched path
ON
LSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Label Switching Routing

MAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . media access control
MP-BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiprotocol Border Gateway Protocol
MP-EBGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiprotocol external BGP
MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multicast Source Discovery Protocol
E
MVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .multicast virtual private network

NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Address Translation
NLRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network layer reachability information
US
NSSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .no-so-stubby area

OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Shortest Path First
P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . provider
PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . provider edge
PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .penultimate-hop popping
AL
POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . point of presence

PP-VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . provider-provisioned VPN
PVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . permanent virtual connection
RD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . route distinguisher
RN
RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . random early detection

RID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . router ID
RP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . rendezvous point
SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . security association
TE
SAFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . subsequent address family identifier

S-PMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selective-PMSI
TCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . translational cross-connect
VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .virtual LAN
VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual private LAN service
IN
VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual private network
www.juniper.net Acronym List • ACR–1

VRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VPN route and forwarding
WRR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . weighted round-robin
E
AR
SH
T
NO
O
-D
LY
ON
E
US
AL
RN
TE
IN
ACR–2 • Acronym List www.juniper.net

L Use Only - Do Not Share: Junos Layer 3 Vpns

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

L Use Only - Do Not Share: Junos Layer 3 Vpns

Uploaded by

Copyright:

Available Formats

E

Worldwide Education Services

1133 Innovation Way

Course Number: EDU-JUN-JL3V

Chapter 7: Interprovider VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

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

The Forwarding Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-26

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

Multicast VPN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3

Reverse Path Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-12

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

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

www.juniper.net Contents • iii

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

• Describe the propagation of VPN routing information within an AS.

import/export routes from a routing instance using route distinguishers/route targets.

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

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

www.juniper.net Course Overview • v

vi • Course Overview www.juniper.net

Chapter 9: Multicast Review and Draft Rosen

www.juniper.net Course Agenda • vii

Courier New Console text:

Normal CLI No distinguishing variant. Physical interface:fxp0,

config.ini in the Filename field.

Defined and Undefined Syntax Variables

Style Description Usage Example

CLI Variable Text where variable value is policy my-peers

GUI Variable Click my-peers in the dialog.

viii • Document Conventions www.juniper.net

www.juniper.net Additional Information • ix

x • Additional Information www.juniper.net

attached to a common provider edge (PE) router;

• The flow of control and data traffic in a hub-and-spoke topology;

• Junos OS support for different types of egress protection.

Chapter 6–2 • Layer 3 VPNs—Advanced Topics www.juniper.net

Exchanging Routes Between VRF Tables

www.juniper.net Layer 3 VPNs—Advanced Topics • Chapter 6–3

Using Routing Table Groups

Chapter 6–4 • Layer 3 VPNs—Advanced Topics www.juniper.net

www.juniper.net Layer 3 VPNs—Advanced Topics • Chapter 6–5

VRF Routing Table Group Example

Chapter 6–6 • Layer 3 VPNs—Advanced Topics www.juniper.net

www.juniper.net Layer 3 VPNs—Advanced Topics • Chapter 6–7

Verifying the Results

Site A and Site B Can Communicate

Chapter 6–8 • Layer 3 VPNs—Advanced Topics www.juniper.net

vpn-b’s Modified VRF Export Policy: The Final Step

www.juniper.net Layer 3 VPNs—Advanced Topics • Chapter 6–9

Chapter 6–10 • Layer 3 VPNs—Advanced Topics www.juniper.net

Reduces the Number of BGP Sessions and LSPs Required

Two VRF Instances Required at Hub

Two VRF Interfaces Required at Hub

www.juniper.net Layer 3 VPNs—Advanced Topics • Chapter 6–11

Locally Attached Spokes

Chapter 6–12 • Layer 3 VPNs—Advanced Topics www.juniper.net

Signaling Flow Between Spoke Locations

www.juniper.net Layer 3 VPNs—Advanced Topics • Chapter 6–13

Data Flow Between Spoke Locations

1. CE-2 sends a packet addressed to the CE-1 site.

6. Spoke PE-1 forwards the packet to CE-1.

Chapter 6–14 • Layer 3 VPNs—Advanced Topics www.juniper.net

Sample Spoke VRF Table