Juniper Advanced VPNs Update)

Advanced VPNs
Training Course
Module 0: Course Introduction
Course Contents
Contents:
Introduction to VPNs
Layer 3 VPNs
Basic Layer 3 VPN Configuration with JUNOS Software
Troubleshooting Layer 3 VPNs
Layer 2 VPNs (Kompella)
Layer 2 VPN Configuration and Troubleshooting
(Kompella)
VPLS Configuration and Troubleshooting
Appendix : MPLS Primer
2
Advanced VPNs
Training Course
Module 1: Introduction to VPNs
Module Objectives
After
successfully completing this module, you will
be able to:
Define the term VPN and describe the benefits of IP-based
VPN solutions
List two Characteristics of CPE-based VPNs
Site two characteristics of provider-provisioned VPNs
Describe the pros and cons of Layer 2 and Layer 3 VPN
solutions from a-provider's perspective
Describe the pros and cons associated with Layer 2 and
Layer 3 VPN solutions from a customer's perspective
List the VPN solutions available with JUNOS Internet
software
4
Agenda: Introduction to VPNs
Overview of VPNs
CPE-Based VPNs
Provider-Provisioned VPNs
Introduction to RFC 2547
Introduction to CCC/Layer 2 MPLS VPN
IETF Standards Update
Conclusions
What is a VPN?
Corporate Intranet
Headquarters Branch
Office
Shared Public
Mobile Users and
Infrastructure Telecommuters
Suppliers, Partners
Extranet and Customers
Virtual private network:

A private network constructed over a shared
infrastructure
Virtual: not a separate physical network
Private: separate addressing and routing
Network: a collection of devices that communicate
Policies are key—global connectivity is not the goal
6
Deploying VPNs in the 1990s
Provider Frame Relay Network
DLCI
DLCI
FR Switch
DLCI
CPE FR Switch FR Switch CPE
Operational model
PVCs overlay the shared infrastructure (ATM/Frame Relay)
Routing occurs at customer premise
Benefits
Mature technologies
Relatively “secure”
Service commitments (bandwidth, availability, and more)
Limitations
Scalability and management
Not a fully integrated IP solution
Deploying VPNs in the 21st Century

Corporate
Intranet Branch
Headquarters
Office
Internet
Mobile Users and
Remote Access Telecommuters
Suppliers, Partners
Extranet and Customers
Use IP infrastructure
Can be shared with Internet service
Increasing importance of IP/MPLS (not ATM/FR)
Subscriber benefits
A single network connection for all services
Lower operational expenses
Provider benefits
Multiservice infrastructure that supports all services
Creates additional source of revenue
8
VPN Classification Model
CPE-VPN PP-VPN
CPE CPE PE CPE
Subscriber Subscriber Subscriber
Site 1 VPN Tunnel Site 2 Site 1
PE PE
PE
PE
Subscriber Subscriber Subscriber
Site 3 VPN Site 3 Site 2
PE
CPE CPE CPE
Customer-managed VPN solutions (CPE-VPNs)

Layer 2: L2TP and PPTP
Layer 3: IPsec tunnel mode
Provider-provisioned VPN solutions (PP-VPNs)
Layer 3: MPLS-based VPNs (RFC 2547bis)
Layer 3: Non-MPLS-based VPNs (Virtual Routers)
Layer 2: MPLS VPNs
Layer 2 CPE-
CPE-VPNs: L2TP and PPTP
V.x modem L2TP

Dial access
L2TP tunnel access server
server
Dial Access Provider Service Provider or VPN

PPP dial-up
Dial access PPTP
PPTP tunnel access server
server
Application
Dial access for remote users
Layer 2 Tunneling Protocol (L2TP)
RFC 2661
Combination of L2F and Point-to-Point Tunneling Protocol
Point-to-Point Tunneling Protocol (PPTP)
Bundled with Windows and Windows NT
Both support IPsec for encryption
Authentication & encryption at tunnel endpoints
10
Layer 3 CPE-
CPE-VPNs: IPsec Tunnel Mode
Defines the IETF Layer 3 security architecture
Applications
Strong security requirements
Extending VPNs across multiple service providers
Security services include
Access control
Data origin authentication
Replay protection
Data integrity
Data privacy (encryption)
Key management
11
Layer 3 CPE-
CPE-VPNs: IPSec – Example
Public Internet
Corporate Branch
HQ office
CPE CPE
IPSec ESP Tunnel Mode
Routing must be performed at CPE

Tunnels terminate on subscriber premise
Only CPE equipment needs to support IPSec
Modifications to shared/public resources are not required
ESP tunnel mode
Authentication insures integrity(CPE to CPE)
Encrypts original header/payload across internet
Supports private address space
12
Layer 3 CPE-
CPE-VPNs:
IPsec Benefits and Limitations
Public Internet
Corporate Branch
HQ office
CPE CPE
IPSec ESP Tunnel Mode
Benefits
Does not interfere with existing applications—runs at Layer 3
Protected packets are forwarded by existing routers
Limitations
Minimal provider opportunity (except for delivering a reliable and
scalable Internet service)
Note
United States is easing export of encryption technology
IPsec is the subscriber’s “take charge” solution
IPsec is the quickest way to a common pipe
13
Provider - Provisioned VPNs:

Layer 3 vs. Layer 2
Layer 3 Layer 2
Provider's routers Customer maps its Layer
participate in customer's 3 routing to the circuit
Layer 3 routing mesh
Provider's routers Provider delivers Layer 2
manage VPN-specifjc circuits to the customer,
routing tables, one for each remote site
distributes ,routes to Customer routes are
remote sites transparent to provider
CPE routers advertise
their routes to the
provider
14
Layer 3 PP-
PP-VPNs: RFC 2547bis (1/2)
Service Provider Network
CE CE
Site 1 PE PE Site 3
P VRF
VRF
VRF
CE CE
Site 2 P Site 2
P
P
CE VRF CE
Site 3 VRF Site 1
VRF P
PE PE
Application: outsource VPN

Operational model
PE maintains site-specific forwarding tables for each
of its directly connected VPN sites
Conventional IP routing between customer and provider
VPN routes distributed using MP-IBGP
VPN traffic forwarded across provider backbone using MPLS
15
Layer 3 PP-
PP-VPNs: RFC 2547bis (2/2)
Label Distribution Protocol (LDP) or Resource Reservation
Protocol (RSVP) to setup MPLS tunnel through provider
backbone
BGP is used to distribute
Information about the VPN (discovery)
Routing and reachability for the VPN
Labels for per-VPN LSPs (tunneled in PE-PE LSP)
Flexible, policy-based control mechanism
Export “route targets” associate routes to a particular VPN in
the BGP update
Import “route targets” control whether a route will be
accepted into a site-specific forwarding table
16
Layer 3 PP-
PP-VPNs: Virtual Routers
At high level, Virtual Routers (VRs) are similar to
2547
Network Layer (IP) forwarding in PE equipment for
private networks
VPN-specific forwarding tables
PE participates in private network routing
Routing for private nets across public net
is tunneled along with data
VR within PE operates as if it were a normal router in
the private network
Can use MPLS or other tunneling approach
17
Virtual Router Issues

VPN endpoint discovery
Several options (BGP, multicast, LDAP, and more)
Scaling of routing
Many instances of routing have to be run over the
public network
Interoperability
Many VR approaches
None have obtained “traction”
Extranets
Not as natural as 2547bis
18
Layer 3 PP-
PP-VPN Advantages
Subscriber
Outsource WAN infrastructure
Offload routing complexity to provider
Suits small to medium enterprises that do
not wish to build core routing competency
into their organizations
Provider
VPN-specific routing information is not maintained on
all backbone routers
Value-added service (revenue opportunity)
19
Layer 3 PP-
PP-VPN Disadvantages
Policy-based control creates administrative
burden for provider
Scalability and management can be issues for

extremely large networks
Some customers prefer to maintain control of

their routing architecture
20
MPLS
MPLS--Based Layer 2 PP-
PP-VPNs
Layer 2 MPLS-based VPNs
Circuit cross-connec (CCC)
Draft-martini Layer 2 VPNs
Draft-kompella Layer 2 VPNs
Virtual Private LAN Service (VPLS)
21
Circuit Cross-
Cross-connect (CCC)
CCC = Circuit Cross-connect
CCC Table “Good Service SP”
In Out
(Europe Region)
“Good Service SP” LSP1 DLCI 605
(USA Region)
DLCI LSP 1 10.0.0.0
CPE 600 PE
Source PE DLCI CPE
Large Provider 605
DLCI IP/MPLS Network
610 DLCI
PE CPE
608
LSP 2 20.0.0.0
Routing Table CCC Table
In Out In Out CCC Table
10/8 DLCI 600 In Out “Good Service SP”
DLCI 600 LSP 1
20/8 DLCI 610 DLCI 610 LSP 2
LSP2 DLCI 608 (Asia Region)
Provides the foundation for MPLS-based Layer 2 VPNs

Operational model
FR/ATM interface between CPE and PE
Service provider maintains mesh of LSPs between PEs
CPE routes VPN traffic based on subnet/PVC mappings
Ingress PE maps each inbound PVC to a dedicated LSP
Egress PE maps incoming LSP to outbound PVC
22
Circuit Cross-
Cross-connect Issues
Only appropriate for small numbers
of individual private connections
CPE and PE systems are statically configured
Complex initial configuration
Large configuration files
Tedious configuration for adds, moves,
and change
Each DLCI/PVC requires a dedicated LSP
23
MPLS
MPLS--based Layer 2 VPNs
CCC Function
CPE DLCI PE LSPs PE DLCI CPE

600 LSP 5 506
ATM (or LSP 2 LSP 6
ATM (or
Frame Relay) Frame Relay)
DLCI DLCI
610 (MPLS Core) 408
CCC Table CCC Table

In Out In Out
DLCI 600 LSP 2 in LSP 5 LSP 2 in LSP 5 DLCI 506
DLCI 610 LSP 6 in LSP 5 LSP 6 in LSP 5 DLCI 408
Application: very large enterprise or carrier of carriers

Operational model
Leverages CCC technology
Edge routers support MPLS-based Layer 2 VPNs
Core routers support traditional MPLS
Label stacking consolidates multiple DLCIs or PVCs over a single LSP
Routing architecture defined at the customer edge router
24
MPLS
MPLS--based Layer 2 VPNs:
Advantages
Subscriber
Outsourced WAN infrastructure
Easy migration from existing Layer 2 fabric
Can maintain routing control, or opt for managed service
Supports any Layer 3 protocol
Provider
Complements RFC 2547bis
Operates over the same core, using the same outer LSP
Existing Frame Relay and ATM VPNs can be collapsed onto a single
IP/MPLS infrastructure
Label stacking reduces the number of LSPs compared with CCC
No scalability problems associated with storing numerous customer
VPN routes
Simpler than the extensive policy-based configuration
used with 2547
25
MPLS
MPLS--based Layer 2 VPNs:
Disadvantages
Circuit type (ATM/FR) to each VPN site must
be uniform
Managed network service required

for provider revenue opportunity
Customer must have routing expertise (or

opt for managed service)
26
Standards: CPE-Based VPNs
CPE-VPN standards are stable and deployed
RFC 2661 for L2TP
Many RFCs for IPSec
Configuration and provisioning are challenging
Numerous proprietary approaches
Guardian
Checkpoint
Firebox
Infoexpress
27
Standards: Provider-Provisioned
VPNs
RFC 2547 provides overview of benefits
2547bis (Internet-Draft) specifies the details
needed for interoperability
Co-authored by Cisco, Juniper Networks, multiple
service providers, and others
Interoperable products are shipping
Full IETF standardization will take time
Extensions are being considered
OSPF as the PE/CE protocol in BGP/MPLS VPNs
draft-rosen-vpns-ospf-bgp-mpls defines PE router
behavior as ASBR, ABR, and Intemal OSPF router
OSPF Domain-ID supported In JUNOS software
Release 5.0
Multicast in MPLS/BGP VPNs
28
Standards: Provider-Provisioned
VPNs
Summary
layer 2 MPLS VPNs are Internet drafts
draft-kompella-ppvpn-l2vpn (updated version)
supports draft-martini control word-based
encapsulation but has no support of LDP signaling
draft-martini-l2circuit-trans-mpls
draft-martini-l2circuit-encap-mpls
Other standards:
Framework document is Intemet draft that combines
multiple inputs,covers Layer 3 VPNs, and is being
updated to cover Layer 2, CPE PP-VPNs
Requirements document is also Internet draft
Multiple virtual router proposals have been written
but have little industry support
29
Comparison: RFC2547 and MPLS

Layer 2 VPNs
Summary
layer 2 MPLS VPNs are Internet drafts
draft-kompella-ppvpri.f2vpn (updated version)
supports draft-martlnl c.ontrol word-based
encapsulation but has no support of LOP "gnallng
draft-martlnl.f2clrcult-trans-mpls
draft-martlnl-l2clrcult-encap-mpls
Other standards:
Framework document Is Intemet draft that combines
mUltiple Inputs,covers Layer 3 VPNs, and Is being
updated to cover Layer 2, CPE PP-VPNs
Requirements document Is also Internet draft
Multiple virtual router proposals have been written
but have UttIe lndustry support
30
Comparison: RFC2547 and MPLS
Layer 2 VPNs
RFC2547 MPLS Layer 2 VPNs
Ideal for small/medium Ideal for large/corporate
businesses businesses
ISP-managed routing Customer-managed routing
Layer3 Layer 2
MPLS-based MPLS-based
RSVP,LDP RSVP,LDP
Label stacking Label stacking
IP traffic IP traffic
IP multicast
Non IP CPE traffic
31
MPLS VPNs Benefits

Lower costs
lower equipment cost, economies of scale with
common backbone
lower service cost
lower management and support costs
Management can be outsourced to service provider
End users can focus on core competency rather than
on the network
Better connectivity for end users
IP is everywhere
32
A Range of VPN Solutions (1 of 4)
Each customer has different:
Security requirements
Staff expertise
Tolerance for outsourcing
Customer networks vary by size and traffic
volume
Providers differ concerning:
Customer base
Willingness to offer outsourcing
Handling managed router services
33

Customers with very strong security
requirements
Encryption/authentication on customer site
IPSec could be used with any VPN approach
IPSec VPNs are natural (or Layer 2 VPNs)
Customers who want to manage routing fully
Layer 2 VPNs are a natural fit
For example, those who want one instance of OSPF
across entire private network (with VPN and
backdoor links)
Customers just need links between their routers
34
Many customers have limited IP expertise
Want to outsource wide-area interconnection and
routing
RFC 2547bis VPNs are ideal
For remote user access to corporate network
PPTP/L2TP is convenient and effective
Users can access network from anywhere on the
Internet
35

What about virtual router solutions? In the
abstract, virtual routers seem appealing, but…
For customers who outsource routing, puts
unneeded strain on provider network
LSA flooding across provider backbone
For customers with one IGP instance throughout
their network, requires that they coordinate IGP
operation with the provider
Makes sense with one OSPF area across entire
private network, but Layer 2 VPN is ideal in this
case
Unclear whether there is any environment in which
virtual routers are the best VPN solution
36
JUNOS Software Layer 3 VPN
Implementation
Layer 3 VPN support
RFC 2547bis support
Shipping since Release 4.4
LSA flooding across provider backbone
All router platforms support CE, PE, P router functions
Future RFC 2547bis enhancements possible (for
example, multicast)
Standards are still under definition
37
Layer 2 VPN Implementation

CCC support
Support for draft-kompella
Shipping since Release 5.0
All router platforms support CE, PE, and P router
function
Support for draft-martini
Support for VPLS
38
Advanced VPNs
Training Course
Module 2: Layer 3 VPNs
Module Objectives
After successfully completing this module, you will
be able to:
Define the roles of P, PE, and CE routers
Describe the format of VPN-IPv4 addresses
Explain the role of the route distinguisher
Describe the flow of RFC 2547bis control information
Explain the operation of the RFC 2547bis forwarding plane
40
Agenda: Layer 3 MPLS VPNs
RFC 2547bis Terminology
VPN-IPv4 Address Structure
Operational Characteristics
Policy-Based Routing Information Exchange
Traffic Forwarding
41
Customer Edge Routers
Customer Edge
PE CE VPN A
VPN A CE P P
PE
CE
VPN B VPN B
CE PE
Customer Edge (CE) routers

Located at customer premises
Provide access to the service provider network
Can use any access technology or routing protocol for the
CE/PE connection
42
Provider Edge Routers
Provider Edge
PE CE VPN A
VPN A CE P P
PE
CE
VPN B VPN B
CE PE
Provider Edge (PE) routers

Maintain VPN-specific forwarding tables
Exchange VPN routing information with other PE routers
using BGP
Use MPLS LSPs to forward VPN traffic
43
Provider Routers
Provider Routers
PE CE VPN A
VPN A CE P P
PE
CE
VPN B VPN B
CE PE
Provider (P) routers

Forward VPN data transparently over established LSPs
Do not maintain VPN-specific routing information
44
VPN Sites
VPN Sites
PE CE VPN A
VPN A CE P P
PE
CE
VPN B VPN B
CE PE
A site is a collection of machines that can communicate

without traversing the service provider backbone
Each VPN site is mapped to a PE router interface
Routing information is stored in different tables for each
site
45
VPN Routing and Forwarding

Tables (VRFs)
A VRF is created
VPN A for each VPN VPN A
Site 1 connected to the PE Site2
CE
CE––A2 VPN B
Site2
CE–
CE –A1
OSPF
P P PE 2 Routing
Static
VPN B Routes CE
CE––B2
Site 1
VPN A
PE 1
Site 3
CE
CE––A3
E-BGP
CE–
CE –B1 P P PE 3
CE
CE––B3
VPN C CE–
CE –C1 CE
CE––C2
Site 1 VPN C
Site 2
VPN B
Site3
46
VRFs
Each VRF is populated with:
Routes received from directly connected CE routers
associated with the VRF
Routes received from other PE routers
with acceptable BGP attributes
Only the VRF associated with a VPN is used for

packets from a site of that VPN
Provides isolation between VPNs
47
Overlapping Address Spaces

VPN A
10.1/16 10.2/16 Site2
VPN A
Site 1 CE–
CE –A1 CE
CE––A2 VPN B
Site2
P P PE 2
CE
CE––B2
PE 1 10.2/16
PE 3
VPN B VPN A
Site 1 P P Site 3
CE–
CE –B1 CE
CE––A3
CE
CE––B3 10.3/16
10.1/16
10.3/16 VPN B
Site3
48
VPN--IPv4 Address Family
VPN
Route Distinguisher (RD)
Assigned
Type Administrator number Subscriber IPv4 prefix
(2 bytes) (variable (variable (4 bytes)

length) length)
VPN-IPv4 address family

New BGP-4 address family identifier
Route Distinguisher (RD) + Subscriber IPv4 prefix
Route distinguisher disambiguates IPv4 addresses
Supports the private IP address space
Allows SP to administer its own “numbering space”
VPN-IPV4 addresses are distributed by BGP
Uses ‘Multiprotocol Extensions for BGP4’ (RFC 2283)
VPN-IPV4 addresses are used only in the control plane
49

VPN
8 Bytes Route Distinguisher (RD)
Assigned
Type Administrator number Subscriber IPv4 prefix
(2 bytes) (variable (variable (4 bytes)

length) length)
Assigned Number Field: number assigned by the

identified authority for a particular purpose
Administrator Field: identifies an assigned number authority
2 Byte Type Field: determines the lengths of the other two fields
Two values are defined for Type Field: 0 and 1

Type 0: Adm Field = 2 bytes, AN Field = 4 bytes
Adm field must contain an Autonomous System Number (ASN) from IANA
AN field is a number assigned by SP
Type 1: Adm Field = 4 bytes, AN field = 2 bytes
Adm field must contain an IP address assigned by IANA
AN field is a number assigned by SP
Examples: 10458:22:10.1.172/86 or 1.1.1.1:33:10.1/80
50
VPN
Route distinguisher disambiguates
IPv4 addresses
VPN-IPv4 routes
Ingress PE prepends RD to IPv4 prefix
of routes received from each CE
VPN-IPv4 routes are exchanged between PE using BGP
Egress PE converts VPN-IPv4 routes into IPv4 routes
before inserting into site’s routing table
VPN-IPv4 is used only in the control plane
Data plane uses MPLS and IPv4 addressing
51
Using Route Distinguishers

VPN A
10.2/16 Site2
10.1/16 10458:22:10.1/80
VPN A 10458:23:10.1/80 CE–
CE –A2
Site 1 VPN B
BGP Site2
CE–
CE –A1
P P PE 2
CE–
CE –B2
PE 1 10.2/16
PE 3
VPN B VPN A
Site 1 Site 3
P P
CE–
CE –B1 CE–
CE –A3
CE–
CE –B3 10.3/16
10.1/16
10.3/16 VPN B
Site3
52
Operational Model Overview
VPN A
Site2
VPN A CE–
CE –A2
Site 1 VPN B
CE–
CE –A1
Site2
P P
PE 2
PE 1
VPN B CE–
CE –B2
Site 1 PE 3
VPN A
P P Site 3
CE–
CE –B1 CE–
CE –A3
Control Flow
Routing information exchange between CE and PE
Routing information exchange between PEs
LSP establishment between PEs (RSVP or LDP signaling)
Data flow
Forwarding user traffic
53
RFC 2547bis Policies

VPNs defined by administrative policies
Used for connectivity and CoS guarantees
Defined by customers
Implemented by service providers
Full mesh, hub-spoke connectivity, ...

Export route policies
Import route policies
54
Route Distribution
Route distribution is controlled
by BGP Extended Community attributes
Route Target:
Identifies a set of VRFs to which a PE router
distributes routes
Site of Origin:
Identifies the specific site from which a PE router
learns a route
55
Route Targets
Each VPN-IPv4 route advertised through BGP is
associated with a route target attribute
Export policies define what targets are associated
with routes
Upon receipt of a VPN-IPv4 route, a PE router will decide
whether to add that route to a VRF
Import policies define what routes will be added
to a VRF
Route isolation between VRFs is accomplished through
route filtering
SP provisioning tool determines the appropriate export and
import targets
56
Exchange of Routing Information
CE--1
CE CE
CE--2
BGP session
Site 2 PE-
PE -1 PE-
PE -2 Site 1
VRF VRF
CE--3
CE CE
CE--4
Site 1 VRF VRF Site 2
OSPF
10.1/16
CE device advertises route to PE Router

Using traditional routing techniques (OSPF, IS-IS, RIP, BGP,
static routes, etc)
57
CE--1
CE CE
CE--2
BGP session
Site 2 PE-
PE -1 PE-
PE -2 Site 1
VRF VRF
CE--3
CE CE
CE--4
10458:23:10.1/80 OSPF
10.1/16
IPv4 address is added to the appropriate VRF

PE router converts IPv4 address to VPN-IPv4 address
VPN-IPv4 route is installed into the BGP
routing table
58
CE--1
CE CE
CE--2
BGP session
Site 2 PE-
PE -1 PE-
PE -2 Site 1
VRF VRF
CE--3
CE CE
CE--4
10458:23:10.1/80 OSPF
10.1/16
“VPN RED” export
VPN-IPv4 address is associated with an export

target
“VPN RED”
59
CE--1
CE CE
CE--2
BGP session
Site 2 PE-
PE -1 PE-
PE -2 Site 1
VRF VRF
CE--3
CE CE
CE--4
10458:23:10.1/80 OSPF
10.1/16
label Z
Next-
Next-hop PE-
PE-2
VPN-IPv4 route is advertised to other PEs

Inner label
Target
Next-hop
60
“VPN BLUE” import

CE--1
CE CE
CE--2
BGP session
Site 2 PE-
PE -1 PE-
PE -2 Site 1
VRF VRF
CE--3
CE CE
CE--4
“VPN RED” import BGP 10458:23:10.1/80 OSPF

10.1/16
label Z
Next-
Next-hop PE-
PE-2
Each PE is configured with import targets

Import target is used to selectively incorporate VPN-IPv4
routes into VRFs
If import target matches target attribute in BGP route, the route
is incorporated into VRF
Based on configured import policies, 10458:23:10.1/80 is
incorporated in the red VRF but not the blue VRF
61

CE--1
CE CE
CE--2
BGP session
Site 2 PE-
PE -1 PE-
PE -2 Site 1
VRF VRF
CE--3
CE CE
CE--4
10458:23:10.1/80 BGP 10458:23:10.1/80 OSPF

10.1/16
BGP label (inner) label ((Z
Z) “VPN RED” export
IGP (outer) label (y) label Z
Next-
Next-hop PE-
PE-2
Each VPN-IPv4 route in a VRF is associated with:

Inner label to reach the advertised NLRI
Outer label to reach the PE (carried in BGP Next-Hop)
Multiple routes from the same CE may
share the same label
62

CE--1
CE CE
CE--2
BGP session
Site 2 PE-
PE -1 PE-
PE -2 Site 1
VRF VRF
CE--3
CE CE
CE--4
OSPF,…
10.1/16 Next-
Next-hop PE1
Each IPv4 route received in a VRF could be advertised to

the CEs associated with the VRF
Via RIP, OSPF, IS-IS or BGP, or static routes
63
Data Flow
CE-1 CE-2
Site 2 PE-1 PE-2 Site 1
VRF VRF
CE-3 CE-4
VRF
Site 2
Site 1 VRF
(10.1/16)
The PE to PE LSP must be in place before forwarding

data across the MPLS backbone
LSPs are signaled through LDP or RSVP
64
Data Flow
CE-1 CE-2
VRF VRF
CE-3 CE-4
VRF
Site 2
Site 1 VRF
(10.1/16)
IP
10.1.2.3
The CE performs a traditional IPv4 lookup and sends

packets to the PE
65
Data Flow
PE-1
1) Lookup route in
Red FT
2) Push BGP label (Z)
3) Push IGP label (Y)
CE-1 CE-2
VRF VRF
CE-3 CE-4
VRF
Site 2
Site 1 VRF
(10.1/16)
IP
10.1.2.3
The PE consults the appropriate VRF for the inbound

interface
Two labels are derived from the VRF route lookup and
“pushed” onto the packet
66
Data Flow
PE-1
1) Lookup route in
Red FT
2) Push BGP label (Z)
3) Push IGP label (Y)
CE-1 CE-2
VRF VRF
CE-3 CE-4
VRF
Site 2
Site 1 VRF
(10.1/16)
IGP label (Y)
BGP label (Z)
IP
10.1.2.3
Packets are forwarded using two-level label stack

Outer IGP label
Identifies the LSP to egress PE router
Derived from core’s IGP and distributed by RSVP or LDP
Inner BGP label
Identifies outgoing interface from egress PE to CE
Derived from BGP update from egress PE
67
Data Flow
CE-1 CE-2
VRF VRF
CE-3 CE-4
VRF
Site 2
Site 1 VRF
(10.1/16)
IGP label (x)
BGP label (z)
IP
10.1.2.3
After packets exit the ingress PE, the outer label is used
to traverse the service provider
P routers are not VPN-aware
68
Data Flow
Penultimate
Pop top label
CE-1 CE-2
VRF VRF
CE-3 CE-4
VRF
Site 2
Site 1 VRF
(10.1/16)
BGP label (z)

IP
10.1.2.3
The outer label is removed through penultimate hop

popping (before reaching the egress PE)
69
Data Flow
CE-1 CE-2
VRF VRF
CE-3 CE-4
VRF
Site 2
Site 1 VRF
(10.1/16)
IP
10.1.2.3
The inner label is removed at the egress PE

The native IPv4 packet is sent to the outbound interface
associated with the label
70
Advanced VPNs
Training Course
Module 3: Basic Layer 3 VPN

Configuration with JUNOS Software
Module Objectives
After successfully completing this module, you
will be able to:
Create VRFs
Write and apply VRF policy
Configure BGP, extended communities
Configure a point-to-point Layer 3 VPN topology
using RSVP
72
Agenda: Configuring Layer 3 VPNs
Preliminary Steps
PE Configuration
VRF Instance
Assign Route Distinguisher
Associate VRF Interfaces
VRF Policy
Create and Apply BGP Extended Communities
PE-CE Routing Protocol
AS-Override
Site of Origin Community
OSPF Domain Identifier Community
73
2547bis Preliminary Configuration

Preliminary steps:
1. Choose and configure the IGP for PE and P routers
2. Configure MP-IBGP peering among PE routers
Must include VPN-IPv4 NLRI capability
3. Enable the LSP signaling protocol(s)
4. Establish LSPs between PE routers
The PE routers perform VPN-specific
configuration
74
Introduction to VPN Routing Tables
VPN routing table
inet.0
Main IP routing table, relevant for IGP and BGP
inet.3
RSVP and LDP routes installed, relevant for BGP only
vpn.inet.0
Stores all unicast IPv4 routes received from directly
connected CE routers and all explicitly configured static
routes in the routing instance
For each vpn.inet.0 routing table, one forwarding table is
maintained
bgp.l3vpn.0
Stores all VPN-IPv4 unicast routes received from other PE
routers
This table is present only on PE routers－routes are resolved
using the information in the inet.3 routing table
mpls.0
Mpls-switching table
vpn.mpls.0
Mpls-switching table per vpn-incoming interface
75
PE-PE MP-IBGP Peering

PE-to-PE MP-IBGP sessions require VPN-IPv4 NLRI
JUNOS software automatically negotiates BGP route
refresh
[edit]
lab@AmSterdam# show protocol bgp
group int {
type internal;
local-address 192.168.24.1;
family inet {
unicast;
}
family inet-vpn {
unicast;
}
neighbor 192.168.16.1;
}
76
MP-IBGP Peering: PE-PE
lab@Amsterdam> show bgp neighbor
Peer: 192.168.16.1+179 AS 65412 Local: 192.168.24.1+1048 AS 65412
Type: Internal State: Established Flags: < >
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None .
Options: <Preference LocalAddress HoldTime AddressFamily Rib-group Refresh>
Address families configured: inet-unicast inet-vpn-unicast
Local Address: 192.168.24.1 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.16.1 Local ID: 192.168.24.1 Active Holdtime: 90
Keepalive Interval: 30
NLRI advertised by peer: inet-unicast inet-vpn-unicast
NLRI for this session: inet-unicaat inet-vpn-unicast
Peer support Refresh capability (2)
Table inet.O Bit: 10000
Send atate: in sync
Active prefixes: 0
Received pref1xes: 0
Suppressed due to damping: 0
Table bgp.l3vpn.O Bit: 30000
Send state: in sync
Active prefixes: 8
Received prefixes: 8
Table vpna,inet.O Bit; 40000
Send state: in sync
Active prefixes: 7
77
PE Configuration
PE routers do all VPN-specific configuration
PE routing instance
Create routing instance and list associated VRF
interfaces
Assign a route distinguisher
Link the VRF to import and export policies
Configure PE-CE routing protocol properties
VPN policy
Create and apply BGP extended communities (for
example, route target/site of origin)
Create VRF import and export policies
78
Sample Layer 3 VPN Topology
Provider Core AM Fe-0/0/0 2
CE
2
172.20.0-3/24 OSPF Area 0 Lo0:192.168.24.1 1 29/24 B
1 2 1 Fe-0/0/1
AS 65001 P1 P2
16/24 2 1/24 24/24 172.20.4-7/24
192.168.20.1 Fe-0/0/1
AS 65001
CE 2 Fe-0/0/0
HK 1 AS 65412 192.168.28.1
1
A 21/24 Lo0:192.168.14.1
Network characteristics
Interface addressing is 10.0.x.x/24 (except loopbacks)
IGP is single-area OSPF
RSVP signaling between PE devices, LSPs established
between PE routers (CSPF not required)
Full MP-IBGP mesh between PE routers, lo0 peering, VPN-
IPv4 NLRI .
CE-PE link running EBGP
Full-mesh Layer 3 VPN between CE-A and CE-B
Actual lab topology will differ-this is a sample network
79
VRF Routing Instances

VRFs are created at the [edit routing-
instances] configuration hierarchy
[edit routing-instances vpna]
lab@HK# set ?
Possible completions:
+ apply-groups Groups from which to inherit
configuration data
instance-type Type of routing instance
> interface Interface name for this routing instance
> protocols Routing protocol configuration
> route-distinguisher Route Distinguisher for this instance
> routing-options Protocol-independent routing option
configuration
+ vrf-export Export Policy for vrf instance RIBs
+ vrf-import Import Policy for vrf instance RIBs
vrf-table-label Advertise a single VPN label for all routes
in the VRF
80
A Sample VRF Configuration
Creating a VRF called vpn-a with BGP running between
the PE and CE
[edit routing-instances vpn-a]
lab@HK# show
instance-type vrf;
interface fe-0/0/0.0;
route-distinguisher 192.168.16.1:1;
vrf-import vpna-import;
vrf-export vpna-export;
protocols {
bgp {
group ce-a {
type external;
peer-as 65001;
neighbor 10.0.6.2;
}
}
}
81
Sample VRF Import Policy

Installs routes learned from other PE routers using MP-
IBGP
Routes with the specified community are installed in the
associated VRF
[edit policy-options]
lab@HK# show policy-statement vpna-import
term 1 {
from {
protocol bgp;
community vpna-target;
}
then accept;
}
term 2 {
then reject;
}
}
82
Sample VRF Export Policy
lab@HK# show policy-statement vpn-a-export
term 1 {
from protocol bgp;
then {
community add vpn-a-target;
community add ce-name-origin;
accept;
}
}
term 2 {
then reject;
}
This policy advertises routes learned from BGP from the
CE, while adding the route target and origin communities
Matching routes are sent to MP-IBGP peers that have
advertised VPN-IPv4 NLRI capabilities
83
Extended BGP Communities
community ce-name-origin members origin:192.168.16.1:100;
community vpn-a-target members target:65412:100;
The origin tag allows the specification of site of

origin community
So0 can be used to prevent routing loops when a user
has multiple AS numbers
The target tag specifies the route target
Policy matches on the route target control which
routes are imported into a given VRF
Boolean operations possible
84
PE-CE Policy
JUNOS software import/export policies can be

applied to VRF instances
BGP and RIP allow both import and export
Link-state protocols allow only export
Affects routes being sent and received over the
PE-CE link
85
PE-CE BGP Routing/Policy Example

lab@Hong-Kong # show routing-instances
vpna {
………………
}
protocols {
bgp {
import site-a;
group ext {
type external;
peer-as 65001;
as-override;
neighbor 10.0.21.2;
}
}
}
[edit]
lab@Hong-Kong # show policy-options policy-statement site-a
from protocol bgp;
then {
as-path-prepend "64512 64512“;
community add cust-a;
accept;
}
86
AS Override
Use this knob when CE routers belong to the same AS

Causes the PE router to overwrite CE-A's AS # with the
provider's AS # (two provider AS #s in AS-path)
The autonomous-system loops n knob can also be used
remove-private can also work if private AS numbers are
in use

CE
2
OSPF Area 0 Lo0:192.168.24.1 1 29/24 B
1 2 1 Fe-0/0/1
172.20.0-3/24 P1 P2
16/24 2 1/24 24/24 172.20.4-7/24
AS 65001 Fe-0/0/1
172.20.0-3/24 AS 65001
CE 2 Fe-0/0/0
HK 1 AS 65412
1
AS 65412 65412 t
A 21/24 Lo0:192.168.14.1
172.20.0-3/24
AS 65001 t
87
Advanced VPNs
Training Course
Module 4: Troubleshooting
Layer 3 VPNs
Module Objectives
After successfully completing this module, you will be
able to:
Explain the purpose of the vpn-interface switch
Describe why pinging a multi-access VRF interface can be
problematic, and list two ways of making it work
Explain how you can make PE-based traceroutes reveal P
router hops
View PE-PE control now
Describe the Difference between the bgp.l3vpn table and a
VRF
View a layer 3 VPN's VRF and forwarding tables
Monitor the operation of the PE-CE routing protocol
89
Agenda: Troubleshooting Layer 3 VPNs

A Layered Approach
The vpn-interface Switch
Multi-Access VRF Interface Issues
PE- and CE-Based Traceroutes
Viewing VRF Tables and PE-PE Signaling Flow
Monitoring PE-CE Routing Protocols
90
RFC 2547bis Troubleshooting
Best to take a layered approach
Core vs. PE/CE problems
Physical layer, data-link layer, IGP, BGP, MPLS, VPN
configuration and import/export policy
vpn-interface switch for ping, traceroute, Telnet, and
SSH
Routing traffic originated on the PE-CE link for multi-
access interfaces requires special steps
Release 5.2 supports vrf-table-label enhancement
Permits Internet Processor II operations, like ARP, at egress
PE router
91
Troubleshooting: A Layered
Approach
AM
Provider Core CE
P1 P2
HK
CE
Core Problems:
PE-CE Problems: IGP PE-CE Problems:
IGP/EBGP MPLS(RSVP/LDP) IGP/EBGP
Policy IBGP Policy
PE-PE Problems: PE-PE Problems:

VRF-Export VRF-Export
Data Forwarding
92
CE
2
172.20.0-3/24 OSPF Area 0 Lo0:192.168.24.1 1 29/24 B
1 2 1 Fe-0/0/1
AS 65001 P1 P2
16/24 2 1/24 24/24 172.20.4-7/24
192.168.20.1 Fe-0/0/1
AS 65001
CE 2 Fe-0/0/0
HK 1 AS 65412 192.168.28.1
1
A 21/24 Lo0:192.168.14.1
Interface addressing is 10.0.x.x/24 (except loopbacks)
IGP is single-area OSPF
Full MP-IBGP mesh between PE routers, lo0 peering,
VPN-IPv4 NLRI
CE-PE link running EBGP
Full-mesh Layer 3 VPN between CE-A and CE-B
Actual lab topology will differ－
－this network is a sample
93
PE-PE Troubleshooting
Is the core IGP operational?

Are the PE-PE BGP sessions established
IPv4-VPN family?
Are the RSVP/LDP LSPs established between PE
routers?
Do any hidden routes exist?
94
PE-CE Troubleshooting
Is the PE-CE routing protocol operational?

Are the CE routes present in the VRF? .
Watch for maximum-routes prefix limits !
Do pings between PE routers and CE device work?
Is the PE router Internet Processor II equipped?
Are the VPN routes being sent to remote PE routers?
Are the VPN routes being received? ,
Lack of received routes in bgp.l3vpn.0 indicates PE
router does not have any matching route targets
Lack of routes in a particular VRF indicates problems
with the VPN import policy
Are the VPN routes being sent to the CE device?
Are static routes in place to support traffic originated
on multi-access VRF interfaces?
95
The vpn-interface Command

lab@Hong-Kong> ping 10.0.21.1 count 1 .
PING 10.0.21.1 (10.0.21.1): 56 data bytes
ping: send to: No route to host
^c
--- l0.0.21.1 ping statistics ---
1 packets transmitted, 0 packets received. l00% packet loss
lab@Hong-Kong> ping vpn-interface fe-0/0/0 10.0.21.1 count 1

PING 10.0.21.1 (10.0.21.1): 56 data bytes
64 bytes from 10.0.21.1: icmp_seq=0 ttl=255 time=0.334 ms

1 packets transmitted, 1 paekets received. 0% packet loss
round-trip min/avg/max/stddev = 0.334/0.334/0.334/0.000 ms
VRF interface is not installed in inet.0

The vpn-interface switch associates the packet with
a particular VRF table
Primarily intended for local PE-CE communications using
Telnet, SSH, pings, and traceroute
Currently does not support FTP
96
CE-CE VRF Interface Pings
Not an issue for point-to-point interfaces
Multi-access technologies (GE/FE) require special
steps to facilitate ARP
Exporting direct routes from PE router work in JUNOS
software release 5.0 and later
Requires that the PE router has learned at least one route
(static/dynamic) with the CE device as a next hop
Release 5.2 vrf-table-label enhancement
Release 4.4 requires static routes (shown below)
lab@Hong-kong# sbow routing-instance
vpna {
instance-type vrf;
interface fe-0/O/O.O;
vrf-export vpna-expore;
routing-options {
static {
/* ce-ce traffic */
route 10.0.21.2/32 next-hop 10.0.21.2;
/* pe-pe and CE-CE traffic */
route 10.0.21.0/30 next-bop 10.0.21.2;
}
}
97
Static Routes for PE-CE Link

Amsterdam's 10.0.29/24 direct route is unusable (has
only one label)
Amsterdam's exported static routes have two labels
(VRF/RSVP)
lab@Hong-Kong# show route forwarding-table vpn vpna destination 10.0.29/24

Routing table: vpna.inet
Internet:
Destination Type RtRef Nexthop Type Index NhRef Netif
10.0.29.0/24 user 0 10.0.16.2 Push 100008 fe-0/0/1.0
lab@Hong-Kong# show route forwarding-table vpn vpna destination 10.0.29.2

Internet:
10.0.29.2/32 user 0 10.0.16.2 Push 100000 Push 100008(top) fe-0/0/1.0
lab@Hong-Kong# show route forwarding-table vpn vpna destination 10.0.29.0

Internet:
10.0.29.0/32 user 0 10.0.16.2 Push 100000 Push 100008(top) fe-0/0/1.0
98
Internet Processor II Functionality
at Egress PE Router
Starting with Release 5.2, vrf-table-label option in VRF
configuration
Uses LSP sub-interface (LSI) abstract
Creates an LSI that maps to each VRF
Supported core-facing interfaces map reserved MPLS labels to
each VRF LSI
Allows FPC I/O manager ASIC to strip VRF label and map
packets to correct VRF
Internet Processor II can now perform key lookup on IP packet
Requires that core-facing interfaces be non-channelized and
configured for HDLC/PPP encapsulation
Not supported for MP-BGP-Labeled routes (carrier of carriers
/interprovider)
Operational display changes
99
PE-PE VRF Interface Pings

Not really necessary as local PE-CE pings can be used at both
ends .
Multi-access technologies require:
Static routes for multi-access VRF interfaces in Release 4.4
Redistribution of PE router's direct VRF interface route in Release
5.0
Otherwise traffic cannot be sourced from the PE-CE
subnet
Might require local switch to source traffic from PE router's
VRF interface, on older versions of JUNOS software
lab@Hong-Kong> ping vpn-interface fe-0/0/0 10.0.29.2 count 1
PING 10.0.29.1 (10.0.29.1): 56 data bytes
ping: send to: No route to host
^c
1 packets transmitted, 0 packets received. l00% packet loss
lab@Hong-Kong> ping vpn-interface fe-0/0/0 local 10.0.29.1 10.0.21.1 count 1

PING 10.0.29.2 (10.0.29.2): 56 data bytes

100
Traffic Path for PE-PE Pings
CE
2
OSPF Area 0 Lo0:192.168.24.1 1 29/24 B
1 2 1 Fe-0/0/1
16/24 2
P1 1/24
P2 24/24
Fe-0/0/1
CE 2 Fe-0/0/0
HK 1 AS 65412
1
A 21/24 Lo0:192.168.14.1
Echo Request (10.0.21.1-> 10.0.29.1)
Echo Reply (10.0.29.1-> 10.0.21.1)
Internet Processor and ARP processing not available at egress PE router
lab@Hong-Kong> ping vpn-interface fe-0/0/0 10.0.29.1

PING 10.0.29.1 (10.0.29.1): 56 data bytes
^c
101
PE-Based Traceroute: PE-CE Link
Sourcing the traffic from VRF interface allows

remote CE device to respond
P router hops time out due to lack of VRF routes in
the core
lab@Hong-Kong> •••• fe-0/0/0 192.168.28.1 source 10.0.21.1
traceroute to 192.168.28.1 (192,168.28.1) from 10.0.21.1, 30 hops
Max, 40 byte packets
1 * * *
2 * * *
3 10.0.24.2 (10.0.24.2) 0.754 ms 0.686 ms 0.648 ms
MPLS Label=l00000 CoS=0 TTL=1 S=1
4 192.168.28.1 (192.168.28.1) 0.692 ms 0.683 ms 0.654 ms
102
CE-CE-Based Traceroute
Core router hops are hidden because outer label's TTL is set to 255
lab@CE-a# traceroute 192.168.28.1
traceroute to 192.168.28.1 (192.168.28.1). 30 hops max, 40 byte packets
1 l0.0.21.1 (10.0.6,1) 0.444 ms 0.352 ms 0.341 ms
2 10.0.24.2 (10.0.3.7) 0.769 ms 0.702 ms 0.694 ms
MPLS Label=100000 CoS=0 TTL=1 S=1
3 192.168.28.1 (192.168.28.1) 0.483 ms 0.440 ms 0.431 ms
CE-CE traceroute protocol capture:

Frame 3l (62 on wired, 62 on captured)
Ethernet II
MultiProtocol Label Switching Header
MPLS Label: unknown (100011)
MPLS Experimental Bits: 4
MPLS Bottom Of Label Stack: 0
MPLS TTL: 254
MPLS Label. unknown (100001)
MPLS Bottom Of Label Stack: 1
MPLS TTL: 1
Internet Protocol
User Datagram Protocol
Data (12 bytes)
103
Ping/Traceroute Summary
Key review points regarding PE-CE ping and traceroute
testing:
The vpn-interface switch is needed when testing VPN
connectivity from PE routers
Multi-access links require special steps to ensure the
VRF interface is a labeled route
Without these steps. traffic cannot be sourced from the
VRF interface
JUNOS software Release 4.4 requires /30 static routes
With JUNOS Software Release 5.0, the PE router can simply
redistribute the direct route associated with the VRF
interface－
－requires at least one other route
(dynamic/static) pointing to the CE device
Inclusion of local/source switch when PE router
originates traffic determines core vs. PE-CE hops
Can test proper PE-CE VRF interface functionality locally
Can verify core using standard tools－－PE-PE VRF pings
are not really necessary
104
Examining Routes in a VRF
JUNOS software allows the viewing of a VRF with the show
route table vpn-name command
VRFs contain:
The matching routes learned from remote PE routers
Routes learned over the PE-CE link or static routing entries
The bgp.l3vpn.0 table contains all routes learned from other
PE routers with at least one matching route target
Functions as a RIB-In for VPN routes
NLRI updates that do not match at least one VRF are discarded
keep all is useful for troubleshooting route target-related
problems-use only for troubleshooting!
The show route protocol bgp command displays all BGP
routes in all RIBs
Output can be filtered by providing a prefix/mask or by piping
to match or find
105
Viewing the Route Table: Example 1

lab@Hong-Kong> show route table vpna
vpna.inet.O: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)

+ = Active Route. - = Last Active, * = Both
10.0.21.1/32 * [Local/O] 1d 00:26:02

Local
10.0.21.2/32 * [Static/5) 20:36:30
> to 10.0.21.2 via fe-0/0/0.0
10.0.29.1/32 * [BGP/170] 1d 01:19:53, localpref 100, from 192.168.24.1
AS path: I
> to 10.0.16.2 via ge-0/l/0.0, label-switched-path am
172.20.0.0/24 * [BGP/170] 23:23:04, localpref 300
AS path: 65001 I
> to 10.0.21.2 via fe-0/0/0.0
172.20.1.0/24 * [BGP/170] 23:23:04. localpref 300
106
Viewing the Route Table: Example 2
lab@Hong-Kong> show route table vpna 172.20.4.O detail
vpna.inet.0: 16 destinations, l6 routes (16 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
172.20.4.0/24 (1 entry, 1 announced)

*BGP Preference 170/-101
Route Distinguisher. 192.168.24.1:1
Source: 192.168.24.1
Nexthop: 10.0.16.2 via ge-0/1/0.0, selected
label-awitchad-path am
Push 100000, Push 100001(top)
State: <Secondary Active Int-Ext>
Local As: 65412 Peer AS: 65412
Age: 1d 1:34:25 Metrics: 40
Task: BGP_65412.192.168.24.1+1048
Announcement bits (2): O-BGP.O.O.O.O+179 1-KRT
AS path: 65001 I
Comunities: target:65412:lOO origin:l92.168.24.l:1
BGP next hop: 192.168.24.1
Localpref: 100
Router ID: 192.168.24.1
Primary Routing Table bgp.l3vpn.O
107
Viewing the bgp.l3vpn.0 RIB

Displays all Layer 3 VPN NLRI with at least one matching
route target
keep all useful for troubleshooting
Enabled by default on route reflectors
Must be explicitly set on confederation C-EBGP speakers
lab@AM> show route table bgp.l3vpn
bgp.l3vpn.O: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active * = Both
192.168.16.1:1:172.20.0.0/24
*[BGP/170] 14:28:30, localpref 100, from 192.168.5.1
AS path: 65000 I
> to 10.0.0.2 via fe-0/0/0.0, label-switched-path HK
192.168.16.1:1:172.2041.0/24
*[BGP/170] 14:28:30, localpref 10, from 192.168.5.1
AS path: 65000 I
192.168.16.1:1:172.20.2.0/24
*[BGP/170] 14:28:30. localpref 100, from 192.168.5.1
AS path: 65000 I
108
Viewing Routes Sent to Other
PE Routers
Use the show route advertising-protocol bgp peer-
address command
lab@Hong-kong >...advertising-protocol bgp 192.168.24.1 172.20.0.0 detail
vpn.inet.0: 16 destinations, 16 route, (16 active, 0 holddown, 0 hidden)

Prefix Nextbop MED lclpref AS path
172.20.0.0/24 (1 entry, 1 announced)
BGP group int type Internal
Route Distinguisher: 192.168.16.1:1
Advertised Label: 100001
Nexthop: Self
Localpref: 3OO
AS path: 65001 I
Communities: 65412:666 target:65412:l00 origin:192.168.8.1:1
109
Viewing Routes Received from

Other PE Routers
Use the show route receive-protocol bgp peer-
address Command
lab@Hong-Kong> show route receive-protocol bgp 192.168.24.1
inet.O: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)

Prefix Nextbop MED Lclpref AS path
……………
vpna.inet.O: 16 destinations, l6 routes (16 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
……………
172.20.4.0/24 192.168.24.1 100 65001 I
……………
bgp.l3vpn.O: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

……………
192.168.24.1:1:172.20.4.0/24
192.168.24.1 100 65001 I
110
Viewing a VPN Forwarding Table
Use the show route forwarding-table vpn
vpn-name command
lab@Hong-Kong > show route forwarding-table vpn vpna
Internet:
Default perm 0 dscd 6 1
10.0.21.0/24 intf 0 recv 51 1 fe-0/0/0.0
10.0.21.0/32 dest 0 10.0.21.0 recv 49 1 fe-0/0/0.0
10.0.21.1/32 intf 0 10.0.21.1 locl 50 2
10.0.21.1/32 dest 0 10.0.21.1 locl 50 2
10.0.21.2/32 dest 1 0:d0:b7:3f:af:73 ucst 52 8 fe-0/0/0.0
10.0.21.255/32 dest 0 10.0.21.255 bcst 48 1 fe-0/0/0.0
10.0.29.0/24 user 0 10.0.16.2 Push 100008, fe-0/0/1.0
172.20.0.0/24 user 0 10.0.21.2 ucst 52 8 fe-0/0/0.0
112.20.1.0/24 user 0 10.0.21.2 ucst 52 8 fe-0/0/0.0
172.20.2.0/24 user 0 10.0.21.2 ucst 52 8 fe-0/0/0.0
172.20.3.0/24 user 0 10.0.21.2 ucst 52 8 fe-0/0/0.0
172.20.4.0/24 user 0 10.0.16.2 Push 100000, Push 100008(top) fe-0/0/1.0
192.168.20.1/32 user 0 10.0.21.2 ucst 52 8 fe-0/0/0.0
111
Clearing VRF ARP Entries

Use the clear arp vpn vpn-name command
lab@Hong-kong> show arp
MAC Address Address Name Interface
OO:bO:d0:1O:7J:2f 10.0.1.100 10.0.1.100 fxp0.0
0O:dO:b7:3f:af:Of 10.0.1.200 10.0.1.200 fxp0.0
OO:dO:b7:3f:ad:d5 10.0.16.2 10.0.16.2 fe-0/0/1.0
OO:dO:b7:3f:af:73 10.0.21.2 10.0.21.2 fe-0/0/0.0
TOtal entries: 4
lab@Hong-Kong> clear arp

10.0.1.200 10.0.1~200 deleted
10.0.1.100 lO.O.1.10 deleted
10.0.16.2 10.0.16.2 deleted
10.0.16.2 10.0.16.2 deleted
lab@Hong-Kong> clear arp vpn vpna

10.0.21.2 10.0.21.2 deleted
The show arp command displays both inet.0

and VRF ARP entries
112
Monitoring PE-CE BGP Operation
Use the standard BGP CLI operational mode
commands:
show bgp neighbor ce
show bgp summary
show route advertising-protocol bgp ce
show route receiving-protocol bgp ce
show route protocol bgp source-gateway ce
Standard JUNOS software tracing options available for
PE-CE routing instance
113
Advanced VPNs
Training Course
Module 5: Layer 2 VPNs (Kompella)

Module Objectives
After successfully completing this module, you will be
able to:
Describe the benefits of provisioning layer 2 VPNs over an
IP core
State the roles of CE, PE, and P routers in a Layer 2 VPN
Explain the signaling flow used in the Kompella draft
Describe the draft-kompella forwarding approach
State the benefits of over-provisioning a Layer 2 VPN
based on the Kompella draft
Explain the function of VPN forwarding and connection
tables (VFTs and VCTs)
115
Agenda: Layer 2 MPLS VPNs

Overview of Layer 2 Provider-Provisioned
VPNs
Draft-Kompella Operational Model: Control
VFTs
VCTs
Provisioning
Draft-Kompella Operational Model: Data
Forwarding
116
Differences between Kompella and
Martini
Kompella Martini
Auto Provisioning BGP Based Not Defined
Layer 2 Frame Format Martini Encapsulation Martini Encapsulation

IPv4 Layer2
Internetworking
Defined Not Defined
VPN Signaling BGP LDP

Interprovider and Carrier
of Carrier
Defined Not Defined
ATM Modes AAL5, Cell AAL5, Cell
QoS Not Defined Not Defined
IETF Status Internet-Draft Internet-Draft
Vendor Support Three Many
Juniper Support Yes Yes

117
Layer2 Provider-Provisioned VPNs

In the past, providers have used a single ATM
core to support Internet and VPN traffic
ATM PVCs for Internet traffic (ISP)
ATM PVCs for VPNs
ATM interfaces are inefficient and too slow for
core Internet use
Providers are pushed into two core networks
Why not support both Internet and VPN traffic
over an MPLS core?
Map Frame Relay, ATM, and VLANs to MPLS LSPs
Layer 3 VPNs can operate over the same core
118
Layer 2 Provider-Provisioned
MPLS-Based VPNs
Provider edge device delivers Layer 2 circuit
IDs (DLCI, VPI/VCl, or VLAN ID) to the
customer
Customer sees standard Layer 2 circuit identifiers
for each reachable site
PE router maps circuit IDs to and from MPLS
LSPs for transport over the provider core
Can use label stacking to improve scalability
Customer maps its own routing architecture to
the circuit mesh
Customer routes are transparent to provider
Separation of administrative responsibility
119
Improving Traditional Layer2 VPNs

with MPLS
Decouple edge (customer-facing) technology
from core technology
Have a single network infrastructure for
multiple services
Simplify provisioning
120
Standards for Layer 2 VPNs
Two proposals:
Draft-Kompella
draft-kompella-mpls-l2vpn-02.txt
Draft-Martini
draft-martini-l2circuit-trans-mpls-06.txt
draft-martini-l2circuit-encap-mpls-02.txt
Proposals are similar in data plane
Both support a wide range of Layer 2 technologies
Proposals are different in control plane
121
Customer Edge Devices
VPN Site Customer Edge
PE CE VPN A
VPN A CE P P FR
PE
FR
ATM
CE
VPN B VPN B
ATM
CE PE
Customer Edge (CE) device

Router or switch device located at customer premises providing access
to the service provider network
Layer 2 (FR, ATM, Ethernet) and Layer 3 (IP, IPX, SNA …) independence
of the service provider network
Both ends of a connection within a VPN must use the same Layer 2 technology
Different connections may use different Layer 2 technology
Requires a logical connection per remote CE
122
Provider Edge Routers
Provider Edge
PE CE VPN A
VPN A CE P P FR
PE
FR
ATM
CE
VPN B VPN B
ATM
CE PE
Provider Edge (PE) Routers

Maintain VPN-related information
Exchange VPN-related information with other PEs
Using BGP or LDP for draft-kompella
Using LDP for draft-martini
Use MPLS LSPs to carry VPN traffic between PEs
123
Provider Routers
Provider Routers
PE CE VPN A
VPN A CE P P FR
PE
FR
ATM
CE
VPN B VPN B
ATM
CE PE
Provider (P) routers

Forward VPN traffic transparently over established LSPs
Do not maintain VPN-specific forwarding information
124
Draft-
Draft-Kompella:
VPN Forwarding Tables (VFT
(VFTs)
s)
A VFT is created
VPN A for each CE VPN A
Site 1 connected to the PE Site2
CE
CE––A2 VPN B
Site2
CE–
CE –A1 ATM
P P PE 2
ATM
VPN B CE
CE––B2
Site 1
VPN A
PE 1
Site 3
CE
CE––A3
ATM
CE–
CE –B1 P P PE 3
Each VFT is populated with:

The information provisioned for the local CEs
VPN Connection Tables received from other PEs via BGP or LDP
125
Draft-
Draft-Kompella:
VPN Connection Tables (VCT
(VCT))
AVVCT
CT is distributed for
each VPN site to PEs
PEs
CE-1 CE-2
BGP session / LDP Site 1
Site 2 PE-1 PE-2
VFT VFT
CE-2 CE-4
Site 1 VFT VFT Site 2
The VCT is a subset of information held by the VFT

VCTs are distributed by the PEs via BGP or LDP
126
Draft-
Draft-Kompella:
Provisioning the Network
VPN A
Site2
VPN A
CE–
CE –A2
Site 1 VPN B
CE–
CE –A1
Site2
FR
P P
FR
PE 2
PE 1 CE–
CE –B2
VPN B
Site 1
FR
VPN A
P P Site 3
PE 3
CE–
CE –B1 CE–
CE –A3
LSPs between PEs must be pre-established

via RSVP-TE, LDP, or LDP over RSVP-TE
LSPs may be used for many services: Internet, L2 VPN, L3 VPN
May be provisioned independent of Layer 2 VPNs
127
Draft-
Draft-Kompella: Provisioning Customer
Site on PE
CE-4 Routing Table
CE-4 DLCIs
63 In Out
75
10/8 DLCI 63
82
94 20/8 DLCI 75
30/8 DLCI 82
- DLCI 94
List of DLCIs: one for each remote CE, some spare for over-
provisioning
DLCIs independently numbered for each CE
LMI, inverse ARP and/or routing protocols for auto-
discovery and learning addresses
No changes as VPN membership changes
Until over-provisioning runs out
128
Draft-
Draft-Kompella: Provisioning
Customer Site on PE
A VFT is provisioned at each PE for each local CE
CE4 VFT
Imp/Exp RT RT1
CE ID 4
CE4 VCT
CE Range 4
Label Base 1000
Sub-int IDs Label
63
75
82
94
Import/Export Route Target BGP Community

LDP describes the VPN with a VPN-ID
CE-ID : unique value in the context of a VPN
CE Range : maximum number of CEs that it can connect to
Label-base : Label assigned to the first sub-interface ID
The PE reserves N contiguous labels, where N is the CE Range
Sub-interface IDs list : set of local sub-interface IDs (DLCIs) assigned for the CE-PE
connection
The PE assigns the reserved labels to the sub-interface IDs
129
Draft-
Draft-Kompella: Provisioning
Customer Site on PE
CE-1 CE-2
VFT VFT
CE-2 CE-4
FR FR
CE4 VFT
Imp/Exp RT RT1
CE ID 4
CE Range 4
Label base 1000
Sub-int IDs Label
CE4‘s DLCI to CE0 63
63 1000
1000 Label used to reach CE4 from CE0
75 1001 Label used to reach CE4 from CE1
PE-2 is configured with the CE4 VFT
130
Draft-
Draft-Kompella:
Distributing VCTs
Uses BGP
Auto-discovery of members
Auto-assignment of inter-member circuits
BGP Route Target communities + route filtering (based
on Route Target) to configure VPN topologies
131
Draft-
Draft-Kompella:
Distributing VCTs
CE-1 CE-2
Site 2 PE-1 BGP Session PE-2 Site 1
VFT VFT
CE-2 CE-4
FR FR
CE4 VCT update CE4 VCT update

RT RT1 RT RT1
CE ID 4 CE ID 4
CE Range 4 CE Range 4
Label base 1000 Label base 1000
1002 Label used to reach CE4 from CE2
PE-1 receives BGP Route that carries PE-2’s CE4

VCT
132
Draft-
Draft-Kompella:
Updating VFTs
CE-1 CE-2
VFT VFT
CE-2 CE-4
FR DLCI 414 FR DLCI 82
CE2 VFT
Sub-int IDs CE ID Inner Label
107 1 7500
209 2 5020
265 3 9350
414 4 1002 Label used to reach CE4
PE-1 updates sub-interface IDs list of its CE2 VFT

Import Route Target for CE2 VFT (RT1) matches Route Target
(RT1) carried by the BGP route
133
Draft-
Draft-Kompella:
Updating VFTs
CE-1 CE-2
VFT VFT
CE-2 CE-4
FR DLCI 414 FR DLCI 82
CE2 VFT
Sub-int IDs CE ID Inner Label Outer Label
107 1 7500
209 2 5020
265 3 9350
414 4 1002 500 LSP to PE-2
PE-1 updates sub-interface IDs list of its CE2 VFT

Import Route Target for CE2 VFT (RT1) matches Route Target
(RT1) carried by the BGP route
134
Draft-
Draft-Kompella:
Data Flow
CE-1 CE-2
VFT VFT
CE-2 CE-4
VFT VFT Site 2
Site 1
DLCI 414 DLCI 82
packet DLCI
414
The CE-2 sends packets to the PE via the DLCI

which connects to CE-4 (414)
135
Draft-
Draft-Kompella:
Data Flow
PE-1
1) Lookup DLCI in Red VFT
2) Push VPN label (1002)
3) Push IGP label (500)
CE-1 CE-2
VFT VFT
CE-2 CP-4
VFT VFT Site 2
Site 1
IGP label (500) DLCI 82
site label (1002)
Packet
The DLCI number is removed by the ingress PE

Two labels derived from VFT lookup and “pushed” onto packet
Outer IGP label
Identifies the LSP to egress PE router
Derived from core’s IGP and distributed by RSVP or LDP
Inner site label
Identifies outgoing sub-interface from egress PE to CE
Derived from BGP VCT distributed by egress PE
136
Draft-
Draft-Kompella:
Data Flow
CE-1 CE-2
VFT VFT
CE-2 CPE-4
VFT VFT Site 2
Site 1 10.1/16
DLCI 414 IGP label (z) DLCI 82
site label (1002)
Packet
After packets exit the ingress PE, the outer label

is used to traverse the LSP
P routers are not VPN-aware
137
Draft-
Draft-Kompella:
Data Flow
Penultimate
CE-1 Pop top label CE-2
VFT VFT
CE-2 CE-4
VFT VFT Site 2
Site 1 10.1/16
DLCI 414 DLCI 82
site label (1002)
Packet
The outer label is removed through penultimate

hop popping (before reaching the egress PE)
138
Draft-
Draft-Kompella:
Data Flow
CE-1 CE-2
VFT VFT
CE-2 CE-4
VFT VFT Site 2
Site 1
DLCI 414 DLCI 82
packet DLCI
82
The inner label is removed at the egress PE

The egress PE does a label lookup to find the corresponding
DLCI value
The native Frame Relay packet is sent to the corresponding
outbound sub-interface
139
Draft-Kompella: Configuration
Complexity
Optimized for common topologies (but also can

support arbitrary topologies)
For example, full-mesh, hub-and-spoke topologies are
easy to provision
0(N) configuration for the whole VPN
Could be more for complex topologies
0(1) configuration to add a site
Assumes over-provisioning of DLCIs (connection IDs)
at existing sites
140
Draft-
Draft-Kompella:
Supported Layer 2 Technologies
Frame Relay
ATM AAL5 CPCS Mode
ATM Transparent Cell Mode
Ethernet
Ethernet VLAN
Cisco HDLC
PPP
141
Advanced VPNs
Training Course
Module 6: Layer 2 VPN Configuration

and Troubleshooting (Kompella)
Module Objectives
After successfully completing this module, you will
be able to:
Create Layer 2 VPN VRFs
Configure BGP extended communities for use with Layer
2 VPNs
State the purpose of the route target and Layer 2
information extended communities
Configure Layer 2 VPNs in partial- and full-mesh
topologies
State the purpose of the remote site identifier and
provide an example of its use
Configure Layer 2 VPNs using VLAN, Frame Relay, and
ATM technologies
Troubleshoot Layer 2 VPNs using JUNOS software CLI
commands
Compare and contrast the draft-kompella solution to
conventional CCC
143
Agenda: Configuring Layer 2 VPNs

Preliminary layer 2 VPN Configuration
Layer 2 VPN Configuration
layer 2 VRF Routing Instance
Route Distinguisher and Interfaces
VRF Policy and Extended Communities
local Site Properties
Label Blocks and Site Identifiers
Remote Site Identifier
PE-CE Interface Configuration
Layer 2 IP-Only Interworking
Troubleshooting layer 2 VPNs
144
Preliminary Layer 2 VPN Configuration
Preliminary steps for P and PE routers:
1. Choose and configure the IGP
2. Configure MP-IBGP peering among PE routers
Must include l2-vpn NLRI capability
3. Enable MPLS and the desired MPLS signaling
protocol(s) on P and PE routers
4. Establish LSPs between PE routers
LSP establishment automatic for LDP
The BGP next hop associated with the VPN NLRI must
equal the host ID of the LSP's endpoint
PE routers perform all VPN-related
configuration
145
PE-PE IBGP Peering

PE-to-PE MP-IBGP sessions require l2-vpn NLRI
Include family inet-vpn if Layer3 VPN support also
needed
Include family inet if PE router is to support IPv4 NLRI
JUNOS software automatically negotiates BGP route
refresh
[edit}
lab@Amsterdam # show protocol bgp
group int {
type internal;
family inet {
unicast;
}
family 12-vpn {
unicast;
}
neighbor 192.168.16.1;
}
146
MP-IBGP Peering Example
lab@Amsterdam> show bgp neighbor
Peer: 192.168.16.1+1037 AS 65412 Local: 192.168.24.1+179 AS 65412
Type: Internal State: Established Flags: < >
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Options: <Preference LocalAddress HoldTime AddressFamily Rib-group Refresh>
Address families configured: inet-unicast l2vpn
Local Address: 192.168.24.1 Holdtime: 90 Preference: 170
Number of flaps: 0
Peer ID: 192.168.16.1 Local ID: 192.168.24.1 Active Holdtime: 90
Keepalive Interval: 30
NLRI advertised by peer: inet-unicast inet-multicast l2vpn
NLRI for this session: inet-unicaat l2vpn
Peer support Refresh capability (2)
Table inet.O Bit: 10000
Send atate: in sync
Active prefixes: 0
Received pref1xes: 0
Table bgp.l2vpn.0 Bit: 30000
Send state: in sync
Active prefixes: 1
Table vpna.l2vpn.0 Bit: 50000
Send state: in sync
Active prefixes: 1
147
Layer 2 VPN NLRI (VCT)

Length (2 Bytes)
Route Distinguisher(8 Bytes)
Site ID (2 Bytes)
Label Block Offset (2 Bytes)
Label Base (3 Bytes)
Circuit Status Vector
Other Variable Length TLVs
Layer 2 AFI/SAFI not yet assigned by lANA

CE device ID uniquely identifies a site within a given VPN
Label block offset allows a site to choose the correct label
when multiple blocks are advertised
One NLRI update is generated for each label block
Circuit status vector
Indicates label range
Reports status of local circuit and transmit LSP
148
The Circuit Status Vector
F5 RDI Cells
ATM PVC Detected Provider Core Site

Down by HK 2
AM at-0/0/0
OSPF Area 0 Lo0:192.168.24.1 2

1 2 1 Fe-0/0/1
P1 P2
16/24 2 1/24 24/24
Fe-0/0/1
at-0/0/0
Site HK 1 AS 65412
1 X Lo0:192.168.14.1 Bits 0 n
1 …….
Layer 2 NLRI with updated CSV
The circuit status vector contains a single bit for each

label in a block
Setting this bit to a 1 indicates that either (or both) the local
circuit or the LSP to the remote PE router is down
Receiving PE router reports failure to attached CE device
149
Layer 2 Information Extended

Communities
0 Reserved
1 ATM PDUs(AAL5) Community Type (2 Bytes)
2 ATM Cells
Encapsulation Type (1 Byte)
3 Frame Relay
4 PPP Control Flags (1 Byte)
5 Cisco HDLC
Layer 2 MTU (2 Bytes)
6 Ethernet VLAN
7 MPLS Reserved (2 Bytes)
8 IP-Only Layer 2
Internetworking
Layer2 information
Control flags indicate:
If sequencing is required
Whether the Martini control word is required
MTU field describes the VPN's MTU
All members of a VPN must use the same MTU as mismatched
MTU causes NLRI to be ignored
150
Layer 2 VPN Configuration Overview
Layer2 VPN configuration Overview:

Create layer 2 VPN routing instance
Define BGP extended communities (route target)
Write and apply VRF import and export policies
Configure local site properties
Assign a site ID
Specify VPN encapsulation and interfaces
Configure PE-CE VPN interfaces
151

Provider Core AM 21/24 CE
OSPF Area 0 2
2
Lo0:192.168.24.1 fe-0/0/0 2
172.20.0-3/24
1 2 1 Fe-0/0/1
OSPF Area 0 P1 P2 172.20.4-7/24
192.168.20.1 16/24 2 1/24 24/24 OSPF Area 0
Fe-0/0/1
192.168.28.1
CE 1 fe-0/0/0 HK 1 AS 65412
1 21/24 Lo0:192.168.14.1
Interface addressing is 10.0.x/24 (except loopbacks)
IGP is single area OSPF
Full MP-IBGP mesh between PE routers, lo0 peering, l2-
vpn NLRI
CEs run OSPF
Full-mesh Layer 2-VPN between CE-1 andCE-2
Actual lab topology will differ－
－this is a sample network
152
Create a Layer 2 VPN Routing Instance
VRFs are created at the [edit routing-instances]
configuration hierarchy
Selecting instance-type l2vpn creates a VFT instance
type
[edit routing-instances vpna]

lab@HK# set ?
+ apply-groups Groups from which to inherit
configuration data
instance-type Type of routing instance
> interface Interface name for this routing instance
> protocols Routing protocol configuration
> route-distinguisher Route Distinguisher for this instance
> routing-options Protocol-independent routing option
configuration
+ vrf-export Export Policy for vrf instance RIBs
+ vrf-import Import Policy for vrf instance RIBs
153
Sample Layer 2 Instance: Part 1

A layer 2 VPN instance called vpn-a with a single interface is
provisioned between PE router and CE device
Local site properties are set under protocols
lab@hk-pe# show routing-instances vpn-a

instance-type l2vpn;
route-distiuguisher 192.168.16.1:1;
vrf-axport vpna-export;
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
site ce-1 {
site-identifier 1;
}
}
}
}
154
Sample Layer2 VRF Import Policy
Layer 2 VPN import policy

Installs VCTs learned from other PE routers using MP-
IBGP
NLRI with matching route target communities are installed
in the associated Layer 2 VFT
Non-matching updates are discarded
[edit policy options]

lab@pe-1# show policy-statement vpn-a-import
term 1 {
from {
protocol bgp;
community vpn-a-target;
}
then accept;
}
term 2 {
then reject;
}
}
155
Sample Layer2 VRF Export Policy

[edit policy-options policy-statement vpna-export]
lab@Amsterdam# show
term 1 {
then {
community add vpn-a-target;
accept;
}
}
term 2 {
then reject;
}
Layer 2 VPN export policy

Adds a route target community to the site ID and label
block advertised to remote PE routers
No routing protocol-based match condition is specified
156
Layer 2 VPN Extended BGP Communities
community vpn-a-target members target:65412:100;
The target tag specifies a route target

extended community
Policy matches the route target control that the
Layer 2 site information imported into a given VFT
157
Sample Layer2 Instance: Part 2

Local site properties configured under the protocols
portion of l2vpn instances
lab@hk-pe# show routing-instances vpn-a

instance-type l2vpn;
interface fe-0/0/0.O;
protocols {
l2vpn {
site ce-1 {
site-identifier 1;
}
}
}
}
158
Default Site Association Rules
Inherited remote site identifier is one higher than

previous interface
First interface associllted with site 1 by default
Default inheritance Increased by 2 when remote site identifier
= local site ID
Example 1: site 1
site ce-l {
site-identifier 1;
interface fe-O/O/O.O; Default remote site identifier = site 2
interface fe-O/O/O.1; Default remote site identifier = site 3
Example 2: site 6
site ce-6 {
site-identifier 6;
interface fe-O/O/O.O; Default remote site identifier = site 1
interface fe-O/O/O.1; Default remote site identifier = site 2
159
Remote Site Identifier Example

The Configuration
……..
protocol {
l2-vpn {
site ce-1 {
site-identifier 1;
interface fe-0/0/0.0; {
remote-site-id 3;
The Result
Instance : vpn-a
Local site : 1 (ce-1)
Offset: 1, range: 3, label-base: 32768
Allocate lable block size is 4 (32768-32771)

CLI displays show the highest range in use (3)
fe-0/0/0.0 now connects to site 3 (site 1-2 skipped)
160
Remote Site Identifier Example: 2
Both Examples produce equivalent connectivity and label
Range
……..
l2-vpn {
site ce-3 {
site-identifier 3;
interface fe-0/0/0.0; (Default RSI = 1)
interface fe-0/0/0.1; (Default RSI = 2)
……..
l2-vpn {
site ce-3 {
site-identifier 3;
remote-site-id 2;
}
remote-site-id 1;
……..
161
Example: Layer 2 VPN

Site 2
172.20.0-3/24
OSPF Area 0
192.168.20.1 OSPF Area 0 2
Fe-0/0/1
Lo0:192.168.24.1 fe-0/0/0 2 2
CE 1 fe-0/0/0 HK 1 1 2 1 Fe-0/0/1
172.20.4-7/24
1 21/24 P1 P2
Lo0:192.168.14.1 2 1/24 24/24 OSPF Area 0
16/24
Site 1 192.168.28.1
AS 65412
lab@hk-pe# sbow routing-instance vpna lab@Amsterdam# show routing-instances vpn-a

instance-type l2vpn; instance-type 12vpn,
interface fe-0/0/0.0; interface fe-0/0/O.O;
route-distinguisher 192.168.16.1:1; route-distinguisher 192.168.24.1:1;
vrf-import vpna-import; vrf-import vpna-import;
vrf-export vpna-export; vrf-export vpna-export;
protocols { Protocols {
l2vpn { 12vpn {
encapsulation-type ethernet-vlan; encapsulatlon-type ethernet-vlan;
site ce-1 { site ce-2 {
site-identifier 1; site-identifier 2;
interface fe-O/O/0.0; interface fe-O/O/O.O;
…………………………………………… ……………………………………………
162
Interface Configuration: Example 1
ge-0/1/0 {
vlan-tagging;
encapsulation vlan-ccc;
unit 1 {
vlan-id 515; Sample Gigabit Ethernet
}
unit 2 {
vlan-id 525;
}
}
fe-1/O/1 {
vlan-tagging;
unit 0 {
Sample Fast Ethernet
vlan-id 513
}
}
163
Interface Configuration: Example 2

so-2/0/0 { at-2/3/0 {
no-keepalives; atm-options {
encapsulation frame-relay-ccc;
vpi 0 maximum-vcs 1000;
unit 1 {
encapsulation frame-re1ay-ccc; vpi 1 maximum-vcs 1000;
dlci 551; }
} unit 1 {
unit 2 { encapsulation atm-ccc-vc-mux;
encapsulation frame-relay-ccc;
vci 1.42;
dlc1 552;
} }
so-2/0/2 { unit 3 {
encapsulatlan ppp-ccc ; encapsulation atm-ccc-vc-mux;
unit 0; vci 1.53;
}
}
Sample Frame Relay/PPP Sample ATM

Configuration Configuration
164
Expanding Layer 2 VPN Membership:
Part 1
fe-0/0/0.0
Provider Core AM 21/24 .2 CE
OSPF Area 0 2 15/24
2
Lo0:192.168.24.1 fe-0/0/0.1 .2
1 2 1 Fe-0/0/1
P1 P2
16/24 2 1/24 24/24
Fe-0/0/1
fe-0/0/0.0
CE .1 21/24
HK 1 AS 65412
22/24
1 .1 fe-0/0/0.1 Lo0:192.168.14.1
CE
2
Sites 1 and 2 are over-provisioned

1 VLAN ID needed for two site, but two are provisioned
to allow for a future three-node full mesh
Over-provisioning required to take advantage of the
draft-kompella auto-provisioning features
Now, adding site 3 should not require modification to
the Hong Kong PE router (site 1)
165

Part 2
CE-1's interface and protocol configuration
lab@ce-1# sbow interfaces test@ce-l' sbow protocols
fe-0/0/0 { ospf {
vlan-tagging; area 0.0.0.0 {
unit 0 { interface fe-O/O/O.O;
vlan-id 512; interface fe-O/O/O.l;
family inet { }
address 10.0.21.1/24; }
}
}
unit 1 {
vlan-id 513;
family inet {
address 10.0.22.1/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.20.1/32;
}
}
}
166
Part 3
Hong Kong VPN interface and layer 2 configuration (site 1)
[edit interfaces] lab@hk-pe# show routing-instances
lab@hk-pe# show fe-O/O/O vpn-a {
vlan-tagging; instance-type 12vpn;
Encapsulation vlan-ccc; interface fe-0/0/0.0;
unit o{ interface fe-0/0/0.1;
encapsulation vlan-ccc; route-distinguisher 192.168.16.1:1;
vlan-id 512; vrf-import vpna-import;
} vrf-export vpna-export;
unit 1 { protocols {
encapsulation vlan-ccc; l2vpn {
vlan-id 513; encapsulation-type ethernet-vlan;
site ce-1 {
site-identifier 1;
Default site 2 interface fe-0/0/0.0;
association
}
}
} Associated with site 3
} through inheritance
167

Part 4
Amsterdam VPN interface configuration (sites 2 and 3)
[edit interfaces] [edit interfaces)

lab@Amsterdam# show fe-0/0/0 lab@Amsterdam# show fe-O/O/3
vlan-tagging; vlan-tagging;
encapsulation vlan-ccc; encapsulation vlan-ccc;
unit 0 { unit 0 {
vlan-id 512; vlan-id 514;
} }
unit 1 { unit 1 {
vlan-id 514; vlan-id 513;
} }
168
Expanding layer 2 VPN Membership:
Part 5
Amsterdam VPN interface and Layer2 configuration (sites 2 and 3)
.
.
.
[edit routing-instances vpna] protocols {
lab@Amsterdam# show l2vpn {
instance-type l2vpn; encapsulation-type ethernet-vlan;
interface fe-0/0/0.0; site ce-2 {
interface fe-0/0/0.1; site-identifier 2;
interface fe-0/0/3.0; Default association
interface fe-0/0/3.1; with site 3 interface fe-0/0/0.1;
route-distinguisher 192.168.24.1:1; }
}
site ce-3 {
site-identifier 3;
. interface fe-0/0/3.1;
. interface fe-0/0/3.0;
. }
}
} association with site 1 and site 2
(Note interface ordering: LU1 is
Listed before LU 0)
169
The Results: Part 1
lab@hk-pe> show 12vpn connections

L2VPN Connections :
instance : vpn-a
Local site: 1 (ce-1)
offset: 1, range: 3, label-base: 32768
connection-site Type St Time last up # Up trans
2 rmt up Jul 19 04:43:49 2001 1
Local circuit: fe-0/O/O.O, Status: up
Remote PE: 192.168.24.1
Incoming label: 32769, outgoing label: 32768
3 rmt up Jul 19 04:43:49 2001 1
Local circuit: fe-O/O/O.l, Status: up
Remote PE: 192.168.24.1
Incoming label: 32770, outgoing label: 33792
170
The Results: Part 2
lab@Amsterdam# show 12vpn connections
L2VPN Connections :
Instance : vpna
offset: 1. range: 3 label-base: 32768
3 (3) loc Up Jul 18 20:45:46 2001 1
Local circuit: fe-0/0/0.1, Status: Up
Remote circuit: fe-0/0/3.0, Status: Up
1 rmt Up Jul 18 21:47:25 2001 1
Remote PE: 192.168.16.1
Incoming label: 32768. Outgoing label: 32769
offset: 1. range: 2. label-base: 33792
2 (ce-b) loc Up Jul 18 20:45:46 2001 1
Local circuit: fe-0/0/0.l, Status: up
Remote circuit: fe-0/0/3.0, Status: up
1 rmt Up Jul 18 21:47:25 2001 1
Remote PE: 192.168.16.1
Incoming label: 33792. Outgoing label: 32770
171
Layer 2 Interworking
Site 2

Site 1 OSPF Area 0 2
so-0/0/0.0
Fe-0/0/1 Lo0:192.168.24.1
at-0/0/0.0
2 2
CE 1 HK 1 1 2 1 Fe-0/0/1
P1 P2
1 21/24 Lo0:192.168.14.1
16/24 2 1/24 24/24
AS 65412
ATM to Frame Relay Internetworking
Support for Kompella Layer 2 interworking starting in

Release 5.2
Support for PPP, cisco-hdlc, ATM, and Frame Relay media
only
Keepalive traffic terminated by PE router
IPv4 only
New TCC interface encapsulation option
172
Layer 2 VPN Troubleshooting: Overview
Best to take a layered approach
Core vs. PE/CE problems
Core problems often indicated by inability to establish BGP sessions
or PE-PE LSPs
Physical layer, data-link layer, IGP, BGP, MPLS, VPN
configuration and import/export policies
Added difficulty caused by inability to conduct PE-CE ping
testing
Can be difficult to determine operational status of PE-CE link
Ethernet does not support data-link layer keepalives
PPP and HDLC keepalives operate end-to-end
Frame Relay LMI and ATM OAM can be used to verify PE-CE link
integrity
Watch for mismatched DLCIs/VCIs/VLAN IDs on PE-CE link
VLAN IDs must be the same end to end
Support for end-to-end DLCI/VCI circuit status indications
One PE router can show a Layer 2 connection as up, while the
remote end indicates no l2vpn connections found
Release 5.1 adds end-to-end status indication
173
Layer2 VPN Troubleshooting: MTUs

Watch out for fragmentation and MTU issues
P and PE routers cannot fragment
Core MTU must be > PE-CE MTU
VPN/MPLS overhead adds 8 to12 bytes to CE's PDU
IS-IS adjacency problems are common
IS-IS requires a minimum MTU of 1492 bytes for
adjacency formation
Different Layer 2 encapsulations generate various
amounts of overhead
Example: VLAN-based Layer 2 VPN, IS-IS with two-
level label stack requires PE-CE MTU of at least 1517
and P router MTU of at least 1525
MPLS MAC Header VLAN LLC IS-IS PDU

8 14 4 3 1492(min)
VLAN
VLAN--Base L2 VPN Encapsulation Example
174
Troubleshooting: A Layered-
Approach
AM
Provider Core CE
P1 P2
HK
CE
Core Problems:
PE-CE Problems: IGP PE-CE Problems:
For Example: MPLS(RSVP/LDP) For Example:
Circuit ID IBGP Circuit ID
PE-PE Problems: PE-PE Problems:

VRF-export/import VRF-export/import
CE-CE Problem
(For Example: Policy, Routing Protocol,
Addressing, MTU)
175
PE-PE Troubleshooting
Is the core IGP operational?
Are the PE-~E BGP sessions established
Layer 2 VPN family?
Are the RSVP/LDP LSPs established between
PE routers?
BGP next hop = to LSP egress?
Do any hidden routes exist?
Might not show up as hidden on later software
versions
176
PE-CE Troubleshooting
Is the physical layer up?
Physical layer alarms
Frame Relay LMI/ATM ILMI and OAM cells
Lack of IP connectivity between PE-CE makes
conventional troubleshooting problematic
Are compatible circuit IDs provisioned?
Pings and CE access (Telnet) require OOB
access
Separate interface or LU with compatible IP
addressing
177
CE-CE-Based Traceroute
Core router hops are hidden because outer label's TTL is
set to 255
[edit]
test@ce-a# run traceroute 192.168.28.1
traceroute to 192.168.28.1 (192.168.28.1), 30 hops max, 40 byte packets
1 192.168.28.1 (192.168.28.1) 0.495 ms 0.385 ms 0.370 ms
CE-CE traceroute capture:

Frame 31 (62 on wire, 62 captured)
Ethernet II
MPLS Label: Unknown (100011) .
MPLS Experimental Bit : 0
MPLS Bottom of Label Stack: 0
MPLS TTL: 254
MPLS Label: Unknown (37269)
MPLS Bottom of Label Stack: 1
MPLS TTL: 1
Internet Protocol
User Datagram Protocol
Data (12 bytes)
178
Ping/Traceroute Summary
CE-CE traceroutes show one hop or simply fail
PE-PE traceroutes show core hops and
validate core IGP
IGP patch can differ from routing of LSPs used to
forward VPN traffic
No need for vpn-interface switch
179
Displaying Layer 2 VPN Connections

show l2vpn connections operational mode command
lab@hk-pe> show l2vpn connections ?

＜[Enter]> Execute this command
brief Connection status (one line)
down Connections that are not operational
extensive Connection status and history
history Connection history
instance L2VPN instance name
local-site L2VPN local-site name or ID
remote-site L2VPN remote-site name or ID
status Connection and circuit status (default)
up Connections that are operational
up-down Both operational and non-operational connections
| Pipe through a command
180
Sample l2Vpn connections Output
lab@hk> show l2vpn connections extensive
L2VPN Connections:
Legend for connection Status (St) Legend for ci~uit atatus

OR -- out of range up -- operational
EM -- encapsulation mismatch Dn -- down
CN -- circuit not present NP -- no present
OL -- no outgoing label DS -- disabled
Dn -- down WE -- wrong encapsulation
VC-Dn -- Virtual circuit Down UN -- uninitialized
-> -- only Outbound conn is up
<- -- only inbound conn is up
UP -- operational
XX -- unknown
Instance: vpn-a
Local site: ce-a (1)
Interface name Remote Site ID
fe-0/0/0.0 2
Label Base Offset Range
32768 1 2
connection-site type St Time Last UP # Up trans
2 rmt Up Aug 3 00:08:14 2001 1
Local circuits: fe-0/0/0.0, Status: Up
Remote PE: 192.168.24.1
Incoming label: 32769, Outgoing label: 32768
Time Event Interface/Lb1/PE
Aug 3 00:08:14 2001 PE route Up
Aug 3 00:08:14 2001 Out lbl Update 32768
Aug 3 00:08:14 2001 In lbl Update 32769
Aug 3 00:08:14 2001 cktO up fe-0/0/0.0
3 rmt OR 181
Examining layer 2 VPN NLRI

JUNOS software allows the viewing of a VRF by using
the show route table vpn-name command
VRFs contains:
Local entries for attached sites
Layer 2 VPN label blocks (VCTs) for updates received from
remote PE routers with matching route targets
The bgp.l2vpn.0 table contains all VCTs learned from
remote PE routers with matching route targets
NLRI updates that do not match at least one local VFT are
discarded
keep all is useful for troubleshooting route target-
related problems (use only for troubleshooting)
The show route protocol bgp command displays all
BGP routes in all RIBs .
Output can be filtered by piping output to match or find
182
show route table Command:
Example 1
lab@hk-pe> show route table vpn-a
vpn-a.l2vpn.O: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both,
192.168.16.1:1:1:1/96
*[VPN/7] 05:48:27
Discard
192.168.24.1:1:2:1/96
AS path, I
> to 10.0.16.2 via fe-0/0/1.0, label-switched-path am
192.168.24.1:1:3:1/96
AS path, I
Layer 2 VPN VFT example

The first entry represents the local site configuration, which is
advertised to remote PE routers
The last two entries represent Layer 2 VPN NLRI for sites 2 and
3, as received from the Amsterdam PE router
183
Interpreting Layer 2 NLRI Displays

Layer 2 VPN NLRI is 12 bytes, or 96 bits
Represented as RD:Site-ID:label-block-Offset/96
lab@hk-pe> show route table vpn-a extensive
vpn-a.l2vpn.O: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

192.168.16.1:1:1:1/96 (1 entry, 0 announced)
*L2VPN Preference; 7
Next hop type: Discard
State: <Active Int>
Local AS; 65412
Age: 53:10
Task: L2VPN global
AS patb: I
Communities: Layer2 Info: encaps:VLAN, control flags:0, mtu: 0
Label-base : 800000, range : 2, status-vector : 0x80
184
show route table Command:
Example 2
lab@hk-pe> show route table vpn-a detail | find 192.168.24.1:1:2:1/96
192.168.24.1:1:2:1/96 (1_entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 192.168.24:1:1
Source: 192.168.24.1
Nexthop: 10.0.16.2 via fe-0/0/1.0, selected
label-switched-path am
Push 100067
Protocol Nexthop: 192.168.24.1, Indirect nexthop: 84cfc38 39
State: <Secondary Active Int Ext>
Local AS: 65412 Peer AS: 65412
Age: 4:56 Metric2: 3
Task: BGP_65412.192.168.24.1+1028
Announcement hits (1): 0-vpn-a-OSPF
AS path: I
Communities: targat:65412:200 Layer2 Info: encaps:VLAN,
control flags:0, mtu: 0
Label-base : 800000, range : 1, status-vector : 0x80
Localpref: 100
Router ID: 192.168.0.1
Primary Routing Table bgp.l2vpn.0
185
Viewing the bgp.l2vpn.0 RIB

Displays all Layer 2 VPN NLRI with at least one
matching route target
keep all useful for troubleshooting
Enabled by deCault on route reflectors
Must be set explicitly on confederation C-EBGP speakers
lab@hk-pe> show route table bgp.l2vpn
bgp.l2vpn.O: 1 destinations, 1routes (1 active, 0 holddown, 0 hidden)

192.168.24.1:1:4:1/96
*[BOP/170] 01:08:58, localpref 100, from 192.168.24.1
AS path: I
186
Viewing Routes Sent to Other PE
Routers
Use the show route advertising-protocol bgp
peer-address command
lab@hk-pe> show route advertising-protocol bgp 192.168.24.1 detail
vpn-a.l2vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

Prefix Nexthop MED lclpref AS path
192.168.16.1:1:111/96 (1 entry, 1 announced)
BGP group int type Internal
Route Distinguisher: 192.168.16.1:1
Label-base: 32768, range : 3, status-vector: 0x80
Nexthop: Self
Localpref: 100
AS path:_ I
Communities: target:65412t:l00 Laye2-info: encaps:VLAN, control
flags:0, mtu: 0
187
Viewing Routes Received from

Other PE Reuters
Use the show route receive-protocol bgp
peer-address command
lab@hk-pe> sbow route receive-protocol bgp 192.168.24.1
inet.O: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
inet.1: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

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

vpn-a.l2vpn.0: 3 destination, 3 routes, (3 active, 0 holddown, 0 hidden)

Prefix Nexthop MED Lclprer AS path
192.168.24.1:1:2:1/96
192.168.24.1 100 I
192.168.24.1:1:3:1/96
192.168.24.1 100 I
bgp.l2vpn.0: 2 destination, 2 routes (2 active, 0 holddown, 0 hidden)

192.168.24.1:1:2:1/96
192.168.24.1 100 I
192.168.24.1:1:3:1/96
192.168.24.1 100 I
188
Viewing the MPLS Table
Use the show route table mpls command to display
MPLS table entries for Layer 2 VPNs
lab@hk-pe > show route table mpls detail
mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)

......
32769 (1 entry, 1 announced)
*VPN Preference: 7
Nexthop: via fe-0/0/0.0, selected
Pop [0]
State: <Active Int>
Local AS: 65412
Age: 21:40
Task: L2VPN global
Announcement bits (1): O-KRT
AS path: I
......
fe-0/0/0.0 (1 entry, 1 announced)
*VPN Preference: 7
Nexthop: 10.0.16.2 via fe-0/0/1.0, selected
label-switched-path am
Push 32768, Push 100067(top)
Protocol Nexthop: 192.168.24.1 Indirect nexthop: 64cfd48 43
State: <Active Int>
Local AS: 65412
Age: 21:40 Metric2: 3
Task, L2VPN global
Announcement bits (1): O-KRT 189
Viewing the Layer 2 Forwarding

Table
Use the show route forwarding-table command
Pipe output to find ccc to view only ccc and Layer 2 VPN entries
lab@hk-pe> show route forwarding-table | find ccc

Routing table: ccc
MPLS:
Interface.Label Type RtRef Nexthop Type Index NhRef Netif
Default perm 0 dscd 3 1
0 user 0 recv 5 2
1 user 0 recv 5 2
32769 user 0 ucst 45 1 fe-0/0/0.534
fe-0/0/0 (CCC) user 0 indr 44 2
10.0.16.2 Push 32768,Push l00004(top)fe-0/0/1.0
Frames received with label 32769 are mapped to fe-0/0/0.534

Packets that ingress on fe-0/0/0.534 have two labels pushed
The labeled packet is forwarded to 10.0.16.2
190
Tracing Layer 2 VPNs
Tracing options for layer 2 VPNs
lab@hk-pe# set traceoptions flag ?
all Trace everything
connections Trace L2VPN connections
error Trace errors
nlri Trace L2VPN remote site advertisements
route Trace L2VPN PE routes
topology Trace L2VPN topology changes
Sample traceoptions configuration:

Protocols {
l2vpn {
traceoptions {
file file-name;
flag error detail;
flag connections detail;
flag route detail;
flag topology detail;
}
191
Advanced VPNs
Training Course
Module 7 : Basic Configuration

and Trouble Shooting with VPLS
Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net

Virtual Private LAN Service
VPN A
Site2
VPN A CE–
CE –A2
Site 1 VPN B
CE–
CE –A1
Site2
P P
PE 2
PE 1 CE–
CE –B2
VPN B
Site 1
VPN A
P P Site 3
PE 3
CE–
CE –B1 CE–
CE –A3
A private Ethernet network constructed over a ‘shared’ infrastructure

which may span several metro areas
Multipoint to Multipoint Ethernet connectivity where the SP network
looks like an Ethernet broadcast domain
Compliments Layer 3 2547 and Layer 2 VPNs
193
VPLS Acronyms
VPLS
Instance Provider
PE IP Network PE
CPE CPE
Site A Emulated Tunnel Site B
Attachement Attachement
Circuit Circuit
Tunnel (PE to PE)

RSVP-TE, ‘Normal’ LDP, GRE, IPSec ..
May be used for many services:
IPv4 VPN, IPv6 VPN, L2 VPN, 6PE, VPLS..
May be provisioned independent of VPLS
Demultiplexor, Virtual Channel Identifier, VC Label, Inner Label
Identifies the VPLS to which a packet belongs to, as well as the ingress
PE
VPLS Instance : bridging instance residing at the PE
VPLS Domain : VPN
194
VPLS Operations
Control Plane
VPN Discovery
Discover who are the PE members of a given VPN
VPN Signaling
Setup and teardown of the pseudo-wires between
VPLS instances that constitute the VPLS Domain
Forwarding Plane
MAC Learning and Packet Forwarding
MAC Aging
MAC Flushing
195
VPLS Signalling & Auto-

Auto-discovery
Auto-Dicovery : I have VPLS Instance 3 for VPLS domain RED
Local Ports Virtual Remote Ports

PE C
PE A
Rx VC Label W/ Tx VC Label X for VPLS instance A
if 0
if 1 VPLS RED
instance 3 PE B
if 2 Rx VC Label Y / Tx VC Label Z for VPLs instance B
Signaling : Use these VC Labels (Rx) to send traffic to me
196
VPLS Operations
Control Plane
VPN Auto-Discovery
Auto-discovery can be done by BGP
IETF proposals to extend DNS or RADIUS for auto-discovery
VPN Signaling
Demultiplexors can be signaled
by targeted LDP (draft-lasserre-vkompella-ppvpn-vpls)
» O(N^2) LDP sessions operational challenge
by BGP (draft-kompella-ppvpn-vpls)
A single MP-BGP LNRI supports both Auto-Discovery and
Signaling
Using two different protocols for Auto-discovery & Signaling
More complex to debug
More complexity and inter-protocol interactions
More protocol state in the network
197
BGP already does both

Auto
Auto--discovery & Signaling
IP VPN services (aka RFC2547 VPN)

RFC2547, draft-ietf-ppvnp-2547bis
BGP for VPN auto-discovery
draft-ietf-ppvpn-bgpvpn-auto
IPv6 VPN
draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt
Extensions to RFC 2547bis to support IPv6 VPNs
draft-kompella-ppvpn-vpls
BGP is a proven, multi-vendor solution deployed
in production networks today
198
VPLS Control Plane functionality
with MP
MP--BGP
Using BGP for VPN Auto-discovery and Signaling
provides the following benefits
A single MP-BGP NLRI for most efficient Auto-Discovery

and Signaling
No overhead
No need for complex inter-protocol interactions
Same framework as IP-VPNs (2547bis)
Takes advantage of all the scalability, redundancy and

operational simplicity features available in BGP:
Route Reflectors, Refresh, etc…
Supports Multi-AS/Multi-provider operations
199
PE VCT Provisioning
Site 2 Site 3
PE-2 640 LSP PE-3
CE-2 CE-3
VFT VFT
Vlan 10 Vlan 10
LSP 320
Site 2 VCT Site 3 VCT
Route Dist 100:1.2.3.2 Route Dist 100:1.2.3.3
VE ID 2 VE ID 3
Sites 20 Sites 20
Route Target RED Route Target RED
For VPLS Domain RED

PE-2 is configured with Site 2 VCT
PE-3 is configured with Site 3 VCT
Each PE automatically allocates a VPN label block to be used as
demultiplexors
200
VPLS Forwarding Table
Site 2 Site 3
PE-2 640 LSP PE-3
CE-2 CE-3
VFT VFT
Vlan 10 Vlan 10
LSP 320
Site 2 VCT PE--2’s VFT for VPLS RED

PE
Route Dist 100:1.2.3.2 VE-ID outer Inner TX Inner RX
VE ID 2 1 2001
Sites 20 3 2003 Label used by site 3 to reach Site 2
Label base 2000 . . . .
Route Target RED 20 2020
Used by PE-2 to do MAC learning
from site 3
VPLS Forwarding Table (VFT) on PE holds all the VCTs information

Also contains MAC forwarding information (FDB)
201
VPLS Auto-
Auto-discovery & Signaling
MP-
MP-iBGP
Site 2 Site 3
PE-2 640 LSP PE-3
CE-2 CE-3
VFT VFT
Vlan 10 Vlan 10
LSP 320
Site 2 VCT NLRI Site 3 VCT NLRI
VE ID 2 VE ID 3
Sites 20 Sites 20
Next Hop PE-2 Next Hop PE-3
PE-PE VCT distribution using Multi-Protocol BGP (RFC 2858)

Requires full-mesh MP-iBGP or Route Reflectors
Route Distinguisher: disambiguates VCT information
Route Target: determines VPN topology
Analogous to CE-PE routes advertisements in RFC2547 VPNs
VPLS requires one single NLRI advertisement per VPLS instance
per PE
202
VPLS Auto-
MP-
MP-iBGP
Site 2 Site 3
PE-2 640 LSP PE-3
CE-2 CE-3
VFT VFT
Vlan 10 Vlan 10
LSP 320
Site 2 VCT NLRI Site 3 VCT NLRI
VE ID 2 VE ID 3
Sites 20 Sites 20
Next Hop PE-2 Next Hop PE-3
PE--2’s VFT for VPLS RED

PE
VE-ID outer Inner TX Inner RX
1
3 640 3002 2003 Label used to reach site 3
. . . .
20
PE-2 receives BGP NLRI from PE-3 for RED VPLS instance site 3
203
VPLS Auto-
MP-
MP-iBGP
Site 2 Site 3
PE-2 640 LSP PE-3
CE-2 CE-3
VFT VFT
Vlan 10 Vlan 10
LSP 320

PE PE--3’s VFT for VPLS RED
PE
VE-ID outer Inner TX Inner RX VE-ID outer Inner TX Inner RX
1 600 5002 2001 1 300 5003 3001
3 640 3002 2003 2 320 2003 3002
. . . . . . . .
15 670 9002 2020 15 360 9003 3020
A full mesh of pseudo-wires are set-up between all the VPLS instances
for VPLS RED
204
VPLS Operations
Control Plane
VPN Discovery
Discover who are the PE members of a given VPN
Manual
Automatic
VPN Signaling
Forwarding Plane
MAC Learning and Packet Forwarding
Each PE learns MAC addresses on its own
Learned MAC addresses are not
distributed/signaled
Qualified : one FDB per VLAN per VPLS
Unqualified : one FDB per port
MAC Aging
205
VPLS MAC Learning:

Forwarding to a Unknown MAC Address
Site 2 Site 3
PE-2 640 LSP PE-3
CE-2 CE-3
VFT VFT
Vlan 10
X
Vlan 10
LSP 320
X sends a packet
VC label 2003 Tunnel label 320
L2 Ethernet Frame with Source MAC X VC label 2003
Minus preamble, minus checksum
L2 Ethernet Frame with Source MAC X

PE
VE-ID outer Inner TX Inner RX
1 300 5003 3001
2 320 2003 3002
. . . .
20 360 9003 3020
If the destination address is unknown, the packet is “Flooded” to the VPLS domain
‘Split Horizon’ forwarding scheme
Encapsulation is as per draft-martini-encaps
206
VPLS MAC Learning:
Forwarding to an Unknown MAC Address
Site 2 Site 3
PE-2 640 LSP PE-3
CE-2 CE-3
VFT VFT
Vlan 10
X
Vlan 10
LSP 320
X sends a packet
VC label 2003 Tunnel label 320

L2 Ethernet Frame with Source MAC X VC label 2003
L2 Ethernet Frame with Source MAC X

PE PE--2’s VPLS RED FDB
PE
VE-ID outer Inner TX Inner RX MAC outer Inner TX
1 600 5002 2001 X 640 3002
3 640 3002 2003
. . . . . . .
20 670 9002 2020
The ‘VC label’ received by PE-2 defines

On which VPLS instance the MAC lookup should be done
On which site the source MAC address being received resides
207
Broadcast Storms
PEs should rate-limit the flooding of packets to unknown
addresses
Possible that the source MAC address is never learned
PEs should rate-limit broadcasting
Limit damage due to broadcast storms
PEs should consider rate-limiting multicast traffic
(IGMP Snooping, static MAC multicast filters …)
208
VPLS MAC Learning:
Forwarding to a Known MAC Address
Site 2 Site 3
PE-2 640 LSP PE-3
CE-2 CE-3
X
Z Vlan 10
VFT VFT
Vlan 10 Y
Z sends a packet to X
LSP 320

PE
1 600 5002 2001 X 640 3002
3 640 3002 2003 Y 640 3002
. . . . . . .
20 670 9002 2020 P 670 9002
Sending to a known MAC address X: 2 labels derived from FDB lookup
209
VPLS MAC Learning:

Forwarding to a Known MAC Address
Site 2 Site 3
PE-2 640 LSP PE-3
CE-2 CE-3
X
Z Vlan 10
VFT VFT
Vlan 10 Y
LSP 320
Unicast to MAC X
Tunnel label 640 VC label 3002

VC label 3002 L2 Ethernet Frame with Dest MAC X
L2 Ethernet Frame with Dest MAC X

PE
1 600 5002 2001 X 640 3002
3 640 3002 2003 Y 640 3002
. . . . . . .
20 670 9002 2020 P 670 9002
Sending to a known MAC address X

• Two labels derived from MAC ADD Cache lookup
Encapsulation is as per draft-martini-encaps.
210
VPLS MAC Aging
Site 2 Site 3
PE-2 640 LSP PE-3
CE-2 CE-3
X
Z Vlan 10
VFT VFT
Vlan 10 Y
LSP 320

PE
1 600 5002 2001 X 640 3002
3 640 3002 2003 . . .
. . . . . . .
20 670 9002 2020 . . .
Periodically age out unused entries from the MAC address cache
MAC address cache should be limited by VPLS instance (configurable)
211
Dual--homed CPE
Dual
Site 2 P P PE-15
CE-2 PE-2 VFT
Vlan 10 Site 3
Z Vlan 10
VFT CE-3
X
VFT Y
Vlan 10
P P
PE-3
If CE-3 is switch device, it requires either

Run Spanning Tree
PEs need to listen to topology change BPDUs and reduce the MAC
address aging time in case of topology change
Active & Stand-by up-link functionality
212
Summary
Customers want:
IP VPNs (RFC 2547 VPN)
Point-to-point Layer 2 VPNs
Service Providers can offer all of the above:

Over a common infrastructure (MPLS)
A common BGP framework
Auto-discovery and Signaling
Product proven, multivendor
Leveraging BGP scalability
Supporting multi-AS/multi-provider
A single operational infrastructure and a small set

of basic mechanisms means considerable savings!
213
Configuration of VPLS
VPN Connection Table (VCT) is configured on
the PEs per VPLS instance with:
VPN Connection Table (VCT)
Route Distinguisher: defines unique VCT RD 1234:5.6.7.8
Layer 2 encapsulation set to VPLS Layer 2 VPLS
VPLS Edge ID VE ID 3
One per VPLS Instance per PE irrespective of
how many local ports belong to that VPLS
Estimated total number of PEs which have # sites 20
sites belonging to that VPLS
Route Target: determines VPN topology Imp RT 1234:8765

VPLS must be a full mesh
Import RT always the same as Export RT
Implies full-mesh of PE-PE Tunnels & Split-Horizon Exp RT 1234:8765
forwarding scheme to avoid Spanning Tree
214
Configuration Fragment for VPLS
routing-instances vpnA { // Configuration for VPN A
instance-type vpls; // vpls
interface ge-0/0/0.0; // multipoint Ethernet interface
route-distinguisher 1234:5.6.7.8;
route-target 1234:8765; // set Route Target to 1234:8765
protocols { // PE-CE protocol
vpls {
site-range 20;
site CE-A3 {
site-identifier 3;
}
}
}
}
215
Configuration Fragment for 2547

routing-instances vpnA { // Configuration for VPN A
instance-type vrf; // RFC 2547 VPN
interface ge-0/0/0.0; // sub-interface
route-distinguisher 1234:5.6.7.8;
route-target 1234:8765; // set Route Target to 1234:8765
protocols { // PE-CE protocol
rip {
version-2; // RIPv2
group to-CE-A3 {
export default;
interface so-0/0/0.0; // sub-interface for RIPv2
}
}
}
}
216
Sample VPLS Topology
00:12:1e:17:f8:00
00:02:b3:15:ff:f2
Workstation
CE site-id 20
Workstation
CE site-id 3 Layer 2 Switch
PE2
Layer 2 Switch
PE1 (192.168.1.10)
(192.168.1.7) MPLS Core
m CE site-id 2
PE3
00:12:1e:1a:90:41
(192.168.1.9) Layer 2 Switch Workstation
217
Baseline Configuration
P and PE
Create Label-switched-path (LSP) between the
Provider Edge (PE) routers
Either with RSVP or LDP
PE
Setup BGP peer with family l2vpn for VPLS route
exchange
Can use LDP as a signaling protocol as well
PE-CE
Create VPLS routing instance
218
Setup LDP neighbors for LSPs between PEs

admin@PE1> show ldp neighbor
Address Interface Label space ID Hold time
10.1.11.10 so-2/3/0.0 192.168.1.10:0 13
admin@PE1>show ldp database

Input label database, 192.168.1.7:0--192.168.1.10:0
Label Prefix
100000 192.168.1.7/32
100016 192.168.1.9/32
3 192.168.1.10/32
Output label database, 192.168.1.7:0--192.168.1.10:0

Label Prefix
3 192.168.1.7/32
100016 192.168.1.9/32
100000 192.168.1.10/32
219
Setup BGP session between the PEs with

l2vpn family enable
admin@PE1> show configuration protocols bgp
group jnpr {
type internal;
family l2vpn {
signaling;
}
neighbor 192.168.1.10;
neighbor 192.168.1.9;
}
admin@PE1> show bgp summary

Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
bgp.l2vpn.0 4 4 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn
State|#Active/Received/Damped...
192.168.1.9 100 859 868 0 5 2:25:35 Establ
bgp.l2vpn.0: 2/2/0
vpls.l2vpn.0: 2/2/0
192.168.1.10 100 878 885 0 1 4:16:13 Establ
bgp.l2vpn.0: 2/2/0
vpls.l2vpn.0: 2/2/0
220
Create the VPLS instance on each PE

PE1
[edit]
admin@PE1# show interfaces fe-0/3/1
encapsulation ethernet-vpls;
unit 0 {
family vpls;
}
[edit]
admin@PE1#show routing-instances
vpls {
instance-type vpls;
vrf-target target:100:1;
protocols {
vpls {
site CE3 {
site-identifier 3;
}
}
}
}
221
PE2
[edit]
admin@PE2# show interfaces fe-0/2/0
unit 0;
[edit]
admin@PE2# show routing-instances
vpls {
instance-type vpls;
protocols {
vpls {
site CE20 {
site-identifier 20;
}
}
}
}
222
PE3
[edit]
admin@PE3# show interfaces ge-0/2/0
unit 0;
[edit]
admin@PE3# show routing-instances
vpls {
instance-type vpls;
interface ge-0/2/0.0;
protocols {
vpls {
site CE2 {
site-identifier 2;
}
}
}
}
223
Instead of BGP, LDP can be used as signaling
protocol. However, we are going to use BGP this
time as it has more fun. ☺
[edit]
admin@PE3# show routing-instances ldp-vpls
instance-type vpls;
protocols {
vpls {
vpls-id 50;
neighbor 192.168.1.12 {
psn-tunnel-endpoint 192.168.1.12;
}
neighbor 192.168.1.7 {
psn-tunnel-endpoint 192.168.1.7;
}
}
}
224
Common Problems
Unsupported PIC type
Supported PIC type for PE-CE interface
All ATM2 IQ PICs
4-port Fast Ethernet PIC with 10/100 Base-TX interfaces PIC
1-port Gigabit Ethernet PIC
1-port 10 Gigabit Ethernet PIC
1-port Gigabit Ethernet Intelligent Queuing (IQ) PIC
4-port and 8-port Gigabit Ethernet IQ2 PICs with SFP
1-port 10 Gigabit Ethernet IQ2 PIC with XFP
2-port Gigabit Ethernet IQ PIC
4-port, quad-wide Gigabit Ethernet PIC
225
Common Problems
Unsupported interface configuration

It doesn’t necessary to be a working setup
when it passes the commit check
[edit]
admin@Martha_RE0# show interfaces ge-1/1/0
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation vlan-vpls;
vlan-id 100;
family vpls;
}
[edit]
admin@Martha_RE0# commit
commit complete
[edit]
admin@Martha_RE0#
226
Common Problems
Unsupported interface configuration

Should always check the message log after
commit
Oct 15 14:28:27 Martha_RE0 mgd[7182]: UI_COMMIT: User 'admin' requested 'commit'

operation (comment: none)
Oct 15 14:28:30 Martha_RE0 /kernel: ge-1/1/0: Illegal media change. Flexible-
Ethernet-Services is invalid
Oct 15 14:28:30 Martha_RE0 dcd[3924]: DCD_CONFIG_WRITE_FAILED: Interface ge-1/1/0,
configuration write failed for an IFD CHANGE: Operation not supported
FPC 1 REV 01 710-011153 CG7007 E-FPC

PIC 1 REV 08 750-001072 AP3554 1x G/E, 1000 BASE-SX
227
Common Problems
Invalid VLAN ID
With vlan-vpls encapulation
Fast Ethernet 512 through 1023
Gigabit Ethernet 512 through 4094
[edit]
admin@PE1# commit check
[edit interfaces ge-0/0/3]
'unit 1'
VPLS interfaces must have a VLAN-ID >= 512
configuration check succeeds
With extended-vlan-vpls encapsulation

all VLAN IDs 1 and higher are valid
228
Common Problems
Tunnel PIC is missing
Hardware is not present error on the vpls connection
admin@Rita_RE0> show vpls connections
.....
Legend for connection status (St)
EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLS
EM -- encapsulation mismatch WE -- interface and instance encaps not same
VC-Dn -- Virtual circuit down NP -- interface hardware not present
CM -- control-word mismatch -> -- only outbound connection is up
CN -- circuit not provisioned <- -- only inbound connection is up
OR -- out of range Up -- operational
OL -- no outgoing label Dn -- down
LD -- local site signaled down CF -- call admission control failure
RD -- remote site signaled down SC -- local and remote site ID collision
LN -- local site not designated LM -- local site ID not minimum designated
RN -- remote site not designated RM -- remote site ID not minimum designated
XX -- unknown connection status IL -- no incoming label
MM -- MTU mismatch
.....
Instance: vpls
Local site: CE3 (2)
3 rmt NP
20 rmt NP
admin@Rita_RE0>
229
Common Problems
LM/RM error on the VPLS connection
Remote VE
admin@PE3> show vpls connections remote-site 4
Layer-2 VPN connections:

MM -- MTU mismatch
.....
Instance: vpls
Remote site: 4
CE2 (2) rmt RM
230
Common Problems
LM/RM error on the VPLS connection
Local VE
admin@PE1> show vpls connections local-site 4
Layer-2 VPN connections:

MM -- MTU mismatch
.....
Instance: vpls
Local site: CE4 (4)
2 rmt LM
20 rmt LM
231
Common Problems
Traceoption
[edit]
admin@Rita_RE0# set routing-instances vpls protocols vpls traceoptions flag ?
all Trace everything
connections Trace Layer 2 VPN and VPLS connections
error Trace errors
general Trace general events
nlri Trace Layer 2 VPN and VPLS remote site advertisements
normal Trace normal events
policy Trace policy processing
route Trace routing information
state Trace state transitions
task Trace routing protocol task processing
timer Trace routing protocol timer processing
topology Trace Layer 2 VPN and VPLS topology changes
232
Common Problems
Common system statistics to check

admin@PE1> show system statistics vpls
vpls:
0 total packets received
0 with size smaller than minimum
0 with incorrect version number
0 packets for this host
0 packets with no logical interface /* No ifl found in lookup */

0 packets with no family /* No VPLS family found in lookup */
0 packets with no route table /* No VPLS route table found in lookup */
0 packets with no auxiliary table
0 packets with no corefacing entry /* Core facing interface absent */
0 packets with no CE-facing entry /* CE facing interface absent */
3587 mac route learning requests /* Num learning request */

3584 mac routes learnt /* Num MAC addr learnt */
3 requests to learn an existing route /* Dup. addr learning */
0 learning requests while learning disabled on interface
0 learning requests over capacity /* Over limit learning */
3040 mac routes moved /* MAC moved to different ifl */
0 requests to move static route
.....
233
Common Problems
Common statistics to check

.....
509 mac route aging requests /* Num aging request */
507 mac routes aged /* Num mac addr aged */
0 bogus address in aging requests
0 requests to age static route
0 requests to re-ageout aged route
0 requests involving multiple peer FEs
0 aging acks from PFE
0 aging non-acks from PFE
0 aging requests timed out waiting on FEs
0 aging requests over max-rate
0 errors finding peer FEs
0 unsupported platform
admin@PE1>
234
Advanced VPNs
Training Course
Appendix : MPLS Review and

Background Information
Module Objectives
Basic Review of MPLS
High-Level Overview of Traffic Engineering
MPLS Terminology
Resource Reservation Protocol
Named Path via Explicit Route Objects
Constrain-Based Routing Overview
Administrative Groups
Fast Reroute
Circuit-Cross Connect Overview
Label Distribution Protocol
Basic MPLS Configuration Summary
236
MPLS Benefits
Fully integrates IP routing and Layer 2 Switching
Leverage existing IP infrastructures
Optimizes IP Networks by facilitating traffic
engineering
Enable multi-services networking
Integrates private and public networks seamlessly
237
What is Traffic Engineering?
Source Destination
Layer 3 Routing Traffic Engineering
Ability to control traffic flows in the network

Optimize available resources
Move traffic from IGP path to less congested path
238
Traffic Engineering Uses
With Traffic Engineering, you can:

Route path arround bottlenecks
Provide concise traffic control
Provide efficient bandwidth use
Enhance an ISP’s traffic-oriented performance
Enhance statistically bound performance
characteristics of the network
Provide more options, lower costs, and better service
239
High-Level Overview of Traffic

High-
Engineering
Information distribution component

Path selection component
Path signaling component
Packet Forwarding component
240
Information Distribution
IGP extensions propagate information
IS-IS use type/length/value (TLV) tuples
OSPF use opaque LSA type 10
Information propagated within area/level only
Information Propagated
Bandwidth available
Preemption priority
Link affinity (link colors)
Router ID
241
Path Selection
Egress
LSR
Ingress
LSR
LSP
Two main approaches or a hybrid approach

Offline path calculation (in house or third-party tools)
Online path calculation (constraint-based routing)
Hybrid approach provides the accuracy of offline
approach with failure recovery capability
242
Path Signaling
Dynamic path creation requires a signaling
protocol to:
Coordinate label distribution
Route the LSP explicitly
Reserve bandwidth (optional)
Provide class-of-service capability (DiffServ style)
Reassign resources (like bandwidth)
Preempt existing LSPs
Prevent loops
243
MPLS Signaling Protocols
The IETF MPLS architecture does not assume a

single label distribution protocol
LDP
Executes hop-by-hop
Selects same physical path as IGP
Does not support traffic engineering
RSVP
Easily extensible for explicit routes and label distribution
Deployed by providers in production networks
CR-LDP
Extends LDP to support explicit routes
Functionally identical to RSVP
Not deployed
244
Packet Forwarding
Ingress router examines IP header
Packet is then
Classified for interface output queue
Assigned a lable
Encapsulated in an MPLS header
Forwarded toward the next hop in the LSP
245
MPLS Terminology
Forwarding Equivalence Class (FEC)
Stream/flow of IP packets
FEC/label binding mechanism
Label
Fixed-length
Local significance
Label distribution, retention, and control
Downstream on demand/unsolicited downstream
Liberal/conservative
Independent /ordered
LSR label processing
Push/swap/pop/multi-push/swap-push
246
MPLS Terminology: MPLS Shim Header
Label (20-bits) CoS S TTL
L2 Header MPLS Header IP Packet
32
32--bits
MPLS shim header fields

Label
Experimental (CoS)
Stacking bit
Time to live
Reserved and pre-defined label value
247
MPLS Terminology: Label Swapping

Connection Table
In Out Label
IP 25 (port, label) (port, label) Operation
Port 1 Port 2
(1, 22) (2, 17) Swap
(1, 24) (3, 17) Swap
IP 19 (1, 25) (4, 19) Swap
Port 3 Port 4
(2, 23) (3, 12) Swap
Label Swapping
Connection table maintains mappings
Exact match lookup
Input (port, label) determines:
Label operation
Output (port, label)
Same forwarding algorithm used in Frame Relay and ATM
248
MPLS Terminology: Router Type
Egress
LSR
Ingress
New
LSR Transit York
San LSR Transit
Francisco LSR
Penultimate
Router
LSP
Ingress LSR (“head-end LSR”)
Examines inbound IP packets and assigns them to an FEC
Generates MPLS header and assigns initial label
Transit LSR
Forwards MPLS packets using label swapping
Egress LSR (“tail-end LSR”)
Removes the MPLS header
249
Packet Forwarding
Source Ingress Egress

Paris
LSR LSR
Rome
Ingress LSR determines FEC and assigns a label

Forward Paris traffic on the green LSP
Forward Rome traffic on the blue LSP
Traffic is label-swapped at each transit LSR
Egress LSR
Removes MPLS header (dependent upon penultimate hop
pop)
Forward packet based on destination address
250
MPLS Forwarding Example
134.5.6.1
134.5.1.5
Egress Routing Table

Destination Next Hop
200.3.2.7 134.5/16 134.5.6.1
i3 200.3.2/24 200.3.2.1
Ingress Routing Table i1 i2 i3 i5

Destination Next Hop 200.3.2.7
134.5/16 (2, 84)
200.3.2/24 (3, 99)
MPLS Table MPLS Table 200.3.2.1 200.3.2.7

In Out In Out
(1, 99) (2, 56) (3, 56) (5, 0)
251
Test for Understanding

Label Stacking Penultimate Hop Pops Lable
Penultimate LSR
Tunneling LSP
What label value does the egress LSR for the tunneling
LSP signal to the penultimate LSR so that the label 18 is
popped of the top of the stack?
252
Resource Reservation Protocol
Internet standard for resource reservation
Originally intended for IP QoS
Not a routing protocol
Transport and maintains traffic and policy
parameters that are opaque to RSVP
Simplex reservation s for unicast traffic
Receiver-oriented resource allocation
Maintains soft state for graceful changes of:
Multicast membership
Routing
Multiple reservation styles
Support IPv4 and IPv6
253
RSVP Session
Ingress Egress
Router Router
PATH
RESV
R1 R4 R8 R9
Can be simultaneous, multiple, independent

sessions
Session is data flow defined by three parameters
(destination address, protocol ID, destination port)
RSVP sessions are between hosts, not just routers
Use traceoptions to show session creation
information:
May 8 13:26:42 RSVP new Session 192.168.80.1(port 17) Proto O
May 8 13:26:42 RSVP new path state, session 192.168.80.1(port 17) Proto 0
May 8 13:26:42 RSVP new resv state, session 192.168.80.1(port 17) Proto 0
254
RSVP Messaging Protocol
Established Path
State Block
Ingress Egress
Router Router
PATH
RESV
R1 R4 R8 R9
Established Resv
State Block
RSVP message types
Path: establishes state
Resv: reserves resources
PathTear: removes path state
ResvTear: removes reservation state
PathErr: error message send upstream to sender
ResvErr: establishes blockade state
ResvConf: message confirming reservation request
Path and resv state block sdata structures store soft
state information
255
Traffic Engineering Extensions

Path message extensions
Mandatory:
Session object: identifies that the RSVP session will be an LSP tunnel
Label request object: requests LSRs to provide a label binding
Optional:
Explicit route object (ERO): specifies predetermined path,
independent of IGP path
Record route object (RRO): lists the LSRs that the LSP tunnel
traverses
Session attribute object: aids in session identification, and also
controls path setup priority, holding priority, and local-rerouting
features
Resv message extensions
Mandatory:
Label object: performs the upstream-on-demand label distribution
process
Session object: uniquely identifies the LSP being estabflished
Style object: specifies the reservation style (fixed filter or shared
explicit)
Optional:
Record route object: returns the LSPs path to the sender of the path
message
256
Path Message
Ingress Explicit Route = {R1, R2, R3, R4} Egress
LSR PATH PATH PATH LSR
ERO={R2, R3, R4} ERO={R3, R4} ERO={R4}
R1 R2 R3 R4
Establish Path Establish Path Establish Path
State Block State Block State Block
RSVP path message

Explicit route is passed to R1
R1 transmits a path message addressed to R4
Label request object requests label binding
ERO = {strict R2, strict R3, strict R4} (optional field)
Record route object lists nodes visited (optional field)
Session object identifies LSP name
Session attributes controls priority preemption, fast reroute
(optional field)
Sender Tspec requests bandwidth reservation
Each router acts on RSVP packet because of router alert
option
257
Resv Message
Ingress Egress
Penultimate
LSR LSR
LSR
i2 i3 i6 i2 i5 i4
RESV RESV RESV
R1 Label = 17 R2 Label = 20 R3 Label = 3 R4
MPLS Table MPLS Table MPLS Table
In Out In Out In Out
IP Route (2, 17) (3, 17) (6, 20) (2, 20) (5, Pop)
Resv message
R4 transmits a resv message to R3
Label = 3 (indicates that penultimale LSR should pop
header)
Session object uniquely identifies the LSP
Style object identifies fixed filter or shared explicit
Record route object lists nodes visited (optional field)
R3 and R2
Stores outbound label allocates an inbound label
Transmits resv message with inbound label to upstream LSR
R1 binds label to FEC
258
Named Path via Explicit Route Object
Permits explicit path assignment

Used to specify the route RSVP path messages take for
setting up lSP
Can specify loose or strict routes
loose routes rely on routing table to find destination
Strict routes specify the directly connected next hop
A route can have both loose and strict components
Uses ERO processing algorithm
259
Named Path ERO: Strict Route

Next hop must be directly connected to
previous hop
Egress
C E F
LSR
ERO
B strict;
C strict;
E strict;
D strict;
F strict;
A B D
Ingress Strict
LSR
260
Named Path ERO: Loose Route
Consult the routing table at each hop to
determine the best path
Egress
C E F
LSR
ERO
D loose;
A B D
Ingress Loose
LSR
261
Named Path ERO: Strict/Loose Path

Strict and loose routes can be mixed
Egress
C E F
LSR
ERO
C strict;
D loose;
F strict;
A B D Strict
Ingress Loose
LSR
262
Named Path Code
mpls {
traffic-engineering bgp-igp;
label-switched-path Blue1 {
to 192.168.24.1;
primary one
}
label-switched-path Blue2 {
to 192.168.12.1;
primary one; Use loopback address
} instead of interface address
path one { so loose section of path
192.168.20.1 loose; can reroute if necessary
}
isis {
traffic-engineering shortcuts;
interface all {
level 1 disable;
}
}
263
Named Path Verification
lab@HongKong> show mpls lsp
Ingress LSP: 2 label-switched paths
To From State Rt ActivePath P LSP name

192.168.12.1 192.168.16.1 Up 2 One Blue2
192.168.24.1 192.168.16.1 UP 5 One Blue1
Total 2 displayed, Up 2, Down 0
Egress RSVP: 0 sessions

Transit RSVP: 0 sessions

264
Constraint-Based routing Overview
Constraint-
(1 of 2)
Modified shortest path first algorithm
Integrates TED data
IGP topology information
Available bandwidth
Link color
Path determined according to administrative
constraints of LSP
Maximum hop count
Bandwidth
Strict or loose routing
Administrative groups
Priority
Prunes non-qualifying paths then performs an
SPF algorithm on remaining routes
265
Constraint-Based routing Overview

Constraint-
(2 of 2)
Operations Performed by the Ingress LSR
Extended IGP
Traffic Engineering Constrained User

Routing Table
Database(TED) Shortest Path First Constraints
1) Stores information from IGP flooding

2) Stores traffic-engineering information Explicit Route
3) Examines user-defined constraints
4) Calculates the physical path for the LSP
5) Represents path as an explicit route
6) Passes ERO to RSVP for signaling RSVP Signaling
266
IGP Extensions
Extended IGP

Routing Table
Distributes topology and traffic

engineering information using
IGP extensions Explicit Route
Maximum reservable bandwidth
Remaining reservable bandwidth
Link administrative
groups(color)
RSVP Signaling
Mechanisms
Opaque LSAs for OSPF
New TLVs for IS-IS
267
Traffic Engineering Database

Traffic engineering database
Used exclusively for calculating explicit paths for
the placement of LSPs across the physical topology
Maintains traffic engineering information learned
from the extended IGP
Contents
Up-to-date network topology information
Current reservable bandwidth of links --
Link administrative groups (colors)
Link priority information
268
User Constraints
Extended IGP

Routing Table
User-defined constraints applied

to path selection
Bandwidth requirements Explicit Route
Hop count limitations (for fast
reroute)
Administrative groups (colors)
Priority (setup and hold)
RSVP Signaling
Explicit route (strict or loose)
Also specified for signaled LSPs
(no-cspf)
269
Constrained Shortest Path First
Extended IGP

Routing Table
For LSP = (highest priority) to

(lowest priority)
Prune links with insufficient Explicit Route
bandwidth
Prune links that do not contain
an included color
Prune links that contain an
excluded color
RSVP Signaling
Calculate shortest path from
ingress to egress consistent with
ERO
Select among equal-cost paths
(least hop, then fill)
Pass explicit route to RSVP
270
RSVP Signaling
CSPF Egress
LSR
ERO
PATH
RSVP
Ingress RESV
LSR
RSVP signaling :
Explicit route calculated by CSPF is handed to RSVP
RSVP is unaware of how the ERO was calculated
RSVP establishes LSP
Path: Establishes state and requests label assignment
Resv: Distributes labels and reserves resources
271
Administrative Groups (1 of 7)
Thirty-two named groups, 0 through 31－
－carried as
32-bit value in IGP updates
Groups assigned to Interfaces
Silver
San Gold
Francisco
Bronze
272
1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0
Colors advertised on a per-link basis via IGP:
0xC000000E
Colors on router: internal management, bronze,
silver, gold
273
[edit protocols]
mpls {
admin-groups {
good 1;
silver 2;
bronze 3;
management 30;
internal 31;
}
interface so-0/0/0 {
admin-group [ good management ]
}
admin-group silver;
}
admin-group good;
}
admin-group good;
}
}
274
CSPF can include and exclude groups in automatic
path calculation
Logical groupings are supported
mpls {
label-switched-path to-miami {
to 1.1.1.1;
primary use-fargo {
admin-group {
include gold; Logical AND
exclude [ bronze silver ]
}
}
}
path use-fargo {
Logical OR
10.0.1.2 loose;
}
}
275
A-D-H has the lowest IGP metric－

－4
B 5
G 1
3 I
1 2
E
5
A 6 3
2 1
3 D 2
C H
4 F 3
276
Choose the path from A to H using:
admin group {
include [ copper bronze ];
exclude admin;
}
B 5
G 1
3 I
1 2
E
5
A 6 1
2 1
3 6 D 2
C H
4
F 3
277
A-D-E-G-I-H is the shortest path excluding the admin

class and including copper or bronze
B 5
G 1
3 I
1 2
E
5
A 6 1
2 1
3 6 D 2
C H
4
F 3
278
Fast-
Fast-Reroute Operation
Fast reroute in operation:

Configured on ingress router only
Detours around node or link failure
~100s of ms reroute time
Detour paths immediately available
Uses TED to calculate detour
279
Fast-
Fast-Reroute Overview
Short-term solution to reduce packet loss－
－if
node or link fails, upstream node:
Immediately detours
Signals failure to ingress LSR
Ingress LSR knows traffic engineering
constraints
Ingress router computes alternate route based on
configured secondary paths; tries to reestablish
primary path
Initiates long-term reroute solution
By default, reroute paths inherit administrative
groups only－－no other parameters
280
Fast Reroute Example
Enable fast reroute on ingress LSR
SF creates detour around LA
LA creates detour around Austin
Austin creates detour around Miami
Fargo
New York
San
Francisco
Miami
Los Angeles
Austin
281
Fast Reroute Example - Short Term

Solution
LA to Austin link fails
LA immediately detours around Austin
LA signals to SF that failure occurred
Fargo
New York
San
Francisco
Miami
Los Angeles
Austin
282
Fast Reroute Example –
Long Term Solution
SF fails over to secondary path
Fargo
New York
San
Francisco
Miami
Los Angeles
Austin
283
Fast Reroute
protocols mpls { ‧‧‧

label-switched-path Tom { protocols mpls {
to 192.168.24.1; path top {
primary top 192.168.0.1 loose;
secondary bottom { 192.168.2.1 loose;
bandwidth 75m; }
priority 5 5; path bottom {
standby; 192.168.6.1 loose;
} 192.168.12.1 loose;
fast-reroute; }
}
‧‧‧
284
Circuit Cross-
Cross-Connect Overview
Connects two Layer 2 circuits
Supports:
PPP, Cisco HDLC, Frame Relay. ATM. and VLAN 802.1Q
Based on Layer 2 circuit ID
carries any protocol
Connects only like interfaces (for example, Frame
Relay to Frame Relay, or ATM to ATM)
Three types of cross-connects
Layer 2 switching
MPLS tunneling
Stitching MPLS LSPs
285
CCC MPLS Interface Tunneling (1/2)

ATM access network IP backbone ATM access network
ATM VC 514 MPLS LSP ATM VC 590

A M40 M20 B
Transports packets from one interface through an

MPLS LSP to a remote interface
Supports tunneling between two like interfaces, such
as ATM, Frame Relay, PPP, and Cisco HDLC connections
Bridges Layer 2 packets from end to end
ATM operation
286
CCC MPLS Interface Tunneling (2/2)
ATM access network IP backbone ATM access network
ATM VC 514 MPLS LSP1 ATM VC 590

A M40 M20 B
MPLS LSP2
at-7/1/1.514 at-3/0/1.590
[edit protocols] [edit protocols]

user@M40# show user@M20# show
connections { connections {
remote-interface-switch m40-to-m20 remote-interface-switch m20-to-m40
interface at-7/1/1.514; interface at-3/0/1.590;
transmit-lsp lsp1; transmit-lsp lsp2;
receive-lsp lsp2; receive-lsp lsp1;
} }
287
Special Caveats for CCC
VLAN CCC caveats

VLAN tagging at physical interface
VLAN 0-511 on unit with ccc-encap support 802.1Q VLAN
VLAN 512-4094 only VLAN IDs that support CCC
GE PICs must be Rev B
Frame Relay: encapsulates frame-relay-ccc at
physical interface
DLCI 1-511 on unit is normal Frame Relay
DLCI 512-1022 on unit is CCC Frame Relay
Layer 2 switching cross-connect: PPP and HDLC must
be unit 0
ATM: cannot configure family on unit if atm-ccc-vc-mux
encapsulation is set
288
Purpose of LDP (1 of 2)
Creates forwarding equivalence class
A group of IP packets which are forwarded in the
same manner (RFC 3031)
Manages LSP to egress router
New concept
LDP associates the FEC with each LSP it creates
Solves problems
Enables VPNs
Allows traffic class mapping
289
Purpose of LDP (2 of 2)
LDP creates an LSP tree for each FEC from every

possible ingress router to egress router
LDP LSP
B Egress
RSVP LSP G
I
A E
Ingress Only one LDP LSP,

D while four RSVP LSPs
H
C
F
290
Label Distribution Protocol (1 of 2)
Upstream Downstream
LDP Peer LDP Peer
Discovery (Hello messages)
TCP Session Establishment

Sessions
Initialization Messages
Label Request Messages

Advertisement
Label Mapping Messages
Distributes label binding information

Runs on LSRs in conjunction with IP routing protocols
Labels are periodically refreshed
LDP messages types
Discovery: locates potential LDP peers
Session: manages peer-to-peer TCP sessions
Advertisement: creates, changes, or deletes label mappings
Notification: provides advisory information
291
Label Distribution Protocol (2

(2 of 2)
Net: 11.0.0.0 Net: 11.0.0.0

Upstream Net: 10.0.0.0 Net: 10.0.0.0 Downstream Net: 10.0.0.0
LDP Peer Label: 17 LSR Label: 52 LDP Peer Label: 29
i1
i3 i1 i4 i5 i2 i3
MPLS Table Advertise MPLS Table Receive MPLS Table i4

In Out Incoming In Out Outgoing In Out
Label Label
IP Route (1, 17) (4, 17) (5, 52) (2, 52) (3, Pop)
LDP label mapping

Downstream peer assigns labels
Benefits
Traffic engineering information is not piggybacked on
routing protocols
Limitations
LSPs follow the conventional IGP path
Does not support explicit routing
292
LDP Tunneling through RSVP-
RSVP-TE LSP
(1 of 2)
Router A Router B
LDP RSVP LSP LDP
protocols {
mpls {
label-switched-path lsp-path-name {
from source;
to destination;
ldp-tunneling;
}
}
}
293
LDP Tunneling through RSVP-

RSVP-TE LSP
(2 of 2)
LDP LDP
RSVP
LDP LSP RSVP LSP
RSVP tunneling can cause the LDP traffic to be

forwarded through the RSVP tunnel over a
traffic engineered path
294
Basic MPLS Configuration Summary
MPLS configuration summary
Configure MPLS and RSVP protocols
Configure family MPLS on interfaces
Configure an LSP
Configure basic IP stuff (for example, addresses
and protocols )
295
Basic RSVP-
RSVP-Signaled LSP
[edit]
Lab@host# set protocols mpls interface a11
Lab@bost# set protocols rsvp interface a11
Lab@host# set interface IN-#/#/# unit 0 family mpls
Lab@host# set protocols mpls Label-switched-path NAME to IP-address no-cspf
296
Displaying MPLS LSPs
lab@SanFrancisco > show mpls lsp
To From State Rt ActivePath P LSP name

192.168.8.1 192.168.2.1 Up 1 se-gold * sf-to-ny
Egress RSVP: 2 sessions, 1 detours,

To From State Rt Style Labelin Labelout LSPname
192.168.2.1 192.168.8.1 Up 0 1 FF 3 - NYC-to-SF
192.168.2.1 192.168.8.1 Up 0 1 FF 3 - NYC2-to-SF

297
Displaying Additional MPLS Information
lab@SanFrancisco> show mpls lsp extensive

192.168.8.1
From: 192.168.2.1; State: UP, ActiveRoute: 1, LSPname: sf-to-ny
ActivePath: use-gold (primary)
LoadBalanee: Random
*Primary use-gold State: UP
Include gold
Computed BRO (S [L] denotes strict [loose] hops), (CSPF _metric: 30)
10.0.5.2 S 10.0.7.2 S 10.0.9.2 S
102 Jan 5 12:12:28 Selected as active path
101 Jan 5 12:11:58 Record Route: 10.0.5.2 S 10.0.7.2 S 10.0.9.2 S
100 Jan 5 12:11:58 up
99 Jan 5 12:11:58 Clear call
98 Jan 5 12:11:58 CSPP: computation result accepted
97 Jan 5 12:11:43 Record Route: 10.0.3.1 S 10.0.1.2 S 10.0.14.1 S
298
Displaying the MPLS Switching Table
lab@Montreal# show route table mpls.0
mpls.0: 6 destinations, 6 route, (6 active, 0 holddown, 0 hidden)
0 *[MPLS/O] 02:47:47, metric 1
Receive
1 *[MPLS/O] 02:47:47, metric 1
Receive
100003 *[RSVP/7] OO:OO:53, metric 1
> to 10.0.24.2 via fe-0/0/2.0. label-switched-path HK-AM1
100003(S=0) *[RSVP/7] OO:OO:53, metric 1
100004 *[RSVP/7] OO:OO:53, metric 1
100004(S=0) *[RSVP/7] OO:OO:53, metric 1
299
Displaying RSVP Session Information
lab@SanFrancisco > show rsvp session
Ingress RSVP: 2 Sessions

192.168.8.1 192.168.2.1 Up 1 1 FF - 100010 sf-to-ny
192.168.8.1 192.168.2.1 Up 0 1 FF - 100058 sf-to-ny
Egress RSVP: 2 sessions, 1 detours,

192.168.2.1 192.168.8.1 Up 0 1 FF 3 - NYC-to-SF
192.168.2.1 192.168.8.1 Up 0 1 FF 3 - NYC2-to-SF

300
Displaying RSVP Neighbor Information
lab@SanFrancisco > show rsvp neighbor
RSVP neighbors: 3 learned

Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd MsgType
10.0.3.1 0 1/0 5:35:37 3 29386/4556 450 Path,Resv
10.0.4.2 0 1/0 2w1d 22:54:25 3 448522/448391 61407 Path,Resv
10.0.5.2 8 1/0 5:35:42 3 29316/4557 30587 Path,Resv
301
Displaying RSVP-
RSVP-Enabled Interfaces
Lists interfaces configured to run RSVP

Interface bandwidth, reservable bandwidth, high-water
mark, etc.
Detail switch provides RSVP messages statistics
lab@router> show rsvp interface

RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
fxp0.0 Up 0 100% 100Mbps 100Mbps 0bps 0bps
fe-0/0/0.0 Up 0 100% 100Mbps 100Mbps 0bps 0bps
fe-0/0/1.0 Up 0 100% 30Mbps 30Mbps 0bps 0bps
fe-0/0/2.0 Up 1 100% 100Mbps 85Mbps 15Mbps 15Mbps
302
Next Hop Resolution
I-BGP
NJ
134.112/16
Boston
Denver DC
192.168.4.1 192.168.16.1
NY
192.168.24.1
SF Dallas .1
192.168.16.1 .1 10.0.20/30 .2 192.168.8.1
AS 64512 Configure
“next hop self”
lab@SF> show route 192.168.24.1
inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

192.168.24.1/32 *[IS-IS/18] 00:26:50, metric 30, tag 2
> to 10.0.16.2 via fe-0/0/0.0
inet.3: 1 destinations. 1 routes (l active, 0 holddown, 0 hidden)

192.168.24.1/32 *[RSVP/7] 00:00:53, metric 0
> to 10.0.16.2 via fe-0/0/0.0, label-switched-path to_ny
303
Using traceroute to Prove LSP

Works
lab@SF> traceroute 134.112.1.1

traceroute to 134.112.1.1 (134.112.1.1), 30 hops max, 40 byte packets
1 10.0.16.2 (10.0.16.2) 0.766 ms 0.662 ms 0.612 ms
MPLS Label=1056 CoS=O TTL=1 S=1
2 10.0.1.2 (10.0.1.2) 0.709 ms 0.654 ms 0.738 ms
MPLS Label=1021 CoS=O TTL=1 S=1
3 10.0.24.2 (10.0.24.2) 0.648 ms 0.632 ms 0.610 ms
....
304
Advanced VPNs
Training Course
Questions ?
Thank You !
Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net

Juniper Advanced VPNs Update)

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Juniper Advanced VPNs Update)

Încărcat de

Drepturi de autor:

Formate disponibile

Advanced VPNs

Module 0: Course Introduction

Module 1: Introduction to VPNs

Virtual private network:

CPE FR Switch FR Switch CPE

Deploying VPNs in the 21st Century

Customer-managed VPN solutions (CPE-VPNs)

V.x modem L2TP

Dial Access Provider Service Provider or VPN

IPSec ESP Tunnel Mode

Routing must be performed at CPE

IPSec ESP Tunnel Mode

Provider - Provisioned VPNs:

Application: outsource VPN

Virtual Router Issues

Scalability and management can be issues for

Some customers prefer to maintain control of

Provides the foundation for MPLS-based Layer 2 VPNs

CPE DLCI PE LSPs PE DLCI CPE

CCC Table CCC Table

Application: very large enterprise or carrier of carriers

Managed network service required

Customer must have routing expertise (or

Comparison: RFC2547 and MPLS

MPLS VPNs Benefits

A Range of VPN Solutions (2 of 4)

A Range of VPN Solutions (4 of 4)

Layer 2 VPN Implementation

Module 2: Layer 3 VPNs

Customer Edge Routers

Customer Edge (CE) routers

Provider Edge (PE) routers

Provider (P) routers

A site is a collection of machines that can communicate

VPN Routing and Forwarding

Only the VRF associated with a VPN is used for

Overlapping Address Spaces

(2 bytes) (variable (variable (4 bytes)

VPN-IPv4 address family

VPN--IPv4 Address Family

(2 bytes) (variable (variable (4 bytes)

Assigned Number Field: number assigned by the

Two values are defined for Type Field: 0 and 1

Using Route Distinguishers

RFC 2547bis Policies

Full mesh, hub-spoke connectivity, ...

CE device advertises route to PE Router

Exchange of Routing Information

IPv4 address is added to the appropriate VRF

VPN-IPv4 address is associated with an export

Exchange of Routing Information

VPN-IPv4 route is advertised to other PEs

“VPN BLUE” import

“VPN RED” import BGP 10458:23:10.1/80 OSPF

Each PE is configured with import targets

Exchange of Routing Information

“VPN BLUE” import

10458:23:10.1/80 BGP 10458:23:10.1/80 OSPF

Each VPN-IPv4 route in a VRF is associated with:

“VPN BLUE” import

Each IPv4 route received in a VRF could be advertised to

The PE to PE LSP must be in place before forwarding