JL2V 15.a SG V2

RE
A
SH
Junos Layer 2 VPNs
T
NO
15.a
DO
—
Student Guide
Volume 2 of 2
LY
ON
E
US
Worldwide Education Services

AL
1133 Innovation Way

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

TE
IN
RE
This document is produced by Juniper Networks, Inc.
This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks Education
Services.
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The
Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service
A
marks are the property of their respective owners.
Junos Layer 2 VPNs Student Guide, Revision 15.a
Copyright © 2016 Juniper Networks, Inc. All rights reserved.
SH
Printed in USA.
Revision History:
Revision 15.a—June 2016
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for software Release 15.1R2.9. 
T
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
DO
Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known
time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
—
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement
executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its
license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain
prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.
LY
ON
E
US
AL
RN
TE
IN
Contents
A RE
Chapter 6: Virtual Private LAN Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
SH
Layer 2 MPLS VPNs Versus VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
BGP VPLS Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
LDP VPLS Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23
FEC 129 BGP Autodiscovery Control Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
Learning and Forwarding Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
T
Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-48
NO
Chapter 7: VPLS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
VPLS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
VPLS Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-47
Lab: VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-60
DO
Chapter 8: Ethernet VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
EVPN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
EVPN Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
EVPN Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-25
—
EVPN Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-36
Lab: Ethernet VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-58
LY
Appendix A: Interprovider Backbones for Layer 2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Hierarchical VPN Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-3
Carrier-of-Carriers VPN Option C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .A-9
ON
Interprovider VPN Option C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23

Multisegment Pseudowires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-36
Lab: Interprovider L2VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-50
Appendix B: Circuit Cross-Connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

E
Circuit Cross-Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3

Lab: Circuit Cross-Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-14
US
Acronym List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACR-1

AL
RN
TE
IN
www.juniper.net Contents • iii

RE
A
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN
iv • Contents www.juniper.net
Course Overview
RE
This two-day course is designed to provide students with MPLS-based Layer 2 virtual private network (VPN) knowledge
and configuration examples. The course includes an overview of MPLS Layer 2 VPN concepts, such as BGP Layer 2 VPNs,
LDP Layer 2 circuits, FEC 129 BGP autodiscovery, virtual private LAN service (VPLS), Ethernet VPN (EVPN), and Inter-AS
A
Layer 2 VPNs. This course also covers Junos operating system-specific implementations of Layer 2 VPN instances, VPLS,
and EVPNs. This course is based on the Junos OS Release 15.1R2.9.
SH
Through demonstrations and hands-on labs, students will gain experience in configuring and monitoring the Junos OS
and in device operations.
Intended Audience
This course benefits individuals responsible for configuring and monitoring devices running the Junos OS.
T
Course Level
NO
Junos Layer 2 VPNs (JL2V) is an advanced-level course.
Prerequisites
The prerequisites for this course include the following:
DO
• An intermediate-level networking knowledge and an understanding of OSPF, IS-IS, BGP, and Junos policy;
• Experience configuring MPLS label-switched paths using Junos;
• Introduction to the Junos Operating System (IJOS) course or equivalent;
• Junos Routing Essentials (JRE) course or equivalent;
—
• Junos Service Provider Switching (JSPX) course or equivalent;
• Junos Intermediate Routing (JIR) course or equivalent; and
LY
• Junos MPLS Fundamentals (JMF) course or equivalent.

Objectives
After successfully completing this course, you should be able to:
ON
• Define the term virtual private network.

• Describe the business drivers for MPLS VPNs.
• Describe the differences between Layer 2 VPNs and Layer 3 VPNs.
• List advantages for the use of MPLS Layer 3 VPNs and Layer 2 VPNs.
E
• Describe the roles of a CE device, PE router, and P router in a BGP Layer 2 VPN.
US
• Explain the flow of control traffic and data traffic for a BGP Layer 2 VPN.
• Configure a BGP Layer 2 VPN and describe the benefits and requirements of over-provisioning.
• Monitor and troubleshoot a BGP Layer 2 VPN.
AL
• Explain the BGP Layer 2 VPN scaling mechanisms and route reflection.
• Describe the Junos OS BGP Layer 2 VPN CoS support.
• Describe the flow of control and data traffic for an LDP Layer 2 circuit.
RN
• Configure an LDP Layer 2 circuit.

• Monitor and troubleshoot an LDP Layer 2 circuit.
• Describe the operation of FEC 129 BGP autodiscovery for Layer 2 VPNs.
TE
• Configure a FEC 129 BGP autodiscovery Layer 2 VPN.

• Monitor and troubleshoot a FEC 129 BGP autodiscovery for Layer 2 VPNs.
• Describe the difference between Layer 2 MPLS VPNs and VPLS.
IN
www.juniper.net Course Overview • v

• Explain the purpose of the PE device, the CE device, and the P device.
RE
• Explain the provisioning of CE and PE routers.
• Describe the signaling process of VPLS.
• Describe the learning and forwarding process of VPLS.
A
• Describe the potential loops in a VPLS environment.
SH
• Configure BGP, LDP, and FEC 129 BGP autodiscovery VPLS.
• Troubleshoot VPLS.
• Describe the purpose and features of Ethernet VPN.
• Configure Ethernet VPN.
T
• Monitor and troubleshoot Ethernet VPN.
NO
• Describe the Junos OS support for hierarchical VPN models.
• Describe the Junos OS support for Carrier-of-Carriers VPN Option C.
• Configure the interprovider VPN Option C.
• Describe the Junos OS support for multisegment pseudowire for FEC 129.
DO
• Describe and configure circuit cross-connect (CCC).
—
LY
ON
E
US
AL
RN
TE
IN
vi • Course Overview www.juniper.net

Course Agenda
RE
Day 1
Chapter 1: Course Introduction
A
Chapter 2: MPLS VPNs
SH
Chapter 3: BGP Layer 2 VPNs
Lab: BGP Layer 2 VPNs
Chapter 4: Layer 2 VPN Scaling and CoS
Lab: Layer 2 VPN Scaling
T
Chapter 5: LDP Layer 2 Circuits
NO
Lab: LDP Layer 2 Circuit and FEC 129 BGP Autodiscovery
Day 2
Chapter 6: Virtual Private LAN Services
Chapter 7: VPLS Configuration
DO
Lab: VPLS
Chapter 8: Ethernet VPN
Lab: EVPN
—
LY
ON
E
US
AL
RN
TE
IN
www.juniper.net Course Agenda • vii

Document Conventions
RE
CLI and GUI Text
Frequently throughout this course, we refer to text that appears in a command-line interface (CLI) or a graphical user
A
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.
T
Courier New Console text:
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
DO
Filename text box.
• Text field entry
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
Normal GUI
View configuration history by clicking
ON
Configuration > History.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and type
config.ini in the Filename field.
E
Defined and Undefined Syntax Variables

US
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 already policy my-peers

assigned.
GUI Variable Click my-peers in the dialog.
RN
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
GUI Undefined the lab guide might differ from the Select File > Save, and type
TE
value the user must input filename in the Filename field.

according to the lab topology.
IN
viii • Document Conventions www.juniper.net

Additional Information
RE
Education Services Offerings
You can obtain information on the latest Education Services offerings, course dates, and class locations from the World
A
Wide Web by pointing your Web browser to: http://www.juniper.net/training/education/.
About This Publication
SH
The Junos Layer 2 VPNs Student Guide was developed and tested using software Release 15.1R2.9. Previous and later
versions of software might behave differently so you should always consult the documentation and release notes for the
version of code you are running before reporting errors.
This document is written and maintained by the Juniper Networks Education Services development team. Please send
T
questions and suggestions for improvement to training@juniper.net.
NO
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
• Go to http://www.juniper.net/techpubs/.
• Locate the specific software or hardware release and title you need, and choose the format in which you
DO
want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.
Juniper Networks Support
For technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or at 1-888-314-JTAC
—
(within the United States) or 408-745-2121 (outside the United States).
LY
ON
E
US
AL
RN
TE
IN
www.juniper.net Additional Information • ix

A RE
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN
x • Additional Information www.juniper.net

RE
A
SH
Junos Layer 2 VPNs
T
NO
Chapter 6: Virtual Private LAN Service
DO
—
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
We Will Discuss:
• The difference between Layer 2 MPLS virtual private networks (VPNs) and virtual private LAN service (VPLS);
E
• The purpose of the provider edge (PE), customer edge (CE), and provider (P) devices;
• Provisioning of CE and PE routers;
US
• The signaling process of VPLS;

• The learning and forwarding process of VPLS; and
• The potential loops in a VPLS environment.
AL
RN
TE
IN
Chapter 6–2 • Virtual Private LAN Service www.juniper.net

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Layer 2 MPLS VPNs Versus VPLS

The slide lists the topics we will discuss. We discuss the highlighted topic first.
E
US
AL
RN
TE
IN
www.juniper.net Virtual Private LAN Service • Chapter 6–3

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Layer 2 VPNs Are Point to Point

Border Gateway Protocol (BGP) Layer 2 VPNs and LDP Layer 2 circuits are point to point in nature and support Ethernet,
Frame Relay, Point-to-Point Protocol (PPP), and Cisco’s High-Level Data Link Control (Cisco HDLC). Even though Ethernet
E
media can be used between PE and CE devices, only two CE devices can interact over a single emulated Layer 2 circuit or
virtual LAN (VLAN). Although this behavior works well as it is, some customers prefer to have their Ethernet media behave
US
like Ethernet so that more than two hosts or routers can interact over the Layer 2 circuit. This need on behalf of the
customer, and other factors, is what led to the development of VPLS.
Mapping Local Circuits to Remote Sites

AL
In both of the Layer 2 point to point VPNs scenarios, you must manually map local Layer 2 circuits on the PE device to the
remote sites. This mapping might be labor intensive and sometimes confusing, especially when designing a full-mesh
network between PE devices. BGP-based Layer 2 VPNs allows for over-provisioning, which eases the process of adding a new
site, however.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Appearing to Be a Single LAN Segment

A new service that can be provided to the customer is VPLS. To the customer, a VPLS appears to be a single LAN segment. In
fact, it appears to act similarly to a learning bridge. That is, when the destination media access control (MAC) address is not
E
known, an Ethernet frame is sent to all remote sites. If the destination MAC address is known, it is sent directly to the site
that owns it.
US
No Need to Map Local Circuit to Remote Sites

In a VPLS, PE devices learn MAC addresses from the frames that it receives. They will use the source and destination
addresses to dynamically create a forwarding table (vpn-name.vpls) for Ethernet frames. Based on this table, frames are
AL
forwarded out directly connected interfaces or over MPLS label-switched paths (LSPs) across the provider core. This behavior
allows you to not have to manually map Layer 2 circuits to remote sites.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Standards
Two competing RFCs for VPLS exist. One of the remarkable things about these two competing RFCs is that their primary
developers happen to be brothers, Kireeti Kompella (BGP) and Vach Kompella (LDP). The primary difference between the
E
two RFCs is that one uses BGP and one uses LDP for signaling. Currently the Junos operating system supports both LDP and
BGP for signaling, with BGP the preferred solution.
US
The latest standard is the FEC 129 BGP autodiscovery standard defined in RFC 6074. Here the issue of manual provisioning
when using LDP signaling is removed by adding BGP autodiscovery to the LDP signaling solution.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Benefits of BGP
There are a few benefits to using BGP as the signaling protocol for VPLS. For instance, BGP allows for the autodiscovery of
new sites as they are added to a VPLS. When a new site is added to a VPLS, you only need to configure the PE router
E
connected to the new site. All other PE routers discover the new site with the use of the target extended community. Also,
BGP is a very scalable protocol. BGP works well when dealing with large number of routes. Provisioning a VPLS network in a
US
large provider network can be made easier with the use of route reflectors and/or confederations. Finally, BGP was designed
to advertise routes between autonomous systems. Thus, it is inherently possible to build a VPLS across autonomous system
(AS) boundaries.
Based on RFC 2858 (Multiprotocol Extensions for BGP-4), BGP can be extended to carry information for which it was not
AL
originally designed. The BGP draft for VPLS relies on Multiprotocol Border Gateway Protocol (MP-BGP) to carry its routing
information between PE devices.
The RCF 6074 solution that uses BGP for autodiscovery adds some of the benefits of using BGP. It can also support building
VPLS across different AS boundaries. For the LDP part there is support for it by using multisegment FEC 129
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Customer Edge Devices

The customer edge device is normally a router or Layer 2 switch that provides access to the provider’s edge device. Because
the Layer 2 frames generated by the customer are carried across the core using MPLS, there is inherent independence
E
between the Layer 2 technology used at the provider’s edge and the technologies used in the core. This independence
extends to the upper protocol layers as well, because the provider does not interpret in any way the contents of the Layer 2
US
frames.
Both ends of a VPLS must use the Ethernet technology. Unlike point to point Layer 2 VPNs, each remote site does not need to
be associated with a unique Layer 2 circuit identifier to map traffic to a given site. All mapping will be performed
automatically through the MAC learning function of a PE.
AL
Provider Edge Routers

The provider edge routers connect to customer sites and maintain VPLS-specific information. This VPN information is
obtained through local configuration and through signaling exchanges with either BGP or LDP. As with a Layer 3 VPN, the PE
RN
routers forward traffic across the provider’s core using MPLS LSPs. PE routers perform MAC learning and store MACs in a
VPLS-specific MAC table.
Provider Routers
TE
The provider routers do not carry any VPLS state. They simply provide label-switching router (LSR) services to facilitate the
transfer of labeled frames between PE routers.
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
BGP VPLS Control Plane

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

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Provisioning the Local CE Device

The first step in building a VPLS is the configuration of the local CE device. This configuration normally entails assigning a
range of Layer 2 circuit identifiers to logical interfaces on the CE device and having the correct encapsulation settings.
E
For Ethernet with VLAN tagging, it is required that VLAN IDs be the same at both ends of a VPLS. The VPLS standard allows
US
for the expansion of VPN membership without reconfiguring existing sites.

The CE device also requires the configuration of upper-layer protocols to be compatible with the remote CE router. Unlike a
Layer 3 VPN solution, the PE router has no IP or routing protocol configuration because these functions are configured on the
CE routers with end-to-end significance. With VPLS, the CE routers form adjacencies with each other as if they were
connected to the same Ethernet segment, as opposed to becoming adjacent to the local PE router.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
VPLS Route and Forwarding Tables

A VPN routing and forwarding table (VRF) and a VPLS-specific MAC-table are created in the PE router for each VPLS. The VRF
table is populated with information provisioned for the local CE device and contains:
E
• The local site ID;

US
• The site’s Layer 2 encapsulation;

• The logical interfaces provisioned to the local CE device; and
• A label base used to associated received traffic with one of the logical interfaces.
AL
The VRF is also populated with information received from other PE routers in MP-IBGP updates. These updates contain the
remote site’s ID, label base, label, offset, and Layer 2 encapsulation.
The combination of locally provisioned information and Layer 2 VPN network layer reachability information (NLRI) received
from remote PE routers results in a Layer 2 VPN VRF table and an associate MAC table which are used to map traffic to and
RN
from the LSPs connecting the PE routers.

TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Provisioning the Core

As with a Layer 3 VPN, the provider’s core must be provisioned to support the Layer 2 VPN service. Besides a functional
interior gateway protocol (IGP), this support normally involves the establishment of MPLS LSPs between PE routers to be
E
used for data forwarding. The PE-PE LSPs are not dedicated to any particular service. With label stacking, the same LSP can
be used to support multiple Layer 2 VPN customers while also supporting Layer 3 VPNs and non-VPN traffic.
US
Each PE router must also be configured with MP-BGP to peer to other PE routers having local sites belonging to the same
VPN. These MP-BGP sessions must be configured to support the l2-vpn signaling address family so that they can
send and receive Layer 2 NLRI updates.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
VPLS Label Distribution

PE routers exchange MPLS label information using the same MP-BGP NLRI as Layer 2 VPNs. For a given site, a PE will
advertise a block of labels that can be used by remote PEs to forward traffic to the sending PE. Using simple mathematics
E
receiving PEs, can determine which label to use to reach the sending PE.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Provisioning the PE Router

After configuring the local CE device properties, you must provision the site’s VRF on the PE router. The following list shows
what is typically involved:
E
• Specification of route targets or VRF policy.

US
• CE device identifier (site ID), which must be unique in the context of a specific VPN.
• CE device range, which helps determine the size of the site’s label block and therefore how many remote sites
to which it can connect.
• Logical interfaces associated with this VRF.
AL
Some of the steps outlined in the slide can occur automatically and therefore do not require explicit configuration.
Continued on the next page.
RN
TE
IN

Junos Layer 2 VPNs
Provisioning the PE Router (contd.)
RE
Each VPLS interface must be configured to support family vpls and the appropriate encapsulation. Support
encapsulations are:
• ethernet-vpls:
A
– Standard Ethernet encapsulation; and
– Accepts packets with Tag Protocol Identifier (TPID) values.
SH
• vlan-vpls:
– For VLAN 802.1q tagging; and
– Accepts standard TPID values only.
T
• extended-vlan-vpls:
NO
– 802.1q tagging; and
– Accepts special TPID values: 0x8100, 0x9100, and 0x9901.
• ether-vpls-over-atm-llc:
– Bridges Ethernet and Asynchronous Transfer Mode (ATM) interfaces for Ethernet over ATM (AAL-5);
DO
– RFC 2684; and
– Supported on ATM IQ interfaces only.
—
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
VPLS AFI/SAFI
The graphic on the slide displays the structure of VPLS NLRI. The address family indicator (AFI) and subsequent address
family identifier (SAFI) values of 25 and 65 are shared with Kompella Layer 2 VPN NLRIs.
E
The NLRI consists of the site ID, the label base, and the label block offset, which are used when multiple label blocks are
US
generated for a particular site. Each label block is carried as a separate update when multiple blocks exist.
The circuit status vector (CSV) is a bit vector used to indicate the site’s label range (that is, block size) and to report failures
of a PE router’s local circuits.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Layer 2 Information Extended Community

The Layer 2 information extended communities (carried as part of the Layer 2 NLRI) communicate the following information
between PE routers:
E
• The Layer 2 encapsulation type (VPLS is the encapsulation type in a VPLS environment).
US
• The Layer 2 maximum transmission unit (MTU) field, which reports the MTU configured on the sending PE
router’s PE-CE link (because fragmentation is not supported in a Layer 2 VPN environment, the receiving PE
router ignores Layer 2 NLRI with MTU values that differ from the PE router’s local VRF interface).
• Control Flags, the slide shows the meaning of the 5 bits that are used for signaling different VPLS options to the
AL
remote PEs.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
PE-1 and PE-2 are Configured for a VPLS Called VPN A

In the example on the slide, PE-2 is configured with a VRF for its local connection to CE-A4. This configuration assigns CE-A4
the site ID of 4 and associates this VPLS with a route target of RT1. Also, the local site is configured using VLAN tagging with
E
a single VLAN ID of 600.

US
Computes Labels Automatically

Based on the MP-BGP advertisement that results from the information in PE-2’s VRF, PE-2 automatically computes the label
received when traffic is sent to PE-2 from remote PE routers. A single label from the labels in PE-2’s label block is associated
with each of the remote sites. The result is that PE-2 expects to receive traffic from CE-A1 with a label value of 1000.
AL
The slide also shows how transmit labels are calculated based on the local site ID and the received MP-BGP advertisements
from a remote site. Based on the received advertisement from PE-1, PE-2 sends frames destined for Site 1 using an inner
label of 2003 (label-base-remote + local-site-id – label-block-offset). The outer MPLS label used for transmission is 200,
based on the existing MPLS LSP from PE-2 to PE-1.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
MP-IBGP Used for Signaling

The distribution of label blocks between PE routers is facilitated with MP-IBGP using a Layer 2 VPN address family. Because
all PE routers advertise the VPLS instances to which they are attached or no longer attached, every PE router can discover
E
automatically which VPLS instances are running on other PE router by using the target extended community.
US
Automatic Label Mapping

The algorithm defined in the VPLS draft allows each PE router to compute automatically the mapping between remote site
IDs and the label values used to send and receive traffic from them. The labels advertised by a site also are mapped
automatically to VPN tunnel interfaces within a services PIC (Tunnel Services, Adaptive Services, Link Services). Thus, the
AL
connections between sites are created automatically. The PE device learns the MAC addresses during the forwarding
process with the help of the VPN tunnel interfaces.
VPN Policy
RN
VPN policy using route target communities to filter and accept label blocks from remote PE routers results in a VPLS
topology.
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
PE-1 Receives Label Block from PE-3

The label block for CE-A3 contains the site's ID, label block size, label offset, and label base. This update also is associated
with the route target extended BGP community.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
PE-1 Updates Its VRF

PE-1 receives the update from PE-3 and checks the route target for a match. Because the route target matches, the update
is installed in the VRF associated with CE-A1. The L2 VPN NLRI is copied into both the bgp.l2vpn.0 and
E
vpn-name.l2vpn.0 table as in Layer 2 VPNs.

US
PE-1 Computes Outgoing Label

PE-1 uses the update from PE-3 to compute automatically the labels to be used when sending traffic from CE-A1 to CE-A3.
PE-1 uses the algorithm that subtracts the remote PE router’s label offset from its local site ID and adds the resulting value
to the received label base. In this example, PE-1 computes Label 1000 for traffic destined to CE-A3 (1–1 = 0 + 1000 =
AL
1000). PE-3 computes the same label value (1000) as the label it expects to receive on traffic sent by CE-A1.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
PE-1 Computes the Outer Label

PE-1 computes the outer MPLS label by resolving PE-3’s router ID to an LSP in the inet.3 routing table. In this example, the
LSP from PE-1 to PE-3 is associated with label value 300.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
LDP VPLS Control Plane

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

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
PE Routers Advertise Labels Using LDP

In operation, a PE router advertises a label for each remote PE configured. To LDP, this label advertisement is just another
forwarding equivalence class (FEC). These labels are advertised to targeted peers using extended LDP sessions.
E
As shown on the diagram on the slide, the remote PE router (PE-2) uses the input label value advertised by PE-1 as its output
US
label when forwarding traffic associated with this FEC to PE-1. Although not shown on the slide, you can assume that PE-2
has also advertised an input label to PE-1, and that PE-1 pushes this label when sending traffic (for this connection) to PE-2.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
VPLS FEC 128 Element

Using the LDP extended neighbor relationship, PE routers can exchange the virtual circuit labels associated with the VPLS.
Along with each label, an associated FEC element is also advertised. This FEC 128 element is used to describe the
E
parameters of a PE router to the remote LDP neighbor.

US
The fields in this FEC 128 element are described as follows:

• C bit: Specifies whether the Martini control word is present. This bit is set by default (control word present) in
the Junos OS.
• VC type: Layer 2 encapsulation on VPN interface.
AL
• Group ID (optional): Used to group a set of labels together that relate to a particular port or tunnel. Makes
withdrawal of labels easier when there is a failure of a port and there are many VPN labels associated with that
same port.
RN
• VC ID: An administrator-configurable value that represents the Layer 2 circuit.

• Interface parameters: Used to validate interoperability between ingress and egress ports. Possible parameter
can be MTU, maximum number of concatenated ATM cells, interface description string, and other circuit
emulation parameters.
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
FEC 129 BGP Autodiscovery Control Plane

E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
FEC 129 BGP Autodiscovery

The FEC 129 BGP autodiscovery for VPLS is sort of hybrid solution. The BGP part is used to easily discover remote PE
members of the VPLS instance. This overcomes the drawback of the standard LDP signaling solution for VPLS. The BGP
E
peers will advertise their interest in VPLS instances to each other, possibly using route reflectors for more scalability.
US
Once the remote PEs are discovered the next phase is to establish targeted LDP session to each other. In the LDP session
the exchange of the FEC 129 and its associated label is accomplished.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
FEC 129 BGP Autodiscovery NLRI

The BGP autodiscovery routes exchanged between PEs using the family l2vpn auto-discovery-only have a
simple format as shown in the slide. The. route distinguisher is configured in the VPLS instance, the SAII is for VPLS the
E
router-id of the advertising PE.

US
Extended Communities
Important additions to BGP autodiscovery route are two extended communities.
• l2vpn-id: Globally unique Layer 2 VPN / VPLS identifier;
AL
• Route targets: Policy tool to control which PEs are capable of learning about VPLS instance. Multiple route
targets can be used for more complex topologies like hub-and-spoke.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
FEC 129 BGP Autodiscovery Checks

Upon receiving a BGP autodiscovery route from a remote PE, the local PE will check for matching values of the two extended
communities between the PEs. So both the l2vpn-id, and the route target must match for a BGP autodiscovery route to be
E
accepted into the VPLS instance.

US
The BGP pseudowire route format is shown above. The AGI is equal to the l2vpn-id value, the SAII is the router-id of the
advertising PE, and the TAII is the router-id of the receiving PE.
Route Installation.
AL
Local generated BGP autodiscovery routes are installed in the instance.l2vpn.0 table. Also, BGP pseudowire routes
accepted from remote PEs are installed into this table.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
FEC 129 LDP Signaling

After the remote PEs router-id is learned through the BGP autodiscovery process a targeted LDP session is established. The
FEC 129 label information is exchanged and is installed. into the instance.l2vpn.0 and ldp.l2vpn.0 route tables.
E
An easy way to see the FEC 129 label information is seen when using the show ldp database command.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
FEC 129 Element

In the slide, you can see the FEC 129 format in simplified form.
E
• C bit: Specifies whether control word is used or not.

• VC type: Specifies encapsulation type (5 = Ethernet).
US
• AGI: Attachment group identifier equals the configured l2vpn-id.

• SAII: Source attachment individual identifier. For VPLS, it is always the advertising PE router’s router-id.
• TAII: Target attachment individual identifier. For VPLS, it is always the receiving PEs router router-id.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Learning and Forwarding Process

E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Inbound Frame from Local CE Device

The slide shows how Ethernet frames from the local CE devise of a VPLS logically flow through the Packet Forwarding Engine
(PFE) of a router running the Junos OS. Notice that for each learned remote site (by means of L2VPN advertisements), a VPN
E
tunnel interface is created within the Tunnel Services PIC. The VPN tunnel interface is not used for forwarding traffic inbound
from the local CE device. The VPN tunnel interface’s use is described on the next slide.
US
1. An Ethernet frame arrives on interface fe-0/1/0.600. Because the interface is configured as part of a VPLS,
the Ethernet framing is not stripped from the Layer 3 packet inside.
2. The Internet Processor II (or equivalent route lookup ASIC) can learn (if not already known) the local CE device’s
MAC address from the Ethernet header’s source address. Because of this learning process, an entry is stored in
AL
the vpn-name.vpls forwarding table (MAC table) with its associated next hop. This entry is used to forward
traffic to the local CE device as MPLS-encapsulated frames arrive from the core (shown on next slide).
3. The Internet Processor II performs a forwarding lookup for this Ethernet frame using the vpn-name.vpls
RN
table. If the destination MAC address is not known, the Internet Processor II uses a flood route in the forwarding
table, which causes the frame to be flooded to all sites except for the site where the frame originally came from.
In the case described in the slide, there is a specific entry for the destination MAC address so the frame is
encapsulated in two MPLS headers and passed to the outgoing interface.
TE
4. The MPLS-encapsulated Ethernet frame is forwarded to the remote site across the core network by means of
the MPLS LSP built between PE devices.
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Inbound Frame from Core—Remote Site

The slide shows how MPLS-encapsulated Ethernet frames arriving from the core network of a VPLS logically flow through the
PFE of a router running the Junos OS.
E
1. Because of penultimate-hop popping (PHP), an Ethernet frame encapsulated by a single MPLS header arrives
US
on the SONET interface.

2. As with all MPLS-encapsulated data, the Internet Processor II performs a forwarding lookup using the mpls.0
table. Unlike point to point Layer 2 VPNs, instead of having a mapping of inbound labels to an outbound
interface, the inbound labels are mapped to the dynamically created VPN tunnel interface. The reason this
interface mapping is needed on a router running the Junos OS is because after the Internet Processor II
AL
processor does a pop operation based on the mpls.0 table, no other Internet Processor II functions can be
performed. By passing the resulting Ethernet frame through the VPN tunnel interface, the Internet Processor II
is given a second chance to perform another function on the frame (that is, MAC address learning).
RN

TE
IN

Junos Layer 2 VPNs
Inbound Frame from Core—Remote Site (contd.)
RE
3. The Internet Processor II can learn (if not already known) the remote CE device’s MAC address from the
Ethernet headers source address. Because of this learning process, an entry is stored in the vpn-name.vpls
forwarding table with its associated next hop and MPLS encapsulation. The Internet Processor II knows in which
VPLS forwarding table to store the new entry based upon which VPN tunnel interface the packet arrives from.
A
This entry is used to forward traffic to the remote CE device as Ethernet frames arrive from the local CE device
(shown on previous slide).
SH
4. The Internet Processor II performs a forwarding lookup for this Ethernet frame using the vpn-name.vpls
table. If the destination MAC address is not known, the Internet Processor II uses the default route in the
forwarding table, which causes the Internet Processor II to flood the frame to all local sites but not to any
remote sites. In the case described in the slide, there is a specific entry for the destination MAC address so the
frame is passed to the appropriate outgoing interface.
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
CE-A1 Sends Broadcast Traffic to CE-A3

On the slide, the administrator of CE-A1 attempts to ping the core-facing interface of CE-A3. Because CE-A1 does not know
the MAC address to use to send traffic to CE-A3, it must send an Address Resolution Protocol (ARP) request onto the
E
Ethernet segment. This slide shows CE-A1 sending an ARP request frame on VLAN 600. The frame arrives on PE-1 VPLS
interface with a broadcast destination MAC address.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
PE-1 Learns MAC Address from Frame

Before PE-1 forwards the Ethernet frame, it analyzes the addresses in the Ethernet header. PE-1 learns and stores the MAC
address of CE-A1 and related interface in its vpn-name.vpls forwarding table.
E
Broadcast Frame Is Flooded

US
When the destination MAC address of a received Ethernet frame is unknown or is broadcast from a CE device, the Ethernet
frame is duplicated and sent to all remote PE routers for the VPLS. The flooding behavior is based on a default route in the
VPLS forwarding table, vpn-name.vpls.
AL
Lookup Derives Two Labels

Based on a forwarding table lookup, the Ethernet frames are encapsulated into the appropriate inner and outer header, as
shown on the slide.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
PE Router Forwarding
The slide summarizes the forwarding and learning behavior of a PE router.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
MPLS Switching in Core

The labeled Ethernet frames are forwarded over the LSPs connecting the ingress PE router to the remote PE routers. The
P routers in the core perform swap operations on the outer label. The P routers are not aware of the inner label, which
E
remains unchanged throughout this process.

US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Outer Label Removed

The penultimate router pops the label stack, resulting in PE-2 and PE-3 receiving an Ethernet Frame with a single label.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Egress PE Router Looks Up VPLS Label

The egress PE router performs a lookup on the VPLS label in the mpls.0 table. The entry in the mpls.0 table tells the
router to pop the MPLS label and forward the Ethernet frame through the VPN tunnel interface that was created in response
E
to learning PE-1’s label block. The packet is essentially passed through the VPN tunnel interface so that a second lookup can
occur.
US
Egress PE Router Learns and Performs Second Lookup

When an unlabeled Ethernet frame returns from VPN tunnel interface (Tunnel Services PIC), the egress PE router does two
things. First, in the example on the slide, PE-2 and PE-3 learn the MAC address for CE-A1 from source address of Ethernet
AL
Frame. Based on the newly learned MAC address, a dynamically generated route/MAC entry is placed into the
vpn-name.vpls. The new route table entry is a route to the MAC address of CE-A1 with an LSP next hop (push-push
operation based on VCT learned from PE-1). Second, the PE routers perform a lookup in the vpn-name.vpls table.
Because the frame is a broadcast frame that arrived from the provider core, the frame is flooded to all attached CE devices.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Broadcast Frame Analyzed by Remote CE Devices

CE-A2 discards ARP frame because 1.1.1.1 does not belong to it. Because 1.1.1.1 belongs to CE-A3, it responds with an ARP
reply.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
PE-1 Looks Up VPLS Label

E
to learning PE-3’s VCT.

US
When the unlabeled Ethernet frame returns from VPN tunnel interface (Tunnel Services PIC), PE-1 learns the MAC address
for CE-A3 from source address of Ethernet Frame. Based on the newly learned MAC address a dynamically generated route
entry is placed into the vpn-name.vpls. The new route table entry is a route to the MAC address of CE-A3 with an LSP
next-hop (push-push operation based on label block learned from PE-1). Second, PE-1 performs a lookup in the
vpn-name.vpls table. Because the MAC address of CE-A1 was learned earlier, which caused a route to CE-A1 to be
AL
dynamically installed, the frame is sent directly to CE-A1.

RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
PE-1 Looks Up VPLS Label

E
to learning PE-3’s VCT.

US
When the unlabeled Ethernet frame returns from VPN tunnel interface (Tunnel Services PIC), PE-1 learns the MAC address
for CE-A3 from source address of Ethernet Frame. Based on the newly learned MAC address a dynamically generated route
entry is placed into the vpn-name.vpls. The new route table entry is a route to the MAC address of CE-A3 with an LSP
next-hop (push-push operation based on label block learned from PE-1). Second, PE-1 performs a lookup in the
vpn-name.vpls table. Because the MAC address of CE-A1 was learned earlier, which caused a route to CE-A1 to be
AL
dynamically installed, the frame is sent directly to CE-A1.

RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Future Traffic Is Not Flooded

As MAC addresses are learned over time, packets no longer need to be flooded to all remote PE devices across provider core.
Ethernet frames that are now passed between CE-A1 and CE-A3 will be forwarded only between the related PE devices.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
BUM Replication
Broadcast, unicast with unknown destination, and multicast (BUM) traffic is replicated and flooded solely by the ingress PE
by default. This behavior can put a tremendous burden on the PE if it happens to be services several hundred VPLS
E
instances. point to multipoint LSPs can be used specifically for the purpose of carrying BUM traffic. When using a point to
multipoint LSP for this purpose, the ingress PE only needs to send 1 copy of the BUM traffic into the core. The downstream
US
routers along the LSP will perform replication of the traffic. To notify remote PEs that a point to multipoint LSP will be used for
BUM forwarding, the ingress PE re-advertises all label blocks along with the Provider Multicast Service Interface (PMSI)
Tunnel attribute which carries the RSVP session identification information.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Fully Meshed PE Routers

Based on the flooding behavior of VPLS, PE routers must be fully meshed in terms of MPLS LSPs as well as extended LDP or
MP-BGP sessions (route reflectors and confederations can be used).
E
Split Horizon
US
One of the flooding rules of VPLS is that a router cannot flood a packet from a remote PE router to another remote PE router.
Although this behavior causes a need for the full mesh, it helps eliminate the need for a spanning tree protocol in the
provider core.
AL
PE Routers Perform MAC Learning and Flooding

As described on the previous slides, a PE router learns MAC addresses based on received Ethernet frames. A PE device will
not request another PE device to flood or learn on its behalf.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Loops
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Redundant Links Between CE and PE

The slide shows a potential loop situation that can occur when there are multiple links between a CE and the local PE. If
CE-A2 is a router operating at Layer 3, then there should be no Layer 2 loop possible. However, if CE-A2 is a Layer 2 switch
E
then a Layer 2 loop is possible. To prevent Layer 2 data from looping between the CE and PE with redundant links you must
configure either a spanning tree protocol between PE and CE, active and backup links on the PE, Ethernet Ring Protection
US
(ERP), or a link aggregation group (LAG).

AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Multihomed CE
The slide shows a potential loop situation that can occur when there are links between a single CE multiple PEs. If CE-A2 is a
router operating at Layer 3, then there should be no Layer 2 loop possible. However, if CE-A2 is a Layer 2 switch then a
E
Layer 2 loop is possible. To prevent Layer 2 data from looping between the CE and two PEs you must configure either a
spanning tree protocol between PEs and CE, BGP multihoming, or a primary and backup neighbor.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
We Discussed:
• The difference between Layer 2 MPLS VPNs and VPLS;
E
• The purpose of the PE, CE, and P devices;

• Provisioning of CE and PE routers;
US
• The signaling process of VPLS;

• The learning and forwarding process of VPLS; and
• The potential loops in a VPLS environment.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Review Questions
1.
E
2.
US
3.
AL
RN
TE
IN

Junos Layer 2 VPNs
Answers to Review Questions
RE
1.
A Layer 2 VPN is point to point in nature while a VPLS is point to multipoint.
2.
A
Adding and removing sites from a BGP VPLS requires the configuration of only one PE. All other PEs will automatically discover the
added or removed site.
SH
3.
For point-to-point connections MAC address learning is not needed as all incoming traffic can be sent across the single point-to-point
interface. For VPLS, the interface is similar to point-to-multipoint and then choices need to be made. Only if address is not known
flooding to all remote PEs is useful, if MAC address is learned traffic forwarding can be optimized by sending it to specific PE only
T
where MAC address resides.
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN

RE
A
SH
Junos Layer 2 VPNs
T
NO
Chapter 7: VPLS Configuration
DO
—
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 2 VPNs
RE
A
SH
T
NO
DO
—
LY
ON
We Will Discuss:
• Virtual private LAN service (VPLS) configuration, and
E
• VPLS troubleshooting.
US
AL
RN
TE
IN
Chapter 7–2 • VPLS Configuration www.juniper.net

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
VPLS Configuration
E
US
AL
RN
TE
IN
www.juniper.net VPLS Configuration • Chapter 7–3

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Sample VPLS Topology

The diagram on this slide serves as the basis for the various configuration-mode and operational-mode examples that follow.
E
All customer edge (CE) and provider edge (PE) router interfaces use 10.0.12.0/24 addresses. The drawings show only the
interfaces’ subnet and host IDs. Loopback addresses are assigned from the 192.168/16 address block.
US
The core interior gateway protocol (IGP) is Open Shortest Path First (OSPF), and a single area (Area 0) is configured. Because
the examples in this class do not rely on the functionality of the Constrained Shortest Path First (CSPF) algorithm, traffic
engineering extensions need not be enabled.
RSVP is deployed as the MPLS signaling protocol, and label-switched paths (LSPs) are configured between all three PE
AL
routers.
A multiprotocol IBGP(MP-IBGP) peering session is configured between the loopback addresses of the PE routers. The
l2-vpn signaling and inet unicast address families are configured.
RN
The goal of this network is to provide point-to-multipoint connectivity between the three CE routers shown. This network is
considered a full-mesh application because the resulting configuration readily accommodates additional sites with
any-to-any connectivity.
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Interface Configuration
This slide provides an example of Gigabit Ethernet interface configurations for use with VPLS.
E
When using vlan-tagging, only VLAN IDs 512-4094 are available for VPLS encapsulation. If you use extended-vlan-tagging
VLAN IDs 1-4094 are available for VPLS encapsulation. All logical unit levels might also be configured for family vpls,
US
but in later versions of the Junos operating system, this configuration is optional.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
VPLS VRF Table Creation

You create VPLS virtual private network (VPN) routing and forwarding (VRF) tables at the [edit routing-instances]
portion of the hierarchy. You specify a VPLS instance with arguments applied to the instance-type statement. As with a
E
Layer 3 VPN VRF instance, you must assign a route distinguisher, list the VRF interfaces, and link the instance with a
vrf-target community or VRF import and export policies. You also must configure local site properties under the [edit
US
routing-instances instance-name protocols vpls] hierarchy.

AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
BGP VPLS Signaling

In this example, BGP sessions are configured between the PE with family l2vpn signaling configured. This configuration
is the same family that is used for point-to-point Layer 2 VPNs.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Sample BGP VPLS Instance

This slide shows a sample VPLS routing instance based on the sample topology. This instance is called vpn-a. The instance
is assigned a route distinguisher based on the PE router’s loopback address (Type 1 format). The instance-type vpls
E
setting creates a VPLS VRF.

US
This vpn-a instance is associated with a single logical interface (ge-1/0/5.515). Additional interfaces can be listed if the
customer wants to be multihomed.
You can link the VPLS VRF table to either VRF import and export policies or a vrf-target statement, which is used to
match and add route target communities.
AL
The local site properties are configured under the protocols portion of the VPLS instance. These parameters were discussed
in the previous page.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
LDP VPLS Instance Example

You can configure LDP as the signaling protocol for a VPLS routing instance instead of BGP. The functionality is described in
RFC 4762, “VPLS Using LDP Signaling.”
E
The Junos OS does not support all of RFC 4762. When enabling LDP signaling for a VPLS routing instance, network engineers
US
should be aware that only the following values are supported:

• Forwarding equivalence class (FEC)—FEC 128;
• Control bit—0; and
• Ethernet pseudowire type—hexadecimal 0x0005.
AL
To enable LDP signaling for the set of PE routers participating in the same VPLS routing instance, you need to use the
vpls-id statement configured at the [edit routing-instances routing-instance-name protocols
vpls] hierarchy level to configure the same VPLS identifier on each of the PE routers. The VPLS identifier must be globally
RN
unique. When each VPLS routing instance (domain) has a unique VPLS identifier, it is possible to configure multiple VPLS
routing instances between a given pair of PE routers.
LDP signaling requires that you configure a full mesh LDP session between the PE routers in the same VPLS routing
instance. Neighboring PE routers are statically configured. Tunnels are created between the neighboring PE routers to
TE
aggregate traffic from one PE router to another. Pseudowires are then signaled to demultiplex traffic between VPLS routing
instances. These PE routers exchange the pseudowire label, the MPLS label that acts as the VPLS pseudowire demultiplexer
field, by using LDP FECs. Tunnels based on both MPLS and generic routing encapsulation (GRE) are supported.
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
FEC 129 BGP Autodiscovery Configuration

The slide shows the configuration for the BGP session to enable BGP autodiscovery. The family l2vpn
auto-discovery-only enables the exchange of the BGP autodiscovery routes.
E
The output of the show bgp summary command shows that the BGP autodiscovery routes show up in the bgp.l2vpn.0
US
table based on matching route target. From there they are copied into the instance.l2vpn.0 table.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
FEC 129 BGP Autodiscovery Instance

In the slide you see the basic configuration to enable a FEC 129 BGP autodiscovery VPLS instance.
E
The l2vpn-id uniquely identifies the VPLS instance. As targeted LDP is used after the BGP autodiscovery process, LDP
needs to be enabled on the loopback interface.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
CE with Multiple Interfaces to Multiple PEs

The slide discusses the options to prevent a Layer 2 loop in the case that CE-B is an Ethernet switch.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
BGP Path Selection:

Dependent on the L2VPN network redundancy and use of route reflectors (RR) the path selection can be straightforward or
more complex. If there is only a single path to a remote CE the path selection is obvious. However if CE multihoming or route
E
reflection is used the selection process is more complicated.

US
Default Path Selection on PE

On Junos PE devices the default path selection for BGP L2VPNs and VPLS is not the standard BGP path selection algorithm
but the designated forwarder path selection as described in draft-ietf-bess-vpls-multihoming-01.
AL
Since Junos 12.3 it is possible to enable both the designated forwarder path selection algorithm and the standard BGP path
selection algorithm on the PE and RR routers. To enable this feature
• Run Junos OS Release 12.3 or higher on all PE and RR routers.
• Specify unique route-distinguisher on each PE router that is a member of a L2VPN or VPLS deployment.
RN
Configure the l2vpn-use-bgp-rules command on all PE and RR routers. This statement can be globally configured at
the [edit protocols bgp path-selection] hierarchy. It can also be configured at the routing-instance level.
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
BGP Solution
In the example topology, CE-B is a Layer 2 switch that is multihomed to both PE2 and PE3. This redundant topology causes a
potential Layer 2 loop. Luckily, because BGP is used to signal the VPLS, BGP’s normal route selection process will almost
E
completely prevent a loop from occurring. To allow BGP to prevent the potential loop, you must configure the following on
PE2 and PE3:
US
1. Both sites should be configured with the same site ID.

2. Both sites should be configured with the same target extended community.
The configuration settings in the slide will make PE2 and PE3 send label block advertisements that are almost identical
AL
except for the BGP next-hop and route distinguisher. When the remote PE, PE1, receives the 2 sets of label blocks from PE2
and PE3, PE1 will go through its normal route selection process to determine one set of routes (label blocks) to use for
forwarding. The example in the slide shows that you can affect which label blocks will be chosen by modifying the BGP local
preference and set the site-preference (default is 100). In this case, because the label blocks from PE2 are more preferred
RN
(Local Preference is 300), PE2 will be chosen as the designated forwarder for the site. PE3 will not forward or learn on its
ge-1/0/5.515 interface until PE2 withdraws its label block advertisements (PE2’s ge-1/0/4 interface fails). The
multi-homing command is used to prevent a corner case loop that can occur when BGP connectivity to the core is lost
by PE3, it could assume that PE2 is no longer advertising its label blocks and then assume the role of designated forwarder.
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Single Pseudowire
Looking at the slide, you can see that PE1 has received advertisement from both PE2 and PE3. Because each advertisement
represents site 2 of the VPLS, PE1 will only chose 1 advertisement to use for forwarding. The output of the show vpls
E
connection command shows that there is a single pseudowire established to connect site 1 to site 2. If the PE-CE
interface on PE2 fails, there will be a short period of time that is required to establish a new pseudowire to connect site 1 to
US
site 2. Wouldn’t it be nice if a pre-established pseudowire was available between PE1 and PE3 on hot standby? The next few
slides discusses how to get quicker failover times by slightly modifying the solution shown on this slide.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Control Flags
The best-site feature described in the next few slides makes use of the 3 bits of the control flags in the Layer2-info
community advertised along with a site’s label blocks.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Dummy Sites
To configure the best-site feature, each instance of a VPLS must have a single site added. The slide shows the
configuration of PE2 and PE3 but PE1 would need to have a similar configuration (in the future slides you will see that PE1 is
E
configured with site 991). This “dummy” site will be configured with no interfaces as well as the best-site statement.
Since this site has no interfaces, it is impossible for the site to go down (it is always up). The PE routers will advertise two
US
types of label blocks; one set for the real sites and one advertisement for the dummy site. Another optional statement that
should be configured is the mac-flush statement. This will allow a PE to request that another PE flushes (removes) all MAC
entries that were learned from the requesting site. As mentioned earlier, a flush request is signaled when the previous label
block’s Layer2 Info community had the flush bit set to 1 and then a matching but updated label block is received which has
the flush bit set to 0 (it is the transition from 1 to 0 that causes a flush).
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Fully Meshed Pseudowires

Remember, each PE advertises label blocks for the real sites and label blocks for the dummy sites. It is the exchange of label
blocks for the dummy sites that causes the PEs to establish a full mesh of “always on” pseudowires. It may appear from the
E
output that there is no connectivity between site 1 and 2 but this is not true. It turns out that there only has to be a single
pseudowire established between VPLS instances to provide connectivity between the sites of two PEs. All sites of a VPLS
US
instance can use the single pseudowire for data transport. On the slide, you can see that there is a pseudowire between site
991 and 992 (also available for site1 to site 2 data transport between PE1 and PE2) and between 991 and 993 (also
available for site1 to site 2 data transport between PE1 and PE3). These sites were chosen for the establishment of the
pseudowires because they were advertised with the best site bit set (because we configured the best-site setting). Now
just because the pseudowires are available doesn’t mean they are being used. The next few slides show how a PE1
AL
determines which of the two pseudowires it will actually use to pass user data over to site 2.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Before Failure
After the establishment of the pseudowires and before any link failures, PE1 must choose which pseudowire it will use to
forward user data to site 2. The slide shows that both PE2 and PE3 have each advertised a label block representing site 2.
E
Since the advertisement from PE2 has a higher BGP local preference (300), it is PE2’s label block that is chosen to reach
site 2. The pseudowire between PE1 and PE3 will go unused yet remain available in the case of failure. However, PE3 has set
US
its interface flags to CCC-Down so it cannot forward data at the moment.

AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
At The Time of Failure

When PE2 detects link down on ge-1/0/4, it notifies both PE1 and PE3 by advertising it’s offset 1 label block with the down
bit set, flush bit unset, and local preference set to 0. PE1 will react to this advertisement by flushing the MAC entries learned
E
from PE2 and can now immediately start sending user data over the site 991 to site 993 pseudowire. PE3 reacts to this
advertisement by enabling the ge-1/0/5 interface for forwarding and also re-advertising its own label block to PE1 and PE2.
US
The advertisement from PE3 will have the flush bit set (which does not cause a flush on the remote PEs).
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
LDP Solution
To prevent a Layer 2 forwarding loop in this scenario when using an LDP VPLS, special configuration is made on PE1.
Assuming that the desired primary forwarding path is between PE1 and PE2 with PE3 acting as a backup. In the VPLS
E
configuration for PE1, PE2 would be listed as a neighbor and PE3 would be listed as a backup neighbor in the event of PE2
failure. PE2 and PE3 would be configured as normal. In PE1’s configuration, it is also possible to configure PE3 in standby
US
mode. In that case, PE1 and PE3 would establish a pseudowire between one another even when PE2 is available. Although,
PE3 would send broadcast, unicast unknown, multicast (BUM) and so forth to PE1, PE1 will not learn or forward any traffic to
or from PE3 while PE2 is available.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
CE with Multiple Interfaces to One PE

The slide discusses the options to prevent a Layer 2 loop in the case that CE-C is an Ethernet switch.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Primary Interface
It is possible to configure the PE to monitor its own VPLS interfaces, allowing only one interface to be primary and active at
any one time. A benefit of this feature is that there is no requirement to run a spanning tree protocol and yet the PE behaves
E
similarly. To use this feature, you must list each interface connected to the site under the site-level configuration. Finally, you
must specify an active interface. If you specify a particular interface as the active interface then that interface will be used by
US
the PE for learning and forwarding for the site. All other interfaces will not forward or learn during this period. If the active
interface goes down then one of the other configured interfaces will take over as active. Once the primary comes back up, it
will again become the active forwarder. For non-revertive behavior, set the active interface to any. There might be packet loss
during the failover from one interface to another, however the main concern is Layer 2 loop prevention.
AL

RN
TE
IN

Junos Layer 2 VPNs
Primary Interface (contd.)
RE
The same configuration options also exist for LDP VPLS, and FEC 129 BGP autodiscovery VPLS.
For LDP VLS see the example configuration below.
[edit routing-instances vpn3]
A
lab@mxB-1# show
instance-type vpls;
SH
interface ge-1/0/4.515;
protocols {
vpls {
T
site 1 {
active-interface primary ge-1/0/4.515;
NO
}
vpls-id 100;
neighbor 193.168.2.2;
}
}
DO
For FEC 129 BGP autodiscovery VPLS look at the configuration example below:
lab@mxB-1> show configuration routing-instances vpn4
instance-type vpls;
interface ge-0/0/1.0; —
route-distinguisher 1:1;
l2vpn-id l2vpn-id:1:1;
vrf-target target:1:1;
LY
protocols {
vpls {
multi-homing {
site 1 {
ON
identifier 1;
active-interface {
primary ge-0/0/1.0;
}
E
}
}
US
}
}
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Link Aggregation
The configuration example shows the use of a link aggregation group (LAG) to prevent a Layer 2 loop. Instead of two separate
1 Gbps interfaces, it is possible bind them together to make the 2 interfaces logically appear as a single 2 Gbps interfaces to
E
the PE and CE involved. Not only will this configuration allow for Layer 2 loop prevention, it will also double the customer’s
access speed to the network.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Ethernet Ring Protection

The slide shows the configuration to enable the Ethernet Ring Protection (ERP) control channel on VLAN 100. To protect the
Ethernet ring, a single link between PE1 and CE-C acts as the ring protection link (RPL) on the ring (ge-1/0/4 from the
E
perspective of PE1). PE1 acts as the RPL owner and controls the state of the RPL. During normal operation with no failures
(idle state), the RPL owner places the RPL in the blocking state, which results in a loop-free topology. If a link failure occurs
US
somewhere on the ring, the RPL owner places the RPL in a forwarding state until the failed link is repaired. Once the failed
link is repaired, the Junos OS acts in a revertive manner, returning the RPL to the blocking state.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Spanning Tree Protocols

Spanning tree protocols cannot be configured directly in a VPLS routing-instance. However, you can use a Layer 2 control
routing instance instead. A benefit of using this type of routing instance is that you can run a spanning tree protocol using
E
interfaces that belong to several different VPLS routing instances, not just one. The slide shows the use of a Layer 2 control
routing instance to ensure that no loop exists between the PE and CE. For the topology to work properly, the CE (Layer 2
US
switch) should also be configured for a spanning tree protocol. Use the show spanning-tree interface
routing-instance instance-name command to view the forwarding and blocking state of the interfaces.
user@PE1> show spanning-tree interface routing-instance l2-control
...
AL
Spanning tree interface parameters for instance 1
Interface Port ID Designated Designated Port State Role

port ID bridge ID Cost
RN
ge-1/0/4 128:45 128:55 32769.80711fc307d1 20000 FWD ROOT

ge-1/0/6 128:47 128:57 32769.80711fc307d1 20000 BLK ALT.
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
MAC Moves Might Indicate Loops

If a MAC address frequently moves between interfaces this might indicate a loop in the Layer 2 network. For some MAC
address moving between interfaces is normal, VRRP for example. These MAC addresses have to be excluded from the MAC
E
move loop prevention as they result in false positives

US
MAC Move Detection Methods

Junos support two approaches to disable an interface that is suspected of causing the loop.
• Base learning interface (base IFL) approach: Primary approach that maintains base interface for every MAC
AL
address. The base interface is the interface where the MAC address was first learned and stable on for at least
300s. If the MAC address frequently moves between the base interface and second interface, this second
interface will be disabled as it considered the source of the loop.
• Statistical approach: Secondary approach if the MAC address cannot be associated with base interface (base
RN
interface is null). Statistics of the MAC moves between interfaces learned and is used to disable the interface
considered the source of the loop.
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Global VPLS MAC Move Settings

There are global MAC move settings for all VPLS instances.
E
• cooloff-time: Timer (default 30 seconds) that starts when interface gets disabled. During this time other
MAC moves in the VPLS instance are ignored, and no other interfaces in the VPLS instance are disabled.
US
• interface-recovery-time: By default interface is disabled permanently. If this timer is configured the

interface is enabled after the expiration of interface recovery time.
• statistical-approach-wait-time: Time (default 30 seconds) when statistics for MAC move are
collected for MAC address that have no base interface (base IFL is null)
AL
Enable MAC Move in VPLS Instance

To enable MAC move loop detection in a specific VPLS instance configure the enable-mac-move-action at the [edit
routing-instances name protocols vpls] hierarchy level.
RN
To verify MAC move loop prevention you can use the following commands show vpls mac-move-action, show
l2-learning mac-move-buffer, show vpls mac-table extensive. To verify if interface is disabled use
show interface interface-name command.
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Stitching a Point-to-Point VPN to a VPLS

It is possible to add or stitch a point to point Layer 2 VPN (Layer 2 VPN or Layer 2 Circuit) into a VPLS. To do so, one end of the
point-to-point Layer 2 VPN must terminate on a PE that is also a VPLS edge device. Logical tunnel interfaces can be used as
E
the stitching mechanism on the terminating PE.

US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Stitch Configuration
The example on the slide shows the stitching of a BGP Layer 2 VPN (L2VPN) to a VPLS. On the terminating PE, there should
be a separate routing instance for both the L2VPN and the VPLS. Instead of specifying a physical interface in the L2VPN
E
routing instance, notice that lt-1/0/10.1 is used. The interface configuration for lt-1/0/10.1 uses vlan-ccc encapsulation as
expected. Also, the peer interface, lt-1/0/10.0 uses vlan-vpls encapsulation. The last step to the stitching process is to add
US
the lt-1/0/10.0 interface to the VPLS.

AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
BGP and LDP VPLS Interworking

There are vendors that make routers that only support LDP-signaled VPLS. BGP and LDP VPLS interworking allows for routers
of this type to coexist in a network that uses the benefits of BGP-signaled VPLS. To interconnect these two different VPLS
E
types there must be a single border router that has a full mesh of BGP sessions to the PEs in the BGP-based network (unless
route reflection or confederations are used) and a full mesh of LDP sessions to the PEs participating in the LDP VPLS. The
US
border router, PE3, has a single media access control (MAC) table that it uses to learn and forward for both VPLS types. With
interworking, the concept of mesh groups has been introduced. In the example in the slide, the BGP session mesh will fall
into one mesh group (the default mesh group) and the LDP session mesh will fall into another mesh group. When BUM traffic
arrives from one mesh group, it will be flooded to all CE interfaces as well as all mesh groups for the VPLS except for the one
from which the frame arrived. Essentially, the flooding behavior considers a mesh group to be just another CE interface.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Same Routing Instance

Unlike the stitching example in the previous slides, interworking uses a single routing instance. The configuration for both
the BGP and LDP VPLS is performed in the single VPLS instance on the border router.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
VPLS with Point-to-Multipoint LSPs

To allow for a PE to flood BUM traffic using point-to-multipoint LSP, simply configure an RSVP provider tunnel. You can use
the default template or you can use a user defined label switched path template.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
PIM Snooping for VPLS

PIM snooping allows the PEs to learn about multicast routers that are interested in certain multicast sources. By listening to
PIM hello/join/prune messages the PE can fill the multicast forwarding tree, which allows it to only send traffic to interested
E
receivers. This reduces bandwidth usage to sites that are not interested in these multicast streams.
US
To enable it, configure pim-snooping at the [edit routing-instance name protocols] hierarchy level.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
No Tunnel PIC Required

A tunnel pic is no longer required to run VPLS on the Junos OS because the command no-tunnel-services can be
configured under the routing instance. When this command is configured, instead of seeing VPN tunnel interfaces,
E
label-switched interfaces (LSIs) are used instead. This command has very similar restrictions to the vrf-table-label
command.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
LSI Interface
The label-switched interfaces (LSIs) replace the use of the VPN tunnel interfaces inside the forwarding table of the router,
but all the forwarding concepts stay the same. In other words, a unique LSI interface is still created for every remote site and
E
used for packets received from remote PEs.

US
The use of the LSI interface does have a few limitations. The forwarding rate is limited on a per LSI basis and his variable per
router type. When using tunnel services, the forwarding rate can be increased by adding more Tunnel PICs to the router (or
enabling them on an MX Series Ethernet Services router).
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
MAC Table Size

You can modify the size of the VPLS MAC address table. The default table size is 512 MAC addresses, the minimum is 16
addresses, and the maximum is 527,287 addresses.
E
If the MAC table limit is reached, new MAC addresses can no longer be added to the table. Eventually the oldest MAC
US
addresses are removed from the MAC address table automatically. The removal of MAC addresses frees space in the table,
allowing new entries to be added. However, as long as the table is full, new MAC addresses are not learned however traffic
will continue to be forwarded using the process of flooding by default. You can also specify to have the router drop traffic to
unknown destinations when the MAC table is full.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
MAC Table Size Limit

You can limit the total system MAC table size as shown on the previous slide. Because this limit applies to each VPLS routing
instance, the MAC addresses of a single interface can consume all the available space in the table, preventing the routing
E
instance from acquiring addresses from other interfaces.

US
You can limit the number of MAC addresses learned from each interface configured for a VPLS routing instance.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Label Block Size

A PE will advertise enough labels to ensure that each remote site that it learns can send traffic downstream and upstream
from itself. A PE can advertise blocks of labels in sets of 2, 4, 8, or 16. If there are giant gaps in site IDs, then it is possible
E
that many of the advertised labels will go unused. To minimize the wasted label allocations you can configure a lower
label-block size. However, a lower label block size will force the PE to advertise many routes to represent the full set of sites.
US
If your concern is to keep the number of route advertisement low, then set the label block size higher. The default is 8.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Rate Limits
A policer can be used to rate limit traffic that is being flooded. Rate limiting can be configured for all traffic or from certain MAC
addresses if matched in the from statement:
E
[edit]
US
user@PE# set firewall family vpls filter foo term 1 from ?

Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
> destination-mac-address Destination MAC address
AL
+ ether-type Match Ethernet type

+ ether-type-except Do not match Ethernet type
+ forwarding-class Match forwarding class
+ forwarding-class-except Do not match forwarding class
RN
+ interface-group Match interface group

+ interface-group-except Do not match interface group
> source-mac-address Source MAC address
+ vlan-ether-type Match VLAN Ethernet type
+ vlan-ether-type-except Do not match VLAN Ethernet type
TE
Be Careful What You Wish For

Take proper care when applying a VPLS policer and remember the variety of packets that are being flooded. For instance,
IN
routing protocol packets might be sent to other CEs and could be rate limited by the policer!.

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Default VPLS Bridge Domain Mode

A VPLS is essentially a Layer 2 bridge domain. It obviously is slightly different in that it uses pseudowires to be able to send
traffic to remote PE routers. So far in this chapter, we have shown the configuration of all the VPLS instances without the
E
configuration of the vlan-id statement.

US
[edit routing-instances vpn-a]

user@PE3# show
instance-type vpls;
vlan-id <value>;
AL
...
You will usually add interfaces to a VPLS that have similar VLAN tagging as all of the other sites/interfaces that belong to the
VPLS. However, there may come a time when there is a need to add an interface that uses different VLAN tagging that the
rest of the VPLS. The slide shows that when no vlan-id statement is configured for the VPLS, you must configure VLAN
RN
map statements to translate (or normalize) between the dissimilar VLAN tags.
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
vlan-id vlan-id Statement

To make the translation configuration easier, you can add the vlan-id statement to your VPLS instances. In the slide, all of
the VPLS instances (on PE1, PE2, and PE3) for this customer have been configured with the vlan-id 515 statement.
E
PE-CE interfaces that are configured with VLAN of 515 will be treated as normal. For PE-CE interfaces with dissimilar VLAN
tags (i.e. not singly tagged with 515), the router will automatically perform the appropriate push, pop, and swap operations
US
as shown in the slide. Things will work consistently if all VPLS instances for a customer are configured with the same VLAN
ID. In the example, all frames transmitted towards the core will be sent encapsulated in a single VLAN tag of 515. Also, all of
the receiving PE routers are expecting to receive only single tagged packets (VLAN ID 515) from the remote PE routers.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
vlan-id none Statement

The vlan-id none statement is similar to the previous slide except that all VLAN tags will be stripped (not translated) from
incoming PE-CE interface packets. In the slide, all of the VPLS instances (on PE1, PE2, and PE3) for this customer have been
E
configured with the vlan-id none statement. For PE-CE interfaces with any VLAN tags (i.e. not untagged), the router will
automatically perform the appropriate push and pop operations as shown in the slide. Things will work consistently if all
US
VPLS instances for a customer are configured with the same setting. In the example, all frames transmitted towards the core
will be sent encapsulated in no VLAN tags. Also, all of the receiving PE routers are expecting to receive no VLAN tags on
packets received from the remote PE routers.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
vlan-tags Statement
For VPLS that uses a dual stack VLAN, translation configuration can be made easier by adding the vlan-tags statement to
your VPLS instances. In the slide, all of the VPLS instances (on PE1, PE2, and PE3) for this customer have been configured
E
with the same vlan-tags statement. PE-CE interfaces that are configured with same inner and outer VLAN IDs will be
treated as normal. For PE-CE interfaces with dissimilar VLAN tags (i.e. not dual tagged with 300 and 515), the router will
US
automatically perform the appropriate push, pop, and swap operations as shown in the slide. Things will work consistently if
all VPLS instances for a customer are configured with the same VLAN ID. In the example, all frames transmitted towards the
core will be sent encapsulated in a two VLAN tags of 300 and 515. Also, all of the receiving PE routers are expecting to
similarly tagged packets from the remote PE routers.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
vlan-id all Statement

The vlan-id all statement is different than the rest of the options discussed so far. With the other options, the
vlan-id statement provided for VLAN tag translation and, not so obviously, created a single broadcast/learning domain.
E
Learning so far has been performed solely based on received source MAC addresses. VLAN IDs have not been taken into
consideration while learning.
US
The vlan-id all statement performs no translation and also changes the learning behavior of a bridge domain. In all of
the cases discussed so far (including a VPLS with no vlan-id statement configured) it has been assumed that all PE-CE
interfaces of a VPLS were part of the same broadcast domain. What if your customer wants VPLS service that allows the
ability to have 100s or 1000s of broadcast domains (VLANs) between sites? Will you have to configure 100s or 1000s of
AL
VPLS instances? Configuring 1000s of VPLS instances on each PE would be one option, or you could configure a single VPLS
instance on each PE and use the vlan-id all statement. With this statement configured learning and flooding is based
on the combination of both source MAC address and inner VLAN ID. Packets received on PE-CE interfaces are sent to remote
PE with their inner VLAN tags unchanged (outer VLAN tags are popped). Packets received from the core can only be sent out
RN
PE-CE interfaces that have similar inner VLAN tags as those on the packet being transmitted.
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
VPLS Troubleshooting
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
VPLS Connections Legend

The show vpls connections command is an excellent command to help you determine the status of a VPLS. Every
time that you issue the command the legend shown on the slide will be displayed followed by a listing of each VPLS and its
E
status (see next slide). The legend will help you interpret the status code for each VPLS.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
show vpls connections Command

The output on the slide shows the status of the VPLS from site 1 and site 3 to site 2 (refer to the example network).
Remember that site 1 and site 3 were configured under the same VPLS routing instance. Based on the output on the slide,
E
the 3 sites should be able to communicate with each other with no problems. You should not be alarmed when you see a
status of LM for the site 3 to site 2 connection. When two or more sites are configured under one VPLS instance, the site with
US
the lowest site ID will form the connection to the remote site. All other sites in the local VPLS instance, will use that same
connection (pseudowire) to forward and learn. Remember, all of the sites configured under the same VPLS routing instance
are also using the same, single MAC table.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Flood Routes
To determine the current flooding behavior of the VPLS, use the show vpls flood command. This command will help you
determine which interfaces are being used to learn and forward. If you have configured an active interface for a multihomed
E
PE, this command is great to help determine which interface is currently active.
US
Why are there so many flood routes? You should normally expect to see 3 flood routes in the VPLS forwarding table. The
flooding behavior on a PE is based upon the interface that BUM traffic arrives on. If BUM traffic arrives from a locally connect
CE, then the traffic needs to be flooded to all local CEs (except the one the traffic came from) and to all remote PEs. If BUM
traffic arrives from a remote PE, then the traffic needs to be flooded to only local CEs, not to any remote PE (because of PE
full-mesh). If BUM traffic arrives from the Routing Engine (RE), then the traffic needs to be flooded to all local CEs and to all
AL
remote PEs. There should be a flood route for each of the three scenarios.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
View the MAC Table

Use the show vpls mac-table command to see the routing engines copy of the MAC table. To clear the table, use the
clear vpls mac-table command.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
VPLS Statistics
The following fields are present in the output of the statistics command:
E
• Instance: Name of the VPLS instance.

• Local interface: Name of the local VPLS virtual loopback tunnel interface, 
US
vt-fpc/pic/port.nnnnn, where nnnnn is a dynamically generated virtual port used to transport and
receive packets from other PE routers in the VPLS domain.
• Index: Number associated with the next hop.
• Remote provider edge router: Address of the remote PE router.
AL
• Multicast packets: Number of multicast packets received.

• Multicast bytes: Number of multicast bytes received.
RN
• Flood packets: Number of VPLS flood packets received.

• Flood bytes: Number of VPLS flood bytes received.
• Current MAC count: Number of MAC addresses learned by the interface.
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
VPLS NLRI
This screen capture shows the contents the vpn-name.l2vpn.0 table. This table displays all received label blocks from
remote sites that have the correct target community attached.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
FEC 129 BGP Autodiscovery NLRI

The slide above shows the details of a BGP autodiscovery route in the bgp.l2vpn.0 route table. Notice the extended
communities (l2vpn-id, and route target) that are added to the NLRI.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
FEC 129 LDP Database

This slide shows the output of the show ldp database command. It is easy to see the FEC 129 database entries and
their associated labels.
E
Highlighted are the hex values of the l2vpn-id, the advertising PE’s router-id, and the receiving PE’s router-id. These 3
US
items help to uniquely identify the VPLS connection for a given VPLS instance.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
MPLS Forwarding Table

The capture displays the mpls.0 table, which is the table used to forward packets that arrive from the provider’s core. This
slide shows that packets that arrive from the provider encapsulated with an MPLS label of 800002 have the MPLS header
E
popped and the resulting Ethernet frame forwarded to the VPN tunnel interface, vt-1/0/10.1049091.
US
It also shows the reverse direction, packets that arrive from the VPN tunnel interface vt-1/0/10.1049091 are sent to the
remote PE with a double push operation.The top label 299920 identifies the LSP towards the PE, the inner label 800001 is
unique for the VPLS connection.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
VPLS Forwarding Table

The vpn-name.vpls table is essentially the packet forwarding engine’s copy of the MAC table. All learned MAC addresses
are placed in this table along with its next hop. A benefit of looking at this table is that it is possible to see the MPLS label
E
stack that will be used when forwarded traffic to a particular MAC address.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
RE
A
SH
T
NO
DO
—
LY
ON
We Discussed:
• Virtual private LAN service (VPLS) configuration, and
E
• VPLS troubleshooting.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Review Questions
1.
E
2.
US
3.
AL
4.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Lab: VPLS
The slide provides the objective for this lab.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
RE
1.
To prevent a layer 2 loop when a CE is multihomed to a single PE, you must configure either primary/backup link, LAG, ERP, or a
spanning tree protocol.
A
2.
To prevent a layer 2 loop when a CE is multihomed to multiple PEs, you must use BGP for signaling which automatically prevents a
SH
loop or when using LDP for VPLS signaling specify a neighbor and a backup neighbor.
3.
When tunnel services are not available (no Tunnel PIC) the command no-tunnel-services can be enabled to use LSI interfaces instead
of vt interfaces.
T
4.
NO
The flooding behavior on a PE is based upon the interface that BUM traffic arrives on. If BUM traffic arrives from a locally connect
CE, then the traffic needs to be flooded to all local CEs (except the one the traffic came from) and to all remote PEs. If BUM traffic
arrives from a remote PE, then the traffic needs to be flooded to only local CEs, not to any remote PE (because of PE full-mesh). If
BUM traffic arrives from the RE, then the traffic needs to be flooded to all local CEs and to all remote PEs. There should be a flood
route for each of the 3 scenarios.
DO
—
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
RE
A
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN

A RE
SH
Junos Layer 2 VPNs
T
NO
Chapter 8: Ethernet VPN
DO
—
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
We Will Discuss:
• The operation of Ethernet VPNs;
E
• Ethernet VPN configuration; and

• Ethernet VPN troubleshooting.
US
AL
RN
TE
IN
Chapter 8–2 • Ethernet VPN www.juniper.net

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Overview
E
US
AL
RN
TE
IN
www.juniper.net Ethernet VPN • Chapter 8–3

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Ethernet VPN Versus VPLS Functionality

Ethernet VPN is developed to overcome some of the shortcomings of VPLS.The Ethernet VPN requirements are described in
RFC 7209. The table lists some of the most important improvements in Ethernet VPNs compared to current VPLS
E
implementations.
US
• Address learning: MAC address learning is now done in the control plane using MP-BGP. This allows for better
control and greater scalability.One of the advantages is decreased need for forwarding traffic towards unknown
unicast addresses, as MAC addresses are shared among PEs as soon as a PE locally learns a MAC address.
• Redundancy: The option for Active/Active forwarding is great improvement, it allows for optimal utilization of
links in both the core and the access layer.
AL
• Traffic optimization: VPLS has major issues with optimal traffic forwarding, especially with regard to Layer 3
flows. As a result of a much better integration between Layer 2 and Layer 3 in EVPN traffic flows can be much
more efficient from a end-to-end standpoint. Features like ARP/ND proxy, and default gateway synchronization
RN
allow traffic to exit and enter at the nearest PE router, instead of having to potentially cross intra-DC links
multiple times (tromboning).
TE
IN

Junos Layer 2 VPNs
Ethernet VPN Versus VPLS Functionality (contd.)
RE
• Provisioning: EVPN can use the same interface for Layer 2 and Layer 3 traffic. The RFC 7432 also suggests
some other provisioning features that not yet have been implemented in Junos, for example dynamic
assignment of ESI.
• Data plane options: VPLS is only supported using MPLS encapsulation. For EVPN other encapsulation options
A
are possible, although not always implemented by vendors. An alternative for MPLS encapsulation that is very
popular in data centers is VXLAN. This is also supported by Juniper MX Series, as well as Juniper QFX Series.
SH
VXLAN is out of the scope of this course and is covered in the Advanced Data Center Switching (ADCX) course.
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Customer Edge Devices

The customer edge device is normally a router or Layer 2 switch that provides access to the provider’s edge device. Both
ends of the Ethernet VPN must be Ethernet-based. For active/active multihoming the CE device must support aggregated
E
Ethernet (LAG) interfaces.

US
Provider Edge Routers

The provider edge routers connect to the customer sites and maintain EVPN specific information. This information is
obtained through local configuration and through MP-BGP signaling with other PEs. Traffic will tunneled across the provider’s
core using MPLS LSPs.
AL
Provider Routers
The provider routers do not carry any EVPN state. They simply provide label-switching router services to facilitate the transfer
RN
of labeled frames between PE routers.

TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Ethernet VPN Instance

RFC 7432 introduces some new terminology used in EVPN. An Ethernet VPN instance (EVI) is defined as all the PE devices
participating in the specific EVPN.
E
Ethernet Segment
US
When a customer site (device or network) is connected to one or more PEs via a set of Ethernet links, then that set of
Ethernet links is called an Ethernet segment (ES).
Ethernet Segment Identifier

AL
A unique non-zero identifier that identifies an Ethernet segment is called an Ethernet segment identifier (ESI). Multihomed
CEs (active/active or active/standby) require a unique ESI for the links. Both PEs need to use the same unique ESI when
connected to the same CE device.
RN

Single-homed CE devices do not require an ESI as they by default attain the reserved value of
0x00:00:00:00:00:00:00:00:00:00. The MAX-ESI value of 0x:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF is also reserved.
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Operation
The slide lists the topic we will discuss next.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Control Plane

The main signaling protocol used by Ethernet VPNs is multiprotocol BGP to advertise both the EVPN routing information
(family evpn signaling), as well as the Layer 3 VPN routes (family inet-vpn unicast) for optimal Layer 3
E
integration.
US
The other signaling requirements for the provider’s core are same as before, so IGP for reachability and MPLS LSPs for
forwarding of labeled frames between PEs. Either LDP or RSVP can be used to establish LSPs across the provider core.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Ethernet VPN Route Types

The table in the slide shows the different route types, their description, usage, and reference information.
E
1. Ethernet autodiscovery route: Only advertised by PE that is part of multihomed CE (same ESI). There are two
different type of Ethernet autodiscovery routes, and each has their own format and functionality:
US
a. A-D Route per ESI: Used for MAC address mass withdraw to speed up convergence after link failure, and
prevents BUM traffic loops between PEs mulithomed to same CE device (split horizon); and
b. A-D Route per EVI: Used to enable active/active load balancing to PEs connected to multihomed CE
(aliasing).
AL
2. MAC and MAC/IP route: Advertised to indicate reachability to the MAC or MAC/IP address. The MAC/IP address
advertisements are optional and used when Layer 3 functionality is required (i.e., routing).
3. Inclusive Multicast Ethernet tag route: Used to enable ingress replication for forwarding BUM traffic between
RN
PEs.
4. Ethernet Segment route: Only advertised, and accepted by PEs connected to a multihomed CE (same ESI). It
provides information for the Designated Forwarder (DF) election, which prevents traffic duplication and BUM
loops towards the CE device.
TE
5. IP Prefix route: Specific Layer 3 network route advertisement.

IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Local MAC/(IP) Address Learning

To learn local attached MAC addresses normal data plane learning is used, just like VPLS or standard Layer 2 switching. In
Ethernet VPNs it is optionally to include Layer 3 interfaces into the EVI, and this allows for learning of IP addresses as well.
E
Remote MAC/(IP) Address Learning

US
Once a EVPN PE has learned a local MAC/(IP) address, it advertises this address using MP-BGP to the other PEs that are part
of the EVI. The route type is 2, and it is called the MAC/IP advertisement route.
The diagram shows the format and fields of the type 2 route. Junos uses the per instance label allocation which means that
AL
the same label can be used to reach all addresses in a given instance.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
BUM Traffic Forwarding

Junos devices that uses MPLS encapsulation for Ethernet VPNs can only use ingress replication at this time. Ingress
replication means that to flood traffic to remote PEs the traffic has be replicated, once for each remote PE. The EVPN label
E
for this BUM traffic is learned per PE from the route type 3, inclusive multicast Ethernet tag route.
US
The diagram shows the format of the inclusive multicast Ethernet tag route.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
All-Active Redundancy: Designated Forwarder Election

One of the great features of EVPN is the possibility to have Active/Active forwarding towards multihomed CE device. For
unicast traffic this is not a problem at all, but for BUM traffic this does provide some challenges. For all-active redundancy
E
mode the CE device needs to be connected to the PEs using an aggregated Ethernet interface (LAG).
US
To prevent duplicate packets arriving at the CE the two PEs hold a designated forwarder (DF) election. The designated
forwarder is elected per EVI using route type 4, and allows only the DF router to forward BUM traffic arriving from the
provider’s core.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Designated Forwarder Election: Type 4 Routes

The diagram in the slide shows the format of the Ethernet segment route (type 4). This route is only relevant to both PEs
connected to the same ESI. To make sure only these PEs learn this route, the ES-Import route target is added to this route.
E
This ES-Import route-target is dynamically created based on the value of the ESI. So only the PE routers who share the same
ESI will accept them into their routing tables. The algorithm used for the DF election allows different DFs per EVI to enable
US
some form of load sharing across PEs.

AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
All-Active Redundancy Split Horizon

One of the great features of EVPN is the possibility to have Active/Active forwarding towards multihomed CE device. For
unicast traffic this is not a problem at all, but for BUM traffic this does provide some challenges.
E
To prevent looping of BUM traffic back to the multihomed CE, the split horizon feature was developed. The DF router inspects
US
any BUM traffic to see if this traffic didn’t originate on the same ESI segment as it would be forwarded on. The only PE that
can cause this issue is the non-DF router for this ESI. So the non-DF router will add the split horizon label (route type 1)
learned from the DF of the ESI when forwarding traffic from a given ESI.The DF router checks to see if there is any split
horizon label in the BUM traffic received, and if there is a match with its local ESI the BUM traffic will not be forwarded across
that ESI.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Split Horizon: Type 1 Routes

The diagram shows the format of the type 1 route (A-D route per ES). The split horizon label is advertised as part of an
extended community attached to the type 1 route. The split horizon label is also called the ESI label. The extended
E
community also indicates what type of redundancy mode is used for this given ESI: single-active (1) or active-active (0).
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
All-Active Redundancy: Aliasing

In the ideal situation unicast traffic would be load balanced across the PEs attached to the same ESI. However there are
situations where this is not a straight forward as expected. Some type of traffic, and thereby source MAC addresses, might
E
always be forwarded from the CE device on the same single link, This means that only a single PE will learn the MAC/IP
information and the remote PEs only learn the destination from that single PE. To overcome this issue the aliasing feature is
US
used in the EVPN solution.

When a remote PE learns a MAC address associated with a specific ESI, it will install all next hops to that ESI, so both PEs,
regardless if it learned the MAC address from both. The aliasing label is learned from type 1 (A-D route per EVI).
In Junos the aliasing label and the MAC/IP label (per instance) are actually the same.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Aliasing: Type 1 Routes (A-D per EVI)

This diagram shows the format of the type 1 route (A-D per EVI). The MPLS advertised is the aliasing label that enables load
balancing unicast traffic to all PEs connected to an ESI regardless if the MAC address was learned across both PEs or not.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Single-Active Redundancy
Besides the Active/Active forwarding, which typically is preferred, EVPN also supports the Active/Standby forwarding, where
there is only 1 active PE, and the others are just for backup purposes. In single-active redundancy mode the connection
E
between the PEs and the CE can not be a LAG interface. Only one of the links from the CE can be active.
US
In single-active mode the split horizon feature is still advised to be implemented so no BUM traffic loops occur during change
over or startup (both PEs think they are the DF).
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
MAC Moves
In modern data centers, VM mobility is an important feature for workload optimization, high availability, and design flexibility.
If a VM moves from one DC to another DC its associated MAC/IP addresses also move.
E
How can the EVPN cope with these MAC address location changes?
US
EVPN MAC Mobility

When a VM moves to a different DC, it typically will generate some traffic (gratuitous ARP for example) which triggers local
MAC learning in the EVI. The local learning results in MP-BGP advertisements (type 3) to the remote PEs, including the
AL
previous DC where the VM was located. When the “old” PE sees the new update it will withdraw its type 3 advertisement.
The RFC 7432 specifies a new extended community (MAC mobility) but this is not supported by Junos at this time.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Mass MAC Address Withdraw

To speed up convergence, purging of stale MAC address entries, EVPN has a mass MAC address withdraw feature for
multihomed CEs. If the PE-CE link fails the PE router can withdraw the type 1 route (A-D per ESI). The remote PEs, who
E
receive this withdraw of the route, can now easily remove all the forwarding entries towards this ESI from this specific PE. A
single type 1 route withdraw can therefore update the next hops of thousands of MAC address routes.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Ethernet VPN Forwarding

The data plane for EVPN is very similar to that of Layer 2 VPNs or VPLS. Basically label stacking is used with the inner label
being the EVPN-learned labels, and the outer label the transport LSP label learned through RSVP or LDP.
E
The table shows the different EVPN learned labels and their usage in the data plane.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Layer 3 Integration: ARP / ND

To learn local MAC and IP addresses the EVI instance needs to have a Layer 3 interface assigned to it, in Junos that means
an IRB interface. The IRB interface allows ARP/ND learning as it typically acts as the default gateway.
E
Layer 3 Integration: Default Gateway Synchronization

US
By default any IRB interface added to the EVI is advertised (MAC/IP type 2) to the other PEs in the EVPN. The
evpn-default-gateway extended community is attached to these advertisements to indicate that these addresses
should be installed as a default gateway address. If any PE receives a local ARP requests for any MAC/IP route with this
community than proxy ARP/ND should be performed. This results in more efficient traffic flows as the Layer 3 routing can
AL
now be done on the nearest local PE, instead of possibly having to go across the EVPN. to reach the default gateway address.
This is a form of a distributed default gateway function. Multiple PEs share the default gateway function for a given MAC/IP
combination.
The default gateway synchronization can be done in two ways:
RN
• Dynamic: MAC address of type 2 routes with evpn-default-gateway community is installed as a local
peer gateway. Required if MAC address of IRB interfaces are not identical. If VM moves from one DC to another,
its ARP has not changed and it is still looking for the MAC address of the default gateway for which it initially
ARPed. To make sure MAC entry works, all PEs must install it as peer gateway, so VM can route via nearest local
TE
PE.
• Manual: If you configure all the IRB interfaces with the same MAC/IP address information than no need for
dynamic advertisements as information is already known. This is recommended practice as it does not need
IN
any updates during move/add/changes in the EVPN.

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Ethernet VPN and Layer 3 VPN

It is common practice to combine the EVPN with a L3VPN service to optimally route ingress and egress traffic for a given EVI.
IRBs can possibly share the same L3VPN instance depending on the policy requirements.
E
IRB interfaces are placed in both a EVI and L3VPN instance (vrf). Whenever a new local MAC/IP address is learned this will
US
be advertised to the remote PEs in the EVI, as a type 2 route. At the same time this will result in the advertisement of a /32
host route for that IP address in the L3VPN instance. This allows the L3 routing to learn exactly where specific hosts are
located, include VM mobility, and results in efficient flow forwarding across the network.
A given PE will actually learn the same IP route twice, once via the EVI (type 3 MAC/IP) and via the host route in the L3VPN.
The EVPN route is always preferred over the host route in that case. There might be PEs that are part of the L3VPN but not a
AL
member of the EVI. They will use the host route to route towards the EVI for that specific IP address.
So ingress traffic is optimized using the type 3 and host route distribution inside the EVI / L3VPN service. Egress traffic is
optimized using the default gateway synchronization so that traffic can leave using the nearest PE device in the EVI.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Configuration
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Sample EVPN Topology

The diagram on this slide serves as the basis for the various configuration-mode and operational mode examples that follow
E
The CE interface addressing uses the 10.0.20.0/24 addresses. The IRB interfaces on all PE use the 10.0.20.1/24 address.
The IGP in the provider’s core is OSPF using a single area 0 configuration. Traffic engineering extensions are not required as
US
LDP signaling is used for the MPLS LSP signaling.

The goal of this network is to have point-to-multipoint connectivity between the CE-A and CE-B for both Layer 2 (EVPN) and
Layer 3 (L3VPN).
The CE-B is multihomed to both PE2 and PE3 using a LAG interface, so all-active redundancy mode for the EVPN is possible.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Ethernet VPN: BGP Peering

To support EVPN and L3VPN route advertisements between the PEs the BGP session needs to support both family evpn
signaling, and family inet-vpn unicast.
E
To support optimal load balancing for the L3VPN, a load balancing policy (LB) is configured and applied on the forwarding
US
table.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Single-Homed PE Interface Configuration

The slide shows the basic Layer 2 interface configuration to support EVPN deployment including the IRB interfaces.
E
The EVPN PE interface can be configured in two service interface modes:

• VLAN-based: The ge-1/0/4 unit 620 shows an example of the VLAN-based service interface configuration. Each
US
EVI will have its own single VLAN.

• VLAN aware bundle: The ge-1/0/4 unit 700 shows an example of this service interface. This is only shown to
illustrate this type of configuration but is not used in sample topology.
The IRB example shows how to manually configure the MAC address to enable manual default gateway synchronization.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Multihomed PE Interface Configuration

For PEs that are part of a multihomed CE setup there are some special issues to consider regarding the interface
configuration.
E
• The interface that connects to the multihomed CE needs a unique non-zero ESI value. Remember this must be
US
the same on both PEs involved in the multihoming setup. Here the ESI value of
00:01:02:03:04:05:06:07:08:09 is used.
• The interface that connects to the multihomed CE must have the redundancy mode set. By default the
redundancy mode is all-active, but single-active is also possible.
AL
• For Active/Active forwarding the connection between PE-CE must a be LAG interface. To “trick” the CE device
into thinking its LAG interface is connected to the same device. Both PEs must use the same lacp
system-id (00:00:00:00:00:01 in this example). Full MC-LAG is not required in this setup.
Notice that the same MAC/IP address is used on the IRB interface on this PE2 as is configured on PE1.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Instance: VLAN Based

This slide shows the EVPN routing instance for VLAN based service interface. The instance-type is evpn, and the interface
and vlan-id are configured at the [edit routing-instances name] hierarchy level.
E
For all EVPN instances the route-distinguisher must be unique, and therefore type 1 (based on loopback IP address) is highly
US
recommended.
To enable Layer 3 routing, the IRB interface is added to the EVPN instance (irb.620, in this example).
To enable dynamic default gateway synchronization the default-gateway advertise option is configured. If you prefer
the recommended practice of manual default gateway synchronization use the default-gateway do-not-advertise
AL
command. Remember from the previous slide we manually configured both the IP and MAC address on the IRB interface.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Instance: VLAN Aware Bundle

This shows an example of the way you configure the EVPN routing instance if VLAN aware bundle service interface is
used.The instance-type is now virtual-switch, and the interface and VLAN information is completely different
E
configured.
US
The VLAN aware bundle is actually the preferred way of using EVPNs as it is much less provisioning to do add/move/
changes. So even if you start out with only 1 VLAN, it might be useful to configure VLAN aware bundle interface for your EVI.
The VLANs in the VLAN aware bundle service interface share the same EVI but each retains its own broadcast domain.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Instance on PE2

This slide shows the configuration of the EVI on PE2. As it is part of an all-active redundancy mode the PE-CE interface must
be the LAG interface (ae0.620 in this example). To act as a default gateway, the IRB interface is added to the EVI.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Instance: Misc Options

This slide shows the possible options under the [edit routing-instance name protocols evpn] hierarchy level
to customize your EVI configuration.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN: Default Configuration Settings

There are two settings that are used when using EVPNs, by inheriting the configuration statements from the junos-defaults
section.
E
• The evpn-pplb policy is configured and applied on the forwarding table to enable maximum load balancing
US
across the EVPN PEs, especially for multihomed CE setups.

• The chained-composite-next-hop ingress evpn is applied on the forwarding to improve scalability
and L2 rewrites for the EVIs.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
L3VPN Instance on PE1

The slide shows the configuration of the Layer 3 VPN instance on PE1, identical configuration on PE2/PE3. The instance-type
is vrf and only the IRB interface is added to provide optimal Layer 2 and Layer 3 integration with the EVPN.
E
The vrf-table-label is recommended for the L3VPN instance in this kind of EVPN setup as often no routes are learned
US
from the CE device.

AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Troubleshooting
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
BGP Session Verification

In the output above you can see that the BGP sessions with PE2 and PE3 are in the Establ state on PE1. By looking at the
bgp.l3vpn.0, and the bgp.evpn.0 tables showing it is clear that the correct address families have been exchanged
E
across the BGP session.

US
The specific VRF tables L3VPN.inet.0 and EVPN.evpn.0 show that some routes already have been exchanged.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Show EVPN Instance Extensive on Single-Homed PE1, Part 1

The slide shows the first half of the show evpn instance extensive output on the single-homed PE1. You can see
that the Per-instance MAC route label = 300976, so all the MAC/IP addresses locally learned on this PE1 are remotely
E
reachable through this MAC route label.

US
The interface ge-1/0/4.620 connected to CE-A shows that the ESI is 0 as it is a single-homed CE.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Show EVPN Instance Extensive on Single-Homed PE1, Part 2

This slide shows the second part of the show evpn instance extensive output on PE. It shows a quick overview of
the type and amount of routes received from your EVPN BGP neighbors.
E
It also shows the discovery of a multihomed segment (ESI: 00:01:02:03:04:05:06:07:08:09), the PEs connected to this ESI,
US
the aliasing label, and the redundancy mode for this ESI.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Instance Status On Multihomed PE2, Part 1

This output again shows half the output of the show evpn instance extensive command, but this time on PE2
which is part of the CE-B multihomed setup.
E
It shows the ae0.620 interface with it’s ESI value, and indicates that this ESI is in all-active redundancy mode.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Instance Status On Multihomed PE2, Part 2

The output above shows the second part of the show evpn instance extensive output on PE2.
E
The new information here is that on PEs part of the multihomed CE setup you can see the result of the designated forwarder
election, and it easily shows the split-horizon label.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Routes: Type 1: Ethernet A-D per ESI

This slide shows one way to look at the type 1 routes used in the EVPN signaling. The Ethernet autodiscovery per ESI route is
easily recognized by its FFFF.FFFF (Max-ET) at the end of the type 1 route. It also shows the ESI label extended community
E
dynamically attached to the route that advertises the redundancy mode (all-active) and the split horizon label (300911).
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Routes: Type 1: Ethernet Autodiscovery per EVI

The slide shows one way to look at the type 1 Ethernet A-D per EVI route used in the EVPN signaling. This type 1 route is easily
recognizable as the Ethernet tag value = 0 at the end of the route. This route advertises the aliasing label (not seen here) and
E
only has the standard extended route-target community attached.

US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Routes: Type 2: MAC Advertisement

This slide shows how to find the type 2 MAC advertisement route.This is a MAC only advertisement and therefore can only be
used for Layer 2 forwarding.
E
If you already know which MAC address you need, use the evpn-mac-address option as part of your show command.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Routes: Type 2: MAC/IP Advertisement

In this output you can see the advertisement of the MAC address (84:18:88:84:cf:c0) AND the IP address (10.0.20.12) of a
remote host learned in the EVPN on PE1. It was learned from PE2 as the RD = 193.168.2.2:200.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN and L3VPN: ARP Table

Because the configuration included IRB interfaces, ARP learning is enabled. In the output, the host 10.0.20.12 MAC address
is learned in both the EVPN table, and the L3VPN table. This output illustrates the L3 integration between the EVPN and the
E
L3 VPN service.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Routes: Type 2: Default Gateways

This slide shows an advertisement of an IRB interface with the evpn-default-gateway extended community attached.
This was accomplished by removing the manual MAC address configuration on the IRB interface on PE2. This results in the
E
IRB being advertised with is own unique MAC address to all remote PEs. Upon receipt of this route, it will add the MAC
address as a peer-gateway-macs entry.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Ethernet VPN: Peer-Gateway-MACS

This slide shows the MAC addresses installed as a distributed default gateway. From the previous slide this is because of the
different MAC address learned with the evpn-default-gateway extended community attached.
E
Just a reminder the recommended option is to manually synchronize your default gateway by configuring identical IP/MAC
US
address on the IRBs for the PEs used as default gateway, and use the default-gateway do-not-advertise option,
in the EVI.
If you use this method the output of the show evpn peer-gateway-macs (VLAN based service interface) or show
bridge peer-gateway-macs (VLAN aware bundle service interface) command is empty, and that is what is expected in
this case.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Routes: Type 3: Inclusive Multicast

This shows one way to view the type 3 route used to advertise the label that will be used for the ingress replication of BUM
traffic between PEs. In this example, the advertisement comes from PE1 (RD = 193.168.2.1:200), and its PMSI label
E
(301024). This label will be used as the inner label if PE2 (or PE3) needs to send BUM traffic towards PE1.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
EVPN Routes: Type 4: Ethernet Segment

The slide shows one way to view the type 4 routes used to elect the designated forwarder on an ESI. As shown, the
es-import-target extended community is dynamically attached, and its value is derived from the ESI (only 6 bytes are
E
used).
US
Only the PEs involved in the ESI will accept this route, as they are the only one with the correct (hidden, dynamically created)
import policy that matches this es-import-target:1-2-3-4-5-6 value.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Layer 3 VPN Routes: Host Routes

The Layer 3 integration allows the L3 VPN service to learn routes through the MAC/IP advertisements. Here you can see both
the subnet (10.0.20.0/24), and the host routes (10.0.20.12/32) in the L3VPN.inet.0 route table.
E
The 10.0.20.1/32 address is the default gateway address from the IRB interfaces. It shows a local entry (preferred), and a
US
EVPN learned entry for PE2. PE2 did not have the identical MAC/IP combination and therefore was advertised and accepted
as a possible route towards 10.0.20.1.
Notice that the 10.0.0.20.12 route has many next hops; this is because of the aliasing feature that allows forwarding to both
PEs.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Ethernet VPN: MAC Addresses

To have a look at the MAC addresses, you can use multiple commands:
E
• show evpn database;

• show evpn mac-table (VLAN based service interface);
US
• show bridge mac-table bridge-domain VLAN instance EVI_Name (VLAN bundle aware
service interface).
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Ethernet VPN: MPLS Forwarding Table

The show route table mpls.0 command shows both ingress and egress routes for specific unicast destinations (MAC
Egress /Ingress MAC), and for sending and receiving BUM traffic (Egress-IM / Ingress-IM).
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Ethernet VPN: Command Options

To look at specific EVPN information, many of the show route type of commands have the option for evpn-? filtering.
This option can be very useful if you have to find a known specific MAC address route in a EVI with 100.000 MAC addresses
E
known.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
We Discussed:
• EVPN operations;
E
• EVPN configuration; and

• EVPN troubleshooting.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Review Questions
1. 
E
2. 
US
3. 
4. .
AL
RN
TE
IN

Junos Layer 2 VPNs
RE
1.
The purpose of an ESI is to identify a set of links connected to a site (CE). This is essential for the support of active/active and active/
standby multihoming. The reserved values are 0x00:00:00:00:00:00:00:00:00:00 for single-homed interfaces, and
A
0xFF:FF:FF:FF:FF:FF:FF:FF:FF:FF for max-ESI.
2.
SH
The aliasing feature allows optimal load balancing to all-active PEs for a given ESI regardless if the MAC/IP information was learned
from one or both PEs.
3.
The inclusive multicast Ethernet tag route (type 3) is needed to provide label information to forward BUM traffic, using ingress
T
replication, towards a single-homed CE from a remote PE.
NO
4.
To advertise MAC and IP addresses the EVI needs to have Layer 3 interface added to its configuration. In Junos these are the IRB
interfaces. Only then can ARP learning take place, and will IP addresses be learned.
DO
—
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Lab: Ethernet VPN

E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
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
following sites:
E
• Pathfinder: An information experience hub that provides centralized product details.

US
• 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 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN
www.juniper.net
A RE
SH
Junos Layer 2 VPNs
T
NO
Appendix A: Interprovider Backbones for Layer 2 VPNs
DO
—
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
We Will Discuss:
• Junos operating system support for carrier of carriers;
E
• Junos support for interprovider virtual private networks (VPNs);

• Configuration of BGP-based L2VPNs for interprovider Option C;
US
• Multisegment pseudowires; and

• Configuration of multisegment pseudowires for interprovider.
AL
RN
TE
IN
Appendix A–2 • Interprovider Backbones for Layer 2 VPNs www.juniper.net

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Hierarchical VPN Models

E
US
AL
RN
TE
IN
www.juniper.net Interprovider Backbones for Layer 2 VPNs • Appendix A–3

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Carrier-of-Carriers Model
This model allows service provider A to offer a IP backbone service to the customer, another service provider. Assume the
customer is a new service provider that has a point of presence (POP) in a few sparse locations with no backbone network to
E
interconnect those POPs. The customer (the new service provider) can purchase the carrier-of-carriers service from the
service provider A to interconnect its sites making the customer network appear as a single autonomous system (AS) without
US
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, BGP virtual private LAN service (VPLS), or BGP Ethernet VPN to extend
between autonomous system or service providers.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
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
provider A will be providing VPN service to its own customers. The details of this model are described in subsequent slides.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Option A
RFC 4364 describes three methods of providing multiple AS backbones. Option A is the least scalable of the options. This
option requires that the autonomous system boundary routers (ASBRs) maintain separate VPN routing and forwarding tables
E
and store all of the associated L2VPN routes for every one of its customers. For VPLS deployments it also means that the
ASBR routers need to learn MAC addresses (data plane). So it creates scalability bottlenecks for both control plane (L2VPN
US
routes) and data plane (MAC addresses) resources. Although this option is supported by the Junos OS, it is not a
recommended solution.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Option B
With option B, the ASBRs does not need to maintain separate VPN instances for each VPN. However, the ASBR will still have
to keep L2VPN routes in a single routing table, bgp.l2vpn.0 for L2VPN routes. Through an EBGP session between one
E
another, the ASBRs will then exchange L2VPN routes as label routes. The EBGP advertised labels are used stitch together
the label-switched paths (LSPs) that terminate between provider edge (PE) and ASBR. For VPLS deployments there is also no
US
need anymore to learn MAC addresses on the ASBR routers.

AL
RN
TE
IN

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

E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Service Provider Routers

The service provider’s P routers only maintain routes internal to the provider’s network (P-routes). The PE routers maintain
both P-routes and customer internal routes (C-routes). The C-routes are housed in customer-specific VRF tables on the PE
E
routers and normally consist of at least the customer’s /32 loopback addresses. The provider’s PE routers do not carry the
customer’s external routes (C-external), which is a critical aspect of the overall scalability of this model.
US
Customer Routers
The customer’s routers must maintain both C-internal and C-external routes. External routes are those learned from the
customer’s downstream subscribers and are now stored in site-specific VRF tables. Unlike the previous examples, the
AL
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
networks.
TE
Continued on next page.

IN

Junos Layer 2 VPNs
Three-Level Label Stack Required
RE
The presence of VPN-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:
1. The bottom label is the VPN label assigned using MP-BGP. This label does not change as the packet is
forwarded.
A
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,
T
the Junos OS currently supports MP-BGP for this purpose.
RFC 3107, Carrying Label Information in BGP-4, specifies labeled routes. Labeled route advertisements use SAFI 4 and
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.
DO
—
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
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
LSP signaling protocol need not be the same; the customer can use LDP while the provider uses RSVP.
E
MP-BGP Signaling Between Provider PE and Customer CE Routers

US
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
IBGP/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
establish IBGP (same AS numbers) sessions or multihop EBGP (different AS numbers) sessions through the provider’s
RN
backbone for the purposes of exchanging external routes. In this case, the routes are exchanged using MP-BGP and are
labeled VPN routes.
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
TE
hops to their clients.

IN

Junos Layer 2 VPNs
Signaling: Step by Step
RE
The details of the signaling exchanges shown on the slide are:
1. The IGP at customer Site 2 exchanges internal reachability with CE-2. L2VPN 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
A
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).
SH
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.
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).
T
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.
NO
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).
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.
DO
6. PE-4 connects via L2VPN to one of its subscribers. The circuit information can now be advertised to other
members of this L2VPN.
7. The L2VPN route information is now advertised to PE-1 using the MP-EBGP session established at Step 5. This
NLRI advertisement includes the VPN label that PE-4 expects to receive for routes associated with this
particular L2VPN instance. —
8. PE-1 can bring the Layer 2 connection up after learning the L2VPN route information from PE4.
.
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
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
result is the need for a three-level label stack.
E
Forwarding: Step by Step

US
The details of the forwarding operation shown on the slide are:

1. A frame arrives at PE1 that is meant for the subscriber L2VPN circuit that terminates on PE4
2. PE-1 pushes two labels onto the frame: the inner label is the L2VPN label assigned by PE-4, and a second label
AL
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 frame with the LSP between PE and CE routers.
3. CE-1 receives the labeled frame and swaps the top label.
RN
4. PE-2 receives the labeled frame 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 frame with only two labels.
6. PE-3 also performs a swap on the top label before forwarding the frame to CE-2.
TE

IN

Junos Layer 2 VPNs
Forwarding: Step by Step (contd.)
RE
7. Being the penultimate router for the LSP to PE-4, CE-2 pops the label stack and sends the resulting VRF-labeled
frame to PE-4.
8. PE-4 pops the L2VPN label and consults the corresponding VPN table to perform a lookup on the now unlabeled
A
frame.
9. The native frame is forwarded out PE-4’s L2VPN interface towards the subscriber to which it is addressed.
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
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
captures relating to this slide.
E
The provider’s network is assigned AS 65512. It already has established an LSP between PE-2 and PE-3 using RSVP. The PE
US
routers have a L2VPN instance configured, along with the necessary L2VPN 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 (L2VPN) 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 subscriber L2VPN route 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 2 VPNs
A RE
SH
T
NO
DO
—
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
to CE-1, and family inet-vpn is configured for the multihop MP-EBGP session to PE-4.
E
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 2 VPNs
A RE
SH
T
NO
DO
—
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
shown). The MP-IBGP session to PE-1 has the labeled-unicast family configured. This configuration is needed so that
E
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
lab@ce-1# show policy-options

policy-statement internals {
term 1 {
from protocol [ ospf direct ];
RN
then accept;
}
term 3 {
then reject;
}
TE
}.
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Carrier-of-Carriers VPNs Operation: VPN Routes

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

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
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
table. This copying is the result of the resolve-vpn option on PE-1 and is critical to the operation of this network.
US
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 2 VPNs
A RE
SH
T
NO
DO
—
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, frames received with a label of 300288 have
their top label swapped. PE-2 pushes a new label (obtained from RSVP or LDP) onto the stack, creating a three-level label
E
stack (VPN-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
mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

AL
+ = Active Route, - = Last Active, * = Both
...
299904 *[VPN/170] 19:07:27
RN
> 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

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
penultimate router for this LSP.
IN

Junos Layer 2 VPNs
RE
A
SH
T
NO
DO
—
LY
ON
Carrier-of-Carriers L2VPN Status

This slide shows how to verify if the carrier-of-carriers L2VPN connection is up and running.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Interprovider VPN Option C

E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Service Provider Routers

The service provider routers (P, PE, ASBR) have different needs as to which routes they need to learn and maintain:
E
• P routers only maintain the internal routes from its own AS (AS-internal);
• PE routers maintain the internal routes from its own AS (AS-internal), the loopback address from the other AS
US
PEs (AS-external), and the L2VPN routes; and

• ASBR routers maintain the internal routes from its own AS (AS-internal), and the loopback addresses from the
other AS PEs (AS-external). It does not maintain L2VPN routes which makes this solution scalable.
AL
ASBR Routers
The ASBR routers interconnect the providers. To ensure that the L2VPN 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 L2VPNs they only care about their own circuit
information and their local routing (if used at all).
TE

IN

Junos Layer 2 VPNs
Three-Level Label Stack Required
RE
The presence of L2VPN 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:
1. The bottom label is the L2VPN label assigned using multihop MP-EBGP. This label does not change as the
A
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
T
currently supports MP-BGP for this purpose.
RFC 3107, Carrying Label Information in BGP-4, specifies labeled routes. Labeled route advertisements use SAFI 4 and differ
NO
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.
DO
—
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
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,
RSVP, or both can be used.
E
MP-EBGP Signaling Between Provider ASBR Routers

US
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
PEs 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
an IBGP session to the local PE routers. This ensures that the PE routers learn the label towards the remote PE’s loopback
RN
addresses.
MP-EBGP Signaling Between the PE Routers

To actually exchange the L2VPN route information a multihop EBGP session is established between the relevant PEs. In
TE
small deployments this can be done by full mesh PE peerings.

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—
IN
unchanged—the third party next hops to their clients.

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Interprovider L2VPNs: Data Flow

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

US

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

Junos Layer 2 VPNs
Forwarding: Step by Step (contd.)
RE
6. Being the penultimate router for the LDP LSP to PE2, P2 pops the label stack and sends the resulting
L2VPN-labeled frame to PE2.
7. PE2 pops the L2VPN label and consults the corresponding table to forward the traffic out of the correct
A
CE-facing interface.
8. The native frame is forwarded out PE2’s L2VPN interface towards the subscriber to which it is addressed.
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Interprovider L2VPN Between AS65201 and AS65202

E
Within each provider’s network the IGP and LDP protocols already have been configured so that within each AS there is an
US
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 PEs loopback prefixes are advertised to the other provider’s ASBR.
I-BGP Signaling Between ASBR and Local PE Routers

To distribute the learned remote PE’s loopback addresses, the ASBR peers with the local PEs.
RN
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 L2VPN NLRI is advertised as a labeled-VPN route by PE2 to PE1 using this MP-EBGP session.
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
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
ASBR1, and family l2vpn signaling is configured for the multihop MP-EBGP session to PE2.
E
US
resolve-vpn
The resolve-vpn option causes PE1 to copy the labeled-unicast routes it receives from ASBR1 into inet.3, which
allows L2VPN 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 L2VPN routing-instance configuration that is identical as used for single provider BGP L2VPNs.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
ASBR1 Configuration
This slide shows the key aspects of ASBR1’s configuration. Family labeled-unicast is configured for its MP-IBGP
session to ASBR1, and for its MP-EBGP session to ASBR2.
E
Notice the export policy called internals that contains the local PE’s loopback addresses.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Layer 2 VPN Routes

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

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
MP-IBGP 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
table. This copying is the result of the resolve-vpn option on PE1 and is critical to the operation of this network. Normally,
US
L2VPN 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 indicates that a multinetwork LSP between PE1 and PE2 exists.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Interprovider L2VPN Operation: PE2

This slide shows the L2VPN instance’s mpls.0 table that exists on PE2. Here, frames received from the interface 
ge-1/0/6.620 (CE-A1) are sent towards ASBR1. The frame will have 3 labels pushed on PE2:
E
• Label 800001 (L2VPN label received from PE2 across MP-EBGP session);
US
• Label 300224 (Label received from the labeled unicast MP-IBGP session with ASBR1); and
• 299792 = Top label (Label received from P1 router using the LDP protocol).
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
L2VPN Status
This slide shows how to verify if the interprovider L2VPN connection is up and running.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Multisegment Pseudowires
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Single Segment Pseudowire

A pseudowire setup directly between two PE devices. This is the typical deployment within a provider’s network. However
there are situations where this is not possible or desirable.
E
• Between different providers or administrative domains

US
• Different IGP domains

Security and/or scalability reasons might limit the reachability between the PEs involved in the pseudowire. To overcome this
limitation multisegment pseudowires were developed. For more details on the requirements for multisegment pseudowires
have a look at RFC5254.
AL
Multisegment Pseudowire (RFC 6073)

Multisegment pseudowires are defined in RFC6073. A multisegment pseudowire allows multiple segments to be switched
together into a single end-to-end pseudowire. The big advantage of multisegment pseudowires is that they don’t require
RN
end-to-end reachability from PE to PE, but only visibility to the end of the individual segment. This allows greater scalability
and path control across administrative or interprovider boundaries.
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Multisegment Pseudowire Terminology

This slide provides an overview of the terminology of multisegment pseudowires as described in RFC6073
E
• Single segment pseudowire (SS-PW): A pseudowire setup unchanged between two PEs.
• Multisegment pseudowire (MS-PW): A set of two or more pseudowire segments that function as a single
US
point-to-point pseudowire. Each end must terminate on the T-PE. Up to 254 segments can be combined into a
multisegment pseudowire.
• Pseudowire terminating provider edge (T-PE): A PE where the customer facing interface is connected. There
must be a T-PE at the begin and end of the multisegment pseudowire.
AL
• Pseudowire switching provider edge (S-PE): A PE capable of switching the control and data plane of the
pseudowire segments into a mutlisegment pseudowire. The S-PE allow for exact path control across the
administrative domains, or across providers. By limiting the S-PEs, it also offers greater scalability.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Junos Multisegment Pseudowires

Junos supports FEC 129 BGP autodiscovery as a mechanism for dynamically creating multisegment pseudowires. The BGP
sessions are needed between the T-PE and the S-PE for each segment, but not end-to-end. Route reflection is supported by
E
configuring the S-PE as the route reflectors. The multisegment pseudowire autodiscovery uses a new BGP address family
(AFI 25, SAFI 6).
US
Targeted LDP Sessions

Once the BGP autodiscovery has identified the S/T-PE involved in the pseudowire path, targeted LDP sessions will be
established from one side of the multisegment pseudowire (active source T-PE) to the other end (passive target T-PE) of the
AL
multisegment pseudowire. The use of an active and passive T-PE ensures that the same set of S-PEs are used in both
directions for the setup of the multisegment pseudowires. The active T-PE is the one with the highest source attachment
individual identifier (SAII) which is determined by configuration.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Provider Networks
The provider network needs to be MPLS-enabled so that end-to-end LSPs exist between the different PEs.
E
E-BGP Multihop Peering Between S-PE Routers

US
The S-PEs must have BGP sessions between them. In an interprovider scenario this means multihop E-BGP sessions using
family l2vpn autodiscovery-mspw to discover the path between the two T-PEs.
I-BGP Peering Between S-PE and Local T-PEs

AL
.The S-PE and it’s local T-PE need to have a I-BGP session using family l2vpn autodiscovery-mspw.
Route Reflectors
RN
Route reflection is supported by using the S-PEs as route reflectors.

TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Carrier-of-Carriers VPN Data Forwarding

This slide uses steps to describe the forwarding operations between T-PE1 and T-PE2 in an interprovider multisegment
pseudowire L2VPN application. The result is the need for only a two-level label stack.
E

US

1. A frame addressed to CE-A2 arrives at T-PE1.
2. T-PE1 pushes two labels onto the L2VPN frame, the inner label is the multisegment pseudowire label (segment
AL
1 = 2001), and the outer label is the LDP LSP towards S-PE1 (1020).
3. The P router in AS100 provides PHP for the LDP LSP and therefore pops the top label.
4. The S-PE1 router provides the segment switching function by swapping the segment 1 label (2001) for the
RN
segment 2 label (2002).

5. The S-PE2 router repeats the segment switching function by swapping the segment 2 label (2002) for the
segment 3 label (2003). To get the MPLS packet across the AS200 P routers, it also pushes a new top label
(1010) learned from the LDP LSP.
TE
6. The P router in AS200 provides PHP for the LDP LSP and therefore pops the top label.
7. The T-PE2 router pops the segment 3 label (2003) and forwards towards CE-A2 device.
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Interprovider Multisegment Pseudowire L2VPN Example

E
The site 1 network uses AS65201 and has LDP LSP reachability between PEs. The site 2 network uses AS65202 and also
US
has LDP LSP reachability between its PEs. There is no IGP reachability between the two provider networks. LDP is enabled
between the two provider networks to enable targeted LDP sessions. To make loopbacks reachable between S-PE1 and
S-PE1 static routes are used in this example.
FEC129 BGP autodiscovery for multisegment pseudowires (family l2vpn autodiscovery-mspw) is configured on
the sessions between the T-PE and S-PE (I-BGP), and between the S-PEs (multihop E-BGP).
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
T-PE1 Configuration
This slide shows an example of a T-PE configuration. The family l2vpn autodiscovery-mspw is configured on the
I-BGP session toward the local S-PE router.
E
The routing instance is configured for FEC129 BGP autodiscovery as for a single segment pseudowire with one important
US
difference. The format of the attachment identifier is different, as a type 2 Attachment circuit identifier (AII) is required for
multisegment pseudowires. The format of the type 2 AII is:
• Global_ID: global identification, which is usually the AS number
• Prefix; IPv4 address, which is usually the router ID
AL
• AC_ID; local attachment circuit, which is a user configurable value

In the example above the source-attachment identifier is 200:200:1 on this T-PE1, and the target attachment identifier is
200:200:2 for T-PE2. This means that in this example T-PE2 will be the active T-PE for the setup of the targeted LDP sessions
RN
as it has the higher attachment circuit identifier.

The use of the type AII, together with unique PE loopback addressing should allow for unique multisegment pseudowires
across interproviders.
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
S-PE1 Configuration
This slide shows an example of a S-PE configuration. The family l2vpn autodiscovery-mspw is configured on the
I-BGP session toward the local T-PE router, and on the multihop E-BGP session towards the other providers S-PE.
E
The static route is needed to be able to setup the E-BGP session to the loopback address of the remote S-PE.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Interprovider Multisegment Pseudowires Operation: L2VPN Routes

This slide shows the FEC 129 BGP autodiscovery multisegment pseudowire routes learned by the S-PE1 router. It has
learned two routes, one for each segment it needs to switch between.
E
• Segment 1 (T-PE1 ,<--> S-PE1); it learned the route from the local T-PE1 (193.168.12.2)
US
193:168.12.2:200:200:0.0.0.200:1 AD2;and
• Segment 2 (S-PE1 <--> S-PE2); it learned the route from the remote S-PE2 (193.168.2.2)
193.168.2.2:200:200:0.0.0.200:2 AD2.
The format of the FEC 129 BGP autodiscovery multisegment pseudowire routes is:
AL
• Router ID; and

• Source attachment identifier (SAII).
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Interprovider Multisegment Pseudowires: Label Operation

This slide shows the mpls.0 table on the T-PE1 end of the multisegment pseudowire created. It shows that traffic arriving on
the CE facing interface ge-1/0/6.620 will have two labels pushed onto it:
E
• The inner label is 299952 as is learned via the I-BGP session using the family l2vpn
US
autodiscovery-mspw, and identifies the first segment of the multisegment pseudowire (T-PE1 <--> S-PE1).
• The top label is 299776 which identifies the LDP LSP towards the loopback of S-PE1.
The second output is from the mpls.0 table on S-PE1 and shows the segment switching operation between segment 1
(T-PE1 <--> S-PE1) and the next segment 2 (S-PE1 <--> S-PE2) of the multisegment pseudowire. Note the top label was
AL
already removed by the P router.

• Label 299952 (segment 1) is swapped to label 300256 (segment 2). These labels were exchanged across the
BGP session using family l2vpn autodiscovery-mspw.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Interprovider Multisegment Pseudowires: L2VPN Status

To check the end-to-end status of the multisegment pseudowire use the show l2vpn connections command on one of
the T-PE routers.
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
We Discussed:
• Junos operating system support for carrier of carriers;
E
• Junos support for interprovider VPNs;

• Configuration of BGP-based L2VPNs for interprovider Option C;
US
• Multisegment pseudowires; and

• Configuration of multisegment pseudowires for interprovider.
.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Review Questions
1.
E
2.
US
3.
AL
.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Lab: Interprovider L2VPNs

E
.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
RE
1.
In a carrier-of-carrier application the customer routers maintain both customer internal and external routes (non-VPN). In an
interprovider VPN, except for the ASBRs connected to VPN sites, the customer routers maintain customer internal routes only
A
2.
The three interprovider VPN options are A (back to back VPNs), option B (single VPN table on ASBRs), and option C (greatest
SH
scalability, no VPN routes on ASBRs).
3.
The T-PE router is at the begin and end of a multisegment pseudowire and connects directly to the CE device. The S-PE router
switches between different segments to let the multisegment pseudowire function as a single end-to-end pseudowire. S-PEs do not
T
have connections to CE devices.
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN

A RE
SH
Junos Layer 2 VPNs
T
NO
Appendix B: Circuit Cross-Connects
DO
—
LY
ON
E
US
AL
RN
TE
IN
Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
We Will Discuss:
• Configuring CCC Layer 2 switching;
E
• Configuring CCC MPLS interface tunneling; and

• Configuring CCC MPLS LSP stitching.
US
AL
RN
TE
IN
Appendix B–2 • Circuit Cross-Connects www.juniper.net

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Circuit Cross-Connect
E
US
AL
RN
TE
IN
www.juniper.net Circuit Cross-Connects • Appendix B–3

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Connects Two Layer 2 Sites

Circuit cross-connect (CCC) allows you to configure transparent connections between two sites, where the circuit can be a
Frame Relay data-link connection identifier (DLCI), an ATM VC, a Point-to-Point Protocol (PPP) interface, a Cisco High-Level
E
Data Link Control (HDLC) interface, or an MPLS LSP. Using CCC, packets from the source circuit are delivered to the
destination circuit with, at most, the Layer 2 address being changed. No other processing—such as header checksums,
US
time-to-live (TTL) decrementing, or protocol processing—is done.
Cross-Connect Types
CCC circuits fall into two categories: logical interfaces, which include DLCIs, VCs, and PPP and Cisco HDLC interfaces; and
AL
LSPs. The two circuit categories provide the following three types of cross-connect:
• Layer 2 switching: Cross-connects between logical interfaces provide what is essentially Layer 2 switching. The
interfaces that you connect must be of the same type. This type of switching can also be used to direct traffic
to/from P2MP LSPs.
RN
• MPLS tunneling: Cross-connects between interfaces and LSPs allow you to connect two distant interface
circuits of the same type by creating MPLS tunnels that use LSPs as the conduit.
• LSP stitching: Cross-connects between LSPs provide a way to stitch together two LSPs, including paths that fall
TE
in two different traffic engineering database (TED) areas.

IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
CCC Layer 2 Switching

One of the features of CCC is the ability to enable local Layer 2 switching on Junos devices. It supports switching between
similar Layer 2 interfaces, as well as translational cross-connects (TCC) between different type of Layer 2 interfaces. Frames
E
arriving at one interface can be sent out another interface on the same device.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Configuration Example
In the configuration example above you see the configuration that makes traffic arriving at logical interface ge-0/0/1.0, exit
logical interface ge-0/0/2.0 and vice versa (bidirectional). In this case the Layer 2 switching is between two similar
E
interfaces that use Ethernet VLANs with the same VLAN ID (610).
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Interface Tunneling
CCC requires that you have 2 dedicated LSPs to accommodate transmit and receive traffic for every CCC connection
configuration. This is because CCC does not support label stacking like Layer 2 circuits, Layer 2 VPNs and VPLS. This is one
E
of the primary reasons that CCC is not a scalable solution for larger networks. CCC allows you to connect two ATM, Frame
Relay, PPP, Ethernet, or Cisco HDLC access links using an MPLS tunnel. Layer 2 packets are essentially bridged from end to
US
end in this configuration. In the figure on the slide, MPLS LSPs connect two Ethernet networks across an IP cloud. The
Ethernet interface on the R1 expects a VLAN value of 610 (on whatever path is enabled on that interface). R3 will also
transmit and receive using VLAN 610 (on whatever path is enabled on the output interface). The IP backbone between the
two routers has two LSPs—one in each direction—that connect the two PE routers. When the packets come in to R1 destined
to the network attached to R3, R1 places an MPLS header on the packets and transmit them down the LSP. Once the
AL
packets reaches R3, the MPLS headers are stripped off, and the packet are forwarded out the CE facing interface.
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
The configuration examples on the slide show that the receive LSP on one router is the transmit LSP on the other router. The
names referenced are the names of the transmit or receive LSPs displayed when you issue the show mpls lsp command.
E
To configure LSP tunnel cross-connects, you must also configure the CCC encapsulation on the ingress and egress router’s
US
CE facing interfaces. Below is an example from R1:

[edit]
user@R1# show interfaces ge-1/0/4
vlan-tagging;
encapsulation vlan-ccc;
AL
unit 610 {
encapsulation vlan-ccc;
vlan-id 610;
}
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
LSP Stitching
Another use of CCC is to stitch two separate label-switched paths (LSPs) together into one seamless LSP end-to-end.
E
The stitching is unidirectional only, so you must stitch for each direction separately, which requires 2 different connections if
you want bidirectional traffic flows.
US
Only dynamic RSVPs are supported for LSP stitching.

AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
The configuration example on the slide shows two distinct connections. One in the direction R1 towards R3, which stitches
the LSP-1 and LSP-2 together. Another one in the opposite direction R3 towards R1, which stitches the LSP-3 and LSP-4
E
together. Make sure you understand the direction of the stitched LSPs as it is important to configure the correct
transmit-lsp and receive-lsp.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
CCC Drawbacks
The following list details some of the drawbacks of CCC:
E
• CE and PE router configuration can be complex, especially during adds, moves, and changes. The customer
must coordinate with the service provider.
US
• Each data-link connection identifier (DLCI)/PVC requires a dedicated set of MPLS LSPs. There can be no sharing
of the LSP when using CCC.
• CCC as a Layer 2 VPN solution is only appropriate for small numbers of individual private connections.
Interface types must be the same at all CE device locations. For instance, if Frame Relay is used at one VPN site then Frame
AL
Relay must be used at all other sites. However, the Junos OS has a feature called translational cross-connect (TCC) that can
be used when there are different interfaces types at the CE locations
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
We Discussed:
• Configuring CCC Layer 2 switching;
E
• Configuring CCC MPLS interface tunneling; and

• Configuring CCC MPLS LSP stitching.
US
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Review Questions
1.
E
2.
US
3.
AL
RN
TE
IN

Junos Layer 2 VPNs
A RE
SH
T
NO
DO
—
LY
ON
Lab: Circuit Cross-Connect

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

Junos Layer 2 VPNs
RE
1.
The requirement for Layer 2 switching are to configure the interfaces with the appropriate Layer 2 encapsulation, enable protocols
mpls, and configure the connection between the two interfaces.
A
2.
There are 2 LSPs required as CCC doesn’t support label stacking so for each virtual circuit that you want to transport across the core
SH
you’ll need a separate transmit and a receive LSP.
3.
The command to display the operational status of a CCC circuit is show connections.
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN

Junos Layer 2 VPNs
RE
A
SH
T
NO
DO
—
LY
ON
E
US
AL
RN
TE
IN

Acronym List
RE
AAL5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATM Adaptation Layer 5
A
AFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Family Identifier
ANSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .American National Standards Institute
SH
ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Address Resolution Protocol
AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .autonomous system
ASBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .autonomous system boundary routers
ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asynchronous Transfer Mode
BECN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .backward explicit congestion notification
T
BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Border Gateway Protocol
BUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . broadcast, unknown unicast, and multicast
NO
CapEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .capital expenses
CCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . circuit cross-connect
CE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . customer edge
CIR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .committed information rate
Cisco HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cisco High-Level Data Link Control
CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .command-line interface
DO
CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . class-of-service
CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cyclic redundancy check
CSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Constrained Shortest Path First
CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . circuit status vector
DCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .data communication equipment
—
DE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Discard Eligibility Bit
DF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Designated Forwarder
DLCI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .data-link connection identifier
ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ethernet Ring Protection
LY
ES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Ethernet segment
ESI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Ethernet segment identifier
EVI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EVPN Instance
FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . forwarding equivalence class
ON
FECN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . forward explicit congestion notification

FPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Flexible PIC Concentrator
GCRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Generic Cell Rate Algorithm
GRE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .generic routing encapsulation
GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .graphical user interface
E
HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . High-Level Data Link Control

IEEE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Institute of Electrical and Electronics Engineers
US
IGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . interior gateway protocol

InARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Inverse Address Resolution Protocol
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP version 4
ITU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .International Telecommunication Union
JNCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juniper Networks Certification Program
L2VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Layer 2 VPN
AL
LAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . link aggregation group

LB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . load-balancing policy
LoL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . loss of light
LSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .label-switched interface
RN
LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . label switched path

MAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . media access control
MP-BGP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multi-protocol Border Gateway Protocol
MTU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . maximum transmission unit
TE
NLRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . network layer reachability information

OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Shortest Path First
P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . provider
PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . protocol data unit
IN
PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . provider edge
www.juniper.net Acronym List • ACR–1

PFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packet Forwarding Engine
RE
PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .penultimate-hop popping
PLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . packet loss priority
PMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Provider Multicast Service Interface
POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . point of presence
PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Point-to-Point Protocol
A
PVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . permanent virtual connection
RDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . remote defect indication
SH
RE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Engine
RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . random early detection
RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ring protection link
SAFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . subsequent address family identifier
SAII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . source attachment individual identifier
T
SLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .service-level agreement
SNAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . subnetwork attachment point
NO
TCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . translational cross-connect
TED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . traffic engineering database
TPID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tag Protocol Identifier
TTL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . time-to-live
VC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Chassis
DO
VCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Chassis identifier
VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .virtual LAN
VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .virtual private LAN service
VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual private network
VR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . virtual router
VRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VPN route and forwarding
—
WRR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . weighted round-robin
LY
ON
E
US
AL
RN
TE
IN
ACR–2 • Acronym List www.juniper.net

JL2V 15.a SG V2

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

JL2V 15.a SG V2

Uploaded by

Copyright:

Available Formats

RE

Worldwide Education Services

1133 Innovation Way

Course Number: EDU-JUN-JL2V

Appendix A: Interprovider Backbones for Layer 2 VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Interprovider VPN Option C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-23

Appendix B: Circuit Cross-Connects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

Circuit Cross-Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3

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

www.juniper.net Contents • iii

• Junos MPLS Fundamentals (JMF) course or equivalent.

• Define the term virtual private network.

• Configure an LDP Layer 2 circuit.

• Configure a FEC 129 BGP autodiscovery Layer 2 VPN.

www.juniper.net Course Overview • v

vi • Course Overview www.juniper.net

www.juniper.net Course Agenda • vii

Input Text Versus Output Text

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxp0,

Configuration > History.

Defined and Undefined Syntax Variables

Style Description Usage Example

CLI Variable Text where variable value is already policy my-peers

value the user must input filename in the Filename field.

viii • Document Conventions www.juniper.net

www.juniper.net Additional Information • ix

x • Additional Information www.juniper.net

• The signaling process of VPLS;

Chapter 6–2 • Virtual Private LAN Service www.juniper.net

Layer 2 MPLS VPNs Versus VPLS

www.juniper.net Virtual Private LAN Service • Chapter 6–3

Layer 2 VPNs Are Point to Point

Mapping Local Circuits to Remote Sites

Chapter 6–4 • Virtual Private LAN Service www.juniper.net

Appearing to Be a Single LAN Segment

No Need to Map Local Circuit to Remote Sites

www.juniper.net Virtual Private LAN Service • Chapter 6–5

Chapter 6–6 • Virtual Private LAN Service www.juniper.net

www.juniper.net Virtual Private LAN Service • Chapter 6–7

Customer Edge Devices

Provider Edge Routers

Chapter 6–8 • Virtual Private LAN Service www.juniper.net

BGP VPLS Control Plane

www.juniper.net Virtual Private LAN Service • Chapter 6–9

Provisioning the Local CE Device

for the expansion of VPN membership without reconfiguring existing sites.

Chapter 6–10 • Virtual Private LAN Service www.juniper.net

VPLS Route and Forwarding Tables

• The local site ID;

• The site’s Layer 2 encapsulation;

from the LSPs connecting the PE routers.

www.juniper.net Virtual Private LAN Service • Chapter 6–11

Provisioning the Core

Chapter 6–12 • Virtual Private LAN Service www.juniper.net

VPLS Label Distribution

www.juniper.net Virtual Private LAN Service • Chapter 6–13

Provisioning the PE Router

• Specification of route targets or VRF policy.

Chapter 6–14 • Virtual Private LAN Service www.juniper.net

www.juniper.net Virtual Private LAN Service • Chapter 6–15

Chapter 6–16 • Virtual Private LAN Service www.juniper.net

Layer 2 Information Extended Community