Juniper Advanced VPNs Update]

Advanced VPNs Training Course

Module 0: Course Introduction

2

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


Module 1: Introduction to VPNs

4

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

5

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

6

What is a VPN?What is a VPN?

� 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

Shared PublicInfrastructureShared PublicInfrastructure Mobile Users and Mobile Users and

TelecommutersTelecommuters

BranchBranch

OfficeOffice

Corporate Corporate HeadquartersHeadquarters

Suppliers, PartnersSuppliers, Partnersand Customersand Customers

IntranetIntranetIntranetIntranet

ExtranetExtranetExtranetExtranet

7

Deploying VPNs in the 1990sDeploying VPNs in the 1990s

� 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

Provider Frame Relay NetworkProvider Frame Relay NetworkProvider Frame Relay NetworkProvider Frame Relay Network

CPECPECPECPE CPECPECPECPE

DLCIDLCI

FR SwitchFR SwitchFR SwitchFR Switch

DLCIDLCI

DLCIDLCI

FR SwitchFR Switch

FR SwitchFR SwitchFR SwitchFR Switch

8

Deploying VPNs in the 21st CenturyDeploying VPNs in the 21st Century

� 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

InternetInternet

Remote AccessRemote Access

IntranetIntranetIntranetIntranet

ExtranetExtranetExtranetExtranet

Mobile Users and Mobile Users and TelecommutersTelecommuters

BranchBranch

OfficeOffice

Corporate Corporate HeadquartersHeadquarters

Suppliers, PartnersSuppliers, Partnersand Customersand Customers

9

VPN Classification ModelVPN Classification Model

� 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

PE

PE

CPE

CPE

Subscriber

Site 3

PP-VPN

Subscriber

Site 2

CPE

PECPE

PE PE

PE

CPE

CPE

CPE-VPN

VPN TunnelSubscriber

Site 1

Subscriber

Site 3

Subscriber

Site 2

VPN

Subscriber

Site 1

10

Layer 2 CPELayer 2 CPE--VPNs: L2TP and PPTPVPNs: L2TP and PPTP

� 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

Dial Access Provider

V.x modem

PPP dial-upService Provider or VPN

L2TP

access serverDial access

serverL2TP tunnel

Dial access

server

PPTP

access serverPPTP tunnel

11

Layer 3 CPELayer 3 CPE--VPNs: IPsec Tunnel ModeVPNs: 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

12

Layer 3 CPELayer 3 CPE--VPNs: IPSec VPNs: IPSec –– ExampleExample

� 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

Corporate

HQ

Branch

officeCPE CPE

IPSec ESP Tunnel ModeIPSec ESP Tunnel Mode

Public Internet

13

Layer 3 CPELayer 3 CPE--VPNs: VPNs: IPsec Benefits and LimitationsIPsec Benefits and Limitations

� 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

Corporate

HQ

Branch

officeCPE CPE

IPSec ESP Tunnel ModeIPSec ESP Tunnel Mode

Public Internet

14

Provider - Provisioned VPNs:Layer 3 vs. Layer 2

� Layer 3

� Provider's routers participate in customer's Layer 3 routing

� Provider's routers manage VPN-specifjc routing tables, distributes ,routes to remote sites

� CPE routers advertise their routes to the provider

� Layer 2

� Customer maps its Layer 3 routing to the circuit mesh

� Provider delivers Layer 2 circuits to the customer, one for each remote site

� Customer routes are transparent to provider

15

Layer 3 PPLayer 3 PP--VPNs: RFC 2547bis (1/2)VPNs: RFC 2547bis (1/2)

� Application: outsource VPN� Operational model

� PE maintains site-specific forwarding tables for eachof 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

Service Provider NetworkService Provider Network

Site 1Site 1

Site 1Site 1

Site 2Site 2

Site 3Site 3

Site 2Site 2

Site 3Site 3

CECE

CECE

CECE

VRF

VRF

VRF

VRF

VRF

PEPE PEPE

PEPEPP

PP

PEPE

PPPP

PP

CECE

CECE

CECE

VRF

16

Layer 3 PPLayer 3 PP--VPNs: RFC 2547bis (2/2)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

17

Layer 3 PPLayer 3 PP--VPNs: Virtual RoutersVPNs: 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 netis 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

18

Virtual Router IssuesVirtual 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

19

Layer 3 PPLayer 3 PP--VPN AdvantagesVPN 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)

20

Layer 3 PPLayer 3 PP--VPN DisadvantagesVPN 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

21

MPLSMPLS--Based Layer 2 PPBased Layer 2 PP--VPNsVPNs

� Layer 2 MPLS-based VPNs

� Circuit cross-connec (CCC)

� Draft-martini Layer 2 VPNs

� Draft-kompella Layer 2 VPNs

� Virtual Private LAN Service (VPLS)

22

In Out

LSP 1DLCI 600

LSP 2DLCI 610

In Out

DLCI 60010/8

DLCI 61020/8

Circuit CrossCircuit Cross--connect (CCC)connect (CCC)

� 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

CPECPE

CPECPE

DLCIDLCI600600

DLCIDLCI610610

LSP 1LSP 1

LSP 2LSP 2

DLCIDLCI608608

DLCIDLCI605605

PEPE

PEPE

CPECPE

20.0.0.020.0.0.0

10.0.0.010.0.0.0

SourceSource

Routing TableRouting TableCCC TableCCC Table

““““““““Good Service SP”Good Service SP”

(USA Region)(USA Region)


(Europe Region)(Europe Region)


(Asia Region)(Asia Region)

CCC TableCCC Table

CCC TableCCC TableIn Out

DLCI 605LSP1

Large ProviderIP/MPLS NetworkLarge Provider

IP/MPLS Network

CCC = Circuit Cross-connectCCC = Circuit Cross-connect

In Out

DLCI 608LSP2

PE

23

Circuit CrossCircuit Cross--connect Issuesconnect 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

24

CCC FunctionCCC Function

ATM (or Frame Relay)ATM (or

Frame Relay)

ATM (or Frame Relay)ATM (or

Frame Relay)

MPLSMPLS--based Layer 2 VPNsbased Layer 2 VPNs

� 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

PEPE PEPELSPsLSPs

CCC TableCCC Table

LSP 2 LSP 6

LSP 5LSP 5

CCC TableCCC Table

DLCIDLCI

600600

DLCIDLCI

610610

DLCIDLCI

506506

DLCIDLCI

408408(MPLS Core)(MPLS Core)

CPECPECPECPE

In Out

LSP 2 in LSP 5DLCI 600

LSP 6 in LSP 5DLCI 610

In Out

LSP 2 in LSP 5 DLCI 506

LSP 6 in LSP 5 DLCI 408

25

MPLSMPLS--based Layer 2 VPNs: based Layer 2 VPNs: AdvantagesAdvantages

� 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 configurationused with 2547

26

MPLSMPLS--based Layer 2 VPNs: based Layer 2 VPNs: DisadvantagesDisadvantages

� 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)

27

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

28

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

29

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

30

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

31

Comparison: RFC2547 and MPLS Layer 2 VPNs

� RFC2547

� Ideal for small/medium businesses

� ISP-managed routing

� Layer3

� MPLS-based

� RSVP,LDP

� Label stacking

� IP traffic

� MPLS Layer 2 VPNs

� Ideal for large/corporate businesses

� Customer-managed routing

� Layer 2

� MPLS-based

� RSVP,LDP

� Label stacking

� IP traffic

� IP multicast

� Non IP CPE traffic

32

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

33

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

34


� 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

35


� 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

36


� 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

37

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

38

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


Module 2: Layer 3 VPNs

40

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

41

Agenda: Layer 3 MPLS VPNs

� RFC 2547bis Terminology

� VPN-IPv4 Address Structure

� Operational Characteristics

� Policy-Based Routing Information Exchange

� Traffic Forwarding

42

Customer Edge RoutersCustomer Edge Routers

� 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

CEPP

PECE

CE

CE

PE VPN AVPN AVPN AVPN A

VPN BVPN B VPN BVPN B

PE

Customer Edge

43

Provider Edge RoutersProvider Edge Routers

� 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

CEPP

PECE

CE

CE



PE

Provider Edge

44

Provider RoutersProvider Routers

� Provider (P) routers

� Forward VPN data transparently over established LSPs

� Do not maintain VPN-specific routing information

CEPP

PECE

CE

CE



PE

Provider Routers

45

VPN Sites

� A site is a collection of machines that can communicate without traversing the service provider backbone

� Each VPN site is mapped to a PE router interface

� Routing information is stored in different tables for each site

CEPP

PECE

CE

CE



PE

VPN Sites

46

VPN Routing and ForwardingVPN Routing and ForwardingTables (VRFs)Tables (VRFs)

PP

PP

PP PE 2 PE 2

VPN AVPN A

Site 3Site 3

VPN AVPN A

Site 1Site 1

VPN BVPN B

Site2Site2

VPN BVPN B

Site 1Site 1

PE 1PE 1

PE 3PE 3

VPN AVPN A

Site2 Site2

CECE––A1A1

CECE––B1B1

CECE––A3A3

CECE––A2A2

CECE––B2B2

PP

VPN BVPN B

Site3Site3

CECE––B3B3CECE––C1C1VPN CVPN C

Site 1Site 1 VPN CVPN C

Site 2Site 2

CECE––C2C2

A VRF is created

for each VPN

connected to the PE

Static Static RoutesRoutes

OSPF OSPF RoutingRouting

EE--BGPBGP

47

VRFsVRFs

� 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

48

Overlapping Address SpacesOverlapping Address Spaces

PP

PP

PP PE 2 PE 2

VPN AVPN A

Site 3Site 3

VPN AVPN A

Site 1Site 1 VPN BVPN B

Site2Site2

VPN BVPN B

Site 1Site 1

PE 1PE 1PE 3PE 3

VPN AVPN A

Site2 Site2

CECE––A1A1

CECE––B1B1 CECE––A3A3

CECE––A2A2

CECE––B2B2

PP

VPN BVPN B

Site3Site3

CECE––B3B3

10.1/1610.1/16

10.3/1610.3/16

10.2/1610.2/16

10.3/1610.3/16

10.2/1610.2/16

10.1/1610.1/16

49

Route Distinguisher (RD)Route Distinguisher (RD)

VPNVPN--IPv4 Address FamilyIPv4 Address Family

� 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

TypeType AdministratorAdministratorAssignedAssignednumbernumber Subscriber IPv4 prefixSubscriber IPv4 prefix

(2 (2 bytes)bytes) ((variablevariable

length)length)

((variablevariable

length)length)

(4 (4 bytes)bytes)

50


� 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

TypeType AdministratorAdministratorAssignedAssignednumbernumber Subscriber IPv4 prefixSubscriber IPv4 prefix

(2 (2 bytes)bytes) ((variablevariable

length)length)

((variablevariable

length)length)

8 Bytes 8 Bytes Route Distinguisher (RD)Route Distinguisher (RD)

(4 (4 bytes)bytes)

2 Byte Type Field: determines the lengths of the other two fields

Administrator Field: identifies an assigned number authority

Assigned Number Field: number assigned by the identified authority for a particular purpose

51


� Route distinguisher disambiguatesIPv4 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

52

Using Route DistinguishersUsing Route Distinguishers

PP

PP

PP PE 2 PE 2

VPN AVPN ASite 3Site 3

VPN AVPN ASite 1Site 1 VPN BVPN B

Site2Site2

VPN BVPN BSite 1Site 1

PE 1PE 1PE 3PE 3

VPN AVPN ASite2 Site2

CECE––A1A1

CECE––B1B1 CECE––A3A3

CECE––A2A2

CECE––B2B2

PP

VPN BVPN BSite3Site3

CECE––B3B3

10.1/1610.1/16

10.3/1610.3/16

10.2/1610.2/16

10.3/1610.3/16

10.2/1610.2/16

10.1/1610.1/16

10458:22:10.1/8010458:22:10.1/80

10458:23:10.1/8010458:23:10.1/80

BGPBGP

53

Operational Model OverviewOperational Model Overview

� 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

PP

PP

PP

PE 2 PE 2



Site2Site2


PE 1PE 1

PE 3PE 3


CECE––A1A1

CECE––B1B1CECE––A3A3

CECE––A2A2

CECE––B2B2

PP

54

RFC 2547bis Policies 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

55

Route DistributionRoute 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

56

Route TargetsRoute Targets

� Each VPN-IPv4 route advertised through BGP is associated with a route target attribute

� Export policies define what targets are associatedwith 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 addedto a VRF

� Route isolation between VRFs is accomplished through route filtering

� SP provisioning tool determines the appropriate export and import targets

57

Exchange of Routing InformationExchange of Routing Information

� CE device advertises route to PE Router

� Using traditional routing techniques (OSPF, IS-IS, RIP, BGP, static routes, etc)

10.1/1610.1/16OSPFOSPF

Site 1Site 1 Site 2Site 2

Site 1Site 1Site 2Site 2 PEPE--22

CECE--44

PEPE--11BGP sessionBGP session CECE--22

CECE--33

CECE--11

VRFVRFVRFVRF

VRFVRFVRFVRF

58



CECE--44


CECE--33

CECE--11

VRFVRFVRFVRF

VRFVRFVRFVRF


� 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

10458:23:10.1/8010458:23:10.1/80 10.1/1610.1/16OSPFOSPF

59



CECE--44


CECE--33

CECE--11

VRFVRFVRFVRF

VRFVRFVRFVRF


� VPN-IPv4 address is associated with an export target

� “VPN RED”

10458:23:10.1/8010458:23:10.1/80

““““““““VPN RED” exportVPN RED” export10.1/1610.1/16

OSPFOSPF

60



CECE--44


CECE--33

CECE--11

VRFVRFVRFVRF

VRFVRFVRFVRF


� VPN-IPv4 route is advertised to other PEs

� Inner label

� Target

� Next-hop

10458:23:10.1/8010458:23:10.1/80

““““““““VPN RED” exportVPN RED” export

label Z label Z

10.1/1610.1/16OSPFOSPF

NextNext--hop PEhop PE--2 2

61



CECE--44


CECE--33

CECE--11

VRFVRFVRFVRF

VRFVRFVRFVRF


� 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

““““““““VPN BLUE” importVPN BLUE” import

““““““““VPN RED” importVPN RED” import BGPBGP10.1/1610.1/16

OSPFOSPF10458:23:10.1/8010458:23:10.1/80


label Z label Z


62



CECE--44


CECE--33

CECE--11

VRFVRFVRFVRF

VRFVRFVRFVRF


� 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 mayshare the same label


10458:23:10.1/8010458:23:10.1/80

BGP BGP label label (inner) label ((inner) label (ZZ))IGP (outer) label (y)IGP (outer) label (y)

BGPBGP10.1/1610.1/16

OSPFOSPF10458:23:10.1/8010458:23:10.1/80


label Z label Z


63



CECE--44


CECE--33

CECE--11

VRFVRFVRFVRF

VRFVRFVRFVRF


� 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


10.1/1610.1/16 NextNext--hop PE1hop PE1

OSPF,…OSPF,…

64

Site 2Site 2(10.1/16)(10.1/16)Site 1Site 1

Site 1Site 1Site 2Site 2 PE-2

CE-4

PE-1CE-2

CE-3

CE-1

VRFVRF

VRFVRF

Data FlowData Flow

� The PE to PE LSP must be in place before forwarding data across the MPLS backbone

� LSPs are signaled through LDP or RSVP

65

Data FlowData Flow

� The CE performs a traditional IPv4 lookup and sends packets to the PE



CE-4

PE-1CE-2

CE-3

CE-1

VRFVRF

VRFVRF

IP

10.1.2.3

66



CE-4

PE-1CE-2

CE-3

CE-1

VRFVRF

VRFVRF

IP

10.1.2.3

Data FlowData Flow

� The PE consults the appropriate VRF for the inbound interface

� Two labels are derived from the VRF route lookup and “pushed” onto the packet

PE-1 1) Lookup route in Red FT

2) Push BGP label (Z)3) Push IGP label (Y)

67



CE-4

PE-1CE-2

CE-3

CE-1

VRFVRF

VRFVRF

Data FlowData Flow

� 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

PE-1 1) Lookup route in Red FT

2) Push BGP label (Z)3) Push IGP label (Y)

IP

10.1.2.3

BGP label (Z)

IGP label (Y)

68

Site 2Site 2(10.1/16)(10.1/16)

Data FlowData Flow

� After packets exit the ingress PE, the outer label is used to traverse the service provider

� P routers are not VPN-aware

Site 1Site 1


CE-4

PE-1CE-2

CE-3

CE-1

VRFVRF

VRFVRF

IP

10.1.2.3

BGP label (z)

IGP label (x)

69

Data FlowData Flow

� The outer label is removed through penultimate hop popping (before reaching the egress PE)



CE-4

PE-1CE-2

CE-3

CE-1

VRFVRF

VRFVRF

IP

10.1.2.3

BGP label (z)

Penultimate

Pop top label

70

Data FlowData Flow

� The inner label is removed at the egress PE

� The native IPv4 packet is sent to the outbound interface associated with the label



CE-4

PE-1CE-2

CE-3

CE-1

VRFVRF

VRFVRF

IP

10.1.2.3


Module 3: Basic Layer 3 VPN

Configuration with JUNOS Software

72

Module Objectives


� Create VRFs

� Write and apply VRF policy

� Configure BGP, extended communities

� Configure a point-to-point Layer 3 VPN topology using RSVP

73

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

74

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

75

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

76

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;

}

77

MP-IBGP Peering: PE-PElab@Amsterdam> show bgp neighborPeer: 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: RecvKeepAliveLast Error: None .Options: <Preference LocalAddress HoldTime AddressFamily Rib-group Refresh> Address families configured: inet-unicast inet-vpn-unicastLocal Address: 192.168.24.1 Holdtime: 90 Preference: 170Number of flaps: 0Peer ID: 192.168.16.1 Local ID: 192.168.24.1 Active Holdtime: 90Keepalive Interval: 30NLRI advertised by peer: inet-unicast inet-vpn-unicastNLRI for this session: inet-unicaat inet-vpn-unicastPeer support Refresh capability (2)Table inet.O Bit: 10000

Send atate: in syncActive prefixes: 0Received pref1xes: 0Suppressed due to damping: 0

Table bgp.l3vpn.O Bit: 30000Send state: in syncActive prefixes: 8Received prefixes: 8Suppressed due to damping: 0

Table vpna,inet.O Bit; 40000Send state: in syncActive prefixes: 7Received prefixes: 8

78

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

79

Sample Layer 3 VPN Topology

� 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

Provider Core

AS 65412

P1 P2

CE

A

CE

B

HK

AM

Lo0:192.168.14.1

Lo0:192.168.24.1

Fe-0/0/1

Fe-0/0/1

Fe-0/0/0

Fe-0/0/0

21/24

16/24 1/24 24/24

29/24

1 2

1

2

2

1

1

2

1

2

OSPF Area 0172.20.0-3/24AS 65001

192.168.20.1172.20.4-7/24

AS 65001192.168.28.1

80

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

81

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# showinstance-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;

}}

}

82

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;

}

}

83

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

84

Extended BGP Communities

� 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

community ce-name-origin members origin:192.168.16.1:100;

community vpn-a-target members target:65412:100;

85

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

86

PE-CE BGP Routing/Policy Example

lab@Hong-Kong # show routing-instancesvpna { ………………

}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-afrom protocol bgp;then {

as-path-prepend "64512 64512“;community add cust-a;accept;

}

87

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

Provider Core

AS 65412

P1 P2

CE

A

CE

B

HK

AM

Lo0:192.168.14.1

Lo0:192.168.24.1

Fe-0/0/1

Fe-0/0/1

Fe-0/0/0

Fe-0/0/0

21/24

16/24 1/24 24/24

29/24

1 2

1

2

2

1

1

2

1

2

OSPF Area 0

172.20.0-3/24AS 65001

172.20.4-7/24AS 65001

172.20.0-3/24AS 65001 t

172.20.0-3/24AS 65412 65412 t


Module 4: Troubleshooting

Layer 3 VPNs

89

Module Objectives


� 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

90

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

91

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

92

Troubleshooting: A Layered Approach

Provider Core

P1 P2

CE

CE

HK

AM

PE-PE Problems:VRF-Export

Core Problems:IGP

MPLS(RSVP/LDP)IBGP

PE-CE Problems:IGP/EBGPPolicy

PE-CE Problems:IGP/EBGPPolicy

PE-PE Problems:VRF-Export

Data Forwarding

93


� Network characteristics

� 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

Provider Core

AS 65412

P1 P2

CE

A

CE

B

HK

AM

Lo0:192.168.14.1

Lo0:192.168.24.1

Fe-0/0/1

Fe-0/0/1

Fe-0/0/0

Fe-0/0/0

21/24

16/24 1/24 24/24

29/24

1 2

1

2

2

1

1

2

1

2

OSPF Area 0172.20.0-3/24AS 65001

192.168.20.1172.20.4-7/24

AS 65001192.168.28.1

94

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?

95

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?�

96

The vpn-interface Command

� 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

lab@Hong-Kong> ping 10.0.21.1 count 1 .PING 10.0.21.1 (10.0.21.1): 56 data bytesping: 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 1PING 10.0.21.1 (10.0.21.1): 56 data bytes64 bytes from 10.0.21.1: icmp_seq=0 ttl=255 time=0.334 ms

--- l0.0.21.1 ping statistics ---1 packets transmitted, 1 paekets received. 0% packet lossround-trip min/avg/max/stddev = 0.334/0.334/0.334/0.000 ms

97

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-instancevpna {

instance-type vrf;interface fe-0/O/O.O;route-distinguisher 192.168.16.1:1;vrf-import vpna-import;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;

}}

98

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/24Routing table: vpna.inetInternet: Destination Type RtRef Nexthop Type Index NhRef Netif10.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.2Routing table: vpna.inetInternet: Destination Type RtRef Nexthop Type Index NhRef Netif10.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.0Routing table: vpna.inetInternet: Destination Type RtRef Nexthop Type Index NhRef Netif10.0.29.0/32 user 0 10.0.16.2 Push 100000 Push 100008(top) fe-0/0/1.0

99

Internet Processor II Functionalityat 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

100

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 bytesping: send to: No route to host^c--- l0.0.29.9 ping statistics ---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 1PING 10.0.29.2 (10.0.29.2): 56 data bytes64 bytes from 10.0.29.2: icmp_seq=0 ttl=250 time=0.888 ms

--- l0.0.29.2 ping statistics ---1 packets transmitted, 1 paekets received. 0% packet lossround-trip min/avg/max/stddev = 0.888/0.888/0.888/0.000 ms

101

Traffic Path for PE-PE Pings

Internet Processor and ARP processing not available at egress PE router

lab@Hong-Kong> ping vpn-interface fe-0/0/0 10.0.29.1PING 10.0.29.1 (10.0.29.1): 56 data bytes64 bytes from 10.0.29.2: icmp_seq=0 ttl=251 time=0.833 ms^c--- l0.0.29.1 ping statistics ---1 packets transmitted, 1 paekets received. 0% packet lossround-trip min/avg/max/stddev = 0.833/0.833/0.833/0.000 ms

Provider Core

AS 65412

P1 P2

CE

A

CE

B

HK

AM

Lo0:192.168.14.1

Lo0:192.168.24.1

Fe-0/0/1

Fe-0/0/1

Fe-0/0/0

Fe-0/0/0

21/24

16/24 1/24 24/24

29/24

1 2

1

2

2

1

1

2

1

2

OSPF Area 0

Echo Request (10.0.21.1-> 10.0.29.1)

Echo Reply (10.0.29.1-> 10.0.21.1)

102

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

103

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.1traceroute to 192.168.28.1 (192.168.28.1). 30 hops max, 40 byte packets1 l0.0.21.1 (10.0.6,1) 0.444 ms 0.352 ms 0.341 ms2 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=13 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: 4MPLS Bottom Of Label Stack: 0MPLS TTL: 254

MultiProtocol Label Switching HeaderMPLS Label. unknown (100001)MPLS Experimental Bits: 4MPLS Bottom Of Label Stack: 1MPLS TTL: 1

Internet ProtocolUser Datagram ProtocolData (12 bytes)

104

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

105

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

106

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:02Local

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.1AS path: I

> to 10.0.16.2 via ge-0/l/0.0, label-switched-path am172.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

107

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:1Source: 192.168.24.1Nexthop: 10.0.16.2 via ge-0/1/0.0, selectedlabel-awitchad-path amPush 100000, Push 100001(top)State: <Secondary Active Int-Ext>Local As: 65412 Peer AS: 65412Age: 1d 1:34:25 Metrics: 40Task: BGP_65412.192.168.24.1+1048Announcement bits (2): O-BGP.O.O.O.O+179 1-KRTAS path: 65001 IComunities: target:65412:lOO origin:l92.168.24.l:1BGP next hop: 192.168.24.1Localpref: 100Router ID: 192.168.24.1Primary Routing Table bgp.l3vpn.O

108

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


192.168.16.1:1:172.20.2.0/24*[BGP/170] 14:28:30. localpref 100, from 192.168.5.1


109

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

110

Viewing Routes Received fromOther 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)

Prefix Nexthop MED Lclpref AS path

……………

192.168.24.1:1:172.20.4.0/24

192.168.24.1 100 65001 I

111

Viewing a VPN Forwarding Table

� Use the show route forwarding-table vpn vpn-name command

lab@Hong-Kong > show route forwarding-table vpn vpnaRouting table: vpna.inetInternet:Destination Type RtRef Nexthop Type Index NhRef NetifDefault perm 0 dscd 6 110.0.21.0/24 intf 0 recv 51 1 fe-0/0/0.010.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 210.0.21.1/32 dest 0 10.0.21.1 locl 50 210.0.21.2/32 dest 1 0:d0:b7:3f:af:73 ucst 52 8 fe-0/0/0.010.0.21.255/32 dest 0 10.0.21.255 bcst 48 1 fe-0/0/0.010.0.29.0/24 user 0 10.0.16.2 Push 100008, fe-0/0/1.0172.20.0.0/24 user 0 10.0.21.2 ucst 52 8 fe-0/0/0.0112.20.1.0/24 user 0 10.0.21.2 ucst 52 8 fe-0/0/0.0172.20.2.0/24 user 0 10.0.21.2 ucst 52 8 fe-0/0/0.0172.20.3.0/24 user 0 10.0.21.2 ucst 52 8 fe-0/0/0.0172.20.4.0/24 user 0 10.0.16.2 Push 100000, Push 100008(top) fe-0/0/1.0172.20.5.0/24 user 0 10.0.16.2 Push 100000, Push 100008(top) fe-0/0/1.0172.20.6.0/24 user 0 10.0.16.2 Push 100000, Push 100008(top) fe-0/0/1.0172.20.7.0/24 user 0 10.0.16.2 Push 100000, Push 100008(top) fe-0/0/1.0192.168.20.1/32 user 0 10.0.21.2 ucst 52 8 fe-0/0/0.0192.168.26.1/32 user 0 10.0.16.2 Push 100000, Push 100008(top) fe-0/0/1.0

112

Clearing VRF ARP Entries

� Use the clear arp vpn vpn-name command

lab@Hong-kong> show arpMAC Address Address Name InterfaceOO:bO:d0:1O:7J:2f 10.0.1.100 10.0.1.100 fxp0.00O:dO:b7:3f:af:Of 10.0.1.200 10.0.1.200 fxp0.0OO:dO:b7:3f:ad:d5 10.0.16.2 10.0.16.2 fe-0/0/1.0OO:dO:b7:3f:af:73 10.0.21.2 10.0.21.2 fe-0/0/0.0TOtal entries: 4

lab@Hong-Kong> clear arp10.0.1.200 10.0.1~200 deleted10.0.1.100 lO.O.1.10 deleted10.0.16.2 10.0.16.2 deleted10.0.16.2 10.0.16.2 deleted

lab@Hong-Kong> clear arp vpn vpna10.0.21.2 10.0.21.2 deleted

� The show arp command displays both inet.0 and VRF ARP entries

113

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


Module 5: Layer 2 VPNs (Kompella)

115

Module Objectives


� 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)

116

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

117

Differences between Kompella and 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

Kompella Martini

118

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

119

Layer 2 Provider-ProvisionedMPLS-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

120

Improving Traditional Layer2 VPNs with MPLS

� Decouple edge (customer-facing) technology from core technology

� Have a single network infrastructure for multiple services

� Simplify provisioning

121

� 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

Standards for Layer 2 VPNsStandards for Layer 2 VPNs

122

Customer Edge DevicesCustomer Edge Devices

� 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 …) independenceof 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

CEPP

PECE

CE

CE



PE

Customer Edge

ATMATM

FRFR

ATMATM

FRFR

VPN Site

123

Provider Edge RoutersProvider Edge Routers

� 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

CEPP

PECE

CE

CE



PE

ATMATM

FRFR

ATMATM

FRFR

Provider Edge

124

Provider RoutersProvider Routers

� Provider (P) routers

� Forward VPN traffic transparently over established LSPs

� Do not maintain VPN-specific forwarding information

CEPP

PECE

CE

CE



PE

ATMATM

FRFR

ATMATM

FRFR

Provider Routers

125

PP

PP

PP PE 2 PE 2

VPN AVPN A

Site 3Site 3

VPN AVPN A

Site 1Site 1

VPN BVPN B

Site2Site2

VPN BVPN B

Site 1Site 1

PE 1PE 1

PE 3PE 3

VPN AVPN A

Site2 Site2

CECE––A1A1

CECE––B1B1

CECE––A3A3

CECE––A2A2

CECE––B2B2

PP

A VFT is createdA VFT is created

for each CE for each CE

connected to the PEconnected to the PE

DraftDraft--Kompella:Kompella:VPN ForwardingVPN Forwarding Tables (VTables (VFTFTs)s)

ATMATM

ATMATM

ATMATM

� Each VFT is populated with:

� The information provisioned for the local CEs

� VPN Connection Tables received from other PEs via BGP or LDP

126


Site 1Site 1Site 2Site 2

DraftDraft--Kompella:Kompella:VPN VPN Connection Connection Tables (Tables (VCTVCT))

PE-2

CE-4

PE-1CE-2

CE-2

CE-1

VFTVFT

VFTVFT

� The VCT is a subset of information held by the VFT

� VCTs are distributed by the PEs via BGP or LDP

A VA VCTCT is is distributed for distributed for

each VPN site each VPN site to PEto PEss

BGP session / LDP

127

PP

PP

PPPE 2 PE 2



Site2Site2


PE 1PE 1


CECE––A1A1


CECE––A2A2

CECE––B2B2

PP

DraftDraft--Kompella:Kompella:Provisioning the NetworkProvisioning the Network

� 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

FRFR

FRFR

FRFR

PE 3 PE 3

128

DraftDraft--Kompella:Kompella: Provisioning Customer Provisioning Customer Site on PESite on PE

� 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

CE-4 DLCIs

63

75

82

94

CE-4 Routing Table

In Out

DLCI 6310/8

DLCI 7520/8DLCI 8230/8DLCI 94-

129

DraftDraft--Kompella:Kompella: Provisioning Provisioning Customer Site on PECustomer Site on PE

� A VFT is provisioned at each PE for each local CE

� 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

CECE44 VFTVFT

CE ID 4

CE Range

1000

4

Label Base

Sub-int IDs

63

75

82

94

CECE44 VCTVCT

Label

RT1Imp/Exp RT

130



DraftDraft--Kompella:Kompella: Provisioning Provisioning Customer Site on PECustomer Site on PE

PE-2

CE-4

PE-1CE-2

CE-2

CE-1

VFTVFT

VFTVFT

CECE44 VFTVFT

Imp/Exp RT

CE ID

RT1

4

CE Range

Label

4

Sub-int IDs

63

75

82

94

1001

1002

1003

Label used to reach CE4from CE

11001

Label used to reach CE4 from CE21002

1000 Label used to reach CE4 from CE01000

FRFR

CE4‘s DLCI to CE0 63

CE4‘s DLCI to CE1 75CE4‘s DLCI to CE2 82

CE4‘s DLCI to CE3 94

� PE-2 is configured with the CE4

VFT

Label used to reach CE4from CE

31003

Label base 1000

131

DraftDraft--Kompella:Kompella:Distributing VCTsDistributing 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

132



DraftDraft--Kompella:Kompella:Distributing VCTsDistributing VCTs

� PE-1 receives BGP Route that carries PE-2’s CE4

VCT

PE-2

CE-4

PE-1CE-2

CE-2

CE-1

VFTVFT

VFTVFT

FRFR

Label used to reach CE4 from CE21002

BGP Session

CECE44 VCT updateVCT update

RT

CE ID

RT1

4

CE Range

Label base

4

1000

CECE44 VCT updateVCT update

RT

CE ID

RT1

4

CE Range

Label base

4

1000

133



DraftDraft--Kompella:Kompella:Updating VFTsUpdating VFTs

� 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

PE-2

CE-4

PE-1CE-2

CE-2

CE-1

VFTVFT

VFTVFT

FR DLCI 82FR DLCI 414

CECE22 VFTVFT

CE ID Inner LabelSub-int IDs

Label used to reach CE41002

107

209

265

414

1

2

3

4

5020

7500

9350

134



DraftDraft--Kompella:Kompella:Updating VFTsUpdating VFTs

� 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

PE-2

CE-4

PE-1CE-2

CE-2

CE-1

VFTVFT

VFTVFT

CECE22 VFTVFT

CE ID Inner LabelSub-int IDs

LSP to PE-2500

107

209

265

414

1

2

3

4

5020

7500

9350

1002

Outer Label

FR DLCI 82FR DLCI 414

135



DraftDraft--Kompella:Kompella:Data FlowData Flow

� The CE-2 sends packets to the PE via the DLCI which connects to CE-4 (414)

PE-2

CE-4

PE-1CE-2

CE-2

CE-1

VFTVFT

VFTVFT

DLCI 82DLCI 414

packet DLCI

414

136




� 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

PE-2

CP-4

PE-1CE-2

CE-2

CE-1

PE-1

1) Lookup DLCI in Red VFT

2) Push VPN label (1002)

3) Push IGP label (500)

VFTVFT

VFTVFT

DLCI 82

Packet

site label (1002)

IGP label (500)

137


10.1/1610.1/16



� After packets exit the ingress PE, the outer label is used to traverse the LSP

� P routers are not VPN-aware

PE-2

CPE-4

PE-1CE-2

CE-2

CE-1

VFTVFT

VFTVFT

Packet

site label (1002)

IGP label (z) DLCI 82DLCI 414

138


10.1/1610.1/16



� The outer label is removed through penultimate hop popping (before reaching the egress PE)

PE-2

CE-4

PE-1CE-2

CE-2

CE-1

Penultimate

Pop top label

VFTVFT

VFTVFT

Packet

site label (1002)

DLCI 82DLCI 414

139




� 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

PE-2

CE-4

PE-1CE-2

CE-2

CE-1

VFTVFT

VFTVFT

DLCI 82DLCI 414

packet DLCI

82

140

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

141

DraftDraft--Kompella: Kompella: Supported Layer 2 TechnologiesSupported Layer 2 Technologies

� Frame Relay

� ATM AAL5 CPCS Mode

� ATM Transparent Cell Mode

� Ethernet

� Ethernet VLAN

� Cisco HDLC

� PPP


Module 6: Layer 2 VPN Configuration and Troubleshooting (Kompella)

143

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

144

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

145

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

146

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 bgpgroup int {

type internal;local-address 192.168.24.1;family inet {

unicast;}family 12-vpn {

unicast;}neighbor 192.168.16.1;

}

147

MP-IBGP Peering Examplelab@Amsterdam> show bgp neighborPeer: 192.168.16.1+1037 AS 65412 Local: 192.168.24.1+179 AS 65412Type: Internal State: Established Flags: < >Last State: OpenConfirm Last Event: RecvKeepAliveLast Error: None Options: <Preference LocalAddress HoldTime AddressFamily Rib-group Refresh> Address families configured: inet-unicast l2vpnLocal Address: 192.168.24.1 Holdtime: 90 Preference: 170Number of flaps: 0Peer ID: 192.168.16.1 Local ID: 192.168.24.1 Active Holdtime: 90Keepalive Interval: 30NLRI advertised by peer: inet-unicast inet-multicast l2vpnNLRI for this session: inet-unicaat l2vpnPeer support Refresh capability (2)Table inet.O Bit: 10000

Send atate: in syncActive prefixes: 0Received pref1xes: 0Suppressed due to damping: 0

Table bgp.l2vpn.0 Bit: 30000Send state: in syncActive prefixes: 1Received prefixes: 1Suppressed due to damping: 0

Table vpna.l2vpn.0 Bit: 50000Send state: in syncActive prefixes: 1Received prefixes: 1

148

Layer 2 VPN NLRI (VCT)

� 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

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

149

The Circuit Status Vector

� 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

Provider Core

AS 65412

P1 P2

Site

1

Site

2

HK

AM

Lo0:192.168.14.1

Lo0:192.168.24.1

Fe-0/0/1

Fe-0/0/1

at-0/0/0

at-0/0/0

16/24 1/24 24/24

1 2

1

2

2

1

OSPF Area 0

XX

ATM PVC Detected

Down by HK

F5 RDI Cells

…….11

Bits 0 n

Layer 2 NLRI with updated CSV

150

Layer 2 Information Extended Communities

� 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

Community Type (2 Bytes)

Encapsulation Type (1 Byte)

Control Flags (1 Byte)

Layer 2 MTU (2 Bytes)

Reserved (2 Bytes)

0 Reserved

1 ATM PDUs(AAL5)2 ATM Cells

3 Frame Relay4 PPP5 Cisco HDLC

6 Ethernet VLAN7 MPLS

8 IP-Only Layer 2 Internetworking

151

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

152


� Network characteristics

� 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

Provider Core

AS 65412

P1 P2

CE

1

CE

2

HK

AM

Lo0:192.168.14.1

Lo0:192.168.24.1

Fe-0/0/1

Fe-0/0/1

fe-0/0/0

fe-0/0/0

16/24 1/24 24/24

1 2

1

2

2

1

OSPF Area 021/24

1

2

21/24

172.20.0-3/24

OSPF Area 0

192.168.20.1

172.20.4-7/24

OSPF Area 0

192.168.28.1

153

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


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

154

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-ainstance-type l2vpn;interface fe-0/0/0.0;route-distiuguisher 192.168.16.1:1;vrf-import vpna-import;vrf-axport vpna-export;protocols {

l2vpn {encapsulation-type ethernet-vlan;site ce-1 {

site-identifier 1;interface fe-0/0/0.0;}

}}

}

155

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;

}

}

156

Sample Layer2 VRF Export Policy

[edit policy-options policy-statement vpna-export]lab@Amsterdam# showterm 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

157

Layer 2 VPN Extended BGP Communities

� 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

community vpn-a-target members target:65412:100;

158

Sample Layer2 Instance: Part 2

� Local site properties configured under the protocols portion of l2vpn instances

lab@hk-pe# show routing-instances vpn-ainstance-type l2vpn;interface fe-0/0/0.O;route-distinguisher 192.168.16.1:1;vrf-import vpna-import;vrf-export vpna-export;protocols {


site-identifier 1;interface fe-0/0/0.0;}

}}

}

159

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 1encapsulation-type ethernet-vlan;

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 6encapsulation-type ethernet-vlan;

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

160

Remote Site Identifier Example

� The Configuration……..

protocol {l2-vpn {

encapsulation-type ethernet-vlan;site ce-1 {

site-identifier 1;interface fe-0/0/0.0; {

remote-site-id 3;

� The ResultInstance : vpn-aLocal 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)

161

Remote Site Identifier Example: 2

� Both Examples produce equivalent connectivity and label Range

……..l2-vpn {

encapsulation-type ethernet-vlan;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 {encapsulation-type ethernet-vlan;site ce-3 {

site-identifier 3;interface fe-0/0/0.0; {

remote-site-id 2;}interface fe-0/0/0.1; {

remote-site-id 1;

……..

162

Example: Layer 2 VPN

lab@hk-pe# sbow routing-instance vpnainstance-type l2vpn;interface fe-0/0/0.0;route-distinguisher 192.168.16.1:1;vrf-import vpna-import;vrf-export vpna-export;protocols {


site-identifier 1;interface fe-O/O/0.0;

……………………………………………

Provider Core

AS 65412

P1 P2CE

1

CE

2

HK

AM

Lo0:192.168.14.1

Lo0:192.168.24.1Fe-0/0/1

Fe-0/0/1fe-0/0/0

fe-0/0/0

16/24

1/24 24/24

1 21

2

2

1

OSPF Area 021/24

1

2

21/24

172.20.0-3/24

OSPF Area 0

192.168.20.1

172.20.4-7/24

OSPF Area 0

192.168.28.1Site 1

Site 2

lab@Amsterdam# show routing-instances vpn-ainstance-type 12vpn,interface fe-0/0/O.O;route-distinguisher 192.168.24.1:1;vrf-import vpna-import;vrf-export vpna-export;Protocols {

12vpn {encapsulatlon-type ethernet-vlan;site ce-2 {

site-identifier 2;interface fe-O/O/O.O;

……………………………………………

163

Interface Configuration: Example 1

ge-0/1/0 {vlan-tagging;encapsulation vlan-ccc;unit 1 {

encapsulation vlan-ccc;vlan-id 515;

}unit 2 {


}}fe-1/O/1 {

vlan-tagging;encapsulation vlan-ccc;unit 0 {

encapsulation vlan-ccc;vlan-id 513

}}

Sample Gigabit EthernetSample Gigabit Ethernet

Sample Fast EthernetSample Fast Ethernet

164

Interface Configuration: Example 2

so-2/0/0 {no-keepalives;encapsulation frame-relay-ccc;unit 1 {

encapsulation frame-re1ay-ccc;dlci 551;

}unit 2 {

encapsulation frame-relay-ccc;dlc1 552;

}so-2/0/2 {

encapsulatlan ppp-ccc ;unit 0;

}

at-2/3/0 {

atm-options {

vpi 0 maximum-vcs 1000;

vpi 1 maximum-vcs 1000;

}

unit 1 {

encapsulation atm-ccc-vc-mux;

vci 1.42;

}

unit 3 {

encapsulation atm-ccc-vc-mux;

vci 1.53;

}

Sample Frame Relay/PPPSample Frame Relay/PPPConfigurationConfiguration

Sample ATMSample ATMConfigurationConfiguration

165

Expanding Layer 2 VPN Membership: Part 1

� 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)

Provider Core

AS 65412

P1 P2

CE

1

CE

2

HK

AM

Lo0:192.168.14.1

Lo0:192.168.24.1

Fe-0/0/1

Fe-0/0/1

fe-0/0/0.0

fe-0/0/0.1

16/24 1/24 24/24

1 2

1

2

2

1

OSPF Area 021/24

.1

.2

21/24

CE

2

15/24

fe-0/0/0.0.2

.122/24

fe-0/0/0.1

166

Expanding Layer 2 VPN Membership:Part 2

lab@ce-1# sbow interfacesfe-0/0/0 {

vlan-tagging;unit 0 {

vlan-id 512;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;

}}

}

CE-1's interface and protocol configuration

test@ce-l' sbow protocolsospf {

area 0.0.0.0 {interface fe-O/O/O.O;interface fe-O/O/O.l;

}}

167

Expanding Layer 2 VPN Membership: Part 3

[edit interfaces]lab@hk-pe# show fe-O/O/Ovlan-tagging;Encapsulation vlan-ccc;unit o{


}unit 1 {


Hong Kong VPN interface and layer 2 configuration (site 1)

lab@hk-pe# show routing-instancesvpn-a {

instance-type 12vpn;interface fe-0/0/0.0;interface fe-0/0/0.1;route-distinguisher 192.168.16.1:1;vrf-import vpna-import;vrf-export vpna-export;protocols {


site-identifier 1;interface fe-0/0/0.0;interface fe-0/0/0.1;

}}

}}

Default site 2association

Associated with site 3through inheritance

168

Expanding Layer 2 VPN Membership:Part 4

[edit interfaces]lab@Amsterdam# show fe-0/0/0vlan-tagging;encapsulation vlan-ccc;unit 0 {


}unit 1 {


}

Amsterdam VPN interface configuration (sites 2 and 3)

[edit interfaces)lab@Amsterdam# show fe-O/O/3vlan-tagging;encapsulation vlan-ccc;unit 0 {


}unit 1 {


}

169

Expanding layer 2 VPN Membership:Part 5


lab@Amsterdam# show

instance-type l2vpn;

interface fe-0/0/0.0;




route-distinguisher 192.168.24.1:1;

vrf-import vpna-import;

vrf-export vpna-export;

.

.

.

Amsterdam VPN interface and Layer2 configuration (sites 2 and 3)

.

.

.protocols {


site-identifier 2;interface fe-0/0/0.0;interface fe-0/0/0.1;}

}site ce-3 {

site-identifier 3;interface fe-0/0/3.1;interface fe-0/0/3.0;

}}

}

Default association with site 3

association with site 1 and site 2(Note interface ordering: LU1 is

Listed before LU 0)

170

The Results: Part 1

lab@hk-pe> show 12vpn connectionsL2VPN Connections :instance : vpn-aLocal site: 1 (ce-1)offset: 1, range: 3, label-base: 32768

connection-site Type St Time last up # Up trans2 rmt up Jul 19 04:43:49 2001 1

Local circuit: fe-0/O/O.O, Status: upRemote PE: 192.168.24.1Incoming label: 32769, outgoing label: 32768

3 rmt up Jul 19 04:43:49 2001 1Local circuit: fe-O/O/O.l, Status: upRemote PE: 192.168.24.1Incoming label: 32770, outgoing label: 33792

171

The Results: Part 2

lab@Amsterdam# show 12vpn connectionsL2VPN Connections :Instance : vpnaLocal site: 2 (ce-2)offset: 1. range: 3 label-base: 32768

connection-site Type St Time last up # Up trans3 (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 1Local circuit: fe-0/0/0.0, Status: UpRemote PE: 192.168.16.1Incoming label: 32768. Outgoing label: 32769

Local site: 3 (ce-3)offset: 1. range: 2. label-base: 33792

connection-site Type St Time last up # Up trans2 (ce-b) loc Up Jul 18 20:45:46 2001 1

Local circuit: fe-0/0/0.l, Status: upRemote circuit: fe-0/0/3.0, Status: up

1 rmt Up Jul 18 21:47:25 2001 1Local circuit: fe-0/0/3.1, Status: UpRemote PE: 192.168.16.1Incoming label: 33792. Outgoing label: 32770

172

Layer 2 Interworking

� 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

Provider Core

AS 65412

P1 P2CE

1

CE

2

HK

AM

Lo0:192.168.14.1

Lo0:192.168.24.1Fe-0/0/1

Fe-0/0/1

so-0/0/0.0 at-0/0/0.0

16/24 1/24 24/24

1 21

2

2

1

OSPF Area 021/24

1

2

21/24

Site 1

Site 2

ATM to Frame Relay Internetworking

173

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

174

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

8

MAC Header

14

VLAN

4

LLC

3

IS-IS PDU

1492(min)

VLANVLAN--Base L2 VPN Encapsulation ExampleBase L2 VPN Encapsulation Example

175

Troubleshooting: A Layered-Approach

Provider Core

P1 P2

CE

CE

HK

AM

PE-PE Problems:VRF-export/import

Core Problems:IGP

MPLS(RSVP/LDP)IBGP

PE-CE Problems:For Example:Circuit ID

PE-PE Problems:VRF-export/import

CE-CE Problem

PE-CE Problems:For Example:Circuit ID

(For Example: Policy, Routing Protocol,

Addressing, MTU)

176

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

177

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

178

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

MultiProtocol Label Switching Header

MPLS Label: Unknown (100011) .

MPLS Experimental Bit : 0

MPLS Bottom of Label Stack: 0

MPLS TTL: 254

MultiProtocol Label Switching Header

MPLS Label: Unknown (37269)

MPLS Experimental Bits: 0

MPLS Bottom of Label Stack: 1

MPLS TTL: 1

Internet Protocol

User Datagram Protocol

Data (12 bytes)

179

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

180

Displaying Layer 2 VPN Connections

lab@hk-pe> show l2vpn connections ?Possible completions:＜[Enter]> Execute this commandbrief Connection status (one line)down Connections that are not operationalextensive Connection status and historyhistory Connection historyinstance L2VPN instance namelocal-site L2VPN local-site name or IDremote-site L2VPN remote-site name or IDstatus Connection and circuit status (default)up Connections that are operationalup-down Both operational and non-operational connections| Pipe through a command

show l2vpn connections operational mode command

181

Sample l2Vpn connections Output

lab@hk> show l2vpn connections extensiveL2VPN Connections:

Legend for connection Status (St)OR -- out of rangeEM -- encapsulation mismatchCN -- circuit not presentOL -- no outgoing labelDn -- downVC-Dn -- Virtual circuit Down-> -- only Outbound conn is up<- -- only inbound conn is upUP -- operationalXX -- unknown

Instance: vpn-aLocal site: ce-a (1)

Interface name Remote Site IDfe-0/0/0.0 2Label Base Offset Range

32768 1 2connection-site type St Time Last UP # Up trans2 rmt Up Aug 3 00:08:14 2001 1

Local circuits: fe-0/0/0.0, Status: UpRemote PE: 192.168.24.1Incoming label: 32769, Outgoing label: 32768

Time Event Interface/Lb1/PEAug 3 00:08:14 2001 PE route UpAug 3 00:08:14 2001 Out lbl Update 32768Aug 3 00:08:14 2001 In lbl Update 32769Aug 3 00:08:14 2001 cktO up fe-0/0/0.0

3 rmt OR

Legend for ci~uit atatusup -- operationalDn -- downNP -- no presentDS -- disabled WE -- wrong encapsulationUN -- uninitialized

182

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

183

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

*[BGP/170] 00:02:53. localpref 100, from 192.168.24.1

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

*[BGP/170] 00:02:53. localpref 100, from 192.168.24.1

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

184

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)

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

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

185

show route table Command:

Example 2

lab@hk-pe> show route table vpn-a detail | find 192.168.24.1:1:2:1/96192.168.24.1:1:2:1/96 (1_entry, 1 announced)

*BGP Preference: 170/-101Route Distinguisher: 192.168.24:1:1Source: 192.168.24.1 Nexthop: 10.0.16.2 via fe-0/0/1.0, selectedlabel-switched-path amPush 100067Protocol Nexthop: 192.168.24.1, Indirect nexthop: 84cfc38 39State: <Secondary Active Int Ext>Local AS: 65412 Peer AS: 65412Age: 4:56 Metric2: 3Task: BGP_65412.192.168.24.1+1028Announcement hits (1): 0-vpn-a-OSPFAS path: ICommunities: targat:65412:200 Layer2 Info: encaps:VLAN,control flags:0, mtu: 0Label-base : 800000, range : 1, status-vector : 0x80Localpref: 100Router ID: 192.168.0.1Primary Routing Table bgp.l2vpn.0

186

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


187

Viewing Routes Sent to Other PE Routers

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 path192.168.16.1:1:111/96 (1 entry, 1 announced)

BGP group int type Internal Route Distinguisher: 192.168.16.1:1Label-base: 32768, range : 3, status-vector: 0x80Nexthop: SelfLocalpref: 100AS path:_ ICommunities: target:65412t:l00 Laye2-info: encaps:VLAN, controlflags:0, mtu: 0

Use the show route advertising-protocol bgppeer-address command

188

Viewing Routes Received fromOther PE Reuters

lab@hk-pe> sbow route receive-protocol bgp 192.168.24.1inet.O: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path

inet.1: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)Prefix Nexthop MED Lclpref AS path

mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)Prefix Nexthop MED Lclpref AS path

vpn-a.l2vpn.0: 3 destination, 3 routes, (3 active, 0 holddown, 0 hidden)Prefix Nexthop MED Lclprer AS path192.168.24.1:1:2:1/96

192.168.24.1 100 I192.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)Prefix Nexthop MED Lclpref AS path192.168.24.1:1:2:1/96

192.168.24.1 100 I192.168.24.1:1:3:1/96

192.168.24.1 100 I

Use the show route receive-protocol bgppeer-address command

189

Viewing the MPLS Table

lab@hk-pe > show route table mpls detail

mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both. . . . . . 32769 (1 entry, 1 announced)

*VPN Preference: 7Nexthop: via fe-0/0/0.0, selectedPop [0]State: <Active Int>Local AS: 65412Age: 21:40Task: L2VPN globalAnnouncement bits (1): O-KRTAS path: I

. . . . . .fe-0/0/0.0 (1 entry, 1 announced)

*VPN Preference: 7Nexthop: 10.0.16.2 via fe-0/0/1.0, selectedlabel-switched-path amPush 32768, Push 100067(top)Protocol Nexthop: 192.168.24.1 Indirect nexthop: 64cfd48 43State: <Active Int> Local AS: 65412Age: 21:40 Metric2: 3Task, L2VPN globalAnnouncement bits (1): O-KRT

Use the show route table mpls command to display

MPLS table entries for Layer 2 VPNs

190

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 cccRouting table: cccMPLS:Interface.Label Type RtRef Nexthop Type Index NhRef NetifDefault perm 0 dscd 3 10 user 0 recv 5 21 user 0 recv 5 232769 user 0 ucst 45 1 fe-0/0/0.534fe-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

191

Tracing Layer 2 VPNs

� Tracing options for layer 2 VPNs

lab@hk-pe# set traceoptions flag ?Possible completions:

all Trace everythingconnections Trace L2VPN connectionserror Trace errorsnlri Trace L2VPN remote site advertisementsroute Trace L2VPN PE routestopology 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;

}


Module 7 : Basic Configuration and Trouble Shooting with VPLS

Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net

193

PP

PP

PPPE 2 PE 2



Site2Site2


PE 1PE 1


CECE––A1A1


CECE––A2A2

CECE––B2B2

PP

Virtual Private LAN ServiceVirtual Private LAN Service

� 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

PE 3 PE 3

194

VPLS AcronymsVPLS Acronyms

� 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

Site BSite B

PEPE PEPE

Attachement Attachement

CircuitCircuit

ProviderIP NetworkProvider

IP NetworkCPECPECPECPE

Emulated Tunnel

AttachementAttachement

CircuitCircuit

Site ASite A

VPLSVPLS

InstanceInstance

195

VPLS OperationsVPLS 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

196

VPLS Signalling & AutoVPLS Signalling & Auto--discoverydiscovery

PEPE CC

Auto-Dicovery : I have VPLS Instance 3 for VPLS domain REDAuto-Dicovery : I have VPLS Instance 3 for VPLS domain RED

Local Ports

Rx VC Label W/ Tx VC Label X for VPLS instance Aif 0if 0

Virtual Remote Ports

if 1if 1

if 2if 2Rx VC Label Y / Tx VC Label Z for VPLs instance B

Signaling : Use these VC Labels (Rx) to send traffic to meSignaling : Use these VC Labels (Rx) to send traffic to me

VPLS RED VPLS RED instance 3 instance 3

PEPE AA

PEPE BB

197


� 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(NO(N^2^2) LDP sessions operational challenge) LDP sessions operational challengeby 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

198

BGP already does both BGP already does both AutoAuto--discovery & Signalingdiscovery & 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

� Virtual Private LAN Service (VPLS)� draft-kompella-ppvpn-vpls

� BGP is a proven, multi-vendor solution deployed in production networks today

199

VPLS Control Plane functionality VPLS Control Plane functionality with MPwith MP--BGPBGP

� 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

200

PE VCT ProvisioningPE VCT Provisioning

� 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

Site Site 22 Site Site 33PE-3

CE-3PE-2

CE-2

VFTVFTVlan 10 Vlan 10

LSPLSP640640

LSPLSP 320320Site 3 VCTSite 3 VCT

Route Target

VE ID

RED

3

Sites 20

Label base

Route Dist 100:1.2.3.3

Site 2 VCTSite 2 VCT

Route Target

VE ID

RED

2

Sites 20

Label base


30002000

201

VPLS Forwarding TableVPLS Forwarding Table


CE-3PE-2

CE-2


LSPLSP640640

LSPLSP 320320

Site 2 VCTSite 2 VCT

Route Target

VE ID

RED

2

Sites 20

Label base


� VPLS Forwarding Table (VFT) on PE holds all the VCTs information

� Also contains MAC forwarding information (FDB)

PEPE--2’s VFT for VPLS RED2’s VFT for VPLS RED

outer Inner TXVE-ID

1

3

.

20

.

Inner RX

2001

2020

. .

Label used by site 3 to reach Site 22003

Used by PE-2 to do MAC learning

from site 3

2000

202

VPLS AutoVPLS Auto--discovery & Signalingdiscovery & Signaling


CE-3PE-2

CE-2


LSPLSP640640

LSPLSP 320320

MPMP--iBGPiBGP

� 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

Site 2 VCT NLRISite 2 VCT NLRI

Route Target

VE ID

RED

2

Sites 20

Label base 2000


PE-2Next Hop


Route Target

VE ID

RED

3

Sites 20

Label base 3000


PE-3Next Hop

203



CE-3PE-2

CE-2


LSPLSP640640

LSPLSP 320320

MPMP--iBGPiBGP


outer Inner TXVE-ID

2003

1

3

20

Inner RX

. . ..

� PE-2 receives BGP NLRI from PE-3 for RED VPLS instance site 3


Route Target

VE ID

RED

2

Sites 20

Label base 2000


PE-2Next Hop


Route Target

VE ID

RED

3

Sites 20

Label base 3000


PE-3Next Hop

Label used to reach site 33002640

204



CE-3PE-2

CE-2


LSPLSP640640

LSPLSP 320320

MPMP--iBGPiBGP


outer Inner TXVE-ID

1

3

.

15

600

640

.

670

3002

Inner RX

2003

2001

20209002

. .

5002


outer Inner TXVE-ID

1

2

.

15

300

320

.

360

2003

Inner RX

3002

3001

30209003

. .

5003

� A full mesh of pseudo-wires are set-up between all the VPLS instances for VPLS RED

205


� 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

206

VPLS MAC Learning:VPLS MAC Learning:Forwarding to a Unknown MAC AddressForwarding to a Unknown MAC Address

X sends a packetX sends a packet

� 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

L2 Ethernet Frame with Source MAC XX

Minus preamble, minus checksum

VC label 20032003

Tunnel label 320320VC label 20032003


CE-3PE-2

CE-2


LSPLSP640640

LSPLSP 320320

XX




outer Inner TXVE-ID

1

.

20

300

.

360

Inner RX

3002

3001

30209003

. .

5003

2 320 2003

207

VPLS MAC Learning:VPLS MAC Learning:Forwarding to an Unknown MAC AddressForwarding to an Unknown MAC Address

X sends a packetX sends a packet

� 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



VC label 20032003

Tunnel label 320VC label 20032003


CE-3PE-2

CE-2


LSPLSP640640

LSPLSP 320320

XX




outer Inner TXVE-ID

1

3

.

20

600

640

.

670

3002

Inner RX

2001

20209002

. .

5002

2003

PEPE--2’s VPLS RED FDB2’s VPLS RED FDB

outer Inner TXMAC

. . .

640 3002X

208

Broadcast StormsBroadcast 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 …)

209

VPLS MAC Learning:VPLS MAC Learning:Forwarding to a Known MAC AddressForwarding to a Known MAC Address


outer Inner TXVE-ID

1

3

.

20

600

640

.

670

3002

Inner RX

2003

2001

20209002

. .

5002


outer Inner TXMAC

X

Y

.

P

640

640

.

670

3002

9002

.

3002


CE-3PE-2

CE-2


LSPLSP640640

LSPLSP 320320

XXYYZZ

� Sending to a known MAC address X: X: 2 labels derived from FDB lookup2 labels derived from FDB lookup

X 640 3002

Z sends a packet to XZ sends a packet to X

210

VPLS MAC Learning:VPLS MAC Learning:Forwarding to a Known MAC AddressForwarding to a Known MAC Address


outer Inner TXVE-ID

1

3

.

20

600

640

.

670

3002

Inner RX

2003

2001

20209002

. .

5002


outer Inner TXMAC

X

Y

.

P

640

640

.

670

3002

9002

.

3002

L2 Ethernet Frame with Dest MAC XX

VC label 30023002

Tunnel label 640640

L2 Ethernet Frame with Dest MAC XX

VC label 30023002


CE-3PE-2

CE-2


LSPLSP640640

LSPLSP 320320

XXYYZZ

Unicast to MAC Unicast to MAC XX

X 640 3002

� Sending to a known MAC address XX

• Two labels derived from MAC ADD Cache lookup

� Encapsulation is as per draft-martini-encaps.

211

VPLS MAC AgingVPLS MAC Aging


outer Inner TXVE-ID

1

3

.

20

600

640

.

670

3002

Inner RX

2003

2001

20209002

. .

5002


outer Inner TXMAC

X

.

.

.

640

.

.

.

.

.

.

3002


CE-3PE-2

CE-2


LSPLSP640640

LSPLSP 320320

XXYYZZ

� Periodically age out unused entries from the MAC address cache

� MAC address cache should be limited by VPLS instance (configurable)

212

DualDual--homed CPEhomed CPE

� 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

PP

PP

PP

PP

Site Site 22

PE-2CE-2

VFTVlan 10

ZZSite Site 33

PE-3

CE-3

VFTVlan 10

XXYY

PE-15

VFTVlan 10

213

SummarySummary

Customers want:� IP VPNs (RFC 2547 VPN)

� Point-to-point Layer 2 VPNs

� Virtual Private LAN Service (VPLS)

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!

214

Configuration of VPLSConfiguration of VPLS

� VPN Connection Table (VCT) is configured on the PEs per VPLS instance with:

RD 1234:5.6.7.8

Layer 2 VPLS

VE ID 3

# sites 20

Imp RT 1234:8765

Exp RT 1234:8765

� Route Distinguisher: defines unique VCT

� Layer 2 encapsulation set to VPLS

� VPLS Edge ID� One per VPLS Instance per PE irrespective of how many local ports belong to that VPLS

� Estimated total number of PEs which have sites belonging to that VPLS

� Route Target: determines VPN topology� VPLS must be a full mesh� Import RT always the same as Export RT

� Implies full-mesh of PE-PE Tunnels & Split-Horizonforwarding scheme to avoid Spanning Tree

VPN Connection Table (VCT)

215

Configuration Fragment for VPLSConfiguration Fragment for VPLS

routing-instances vpnA { // Configuration for VPN Ainstance-type vpls; // vplsinterface ge-0/0/0.0; // multipoint Ethernet interfaceroute-distinguisher 1234:5.6.7.8;route-target 1234:8765; // set Route Target to 1234:8765protocols { // PE-CE protocol

vpls {site-range 20;site CE-A3 {

site-identifier 3; }

}}

}

216

Configuration Fragment for 2547Configuration Fragment for 2547

routing-instances vpnA { // Configuration for VPN Ainstance-type vrf; // RFC 2547 VPNinterface ge-0/0/0.0; // sub-interfaceroute-distinguisher 1234:5.6.7.8;route-target 1234:8765; // set Route Target to 1234:8765protocols { // PE-CE protocol

rip {version-2; // RIPv2group to-CE-A3 {

export default;interface so-0/0/0.0; // sub-interface for RIPv2

}}

}}

217

Sample VPLS Topology

m

Layer 2 Switch

Layer 2 Switch

Workstation

Workstation

WorkstationLayer 2 Switch

PE1

(192.168.1.7)

CE site-id 3

CE site-id 20

CE site-id 2

MPLS Core

00:02:b3:15:ff:f2

00:12:1e:17:f8:00

00:12:1e:1a:90:41

PE2

(192.168.1.10)

PE3

(192.168.1.9)

218

Baseline ConfigurationBaseline 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

219


admin@PE1> show ldp neighbor Address Interface Label space ID Hold time10.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 Prefix100000 192.168.1.7/32100016 192.168.1.9/32

3 192.168.1.10/32

Output label database, 192.168.1.7:0--192.168.1.10:0Label Prefix

3 192.168.1.7/32100016 192.168.1.9/32100000 192.168.1.10/32

� Setup LDP neighbors for LSPs between PEs

220


� Setup BGP session between the PEs with l2vpn family enable

admin@PE1> show configuration protocols bgp group jnpr {

type internal;local-address 192.168.1.7;family l2vpn {

s ignaling;}neighbor 192.168.1.10;neighbor 192.168.1.9;

}

admin@PE1> show bgp summary Groups: 1 Peers: 2 Down peers: 0Table Tot Paths Act Paths Suppressed History Damp State Pendingbgp.l2vpn.0 4 4 0 0 0 0Peer 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/0vpls.l2vpn.0: 2/2/0

192.168.1.10 100 878 885 0 1 4:16:13 Establbgp.l2vpn.0: 2/2/0vpls.l2vpn.0: 2/2/0

221


� 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;interface fe-0/3/1.0;vrf-target target:100:1;protocols {

vpls {site CE3 {

site-identifier 3;interface fe-0/3/1.0;

}}

}}

222


� PE2

[edit]admin@PE2# show interfaces fe-0/2/0 encapsulation ethernet-vpls;unit 0;

[edit]admin@PE2# show routing-instances vpls {

instance-type vpls;interface fe-0/2/0.0;vrf-target target:100:1;protocols {

vpls {site CE20 {

site-identifier 20;interface fe-0/2/0.0;

}}

}}

223


� PE3

[edit]admin@PE3# show interfaces ge-0/2/0 encapsulation ethernet-vpls;unit 0;

[edit]admin@PE3# show routing-instances vpls {

instance-type vpls;interface ge-0/2/0.0;vrf-target target:100:1;protocols {

vpls {site CE2 {

site-identifier 2;interface ge-0/2/0.0;

}}

}}

224


� 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;

interface ge-0/0/3.105;

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;

}

}

}

225

Common ProblemsCommon 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


226


� 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#

227


� 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 invalidOct 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-FPCPIC 1 REV 08 750-001072 AP3554 1x G/E, 1000 BASE-SX

228


� Invalid VLAN ID� With vlan-vpls encapulation� Fast Ethernet 512 through 1023

� Gigabit Ethernet 512 through 4094

� With extended-vlan-vpls encapsulation

� all VLAN IDs 1 and higher are valid

[edit]

admin@PE1# commit check

[edit interfaces ge-0/0/3]

'unit 1'

VPLS interfaces must have a VLAN-ID >= 512

configuration check succeeds

229


� 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/VPLSEM -- encapsulation mismatch WE -- interface and instance encaps not sameVC-Dn -- Virtual circuit down NP -- interface hardware not presentCM -- control-word mismatch -> -- only outbound connec tion is upCN -- circuit not provisioned <- -- only inbound connection is upOR -- out of range Up -- operationalOL -- 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 collisionLN -- local site not designated LM -- local site ID not minimum designatedRN -- remote site not designated RM -- remote site ID not minimum designatedXX -- unknown connection status IL -- no incoming labelMM -- MTU mismatch.....Instance: vplsLocal site: CE3 (2)

connection-site Type St Time last up # Up trans3 rmt NP 20 rmt NP

admin@Rita_RE0>

230


� LM/RM error on the VPLS connection� Remote VE

admin@PE3> show vpls connections remote-site 4 Layer-2 VPN connections:

Legend for connection status (St) EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLSEM -- encapsulation mismatch WE -- interface and instance encaps not sameVC-Dn -- Virtual circuit down NP -- interface hardware not present CM -- control-word mismatch -> -- only outbound connection is upCN -- circuit not provisioned <- -- only inbound connection is upOR -- out of range Up -- operationalOL -- 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 collisionLN -- local site not designated LM -- local site ID not minimum designatedRN -- remote site not designated RM -- remote site ID not minimum designatedXX -- unknown connection status IL -- no incoming lab elMM -- MTU mismatch.....Instance: vpls

Remote site: 4connection-site Type St Time last up # Up transCE2 (2) rmt RM

231


� LM/RM error on the VPLS connection� Local VE

admin@PE1> show vpls connections local-site 4 Layer-2 VPN connections:

Legend for connection status (St) EI -- encapsulation invalid NC -- interface encapsulation not CCC/TCC/VPLSEM -- encapsulation mismatch WE -- interface and instance encaps not sameVC-Dn -- Virtual circuit down NP -- interface hardware not present CM -- control-word mismatch -> -- only outbound connection is upCN -- circuit not provisioned <- -- only inbound connection is upOR -- out of range Up -- operationalOL -- 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 collisionLN -- local site not designated LM -- local site ID not minimum designatedRN -- remote site not designated RM -- remote site ID not minimum designatedXX -- unknown connection status IL -- no incoming labelMM -- MTU mismatch.....Instance: vplsLocal site: CE4 (4)

connection-site Type St Time last up # Up trans2 rmt LM 20 rmt LM

232


� 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

233


� Common system statistics to checkadmin@PE1> show system statistics vpls vpls:

0 total packets received0 with size smaller than minimum0 with incorrect version number0 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 table0 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 inter face0 learning requests over capacity /* Over limit learning */3040 mac routes moved /* MAC moved to different ifl */0 requests to move static route

. ....

234


� 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 requests0 requests to age static route0 requests to re-ageout aged route0 requests involving multiple peer FEs0 aging acks from PFE0 aging non-acks from PFE0 aging requests timed out waiting on FEs0 aging requests over max-rate0 errors finding peer FEs0 unsupported platform

admin@PE1>


Appendix : MPLS Review and

Background Information

236

Module ObjectivesModule 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

237

MPLS BenefitsMPLS 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

238

What is Traffic Engineering?What is Traffic Engineering?

� Ability to control traffic flows in the network

� Optimize available resources

� Move traffic from IGP path to less congested path

SourceSource DestinationDestination

Layer 3 RoutingLayer 3 Routing Traffic EngineeringTraffic Engineering

239

Traffic Engineering UsesTraffic 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

240

HighHigh--Level Overview of Traffic Level Overview of Traffic EngineeringEngineering

� Information distribution component

� Path selection component

� Path signaling component

� Packet Forwarding component

241

Information DistributionInformation 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

242

Path SelectionPath Selection

� 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

LSPLSP

IngressIngressLSRLSR

EgressEgressLSRLSR

243

Path SignalingPath 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

244

MPLS Signaling ProtocolsMPLS 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

245

Packet ForwardingPacket 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

246

MPLS TerminologyMPLS 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

247

MPLS Terminology: MPLS Shim HeaderMPLS Terminology: MPLS Shim Header

� MPLS shim header fields

� Label

� Experimental (CoS)

� Stacking bit

� Time to live

� Reserved and pre-defined label value

TTLLabel (20-bits) CoS S

IP PacketIP Packet

3232--bitsbits

L2 HeaderL2 Header MPLS HeaderMPLS Header

248

MPLS Terminology: Label SwappingMPLS Terminology: Label Swapping

� 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

Port 1

Port 3

Port 2

Port 4

Connection TableConnection Table

In

(port, label)

Out

(port, label)

(1, 22)

(1, 24)

(1, 25)

(2, 23)

(2, 17)

(3, 17)

(4, 19)

(3, 12)

Label

Operation

Swap

Swap

Swap

Swap

25IP

19IP

249

MPLS Terminology: Router TypeMPLS Terminology: Router Type

SanSanFranciscoFrancisco

New New YorkYork

LSPLSP

� 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

IngressIngress

LSRLSR TransitTransit

LSRLSR TransitTransitLSRLSR

EgressEgressLSRLSR

PenultimatePenultimate

RouterRouter

250

Packet ForwardingPacket Forwarding

� 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

SourceSourceParisParis

RomeRome


EgressEgressLSRLSR

251

134.5.1.5134.5.1.5

200.3.2.7200.3.2.7

i1 i2

200.3.2.1200.3.2.1

134.5.6.1134.5.6.1

Ingress Routing TableIngress Routing Table

Destination Next Hop

134.5/16

200.3.2/24

(2, 84)

(3, 99)

MPLS TableMPLS TableIn Out

(1, 99) (2, 56)


(3, 56) (5, 0)

Destination

Egress Routing TableEgress Routing TableNext Hop

134.5/16

200.3.2/24

134.5.6.1

200.3.2.1

MPLS Forwarding Example MPLS Forwarding Example

200.3.2.7

200.3.2.7

i3 i5

i3

252

Tunneling LSPTunneling LSP

Test for UnderstandingTest for Understanding

Penultimate LSRPenultimate LSR

Penultimate Hop Pops LablePenultimate Hop Pops LableLabel StackingLabel Stacking

� 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?

253

Resource Reservation ProtocolResource 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

254

RSVP SessionRSVP Session

� 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 OMay 8 13:26:42 RSVP new path state, session 192.168.80.1(port 17) Proto 0May 8 13:26:42 RSVP new resv state, session 192.168.80.1(port 17) Proto 0

IngressIngressRouterRouter

EgressEgress

RouterRouter

R1R1 R4R4 R8R8 R9R9

PATHPATH

RESVRESV

255

RSVP Messaging ProtocolRSVP Messaging Protocol

� 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

IngressIngressRouterRouter

EgressEgress

RouterRouter

R1R1 R4R4 R8R8 R9R9

PATHPATH

RESVRESV

Established PathEstablished PathState BlockState Block

Established ResvEstablished ResvState BlockState Block

256

Traffic Engineering ExtensionsTraffic 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

257

Path MessagePath Message

� 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


EgressEgressLSRLSR

R1R1 R2R2 R3R3 R4R4

PATH

ERO={R2, R3, R4}

PATH

ERO={R3, R4}

PATH

ERO={R4}

Explicit Route = {R1, R2, R3, R4}

Establish Path

State Block

Establish Path

State Block

Establish Path

State Block

258

Resv MessageResv Message

� 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


EgressEgress

LSRLSR

R1R1 R2R2 R3R3 R4R4

RESV

Label = 17

PenultimatePenultimateLSRLSR

RESV

Label = 20

RESV

Label = 3

i5 i4i6 i2i2 i3


IP Route (2, 17)


(3, 17) (6, 20)


(2, 20) (5, Pop)

259

Named Path via Explicit Route ObjectNamed 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

260

Named Path ERO: Strict RouteNamed Path ERO: Strict Route

AA

FFEE

DD

CC

BB


Egress Egress

LSRLSR

� Next hop must be directly connected to previous hop

B strict;B strict;

C strict;C strict;E strict;E strict;D strict;D strict;

F strict;F strict;

EROERO

StrictStrict

261

Named Path ERO: Loose RouteNamed Path ERO: Loose Route

AA

FFEE

DD

CC

BB

Egress Egress

LSRLSR

� Consult the routing table at each hop to determine the best path


D loose;D loose;

EROERO

LooseLoose

262

Named Path ERO: Strict/Loose PathNamed Path ERO: Strict/Loose Path

AA

FFEE

DD

CC

BB

Egress Egress

LSRLSR

� Strict and loose routes can be mixed


C strict;C strict;D loose;D loose;F strict;F strict;

EROERO

StrictStrict

LooseLoose

263

Named Path CodeNamed 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;

}path one {

192.168.20.1 loose;}

isis {traffic-engineering shortcuts;interface all {

level 1 disable;}

}

Use loopback address

instead of interface addressso loose section of pathcan reroute if necessary

264

Named Path VerificationNamed Path Verification

lab@HongKong> show mpls lsp

Ingress LSP: 2 label-switched paths

To From State Rt ActivePath P LSP name192.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 sessionsTotal 0 displayed, Up 0, Down 0

Transit RSVP: 0 sessionsTotal 0 displayed, Up 0, Down 0

265

ConstraintConstraint--Based routing Overview Based routing Overview (1 of 2)(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

266

ConstraintConstraint--Based routing Overview Based routing Overview (2 of 2)(2 of 2)

1) Stores information from IGP flooding

2) Stores traffic-engineering information

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

Routing Table

Extended IGP

Traffic EngineeringDatabase(TED)

ConstrainedShortest Path First

User Constraints

Explicit Route

RSVP Signaling

Operations Performed by the Ingress LSR

267

IGP ExtensionsIGP Extensions

� Distributes topology and traffic engineering information using IGP extensions� Maximum reservable bandwidth

� Remaining reservable bandwidth

� Link administrative groups(color)

� Mechanisms� Opaque LSAs for OSPF

� New TLVs for IS-IS

Routing Table

Extended IGP



User Constraints

Explicit Route

RSVP Signaling

268

Traffic Engineering DatabaseTraffic 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

269

User ConstraintsUser Constraints

� User-defined constraints applied to path selection� Bandwidth requirements

� Hop count limitations (for fast reroute)

� Administrative groups (colors)

� Priority (setup and hold)

� Explicit route (strict or loose)

� Also specified for signaled LSPs (no-cspf)

Routing Table

Extended IGP



User Constraints

Explicit Route

RSVP Signaling

270

Constrained Shortest Path FirstConstrained Shortest Path First

� For LSP = (highest priority) to (lowest priority) � Prune links with insufficient

bandwidth� Prune links that do not contain

an included color� Prune links that contain an

excluded color� Calculate shortest path from

ingress to egress consistent with ERO

� Select among equal-cost paths (least hop, then fill)

� Pass explicit route to RSVP

Routing Table

Extended IGP



User Constraints

Explicit Route

RSVP Signaling

271

RSVP SignalingRSVP Signaling

� 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

IngressIngress

LSRLSR

EgressEgress

LSRLSR

RESVRESV

PATHPATH

RSVP

ERO

CSPF

272

Administrative Groups (1 of 7)Administrative Groups (1 of 7)

� Administrative groups� Thirty-two named groups, 0 through 31－－－－carried as

32-bit value in IGP updates

� Groups assigned to Interfaces

SanFrancisco

Gold

Bronze

Silver

273


� Administrative groups

� Colors advertised on a per-link basis via IGP: 0xC000000E

� Colors on router: internal management, bronze, silver, gold

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

274


[edit protocols]mpls {

admin-groups {good 1;silver 2;bronze 3;management 30;internal 31;

}interface so-0/0/0 {

admin-group [ good management ]}interface so-0/1/0 {

admin-group silver ;}interface so-0/2/0 {

admin-group good ;}interface so-0/3/0 {

admin-group good ;}

}

275


mpls {label-switched-path to-miami {

to 1.1.1.1;primary use-fargo {

admin-group {include gold;exclude [ bronze silver ]

}}

}path use-fargo {

10.0.1.2 loose;}

}

� CSPF can include and exclude groups in automaticpath calculation

� Logical groupings are supported

Logical AND

Logical OR

276


� A-D-H has the lowest IGP metric－－－－4

A

B

C

D

E

F

G

H

I1

3

2

3

5

1

2

4

2

6

1

5

3

3

277


Choose the path from A to H using:admin group {

include [ copper bronze ];exclude admin;

}

A

B

C

D

E

F

G

H

I1

3

2

3

5

1

2

4

2

6

1

5

3

1

6

278


A-D-E-G-I-H is the shortest path excluding the adminclass and including copper or bronze

A

B

C

D

E

F

G

H

I1

3

2

3

5

1

2

4

2

6

1

5

3

1

6

279

� 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

FastFast--Reroute OperationReroute Operation

280

� 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

FastFast--Reroute OverviewReroute Overview

281

Fast Reroute ExampleFast Reroute Example

� Enable fast reroute on ingress LSR

� SF creates detour around LA

� LA creates detour around Austin

� Austin creates detour around Miami

Miami

New York

SanFrancisco

Los Angeles

Fargo

Austin

282

Fast Reroute Example Fast Reroute Example -- Short Term Short Term SolutionSolution

� LA to Austin link fails

� LA immediately detours around Austin

� LA signals to SF that failure occurred

Miami

New York

SanFrancisco

Los Angeles

Fargo

Austin

283

Fast Reroute Example Fast Reroute Example ––Long Term SolutionLong Term Solution

� SF fails over to secondary path

Miami

New York

SanFrancisco

Los Angeles

Fargo

Austin

284

protocols mpls {label-switched-path Tom {

to 192.168.24.1;primary topsecondary bottom {

bandwidth 75m;priority 5 5;standby;

}fast-reroute;

}‧‧‧‧‧‧‧‧‧‧‧‧

Fast RerouteFast Reroute

‧‧‧‧‧‧‧‧‧‧‧‧

protocols mpls {path top {

192.168.0.1 loose;192.168.2.1 loose;

}path bottom {

192.168.6.1 loose;192.168.12.1 loose;

}

285

Circuit CrossCircuit Cross--Connect OverviewConnect 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

286

CCC MPLS Interface Tunneling (1/2)CCC MPLS Interface Tunneling (1/2)

� 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

A BATM VC 514 ATM VC 590

M20MPLS LSP

ATM access network ATM access networkIP backbone

M40

287

CCC MPLS Interface Tunneling (2/2)CCC MPLS Interface Tunneling (2/2)

[edit protocols]

user@M40# show

connections {

remote-interface-switch m40-to-m20

interface at-7/1/1.514;

transmit-lsp lsp1;

receive-lsp lsp2;

}

A BATM VC 514 ATM VC 590

M20MPLS LSP1

ATM access network ATM access networkIP backbone

M40

MPLS LSP2

at-7/1/1.514

[edit protocols]

user@M20# show

connections {

remote-interface-switch m20-to-m40

interface at-3/0/1.590;

transmit-lsp lsp2;

receive-lsp lsp1;

}

at-3/0/1.590

288

� 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-muxencapsulation is set

Special Caveats for CCCSpecial Caveats for CCC

289

� 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

Purpose of LDP (1 of 2)Purpose of LDP (1 of 2)

290

� LDP creates an LSP tree for each FEC from every possible ingress router to egress router

Purpose of LDP (2 of 2)Purpose of LDP (2 of 2)

C

D

E

F

G

H

B

A

I

Egress

Ingress Only one LDP LSP,while four RSVP LSPs

LDP LSP

RSVP LSP

291

� 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

Label Distribution Protocol (1 of 2)Label Distribution Protocol (1 of 2)Upstream

LDP Peer

Downstream

LDP Peer

Discovery (Hello messages)

TCP Session Establishment

Initialization Messages

Label Request Messages

Label Mapping Messages

Sessions

Advertisement

292

� 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

Label Distribution Protocol (Label Distribution Protocol (22 of 2)of 2)

Upstream

LDP Peer

Downstream

LDP PeerLSR


IP Route (1, 17)


(4, 17) (5, 52)


(2, 52) (3, Pop)

i3 i1 i4 i5

i1

i2 i3

i4Receive

Outgoing

Label

Advertise

Incoming

Label

Net: 11.0.0.0

Net: 10.0.0.0

Label: 17

Net: 11.0.0.0

Net: 10.0.0.0

Label: 52Net: 10.0.0.0

Label: 29

293

protocols {mpls {

label-switched-path lsp-path-name {from source;to destination;ldp-tunneling;}

}}

LDP Tunneling through RSVPLDP Tunneling through RSVP--TE LSP TE LSP (1 of 2)(1 of 2)

RSVP LSPRSVP LSPLDPLDP LDPLDP

Router A Router B

294

LDP Tunneling through RSVPLDP Tunneling through RSVP--TE LSP TE LSP (2 of 2)(2 of 2)

LDP LSPLDP LSP RSVP LSPRSVP LSP

LDPLDP LDPLDP

RSVPRSVP

� RSVP tunneling can cause the LDP traffic to be forwarded through the RSVP tunnel over a traffic engineered path

295

Basic MPLS Configuration SummaryBasic 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 )

296

Basic RSVPBasic RSVP--Signaled LSPSignaled 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

297

Displaying MPLS LSPsDisplaying 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


Transit RSVP: 0 sessions


298

Displaying Additional MPLS InformationDisplaying 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

299

Displaying the MPLS Switching TableDisplaying 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


300

Displaying RSVP Session InformationDisplaying 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


Transit RSVP: 0 sessions


301

Displaying RSVP Neighbor InformationDisplaying 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

302

Displaying RSVPDisplaying RSVP--Enabled InterfacesEnabled 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 interfaceRSVP interface: 4 active

Active Subscr- Static Available Reserved HighwaterInterface State resv iption BW BW BW markfxp0.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

303

192.168.16.1

Next Hop ResolutionNext Hop Resolution

Denver DC

Dallas

NY

.1

192.168.4.1 192.168.16.1

192.168.24.1SF10.0.20/30.1 .2

Boston

NJ

134.112/16

I-BGP

Configure “next hop self”

192.168.8.1

AS 64512

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

304

Using Using traceroutetraceroute to Prove LSP to Prove LSP

WorksWorks

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

. . . .


Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidential www.juniper.net

Questions ?

Thank You !

Documents

Juniper Advanced VPNs Update]