Junos® OS Layer 2 VPNs and VPLS User Guide for …...ConfiguringClassofServiceforVPNs|125 VPNsandClassofService|125 RewritingClassofServiceMarkersandVPNs|125 PingingVPNs|127 PingingVPNs,VPLS,andLayer2Circuits|127

Junos® OS

Layer 2 VPNs and VPLS User Guide forRouting Devices

Published

2019-12-10

Juniper Networks, Inc.1133 Innovation WaySunnyvale, California 94089USA408-745-2000www.juniper.net

Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. inthe United States and other countries. All other trademarks, service marks, registered marks, or registered service marksare the property of their respective owners.

Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the rightto change, modify, transfer, or otherwise revise this publication without notice.

Junos® OS Layer 2 VPNs and VPLS User Guide for Routing Devices19.4R1Copyright © 2019 Juniper Networks, Inc. All rights reserved.

The information in this document is current as of the date on the title page.

YEAR 2000 NOTICE

Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-relatedlimitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.

END USER LICENSE AGREEMENT

The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with)Juniper Networks software. Use of such software is subject to the terms and conditions of the EndUser License Agreement(“EULA”) posted at https://support.juniper.net/support/eula/. By downloading, installing or using such software, youagree to the terms and conditions of that EULA.

ii

https://support.juniper.net/support/eula/

Configuring Interfaces for Carrier-of-Carriers VPNs | 13

Configuring Unicast RPF on VPN Interfaces | 13

Configuring the Route Distinguisher | 14

Configuring Automatic Route Distinguishers | 14

Configuring Virtual-Router Routing Instances in VPNs | 15

Configuring a Routing Protocol Between the Service Provider Routers | 16

Configuring Logical Interfaces Between Participating Routers | 16

Configuring Path MTU Checks for VPN Routing Instances | 17

Enabling Path MTU Checks for a VPN Routing Instance | 18

Assigning an IP Address to the VPN Routing Instance | 18

Distributing Routes in VPNs | 19

Enabling Routing Information Exchange for VPNs | 19

Configuring IBGP Sessions Between PE Routers in VPNs | 19

Configuring Aggregate Labels for VPNs | 21

Configuring a Signaling Protocol and LSPs for VPNs | 22

Using LDP for VPN Signaling | 23

Using RSVP for VPN Signaling | 24

Configuring Policies for the VRF Table on PE Routers in VPNs | 27

Configuring the Route Target | 27

Configuring the Route Origin | 28

Configuring an Import Policy for the PE Router’s VRF Table | 29

Configuring an Export Policy for the PE Router’s VRF Table | 31

Applying Both the VRF Export and the BGP Export Policies | 32

Configuring a VRF Target | 33

Configuring the Route Origin for VPNs | 34

Configuring the Site of Origin Community on CE Router A | 35

Configuring the Community on CE Router A | 36

Applying the Policy Statement on CE Router A | 36

Configuring the Policy on PE Router D | 37

Configuring the Community on PE Router D | 37

Applying the Policy on PE Router D | 38

iv

Distributing VPN Routes with Target Filtering | 41

Configuring BGP Route Target Filtering for VPNs | 41

BGP Route Target Filtering Overview | 42

Configuring BGP Route Target Filtering for VPNs | 42

Example: BGP Route Target Filtering for VPNs | 43

Example: Configuring BGP Route Target Filtering for VPNs | 46

Configure BGP Route Target Filtering on Router PE1 | 46


Configure BGP Route Target Filtering on the Route Reflector | 52


Configuring Static Route Target Filtering for VPNs | 57

Understanding Proxy BGP Route Target Filtering for VPNs | 57

Example: Configuring Proxy BGP Route Target Filtering for VPNs | 58

Example: Configuring an Export Policy for BGP Route Target Filtering for VPNs | 79

Reducing Network Resource Use with Static Route Target Filtering for VPNs | 101

Configuring Forwarding Options for VPNs | 103

Chained Composite Next Hops for VPNs and Layer 2 Circuits | 103

Benefits of chained composite next hops | 104

Example: Configuring Chained Composite Next Hops for Direct PE-PE Connections in VPNs | 104

Configuring Graceful Restart for VPNs | 113

VPN Graceful Restart | 113

Benefit of a VPN graceful restart | 114


Enabling Unicast Reverse-Path Forwarding Check for VPNs | 117

Understanding and Preventing Unknown Unicast Forwarding | 117

Verifying That Unknown Unicast Packets Are Forwarded to a Single Interface | 118

Configuring Unknown Unicast Forwarding (ELS) | 119

Configuring Unknown Unicast Forwarding on EX4300 Switches | 119

Configuring Unknown Unicast Forwarding on EX9200 Switches | 120

Verifying That Unknown Unicast Packets Are Forwarded to a Trunk Interface | 122

Configuring Unknown Unicast Forwarding (CLI Procedure) | 123

v

Tracing Layer 2 VPN Traffic and Operations | 150

Disabling Normal TTL Decrementing for VPNs | 151

Layer 2 VPN Configuration Example | 151

Simple Full-Mesh Layer 2 VPN Overview | 152

Enabling an IGP on the PE Routers | 152

Configuring MPLS LSP Tunnels Between the PE Routers | 153

Configuring IBGP on the PE Routers | 154

Configuring Routing Instances for Layer 2 VPNs on the PE Routers | 156

Configuring CCC Encapsulation on the Interfaces | 159

Configuring VPN Policy on the PE Routers | 160

Layer 2 VPN Configuration Summarized by Router | 163

Summary for Router A (PE Router for Sunnyvale) | 164

Summary for Router B (PE Router for Austin) | 167

Summary for Router C (PE Router for Portland) | 171

Example: Configuring MPLS-Based Layer 2 VPNs | 174

Transmitting Nonstandard BPDUs in Layer 2 VPNs and VPLS | 192

Configuring Layer 2 Interfaces | 195

Configuring CCC Encapsulation for Layer 2 VPNs | 195

Configuring TCC Encapsulation for Layer 2 VPNs and Layer 2 Circuits | 196

Configuring the MTU for Layer 2 Interfaces | 198

Disabling the Control Word for Layer 2 VPNs | 199

Configuring Path Selection for Layer 2 VPNs and VPLS | 201

Understanding BGP Path Selection | 201

Routing Table Path Selection | 203

BGP Table path selection | 205

Effects of Advertising Multiple Paths to a Destination | 206

Enabling BGP Path Selection for Layer 2 VPNs and VPLS | 207

vii

Creating Backup Connections with Redundant Pseudowires | 211

Redundant Pseudowires for Layer 2 Circuits and VPLS | 211

Types of Redundant Pseudowire Configurations | 212

Pseudowire Failure Detection | 213

Configuring Redundant Pseudowires for Layer 2 Circuits and VPLS | 214

Configuring Pseudowire Redundancy on the PE Router | 214

Configuring the Switchover Delay for the Pseudowires | 215

Configuring a Revert Time for the Redundant Pseudowire | 215

Configuring Class of Service for Layer 2 VPNs | 217

Configuring Traffic Policing in Layer 2 VPNs | 217

Monitoring Layer 2 VPNs | 219

Configuring BFD for Layer 2 VPN and VPLS | 220

BFD Support for VCCV for Layer 2 VPNs, Layer 2 Circuits, and VPLS | 222

Configuring BFD for VCCV for Layer 2 VPNs, Layer 2 Circuits, and VPLS | 223

Connectivity Fault Management Support for EVPN and Layer 2 VPN Overview | 224

LImitations of CFM on layer 2 VPN and EVPNs | 225

Configuring a MEP to Generate and Respond to CFM Protocol Messages | 226

Configuring a Maintenance Association End Point (MEP) | 227

Configuring a remote Maintenance Association End Point (MEP) | 229

Configuring Group VPNs3Configuring Group VPNv2 | 235

Group VPNv2 Overview | 235

Group VPNv2 Technology Overview | 235

Understanding Group VPNv2 | 236

Group VPNv2 and Standard IPsec VPN | 237

Understanding the GDOI Protocol | 239

GDOI Protocol and Group VPNv2 | 241

Group VPNv2 Traffic | 242

Group Security Association | 242

Group Controller/Key Server | 242

Group Member | 243

viii

Anti-Replay Protection for Group VPNv2 Traffic | 243

Partial Fail-Open on MX Series Member Routers | 243

Group VPNv2 Implementation Overview | 244

Enabling Group VPNv2 | 245

Registering a Group Member | 246

Rekeying a Group Member (groupkey-push Method) | 246

Rekeying a Group Member (groupkey-pull Method) | 247

Authenticating a Group Member | 248

Fragmenting Group VPNv2 Traffic | 248

Encrypting Group VPNv2 Traffic | 249

Decrypting Group VPNv2 Traffic | 250

Configuring a Routing Instance for Group VPNv2 | 250

Establishing Multiple Groups, Policies, and SAs | 250

Connecting with Multiple Cooperative GC/KSs | 250

Implementing IP Delivery Delay Detection Protocol (Time-Based Anti-ReplayProtection) | 251

Changing Group VPNv2 Configuration | 251

Bypassing Group VPNv2 Configuration | 252

Implementing Partial Fail-open on MX Series Member Routers | 252

Supported GDOI IPsec Parameters | 253

Supported GDOI IKEv1 Parameters | 254

Applying Dynamic Policies | 255

Supporting TOS and DSCP | 256

Interoperability of Group Members | 256

Group VPNv2 Limitations | 256

Configuring Group VPNs in Group VPNv2 on Routing Devices | 258

Group VPN on AMS interfaces | 261

Use Case for Configuring Group VPNv2 | 262

Example: Configuring Group VPNs in Group VPNv2 on Routing Devices | 263

ix

Configuring Public Key Infrastructure4Configuring Digital Certificate Validation | 287

Understanding Digital Certificate Validation | 287

Policy Validation | 287

Policy OIDs Configured on MX Series Devices | 288

No Policy OIDs Configured on MX Series Devices | 288

Path Length Validation | 290

Key Usage | 290

EE Certificates | 291

CA Certificates | 291

Issuer and Subject Distinguished Name Validation | 291

Example: Improving Digital Certificate Validation by Configuring Policy OIDs on an MX SeriesDevice | 293

Configuring a Device for Certificate Chains | 299

Understanding Certificate Chains | 299

Multilevel Hierarchy for Certificate Authentication | 299

Example: Configuring a Device for Peer Certificate Chain Validation | 302

Managing Certificate Revocation | 315

Understanding Online Certificate Status Protocol and Certificate Revocation Lists | 315

Comparison of Online Certificate Status Protocol and Certificate Revocation List | 317

Example: Improving Security by Configuring OCSP for Certificate Revocation Status | 317

Configuring Layer 2 Circuits5Overview | 339

Layer 2 Circuit Overview | 339

Layer 2 Circuits Configuration Overview | 341

Configuring Static Layer 2 Circuits | 341

Configuring Local Interface Switching in Layer 2 Circuits | 342

Configuring the Interfaces for the Local Interface Switch | 343

Enabling Local Interface Switching When the MTU Does Not Match | 344

x

Configuring Interfaces for Layer 2 Circuits | 345

Configuring the Address for the Neighbor of the Layer 2 Circuit | 345

Configuring the Neighbor Interface for the Layer 2 Circuit | 346

Configuring a Community for the Layer 2 Circuit | 347

Configuring the Control Word for Layer 2 Circuits | 347

Configuring the Encapsulation Type for the Layer 2 Circuit Neighbor Interface | 349

Enabling the Layer 2 Circuit When the Encapsulation Does Not Match | 349

Configuring the MTU Advertised for a Layer 2 Circuit | 350

Enabling the Layer 2 Circuit When the MTU Does Not Match | 350

Configuring the Protect Interface | 350

Configuring the Protect Interface From Switching Over to the Primary Interface | 351

Configuring the Pseudowire Status TLV | 351

Configuring Layer 2 Circuits over Both RSVP and LDP LSPs | 352

Configuring the Virtual Circuit ID | 353

Configuring the Interface Encapsulation Type for Layer 2 Circuits | 353

Configuring ATM2 IQ Interfaces for Layer 2 Circuits | 354

Example: Configuring the Pseudowire Status TLV | 354

Configuring Policies for Layer 2 Circuits | 357

Configuring the Layer 2 Circuit Community | 357

Configuring the Policy Statement for the Layer 2 Circuit Community | 358

Example: Configuring a Policy for a Layer 2 Circuit Community | 359

Verifying the Layer 2 Circuit Policy Configuration | 360

Configuring LDP for Layer 2 Circuits | 360

Configuring Class of Service with Layer 2 Circuits | 363

Configuring ATM Trunking on Layer 2 Circuits | 363

Layer 2 Circuit Bandwidth Accounting and Call Admission Control | 365

Bandwidth Accounting and Call Admission Control Overview | 365

Selecting an LSP Based on the Bandwidth Constraint | 365

LSP Path Protection and CAC | 366

Secondary Paths and CAC | 367

Fast Reroute and CAC | 367

Link and Node Protection and CAC | 367

xi

Layer 2 Circuits Trunk Mode | 367

Configuring Bandwidth Allocation and Call Admission Control in Layer 2 Circuits | 368

Configuring Pseudowire Redundancy for Layer 2 Circuits | 371

Understanding Pseudowire Redundancy Mobile Backhaul Scenarios | 371

Sample Topology | 372

Benefits of Pseudowire Redundancy Mobile Backhaul | 372

Layer 2 Virtual Circuit Status TLV Extension | 373

How It Works | 374

Example: Configuring Pseudowire Redundancy in a Mobile Backhaul Scenario | 376

Extension of Pseudowire Redundancy Condition Logic to Pseudowire Service Logical InterfaceOverview | 406

Sample Topology | 406

Functionality | 407

Policy Condition for Pseudowire Service Logical Interfaces | 407

Configuring Load Balancing for Layer 2 Circuits | 411

Reducing APS Switchover Time in Layer 2 Circuits | 411

Configuring Per-Packet Load Balancing | 412

Configuring Fast APS Switchover | 413

Configuring Protection Features for Layer 2 Circuits | 415

Egress Protection LSPs for Layer 2 Circuits | 415

Configuring Egress Protection Service Mirroring for BGP Signaled Layer 2 Services | 417

Example: Configuring an Egress Protection LSP for a Layer 2 Circuit | 422

Example: Configuring Layer 2 Circuit Protect Interfaces | 436

Configuring Router PE1 | 437

Configuring Router PE2 | 439

Configuring Router CE1 | 441

Configuring Router CE2 | 442

Example: Configuring Layer 2 Circuit Switching Protection | 443

Monitoring Layer 2 Circuits with BFD | 461

Configuring BFD for VCCV for Layer 2 Circuits | 461

Example: Configuring BFD for VCCV for Layer 2 Circuits | 464

xii

Troubleshooting Layer 2 Circuits | 475

Tracing Layer 2 Circuit Operations | 475

Configuring VPWS VPNs6Overview | 479

Understanding VPWS | 479

Supported and Unsupported Features | 481

Supported VPWS Standards | 482

FAT Flow Labels Overview | 483

Configuring VPWS VPNs | 485

Understanding FEC 129 BGP Autodiscovery for VPWS | 485

Supported Standards in FEC 129 BGP Autodiscovery for VPWS | 485

Routes and Routing Table Interaction in FEC 129 BGP Autodiscovery for VPWS | 485

Layer 2 VPN Behavior in FEC 129 BGP Autodiscovery for VPWS | 486

BGP Autodiscovery Behavior in FEC 129 BGP Autodiscovery for VPWS | 487

LDP Signaling Behavior in VPWS in FEC 129 BGP Autodiscovery for VPWS | 487

Example: Configuring FEC 129 BGP Autodiscovery for VPWS | 488

Example: Configuring MPLS Egress Protection Service Mirroring for BGP Signaled Layer 2Services | 504

Understanding Multisegment Pseudowire for FEC 129 | 526

Understanding Multisegment Pseudowire | 527

Using FEC 129 for Multisegment Pseudowire | 528

Establishing a Multisegment Pseudowire Overview | 529

Pseudowire Status Support for Multisegment Pseudowire | 529

Pseudowire Status Behavior on T-PE | 529

Pseudowire Status Behavior on S-PE | 529

Pseudowire TLV Support for MS-PW | 530


Example: Configuring a Multisegment Pseudowire | 531

Configuring the FAT Flow Label for FEC 128 VPWS Pseudowires for Load-Balancing MPLSTraffic | 579

Configuring the FAT Flow Label for FEC 129 VPWS Pseudowires for Load-Balancing MPLSTraffic | 582

xiii

Configuring VPLS7Overview | 587

Introduction to VPLS | 587

Supported VPLS Standards | 588

Supported Platforms and PICs | 588

VPLS Configuration Overview | 591

Introduction to Configuring VPLS | 591

Configuring an Ethernet Switch as the CE Device for VPLS | 592

Configuring Signaling Protocols for VPLS | 593

VPLS Routing and Virtual Ports | 593

BGP Signaling for VPLS PE Routers Overview | 596

Control Word for BGP VPLS Overview | 596

Configuring a Control Word for BGP VPLS | 597

BGP Route Reflectors for VPLS | 599

Interoperability Between BGP Signaling and LDP Signaling in VPLS | 601

LDP-Signaled and BGP-Signaled PE Router Topology | 601

Flooding Unknown Packets Across Mesh Groups | 603

Unicast Packet Forwarding | 603

Configuring Interoperability Between BGP Signaling and LDP Signaling in VPLS | 603

LDP BGP Interworking Platform Support | 604

Configuring FEC 128 VPLS Mesh Groups for LDP BGP Interworking | 605

Configuring FEC 129 VPLS Mesh Groups for LDP BGP Interworking | 605

Configuring Switching Between Pseudowires Using VPLS Mesh Groups | 606

Configuring Integrated Routing and Bridging Support for LDP BGP Interworking with VPLS | 606

Configuring Inter-AS VPLS with MAC Processing at the ASBR | 607

Inter-AS VPLS with MAC Operations Configuration Summary | 608

Configuring the ASBRs for Inter-AS VPLS | 608

Example: VPLS Configuration (BGP Signaling) | 609

Verifying Your Work | 618

Example: VPLS Configuration (BGP and LDP Interworking) | 624

Verifying Your Work | 638

xiv

Assigning Routing Instances to VPLS | 645

Configuring VPLS Routing Instances | 645

Configuring BGP Signaling for VPLS | 647

Configuring the VPLS Site Name and Site Identifier | 648

Configuring Automatic Site Identifiers for VPLS | 649

Configuring the Site Range | 650

Configuring the VPLS Site Interfaces | 652

Configuring the VPLS Site Preference | 652

Configuring LDP Signaling for VPLS | 653

Configuring LDP Signaling for the VPLS Routing Instance | 655

Configuring LDP Signaling on the Router | 656

Configuring VPLS Routing Instance and VPLS Interface Connectivity | 656

Configuring the VPLS Encapsulation Type | 657

Configuring the MPLS Routing Table to Leak Routes a Nondefault Routing Instance | 658

Configuring the VPLS MAC Table Timeout Interval | 658

Configuring the Size of the VPLS MAC Address Table | 659

Limiting the Number of MAC Addresses Learned from an Interface | 660

Removing Addresses from the MAC Address Database | 661

Configuring a VPLS Routing Instance | 663

Support of Inner VLAN List and Inner VLAN Range for Qualified BUM Pruning on a Dual-TaggedInterface for a VPLS Routing Instance Overview | 664

ConfiguringQualified BUMPruning for aDual-Tagged Interfacewith Inner VLAN list and InnerVLANrange for a VPLS Routing Instance | 667

Configuring a Layer 2 Control Protocol Routing Instance | 669

PE Router Mesh Groups for VPLS Routing Instances | 670

Configuring VPLS Fast Reroute Priority | 671

Specifying the VT Interfaces Used by VPLS Routing Instances | 672

Understanding PIM Snooping for VPLS | 673

Example: Configuring PIM Snooping for VPLS | 674

VPLS Label Blocks Operation | 690

Elements of Network Layer Reachability Information | 690

Requirements for NLRI Elements | 691

How Labels are Used in Label Blocks | 691

Label Block Composition | 692

xv

Label Blocks in Junos OS | 692

VPLS Label Block Structure | 692

Configuring the Label Block Size for VPLS | 695

Example: Building a VPLS From Router 1 to Router 3 to Validate Label Blocks | 696

Associating Interfaces with VPLS | 705

Configuring Interfaces for VPLS Routing | 705

Configuring the VPLS Interface Name | 706

Configuring VPLS Interface Encapsulation | 707

Enabling VLAN Tagging | 709

Configuring VLAN IDs for Logical Interfaces | 710

Enabling VLANs for Hub and Spoke VPLS Networks | 711

Sample Scenario of Hierarchical Virtual Private LAN Service on Logical Tunnel Interface | 711

Configuring Aggregated Ethernet Interfaces for VPLS | 713

VPLS and Aggregated Ethernet Interfaces | 714

Configuring VLAN Identifiers for VLANs and VPLS Routing Instances | 715

Enabling VLAN Tagging | 720

Configuring VPLS Without a Tunnel Services PIC | 721

Configuring Pseudowires | 723

Configuring Static Pseudowires for VPLS | 723

VPLS Path Selection Process for PE Routers | 725

BGP and VPLS Path Selection for Multihomed PE Routers | 727

Dynamic Profiles for VPLS Pseudowires | 729

Use Cases for Dynamic Profiles for VPLS Pseudowires | 730

Example: Configuring VPLS Pseudowires with Dynamic Profiles—Basic Solutions | 731

VPLS Pseudowire Interfaces Without Dynamic Profiles | 731

VPLS Pseudowire Interfaces and Dynamic Profiles | 732

CE Routers Without Dynamic Profiles | 734

CE Routers and Dynamic Profiles | 735

Example: Configuring VPLS Pseudowires with Dynamic Profiles—Complex Solutions | 736

Configuration of Routing Instance and Interfaces Without Dynamic Profiles | 737

Configuration of Routing Instance and Interfaces Using Dynamic Profiles | 738

xvi

Configuration of Tag Translation Using Dynamic Profiles | 741

Configuring the FAT Flow Label for FEC 128 VPLS Pseudowires for Load-Balancing MPLSTraffic | 742

Configuring the FAT Flow Label for FEC 129 VPLS Pseudowires for Load-Balancing MPLSTraffic | 744

Example: Configuring H-VPLS BGP-Based and LDP-Based VPLS Interoperation | 746

Example: Configuring BGP-Based H-VPLS Using Different Mesh Groups for Each Spoke Router | 775

Example: Configuring LDP-Based H-VPLS Using a Single Mesh Group to Terminate the Layer 2Circuits | 805

Example: Configuring H-VPLS With VLANs | 812

Example: Configuring H-VPLS Without VLANs | 829

Sample Scenario of H-VPLS on ACX Series Routers for IPTV Services | 844

Sample Configuration Scenario of H-VPLS for IPTV Services | 844

Guidelines for H-VPLS on ACX Routers | 846

Configuring Multihoming | 847

VPLS Multihoming Overview | 847

Advantages of Using Autodiscovery for VPLS Multihoming | 850


Understanding VPWS | 851


Understanding FEC 129 BGP Autodiscovery for VPWS | 854

Supported Standards in FEC 129 BGP Autodiscovery for VPWS | 854

Routes and Routing Table Interaction in FEC 129 BGP Autodiscovery for VPWS | 854

Layer 2 VPN Behavior in FEC 129 BGP Autodiscovery for VPWS | 855

BGP Autodiscovery Behavior in FEC 129 BGP Autodiscovery for VPWS | 855

LDP Signaling Behavior in VPWS in FEC 129 BGP Autodiscovery for VPWS | 855


Example: Configuring BGP Autodiscovery for LDP VPLS | 872

Example: Configuring BGP Autodiscovery for LDP VPLS with User-Defined Mesh Groups | 895

xvii

VPLS Multihoming Reactions to Network Failures | 909

Configuring VPLS Multihoming (FEC 128) | 910

VPLS Multihomed Site Configuration | 911

Specifying an Interface as the Active Interface | 912

Configuring Multihoming on the PE Router | 913

VPLS Single-Homed Site Configuration | 913

Example: VPLS Multihoming, Improved Convergence Time | 914

Example: Configuring VPLS Multihoming (FEC 129) | 928

VPLS Multihoming Overview | 929

Example: Configuring VPLS Multihoming (FEC 129) | 931

Next-Generation VPLS for Multicast with Multihoming Overview | 947

Operation of Next-Generation VPLS for Multicast with Multihoming Using BGP | 948

Implementation of Redundancy Using VPLSMultihomed Links Between PE and CE Devices | 951

Example: Next-Generation VPLS for Multicast with Multihoming | 953

Configuring Point-to-Multipoint LSPs | 981

Next-Generation VPLS Point-to-Multipoint Forwarding Overview | 981

Next-Generation VPLS Point-to-Multipoint Forwarding Applications | 982

Implementation | 985

Example: NG-VPLS Using Point-to-Multipoint LSPs | 987

Flooding Unknown Traffic Using Point-to-Multipoint LSPs in VPLS | 1029

Configuring Static Point-to-Multipoint Flooding LSPs | 1031

Configuring Dynamic Point-to-Multipoint Flooding LSPs | 1031

Configuring Dynamic Point-to-Multipoint Flooding LSPs with the Default Template | 1032

Configuring Dynamic Point-to-Multipoint Flooding LSPs with a PreconfiguredTemplate | 1033

Example: Configuring Ingress Replication for IP Multicast Using MBGP MVPNs | 1033

Mapping VPLS Traffic to Specific LSPs | 1050

Configuring Inter-AS VPLS and IRB VPLS | 1053

Example: Configuring Inter-AS VPLS with MAC Processing at the ASBR | 1053

Configuring VPLS and Integrated Routing and Bridging | 1085

Configuring MAC Address Flooding and Learning for VPLS | 1086

Configuring MSTP for VPLS | 1087

Configuring Integrated Routing and Bridging in a VPLS Instance (MX Series Routers Only) | 1088

xviii

Configuring Load Balancing and Performance | 1089

Configuring VPLS Load Balancing | 1090

Configuring VPLS Load Balancing Based on IP and MPLS Information | 1092

Configuring VPLS Load Balancing on MX Series 5G Universal Routing Platforms | 1094

Example: Configuring Loop Prevention in VPLS Network Due to MAC Moves | 1096

MAC Moves Loop Prevention in VPLS Network Overview | 1096

Configuring VPLS Loop Prevention Due to MAC Moves | 1098

Example: Configuring Loop Prevention in VPLS Network Due to MAC Moves | 1100

Understanding MAC Pinning | 1117

Configuring MAC Pinning on Access Interfaces for Bridge Domains | 1119

Configuring MAC Pinning on Trunk Interfaces for Bridge Domains | 1120

Configuring MAC Pinning on Access Interfaces for Bridge Domains in a Virtual Switch | 1122

Configuring MAC Pinning on Trunk Interfaces for Bridge Domains in a Virtual Switch | 1124

Configuring MAC Pinning for All Pseudowires of the VPLS Routing Instance (LDP and BGP) | 1126

Configuring MAC Pinning on VPLS CE Interface | 1128

Configuring MAC Pinning for All Pseudowires of the VPLS Site in a BGP-Based VPLS RoutingInstance | 1130

Configuring MAC Pinning on All Pseudowires of a Specific Neighbor of LDP-Based VPLS RoutingInstance | 1132

Configuring MAC Pinning on Access Interfaces for Logical Systems | 1134

Configuring MAC Pinning on Trunk Interfaces for Logical Systems | 1136

Configuring MAC Pinning on Access Interfaces in Virtual Switches for Logical Systems | 1138

Configuring MAC Pinning on Trunk Interfaces in Virtual Switches for Logical Systems | 1140

Configuring MAC Pinning for All Pseudowires of the VPLS Routing Instance (LDP and BGP) forLogical Systems | 1143

Configuring MAC Pinning on VPLS CE Interface for Logical Systems | 1145

Configuring MAC Pinning for All Pseudowires of the VPLS Site in a BGP-Based VPLS RoutingInstance for Logical Systems | 1147

Configuring MAC Pinning on All Pseudowires of a Specific Neighbor of LDP-Based VPLS RoutingInstance for Logical Systems | 1149

Example: Prevention of Loops in Bridge Domains by Enabling theMACPinnning Feature on AccessInterfaces | 1151

Example: Prevention of Loops in Bridge Domains by Enabling theMAC Pinnning Feature on TrunkInterfaces | 1156

xix

Configuring Improved VPLS MAC Address Learning on T4000 Routers with Type 5 FPCs | 1165

Understanding Qualified MAC Learning | 1167

Qualified MAC Learning on the First, Second, and Third VLAN Tags | 1167

Qualified Learning VPLS Routing Instance Behavior | 1168

Configuring Qualified MAC Learning | 1173

Configuring Class of Service and Firewall Filters in VPLS | 1175

Configuring EXP-Based Traffic Classification for VPLS | 1175

Configuring Firewall Filters and Policers for VPLS | 1176

Configuring a VPLS Filter | 1177

Configuring an Interface-Specific Counter for VPLS | 1177

Configuring an Action for the VPLS Filter | 1178

Configuring VPLS FTFs | 1178

Changing Precedence for Spanning-Tree BPDU Packets | 1178

Applying a VPLS Filter to an Interface | 1178

Applying a VPLS Filter to a VPLS Routing Instance | 1179

Configuring a Filter for Flooded Traffic | 1179

Configuring a VPLS Policer | 1180

Firewall Filter Match Conditions for VPLS Traffic | 1181

Monitoring and Tracing VPLS | 1197

Configuring Port Mirroring for VPLS Traffic | 1197

Configuring Y.1731 Functionality for VPLS to Support Delay and Delay Variation | 1197

Tracing VPLS Traffic and Operations | 1199

Connecting Layer 2 VPNs and Circuits to Other VPNs8Connecting Layer 2 VPNs to Other VPNs | 1203

Layer 2 VPN to Layer 2 VPN Connections | 1203

Using the Layer 2 Interworking Interface to Interconnect a Layer 2 VPN to a Layer 2 VPN | 1203

Example: Interconnecting a Layer 2 VPN with a Layer 2 VPN | 1206

xx

Interconnecting Layer 2 VPNs with Layer 3 VPNs Overview | 1228

Interconnecting Layer 2 VPNs with Layer 3 VPNs Applications | 1229

Example: Interconnecting a Layer 2 VPN with a Layer 3 VPN | 1230

Connecting Layer 2 Circuits to Other VPNs | 1261

Using the Layer 2 Interworking Interface to Interconnect a Layer 2 Circuit to a Layer 2 VPN | 1261

Applications for Interconnecting a Layer 2 Circuit with a Layer 2 Circuit | 1263

Example: Interconnecting a Layer 2 Circuit with a Layer 2 VPN | 1263

Example: Interconnecting a Layer 2 Circuit with a Layer 2 Circuit | 1274

Applications for Interconnecting a Layer 2 Circuit with a Layer 3 VPN | 1294

Example: Interconnecting a Layer 2 Circuit with a Layer 3 VPN | 1295

Configuration Statements and Operational Commands9Configuration Statements (All VPNs) | 1323

aggregate-label | 1324

backup-neighbor | 1325

description (Routing Instances) | 1327

family route-target | 1328

graceful-restart (Enabling Globally) | 1330

instance-type | 1332

interface (Routing Instances) | 1335

no-forwarding | 1336

forward-policy-mismatch (Security Group VPN Member) | 1337

proxy-generate | 1338

revert-time (Protocols Layer 2 Circuits) | 1339

route-distinguisher | 1341

route-distinguisher-id | 1345

route-target-filter | 1346

switchover-delay | 1348

unicast-reverse-path | 1349

vpn-apply-export | 1350

vrf-export | 1351

vrf-import | 1353

vrf-mtu-check | 1354

xxi

About the Documentation

IN THIS SECTION

Documentation and Release Notes | xxix

Using the Examples in This Manual | xxix

Documentation Conventions | xxxi

Documentation Feedback | xxxiv

Requesting Technical Support | xxxiv

The Junos operating system (Junos OS) supports layer 2 VPN service which allows customers to havegeographically dispersed private networks across service provider’s networks. Use the topics on this pageto configure VPWS, VPLS, and layer 2 VPN routing instances to enable layer 2 VPN service.

Documentation and Release Notes

To obtain the most current version of all Juniper Networks® technical documentation, see the productdocumentation page on the Juniper Networks website at https://www.juniper.net/documentation/.

If the information in the latest release notes differs from the information in the documentation, follow theproduct Release Notes.

Juniper Networks Books publishes books by Juniper Networks engineers and subject matter experts.These books go beyond the technical documentation to explore the nuances of network architecture,deployment, and administration. The current list can be viewed at https://www.juniper.net/books.

Using the Examples in This Manual

If you want to use the examples in this manual, you can use the load merge or the load merge relativecommand. These commands cause the software to merge the incoming configuration into the currentcandidate configuration. The example does not become active until you commit the candidate configuration.

If the example configuration contains the top level of the hierarchy (or multiple hierarchies), the exampleis a full example. In this case, use the load merge command.

xxix

https://www.juniper.net/documentation/https://www.juniper.net/books

If the example configuration does not start at the top level of the hierarchy, the example is a snippet. Inthis case, use the loadmerge relative command. These procedures are described in the following sections.

Merging a Full Example

To merge a full example, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration example into a text file, save thefile with a name, and copy the file to a directory on your routing platform.

For example, copy the following configuration to a file and name the file ex-script.conf. Copy theex-script.conf file to the /var/tmp directory on your routing platform.

system {scripts {commit {file ex-script.xsl;

}}

}interfaces {fxp0 {disable;unit 0 {family inet {address 10.0.0.1/24;

}}

}}

2. Merge the contents of the file into your routing platform configuration by issuing the load mergeconfiguration mode command:

[edit]user@host# load merge /var/tmp/ex-script.confload complete

xxx

Merging a Snippet

To merge a snippet, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration snippet into a text file, save thefile with a name, and copy the file to a directory on your routing platform.

For example, copy the following snippet to a file and name the file ex-script-snippet.conf. Copy theex-script-snippet.conf file to the /var/tmp directory on your routing platform.

commit {file ex-script-snippet.xsl; }

2. Move to the hierarchy level that is relevant for this snippet by issuing the following configurationmodecommand:

[edit]user@host# edit system scripts[edit system scripts]

3. Merge the contents of the file into your routing platform configuration by issuing the load mergerelative configuration mode command:

[edit system scripts]user@host# load merge relative /var/tmp/ex-script-snippet.confload complete

For more information about the load command, see CLI Explorer.

Documentation Conventions

Table 1 on page xxxii defines notice icons used in this guide.

xxxi

https://www.juniper.net/techpubs/content-applications/cli-explorer/junos/

Table 1: Notice Icons

DescriptionMeaningIcon

Indicates important features or instructions.Informational note

Indicates a situation that might result in loss of data or hardwaredamage.

Caution

Alerts you to the risk of personal injury or death.Warning

Alerts you to the risk of personal injury from a laser.Laser warning

Indicates helpful information.Tip

Alerts you to a recommended use or implementation.Best practice

Table 2 on page xxxii defines the text and syntax conventions used in this guide.

Table 2: Text and Syntax Conventions

ExamplesDescriptionConvention

To enter configuration mode, typethe configure command:

user@host> configure

Represents text that you type.Bold text like this

user@host> show chassis alarms

No alarms currently active

Represents output that appears onthe terminal screen.

Fixed-width text like this

• A policy term is a named structurethat defines match conditions andactions.

• Junos OS CLI User Guide

• RFC 1997, BGP CommunitiesAttribute

• Introduces or emphasizes importantnew terms.

• Identifies guide names.

• Identifies RFC and Internet drafttitles.

Italic text like this

xxxii

Table 2: Text and Syntax Conventions (continued)


Configure the machine’s domainname:

[edit]root@# set system domain-namedomain-name

Represents variables (options forwhich you substitute a value) incommands or configurationstatements.

Italic text like this

• To configure a stub area, includethe stub statement at the [editprotocols ospf area area-id]hierarchy level.

• The console port is labeledCONSOLE.

Represents names of configurationstatements, commands, files, anddirectories; configuration hierarchylevels; or labels on routing platformcomponents.

Text like this

stub ;Encloses optional keywords orvariables.

< > (angle brackets)

broadcast | multicast

(string1 | string2 | string3)

Indicates a choice between themutually exclusive keywords orvariables on either side of the symbol.The set of choices is often enclosedin parentheses for clarity.

| (pipe symbol)

rsvp { # Required for dynamic MPLSonly

Indicates a comment specified on thesame line as the configurationstatement to which it applies.

# (pound sign)

community name members [community-ids ]

Encloses a variable for which you cansubstitute one or more values.

[ ] (square brackets)

[edit]routing-options {static {route default {nexthop address;retain;

}}

}

Identifies a level in the configurationhierarchy.

Indention and braces ( { } )

Identifies a leaf statement at aconfiguration hierarchy level.

; (semicolon)

GUI Conventions

xxxiii

Table 2: Text and Syntax Conventions (continued)


• In the Logical Interfaces box, selectAll Interfaces.

• To cancel the configuration, clickCancel.

Represents graphical user interface(GUI) items you click or select.

Bold text like this

In the configuration editor hierarchy,select Protocols>Ospf.

Separates levels in a hierarchy ofmenu selections.

> (bold right angle bracket)

Documentation Feedback

We encourage you to provide feedback so that we can improve our documentation. You can use eitherof the following methods:

• Online feedback system—Click TechLibrary Feedback, on the lower right of any page on the JuniperNetworks TechLibrary site, and do one of the following:

• Click the thumbs-up icon if the information on the page was helpful to you.

• Click the thumbs-down icon if the information on the page was not helpful to you or if you havesuggestions for improvement, and use the pop-up form to provide feedback.

• E-mail—Send your comments to [email protected]. Include the document or topic name,URL or page number, and software version (if applicable).

Requesting Technical Support

Technical product support is available through the Juniper Networks Technical Assistance Center (JTAC).If you are a customer with an active Juniper Care or Partner Support Services support contract, or are

xxxiv

https://www.juniper.net/documentation/index.htmlhttps://www.juniper.net/documentation/index.htmlmailto:[email protected]?subject=

covered under warranty, and need post-sales technical support, you can access our tools and resourcesonline or open a case with JTAC.

• JTAC policies—For a complete understanding of our JTAC procedures and policies, review the JTACUserGuide located at https://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf.

• Productwarranties—For productwarranty information, visit https://www.juniper.net/support/warranty/.

• JTAC hours of operation—The JTAC centers have resources available 24 hours a day, 7 days a week,365 days a year.

Self-Help Online Tools and Resources

For quick and easy problem resolution, Juniper Networks has designed an online self-service portal calledthe Customer Support Center (CSC) that provides you with the following features:

• Find CSC offerings: https://www.juniper.net/customers/support/

• Search for known bugs: https://prsearch.juniper.net/

• Find product documentation: https://www.juniper.net/documentation/

• Find solutions and answer questions using our Knowledge Base: https://kb.juniper.net/

• Download the latest versions of software and review release notes:https://www.juniper.net/customers/csc/software/

• Search technical bulletins for relevant hardware and software notifications:https://kb.juniper.net/InfoCenter/

• Join and participate in the Juniper Networks Community Forum:https://www.juniper.net/company/communities/

• Create a service request online: https://myjuniper.juniper.net

To verify service entitlement by product serial number, use our Serial Number Entitlement (SNE) Tool:https://entitlementsearch.juniper.net/entitlementsearch/

Creating a Service Request with JTAC

You can create a service request with JTAC on the Web or by telephone.

• Visit https://myjuniper.juniper.net.

• Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).

For international or direct-dial options in countries without toll-free numbers, seehttps://support.juniper.net/support/requesting-support/.

xxxv

https://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdfhttps://www.juniper.net/support/warranty/https://www.juniper.net/customers/support/https://prsearch.juniper.net/https://www.juniper.net/documentation/https://kb.juniper.net/https://www.juniper.net/customers/csc/software/https://kb.juniper.net/InfoCenter/https://www.juniper.net/company/communities/https://myjuniper.juniper.nethttps://entitlementsearch.juniper.net/entitlementsearch/https://myjuniper.juniper.nethttps://support.juniper.net/support/requesting-support/

CHAPTER 1

VPNs Overview

IN THIS CHAPTER

VPLS | 3

Types of VPNs | 3

VPNs and Logical Systems | 7

Layer 2 VPNs | 7

Routers in a VPN | 8

VPLS

In a Layer 3 network only, you can configure virtual private LAN service (VPLS), which is an Ethernet-basedpoint-to-multipoint Layer 2 VPN. It enables you to connect geographically dispersed Ethernet local areanetworks (LAN) sites to each other across an MPLS backbone. For ISP customers who implement VPLS,all sites appear to be in the same Ethernet LAN even though traffic travels across the service provider'snetwork.

RELATED DOCUMENTATION

Junos OS VPNs Library for Routing Devices

MX Series Router Architecture

Types of VPNs

IN THIS SECTION

Layer 2 VPNs | 4

Layer 3 VPNs | 5

3

VPLS | 5

Virtual-Router Routing Instances | 6

A virtual private network (VPN) consists of two topological areas: the provider’s network and the customer’snetwork. The customer’s network is commonly located at multiple physical sites and is also private(non-Internet). A customer site would typically consist of a group of routers or other networking equipmentlocated at a single physical location. The provider’s network, which runs across the public Internetinfrastructure, consists of routers that provide VPN services to a customer’s network as well as routersthat provide other services. The provider’s network connects the various customer sites in what appearsto the customer and the provider to be a private network.

To ensure that VPNs remain private and isolated from other VPNs and from the public Internet, theprovider’s network maintains policies that keep routing information from different VPNs separate. Aprovider can service multiple VPNs as long as its policies keep routes from different VPNs separate.Similarly, a customer site can belong to multiple VPNs as long as it keeps routes from the different VPNsseparate.

The Junos®Operating System (JunosOS) provides several types of VPNs; you can choose the best solutionfor your network environment. Each of the following VPNs has different capabilities and requires differenttypes of configuration:

Layer 2 VPNs

Implementing a Layer 2 VPN on a router is similar to implementing a VPN using a Layer 2 technology suchas ATM or Frame Relay. However, for a Layer 2 VPN on a router, traffic is forwarded to the router inLayer 2 format. It is carried by MPLS over the service provider’s network and then converted back toLayer 2 format at the receiving site. You can configure different Layer 2 formats at the sending and receivingsites. The security and privacy of anMPLS Layer 2 VPN are equal to those of an ATM or Frame Relay VPN.

On a Layer 2 VPN, routing occurs on the customer’s routers, typically on the CE router. The CE routerconnected to a service provider on a Layer 2 VPN must select the appropriate circuit on which to sendtraffic. The PE router receiving the traffic sends it across the service provider’s network to the PE routerconnected to the receiving site. The PE routers do not need to store or process the customer’s routes;they only need to be configured to send data to the appropriate tunnel.

For a Layer 2 VPN, customers need to configure their own routers to carry all Layer 3 traffic. The serviceprovider needs to know only how much traffic the Layer 2 VPN needs to carry. The service provider’srouters carry traffic between the customer’s sites using Layer 2 VPN interfaces. The VPN topology isdetermined by policies configured on the PE routers.

4

Layer 3 VPNs

In a Layer 3 VPN, the routing occurs on the service provider’s routers. Therefore, Layer 3 VPNs requiremore configuration on the part of the service provider, because the service provider’s PE routers muststore and process the customer’s routes.

In the Junos OS, Layer 3 VPNs are based on RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs). ThisRFC defines a mechanism by which service providers can use their IP backbones to provide Layer 3 VPNservices to their customers. The sites that make up a Layer 3 VPN are connected over a provider’s existingpublic Internet backbone.

VPNs based on RFC 4364 are also known as BGP/MPLS VPNs because BGP is used to distribute VPNrouting information across the provider’s backbone, and MPLS is used to forward VPN traffic across thebackbone to remote VPN sites.

Customer networks, because they are private, can use either public addresses or private addresses, asdefined in RFC 1918, Address Allocation for Private Internets. When customer networks that use privateaddresses connect to the public Internet infrastructure, the private addresses might overlap with theprivate addresses used by other network users. BGP/MPLS VPNs solve this problem by prefixing a VPNidentifier to each address from a particular VPN site, thereby creating an address that is unique bothwithinthe VPN and within the public Internet. In addition, each VPN has its own VPN-specific routing table thatcontains the routing information for that VPN only.

VPLS

Virtual private LAN service (VPLS) allows you to connect geographically dispersed customer sites as if theywere connected to the same LAN. In many ways, it works like a Layer 2 VPN. VPLS and Layer 2 VPNs usethe same network topology and function similarly. A packet originating within a customer’s network issent first to a CE device. It is then sent to a PE router within the service provider’s network. The packettraverses the service provider’s network over an MPLS LSP. It arrives at the egress PE router, which thenforwards the traffic to the CE device at the destination customer site.

The key difference in VPLS is that packets can traverse the service provider’s network in apoint-to-multipoint fashion, meaning that a packet originating from a CE device can be broadcast to PErouters in the VPLS. In contrast, a Layer 2 VPN forwards packets in a point-to-point fashion only. Thedestination of a packet received from a CE device by a PE router must be known for the Layer 2 VPN tofunction properly.

In a Layer 3 network only, you can configure virtual private LAN service (VPLS), to connect geographicallydispersed Ethernet local area networks (LAN) sites to each other across an MPLS backbone. For ISPcustomers who implement VPLS, all sites appear to be in the same Ethernet LAN even though traffic travelsacross the service provider's network. VPLS is designed to carry Ethernet traffic across an MPLS-enabledservice provider network. In certain ways, VPLS mimics the behavior of an Ethernet network. When a PErouter configured with a VPLS routing instance receives a packet from a CE device, it first checks theappropriate routing table for the destination of the VPLS packet. If the router has the destination, it forwards

5

it to the appropriate PE router. If it does not have the destination, it broadcasts the packet to all the otherPE routers that are members of the same VPLS routing instance. The PE routers forward the packet totheir CE devices. The CE device that is the intended recipient of the packet forwards it to its final destination.The other CE devices discard it.

Virtual-Router Routing Instances

A virtual-router routing instance, like a VPN routing and forwarding (VRF) routing instance, maintainsseparate routing and forwarding tables for each instance. However, many configuration steps required forVRF routing instances are not required for virtual-router routing instances. Specifically, you do not needto configure a route distinguisher, a routing table policy (the vrf-export, vrf-import, and route-distinguisherstatements), or MPLS between the P routers.

However, you need to configure separate logical interfaces between each of the service provider routersparticipating in a virtual-router routing instance. You also need to configure separate logical interfacesbetween the service provider routers and the customer routers participating in each routing instance. Eachvirtual-router instance requires its own unique set of logical interfaces to all participating routers.

Figure 1 on page 6 shows how this works. The service provider routers G and H are configured forvirtual-router routing instances Red and Green. Each service provider router is directly connected to twolocal customer routers, one in each routing instance. The service provider routers are also connected toeach other over the service provider network. These routers need four logical interfaces: a logical interfaceto each of the locally connected customer routers and a logical interface to carry traffic between the twoservice provider routers for each virtual-router instance.

Figure 1: Logical Interface per Router in a Virtual-Router Routing Instance

Layer 3 VPNs do not have this configuration requirement. If you configure several Layer 3 VPN routinginstances on a PE router, all the instances can use the same logical interface to reach another PE router.This is possible because Layer 3 VPNs use MPLS (VPN) labels that differentiate traffic going to and fromvarious routing instances. Without MPLS and VPN labels, as in a virtual-router routing instance, you needseparate logical interfaces to separate traffic from different instances.

6

One method of providing this logical interface between the service provider routers is by configuringtunnels between them. You can configure IP Security (IPsec), generic routing encapsulation (GRE), or IP-IPtunnels between the service provider routers, terminating the tunnels at the virtual-router instance.

VPNs and Logical Systems

You can partition a single physical router into multiple logical systems that perform independent routingtasks. Because logical systems perform a subset of the tasks once handled by the physical router, logicalsystems offer an effective way to maximize the use of a single routing platform.

Logical systems perform a subset of the actions of a physical router and have their own unique routingtables, interfaces, policies, and routing instances. A set of logical systems within a single router can handlethe functions previously performed by several small routers.

Logical systems support Layer 2 VPNs, Layer 3 VPNs, VPLS, and Layer 2 circuits.. For more informationabout logical systems, see the Logical Systems User Guide for Routers and Switches.

Starting in Junos OS release 17.4R1, Ethernet VPN (EVPN) support has also been extended to logicalsystems running on MX devices. The same EVPN options and performance are available, and can beconfigured under the [edit logical-systems logical-system-name routing-instances routing-instance-nameprotocols evpn] hierarchy.

Release History Table

DescriptionRelease

Starting in Junos OS release 17.4R1, Ethernet VPN (EVPN) support has also been extended tological systems running on MX devices. The same EVPN options and performance are available,and can be configured under the [edit logical-systems logical-system-name routing-instancesrouting-instance-name protocols evpn] hierarchy.

17.4

Layer 2 VPNs

In a Layer 3 network only, you can configure Layer 2 virtual private network (VPN) under a Layer 2 VPNrouting instance type l2vpn.

In a Layer 2 environment, you can use a l2vpn routing instance to transparently carry Layer 2 traffic overan IP/MPLS backbone. Layer 2 traffic is sent to the provider edge (PE) router in Layer 2 format. The PErouter encapsulates the frames and transports them over the IP/MPLS backbone to the PE router on theother side of the cloud. The remote PE router removes encapsulation and sends the frames to the receivingsite in Layer 2 format.

7

RELATED DOCUMENTATION

MX Series Router Architecture

Layer 2 and Layer 3 Features on MX Series Routers

Junos OS VPNs Library for Routing Devices

Routers in a VPN

Figure 2 on page 8 illustrates how VPN functionality is provided by the provider edge (PE) routers; theprovider and customer edge (CE) routers have no special configuration requirements for VPNs.

Figure 2: Routers in a VPN

8

CHAPTER 2

Assigning Routing Instances to VPNs

IN THIS CHAPTER

Configuring Routing Instances on PE Routers in VPNs | 9

Configuring Virtual-Router Routing Instances in VPNs | 15

Configuring Path MTU Checks for VPN Routing Instances | 17

Configuring Routing Instances on PE Routers in VPNs

IN THIS SECTION

Configuring the Routing Instance Name for a VPN | 10

Configuring the Description | 10

Configuring the Instance Type | 11

Configuring Interfaces for VPN Routing | 12

Configuring the Route Distinguisher | 14

Configuring Automatic Route Distinguishers | 14

You need to configure a routing instance for each VPN on each of the PE routers participating in the VPN.The configuration procedures outlined in this section are applicable to Layer 2 VPNs, Layer 3 VPNs, andVPLS. The configuration procedures specific to each type of VPN are described in the correspondingsections in the other configuration chapters.

To configure routing instances for VPNs, include the following statements:

description text;instance-type type;interface interface-name;route-distinguisher (as-number:number | ip-address:number);

9

vrf-import [ policy-names ];vrf-export [ policy-names ];vrf-target {export community-name;import community-name;

}

You can include these statements at the following hierarchy levels:

• [edit routing-instances routing-instance-name]

• [edit logical-systems logical-system-name routing-instances routing-instance-name]

To configure VPN routing instances, you perform the steps in the following sections:

Configuring the Routing Instance Name for a VPN

The name of the routing instance for a VPN can be a maximum of 128 characters and can contain letters,numbers, and hyphens. In Junos OS Release 9.0 and later, you can no longer specify default as the actualrouting-instance name. You also cannot use any special characters (! @ # $ % ^ & * , +< > : ;) within thename of a routing instance.

NOTE: In Junos OS Release 9.6 and later, you can include a slash (/) in a routing instance nameonly if a logical system is not configured. That is, you cannot include the slash character in arouting instance name if a logical system other than the default is explicitly configured.

Specify the routing-instance name with the routing-instance statement:

routing-instance routing-instance-name {...}

You can include this statement at the following hierarchy levels:

• [edit]

• [edit logical-systems logical-system-name]

Configuring the Description

To provide a text description for the routing instance, include the description statement. If the text includesone or more spaces, enclose them in quotation marks (" "). Any descriptive text you include is displayedin the output of the show route instance detail command and has no effect on the operation of the routinginstance.

10

To configure a text description, include the description statement:

description text;




Configuring the Instance Type

The instance type you configure varies depending on whether you are configuring Layer 2 VPNs, Layer 3VPNs, VPLS, or virtual routers. Specify the instance type by including the instance-type statement:

• To enable Layer 2 VPN routing on a PE router, include the instance-type statement and specify thevalue l2vpn:

instance-type l2vpn;

• To enable VPLS routing on a PE router, include the instance-type statement and specify the value vpls:

instance-type vpls;

• Layer 3 VPNs require that each PE router have a VPN routing and forwarding (VRF) table for distributingroutes within the VPN. To create the VRF table on the PE router, include the instance-type statementand specify the value vrf:

instance-type vrf;

NOTE: Routing Engine based sampling is not supported on VRF routing instances.

• To enable the virtual-router routing instance, include the instance-type statement and specify the valuevirtual-router:

instance-type virtual-router;




11

Configuring Interfaces for VPN Routing

IN THIS SECTION

General Configuration for VPN Routing | 12

Configuring Interfaces for Layer 3 VPNs | 13

Configuring Interfaces for Carrier-of-Carriers VPNs | 13

Configuring Unicast RPF on VPN Interfaces | 13

On each PE router, you must configure an interface over which the VPN traffic travels between the PEand CE routers.

The sections that follow describe how to configure interfaces for VPNs:

General Configuration for VPN Routing

The configuration described in this section applies to all types of VPNs. For Layer 3 VPNs andcarrier-of-carriers VPNs, complete the configuration described in this section before proceeding to theinterface configuration sections specific to those topics.

To configure interfaces for VPN routing, include the interface statement:

interface interface-name;




Specify both the physical and logical portions of the interface name, in the following format:

physical.logical

For example, in at-1/2/1.2, at-1/2/1 is the physical portion of the interface name and 2 is the logicalportion. If you do not specify the logical portion of the interface name, the value 0 is set by default.

A logical interface can be associated with only one routing instance. If you enable a routing protocol onall instances by specifying interfaces all when configuring the master instance of the protocol at the [editprotocols] hierarchy level, and if you configure a specific interface for VPN routing at the [editrouting-instances routing-instance-name] hierarchy level or at the [edit logical-systems logical-system-name

12

routing-instances routing-instance-name] hierarchy level, the latter interface statement takes precedenceand the interface is used exclusively for the VPN.

If you explicitly configure the same interface name at the [edit protocols] hierarchy level and at either the[edit routing-instances routing-instance-name] or [edit logical-systems logical-system-name routing-instancesrouting-instance-name] hierarchy levels, an attempt to commit the configuration fails.

Configuring Interfaces for Layer 3 VPNs

When you configure the Layer 3 VPN interfaces at the [edit interfaces] hierarchy level, you must alsoconfigure family inet when configuring the logical interface:

[edit interfaces]interface-name {unit logical-unit-number {family inet;

}}

Configuring Interfaces for Carrier-of-Carriers VPNs

When you configure carrier-of-carriers VPNs, you need to configure the familympls statement in additionto the family inet statement for the interfaces between the PE and CE routers. For carrier-of-carriersVPNs, configure the logical interface as follows:

[edit interfaces]interface-name {unit logical-unit-number {family inet;family mpls;

}}

If you configure family mpls on the logical interface and then configure this interface for anon-carrier-of-carriers routing instance, the family mpls statement is automatically removed from theconfiguration for the logical interface, since it is not needed.

Configuring Unicast RPF on VPN Interfaces

For VPN interfaces that carry IP version 4 or version 6 (IPv4 or IPv6) traffic, you can reduce the impact ofdenial-of-service (DoS) attacks by configuring unicast reverse path forwarding (RPF). Unicast RPF helpsdetermine the source of attacks and rejects packets from unexpected source addresses on interfaceswhere unicast RPF is enabled.

You can configure unicast RPF on a VPN interface by enabling unicast RPF on the interface and includingthe interface statement at the [edit routing-instances routing-instance-name] hierarchy level.

13

You cannot configure unicast RPF on the core-facing interfaces. You can only configure unicast RPF onthe CE router-to-PE router interfaces on the PE router. However, for virtual-router routing instances,unicast RPF is supported on all interfaces you specify in the routing instance.

For information about how to configure unicast RPF on VPN interfaces, see Understanding Unicast RPF(Routers).

Configuring the Route Distinguisher

Each routing instance that you configure on a PE router must have a unique route distinguisher associatedwith it. VPN routing instances need a route distinguisher to help BGP to distinguish between potentiallyidentical network layer reachability information (NLRI) messages received from different VPNs. If youconfigure different VPN routing instances with the same route distinguisher, the commit fails.

For Layer 2 VPNs and VPLS, if you have configured the l2vpn-use-bgp-rules statement, youmust configurea unique route distinguisher for each PE router participating in a specific routing instance.

For other types of VPNs, we recommend that you use a unique route distinguisher for each PE routerparticipating in the routing instance. Although you can use the same route distinguisher on all PE routersfor the same VPN routing instance (except for Layer 2 VPNs and VPLS), if you use a unique routedistinguisher, you can determine the CE router from which a route originated within the VPN.

To configure a route distinguisher on a PE router, include the route-distinguisher statement:

route-distinguisher (as-number:number | ip-address:number);

For a list of hierarchy levels at which you can include this statement, see the statement summary sectionfor this statement.

The route distinguisher is a 6-byte value that you can specify in one of the following formats:

• as-number:number, where as-number is an autonomous system (AS) number (a 2-byte value) and numberis any 4-byte value. The AS number can be in the range 1 through 65,535. We recommend that you usean Internet AssignedNumbers Authority (IANA)-assigned, nonprivate AS number, preferably the Internetservice provider’s (ISP’s) own or the customer’s own AS number.

• ip-address:number, where ip-address is an IP address (a 4-byte value) and number is any 2-byte value.The IP address can be any globally unique unicast address. We recommend that you use the addressthat you configure in the router-id statement, which is a nonprivate address in your assigned prefixrange.

Configuring Automatic Route Distinguishers

If you configure the route-distinguisher-id statement at the [edit routing-options] hierarchy level, a routedistinguisher is automatically assigned to the routing instance. If you also configure the route-distinguisher

14

statement in addition to the route-distinguisher-id statement, the value configured for route-distinguishersupersedes the value generated from route-distinguisher-id.

To assign a route distinguisher automatically, include the route-distinguisher-id statement:

route-distinguisher-id ip-address;


• [edit routing-options]

• [edit logical-systems logical-system-name routing-options]

A type 1 route distinguisher is automatically assigned to the routing instance using the formatip-address:number. The IP address is specified by the route-distinguisher-id statement and the number isunique for the routing instance.

Configuring Virtual-Router Routing Instances in VPNs

IN THIS SECTION

Configuring a Routing Protocol Between the Service Provider Routers | 16

Configuring Logical Interfaces Between Participating Routers | 16

A virtual-router routing instance, like a VRF routing instance, maintains separate routing and forwardingtables for each instance. However, many of the configuration steps required for VRF routing instances arenot required for virtual-router routing instances. Specifically, you do not need to configure a routedistinguisher, a routing table policy (the vrf-export, vrf-import, and route-distinguisher statements), orMPLS between the service provider routers.

Configure a virtual-router routing instance by including the following statements:

description text;instance-type virtual-router;interface interface-name;protocols { ... }

You can include these statements at the following hierarchy levels:


15


The following sections explain how to configure a virtual-router routing instance:

Configuring a Routing Protocol Between the Service Provider Routers

The service provider routers need to be able to exchange routing information. You can configure thefollowing protocols for the virtual-router routing instance protocols statement configuration at the [editrouting-instances routing-instance-name] hierarchy level:

• BGP

• IS-IS

• LDP

• OSPF

• Protocol Independent Multicast (PIM)

• RIP

You can also configure static routes.

IBGP route reflection is not supported for virtual-router routing instances.

If you configure LDP under a virtual-router instance, LDP routes are placed by default in the routinginstance’s inet.0 and inet.3 routing tables (for example, sample.inet.0 and sample.inet.3). To restrict LDProutes to only the routing instance’s inet.3 table, include the no-forwarding statement:

no-forwarding;


• [edit routing-instances routing-instance-name protocols ldp]

• [edit logical-systems logical-system-name routing-instances routing-instance-name protocols ldp]

When you restrict the LDP routes to only the inet.3 routing table, the corresponding IGP route in theinet.0 routing table can be redistributed and advertised into other routing protocols.

For information about routing tables, see Understanding Junos OS Routing Tables.

Configuring Logical Interfaces Between Participating Routers

You must configure an interface to each customer router participating in the routing instance and to eachP router participating in the routing instance. Each virtual-router routing instance requires its own separatelogical interfaces to all P routers participating in the instance. To configure interfaces for virtual-routerinstances, include the interface statement:

16

interface interface-name;




Specify both the physical and logical portions of the interface name, in the following format:

physical.logical

For example, in at-1/2/1.2, at-1/2/1 is the physical portion of the interface name and 2 is the logicalportion. If you do not specify the logical portion of the interface name, 0 is set by default.

You must also configure the interfaces at the [edit interfaces] hierarchy level.

One method of providing this logical interface between the provider routers is by configuring tunnelsbetween them. You can configure IP Security (IPsec), generic routing encapsulation (GRE), or IP-IP tunnelsbetween the provider routers, terminating the tunnels at the virtual-router instance.

For information about how to configure tunnels and interfaces, see the Junos OS Services Interfaces Libraryfor Routing Devices.

Configuring Path MTU Checks for VPN Routing Instances

IN THIS SECTION

Enabling Path MTU Checks for a VPN Routing Instance | 18

Assigning an IP Address to the VPN Routing Instance | 18

By default, the maximum transmission unit (MTU) check for VPN routing instances is disabled onM Seriesrouters (except theM320 router) and enabled for theM320 router. OnMSeries routers, you can configurepath MTU checks on the outgoing interfaces for unicast traffic routed on VRF routing instances and onvirtual-router routing instances.

When you enable anMTU check, the routing platform sends an Internet Control Message Protocol (ICMP)messagewhen a packet traversing the routing instance exceeds theMTU size and has the do-not-fragmentbit set. The ICMP message uses the VRF local address as its source address.

17

For an MTU check to work in a routing instance, you must both include the vrf-mtu-check statement atthe [edit chassis] hierarchy level and assign at least one interface containing an IP address to the routinginstance.

For more information about the path MTU check, see the Junos OS Administration Library.

To configure path MTU checks, do the tasks described in the following sections:

Enabling Path MTU Checks for a VPN Routing Instance

To enable path checks on the outgoing interface for unicast traffic routed on a VRF or virtual-router routinginstance, include the vrf-mtu-check statement at the [edit chassis] hierarchy level:

[edit chassis]vrf-mtu-check;

Assigning an IP Address to the VPN Routing Instance

To ensure that the path MTU check functions properly, at least one IP address must be associated witheach VRF or virtual-router routing instance. If an IP address is not associated with the routing instance,ICMP reply messages cannot be sent.

Typically, the VRF or virtual-router routing instance IP address is drawn from among the IP addressesassociated with interfaces configured for that routing instance. If none of the interfaces associated witha VRF or virtual-router routing instance is configured with an IP address, you need to explicitly configurea logical loopback interface with an IP address. This interface must then be associated with the routinginstance. See Configuring Logical Units on the Loopback Interface for Routing Instances in Layer 3 VPNs fordetails.

18

CHAPTER 3

Distributing Routes in VPNs

IN THIS CHAPTER

Enabling Routing Information Exchange for VPNs | 19

Configuring IBGP Sessions Between PE Routers in VPNs | 19

Configuring Aggregate Labels for VPNs | 21

Configuring a Signaling Protocol and LSPs for VPNs | 22

Configuring Policies for the VRF Table on PE Routers in VPNs | 27

Configuring the Route Origin for VPNs | 34

Enabling Routing Information Exchange for VPNs

For Layer 2 VPNs, Layer 3 VPNs, virtual-router routing instances, VPLS, EVPNs, and Layer 2 circuits tofunction properly, the service provider’s PE and P routers must be able to exchange routing information.For this to happen, you must configure either an IGP (such as OSPF or IS-IS) or static routes on theserouters. You configure the IGP on themaster instance of the routing protocol process at the [edit protocols]hierarchy level, not within the routing instance used for the VPN—that is, not at the [edit routing-instances]hierarchy level.

When you configure the PE router, do not configure any summarization of the PE router’s loopbackaddresses at the area boundary. Each PE router’s loopback address should appear as a separate route.

Configuring IBGP Sessions Between PE Routers in VPNs

Youmust configure an IBGP session between the PE routers to allow the PE routers to exchange informationabout routes originating and terminating in the VPN. The PE routers rely on this information to determinewhich labels to use for traffic destined for remote sites.

Configure an IBGP session for the VPN as follows:

[edit protocols]

19

bgp {group group-name {type internal;local-address ip-address;family evpn {signaling;

}family (inet-vpn | inet6-vpn) {unicast;

}family l2vpn {signaling;

}neighbor ip-address;

}}

The IP address in the local-address statement is the address of the loopback interface on the local PErouter. The IBGP session for the VPN runs through the loopback address. (You must also configure theloopback interface at the [edit interfaces] hierarchy level.)

The IP address in the neighbor statement is the loopback address of the neighboring PE router. If you areusing RSVP signaling, this IP address is the same address you specify in the to statement at the [edit mplslabel-switched-path lsp-path-name] hierarchy level when you configure the MPLS LSP.

The family statement allows you to configure the IBGP session for Layer 2 VPNs, VPLS, EVPNs or forLayer 3 VPNs.

• To configure an IBGP session for Layer 2 VPNs and VPLS, include the signaling statement at the [editprotocols bgp group group-name family l2vpn] hierarchy level:

[edit protocols bgp group group-name family l2vpn]signaling;

• To configure an IBGP session for EVPNs, include the signaling statement at the [edit protocols bgpgroup group-name family evpn] hierarchy level:

[edit protocols bgp group group-name family evpn]signaling;

• To configure an IPv4 IBGP session for Layer 3 VPNs, configure the unicast statement at the [edit protocolsbgp group group-name family inet-vpn] hierarchy level:

[edit protocols bgp group group-name family inet-vpn]

20

unicast;

• To configure an IPv6 IBGP session for Layer 3 VPNs, configure the unicast statement at the [edit protocolsbgp group group-name family inet6-vpn] hierarchy level:

[edit protocols bgp group group-name family inet6-vpn]unicast;

NOTE: You can configure both family inet and family inet-vpn or both family inet6 and familyinet6-vpnwithin the same peer group. This allows you to enable support for both IPv4 and IPv4VPN routes or both IPv6 and IPv6 VPN routes within the same peer group.

Configuring Aggregate Labels for VPNs

Aggregate labels for VPNs allow a Juniper Networks routing platform to aggregate a set of incoming labels(labels received from a peer router) into a single forwarding label that is selected from the set of incominglabels. The single forwarding label corresponds to a single next hop for that set of labels. Label aggregationreduces the number of VPN labels that the router must examine.

For a set of labels to share an aggregate forwarding label, they must belong to the same forwardingequivalence class (FEC). The labeled packets must have the same destination egress interface.

Including the community community-name statement with the aggregate-label statement le

Documents

Junos® OS Layer 2 VPNs and VPLS User Guide for …...ConfiguringClassofServiceforVPNs|125 VPNsandClassofService|125 RewritingClassofServiceMarkersandVPNs|125 PingingVPNs|127 PingingVPNs,VPLS,andLayer2Circuits|127