implementing cisco mpls

817
MPLS Implementing Cisco MPLS Version 2.2 Student Guide Editorial, Production, and Web Services: 06.29.07

Upload: matiullah-jamil

Post on 18-Nov-2014

359 views

Category:

Technology


15 download

DESCRIPTION

Implementing MPLS Cisco

TRANSCRIPT

Page 1: Implementing cisco mpls

MPLS

Implementing Cisco MPLS

Version 2.2

Student Guide

Editorial, Production, and Web Services: 06.29.07

Page 2: Implementing cisco mpls

DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED “AS IS.” CISCO MAKES AND YOU RECEIVE NO WARRANTIES IN

CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY OR IN ANY OTHER PROVISION OF

THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO SPECIFICALLY DISCLAIMS ALL IMPLIED

WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR

PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. This learning product may contain early release

content, and while Cisco believes it to be accurate, it falls subject to the disclaimer above.

Page 3: Implementing cisco mpls

Table of Contents Course Introduction 1

Overview 1Learner Skills and Knowledge 2

Course Goal and Objectives 3Course Flow 4Additional References 5

Cisco Glossary of Terms 5Your Training Curriculum 6

MPLS Concepts 1-1

Overview 1-1Module Objectives 1-1

Introducing Basic MPLS Concepts 1-3

Overview 1-3Objectives 1-3

What Are the Foundations of Traditional IP Routing? 1-4Example: Traditional IP Routing 1-5

Basic MPLS Features 1-6Benefits of MPLS 1-7What Are the MPLS Architecture Components? 1-8

MPLS Control Plane 1-8MPLS Data Plane 1-9

MPLS LSRs 1-10Example: LSR Architecture 1-12Example: Basic MPLS 1-14

Summary 1-15

Introducing MPLS Labels and Label Stacks 1-17

Overview 1-17Objectives 1-17

What Are MPLS Labels? 1-18FEC and MPLS Forwarding 1-19

What Is the MPLS Label Format? 1-20Where Are MPLS Labels Inserted? 1-21

Example: MPLS Label Insertion�Frame-Mode MPLS 1-22What Is an MPLS Label Stack? 1-23

Example: MPLS Label Stack 1-24Example: MPLS Label Stack Format 1-25

What Are MPLS Label Operations? 1-26Example: MPLS Label Operations�Frame-Mode MPLS 1-27

Summary 1-28

Identifying MPLS Applications 1-29

Overview 1-29Objectives 1-29

Which Applications Are Used with MPLS? 1-30What Is MPLS Unicast IP Routing? 1-31What Is MPLS Multicast IP Routing? 1-32What Are MPLS VPNs? 1-33What Is MPLS TE? 1-35What Is MPLS QoS? 1-36What Is AToM? 1-37

AToM Examples 1-38What Are the Interactions Between MPLS Applications? 1-39Summary 1-40Module Summary 1-41

References 1-41

Page 4: Implementing cisco mpls

ii Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Module Self-Check 1-42Module Self-Check Answer Key 1-46

Label Assignment and Distribution 2-1

Overview 2-1Module Objectives 2-1

Discovering LDP Neighbors 2-3

Overview 2-3Objectives 2-3

Establishing an Adjacent LDP Session 2-4What Are LDP Hello Messages? 2-5

Example: Per-Platform Label Space 2-6Negotiating Label Space 2-7Discovering LDP Neighbors 2-8

Example: LDP Neighbor Discovery 2-8Negotiating LDP Sessions 2-9Discovering Nonadjacent Neighbors 2-10

Example: Applications Using Targeted LDP Sessions 2-11Summary 2-12

Introducing Typical Label Distribution in Frame-Mode MPLS 2-13

Overview 2-13Objectives 2-13

Propagating Labels Across a Network 2-14Example: Building Blocks for IP Forwarding 2-15Example: Using the FIB Table to Forward Packets 2-16Example: Using LDP 2-17

What Are LSPs? 2-18Example: IGP Propagates Routing Information 2-19Example: LFIB and LIB Tables 2-20

Propagating Labels Using PHP 2-21Example: PHP�Before 2-21Example: PHP�After 2-22

What Is the Impact of IP Aggregation on LSPs? 2-24Example: MPLS IP Aggregation Problem 2-24

Allocating Labels in a Frame-Mode MPLS Network 2-26Example: Building the FIB Table 2-27Example: Label Allocation 2-28

Distributing and Advertising Labels 2-31Example: Label Distribution and Advertisement 2-31Example: Interim Packet Propagation Through an MPLS Network 2-33Example: LDP Update Sent to All Adjacent Routers 2-34

Populating the LFIB 2-36Example: LFIB Population 2-36

Propagating Packets Across an MPLS Network 2-37Example: Packet Propagation Through an MPLS Network 2-37

Detecting Frame-Mode Loops 2-38Example: Normal TTL Operation 2-39Example: TTL and Loop Detection 2-40Example: Traceroute with Disabled TTL Propagation 2-42

Allocating Per-Platform Labels 2-45Example: Per-Platform Label Allocation 2-45

Summary 2-47

Page 5: Implementing cisco mpls

2006 Cisco Systems, Inc. Implementing Cisco MPLS (MPLS) v2.2 iii

Introducing Convergence in Frame-Mode MPLS 2-49

Overview 2-49Objectives 2-49

What Is the MPLS Steady-State Operation? 2-50What Happens in a Link Failure? 2-51

Example: Link Failure Actions 2-51What Is the Routing Protocol Convergence After a Link Failure? 2-52

Example: Routing Protocol Convergence 2-52What Is the MPLS Convergence After a Link Failure? 2-53What Actions Occur in Link Recovery? 2-55

Example: Link Recovery Actions 2-55Summary 2-58

Introducing MPLS Label Allocation, Distribution, and Retention Modes 2-59

Overview 2-59Objectives 2-59

Label Distribution Parameters 2-60Distributing Labels 2-61

Example: Unsolicited Downstream 2-61Allocating Labels 2-62Retaining Labels 2-63

Example: Liberal Retention Mode 2-63Summary 2-64Module Summary 2-65

References 2-65Module Self-Check 2-66

Module Self-Check Answer Key 2-71

Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-1

Overview 3-1Module Objectives 3-1

Introducing CEF Switching 3-3

Overview 3-3Objectives 3-3

What Are Cisco IOS Platform-Switching Mechanisms? 3-4Using Standard IP Switching 3-5

Example: Standard IP Switching 3-5What Is the CEF Switching Architecture? 3-6Configuring IP CEF 3-7

ip cef 3-7Syntax Description 3-7ip route-cache cef 3-8Syntax Description 3-8Defaults 3-8

Monitoring IP CEF 3-9show ip cef 3-9

Summary 3-11

Configuring Frame-Mode MPLS on Cisco IOS Platforms 3-13

Overview 3-13Objectives 3-13

What Are MPLS Configuration Tasks? 3-14Configuring the MPLS ID on a Router 3-15

mpls ldp router-id 3-15Configuring MPLS on a Frame-Mode Interface 3-16

mpls ip 3-16mpls label protocol [tdp | ldp | both] 3-17

Page 6: Implementing cisco mpls

iv Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: Configuring MPLS on a Frame-Mode Interface 3-18Example: Verifying MPLS on a Frame-Mode Interface 3-20

Configuring a Label-Switching MTU 3-21mpls mtu 3-21

Configuring IP TTL Propagation 3-23mpls ip propagate-ttl 3-23Example: Configuring IP TTL Propagation 3-24Example: Disabling IP TTL Propagation 3-25mpls ip propagate-ttl 3-26

Configuring Conditional Label Distribution 3-29mpls ldp advertise-labels 3-29Example: Conditional Label Distribution Configuration 3-30Example: Enabling Conditional Label Advertisement 3-32

Configuring Frame-Mode MPLS on Switched WAN Media 3-33Summary 3-37

Monitoring Frame-Mode MPLS on Cisco IOS Platforms 3-39

Overview 3-39Objectives 3-39

Monitoring MPLS 3-40show mpls ldp parameters 3-40show mpls interfaces 3-40show mpls ldp discovery 3-41show mpls ldp discovery 3-45

Monitoring LDP 3-47show mpls ldp neighbor 3-47show mpls ldp bindings 3-48show mpls ldp neighbor 3-49show mpls ldp bindings 3-51Examples 3-52

Monitoring Label Switching 3-53show mpls forwarding-table 3-53show ip cef 3-53show mpls forwarding-table 3-54Examples: show mpls forwarding table Command Output 3-55show ip cef detail 3-58

Debugging MPLS and LDP 3-59debug mpls packets 3-60

Summary 3-61

Troubleshooting Frame-Mode MPLS on Cisco IOS Platforms 3-63

Overview 3-63Objectives 3-63

What Are Common Frame-Mode MPLS Issues? 3-64Solving LDP Session Startup Issues 3-65Solving Label Allocation Issues 3-69Solving Label Distribution Issues 3-70Solving Packet-Labeling Issues 3-71

show cef interface 3-72Usage Guidelines 3-72

Solving Intermittent MPLS Failures 3-74Solving Packet Propagation Issues 3-75Summary 3-76Module Summary 3-77

References 3-77Module Self-Check 3-78

Module Self-Check Answer Key 3-81

Page 7: Implementing cisco mpls

2006 Cisco Systems, Inc. Implementing Cisco MPLS (MPLS) v2.2 v

MPLS VPN Technology 4-1

Overview 4-1Module Objectives 4-1

Introducing VPNs 4-3

Overview 4-3Objectives 4-3

Traditional Router-Based Network Connectivity 4-4Advantages of VPNs 4-5

Example: VPNs 4-5VPN Terminology 4-6

What Are the VPN Implementation Models? 4-8What Are Overlay VPN Technologies? 4-9What Are Peer-to-Peer VPN Technologies? 4-15Example: Controlled Route Distribution 4-17What Are the Benefits of VPNs? 4-18What Are the Drawbacks of VPNs? 4-19

Summary 4-20

Categorizing VPNs 4-21

Overview 4-21Objectives 4-21

What Are the Business Categories for VPNs? 4-22What Are Extranet VPNs? 4-23

Example: Overlay VPN�Extranet VPNs 4-23Example: Peer-to-Peer VPN Extranet VPNs 4-24

What Are the Connectivity Categories for VPNs? 4-25What Is the Central Services Extranet? 4-26

Example: Central Services Extranet 4-26What Is a Managed Network Implementation? 4-27

Example: Hybrid Implementation 4-28Summary 4-29

Introducing MPLS VPN Architecture 4-31

Overview 4-31Objectives 4-31

What Are the Drawbacks of Traditional Peer-to-Peer VPNs? 4-32What Is the MPLS VPN Architecture? 4-33What Is the Architecture of a PE Router in an MPLS VPN? 4-35What Are the Methods of Propagating Routing Information Across the P-Network? 4-36What Are RDs? 4-41

Is the RD Enough? 4-45Example: VoIP Service Sample 4-45Example: Connectivity Requirements 4-46

What Are RTs? 4-47How Have Complex VPNs Redefined the Meaning of VPNs? 4-50What Is the Impact of Complex VPN Topologies on Virtual Routing Tables? 4-51

Example: Impact of Complex VPN Topologies on Virtual Routing Tables 4-52Summary 4-53

Page 8: Implementing cisco mpls

vi Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Introducing the MPLS VPN Routing Model 4-55

Overview 4-55Objectives 4-55

MPLS VPN Routing Requirements and Model 4-56What Is the MPLS VPN Routing Model? 4-57

Existing Internet Routing Support 4-61Routing Tables on PE Routers 4-62Identifying End-to-End Routing Update Flow 4-63

Example: End-to-End Routing Update Flow 4-63Route Distribution to CE Routers 4-67

Example: Extending MPLS VPNs with VRF-Lite 4-68Summary 4-69

Forwarding MPLS VPN Packets 4-71

Overview 4-71Objectives 4-71

What Are the End-to-End VPN Forwarding Mechanisms? 4-72What Is VPN PHP? 4-74Propagating VPN Labels Between PE Routers 4-75

Example: VPN Label Propagation Between PE Routers 4-76What Are the Effects of MPLS VPNs on Label Propagation? 4-78What Are the Effects of MPLS VPNs on Packet Forwarding? 4-79

Example: Summarization in the Core 4-80Summary 4-81Module Summary 4-82

References 4-82Module Self-Check 4-83

Module Self-Check Answer Key 4-92

MPLS VPN Implementation 5-1

Overview 5-1Module Objectives 5-1

Using MPLS VPN Mechanisms of Cisco IOS Platforms 5-3

Overview 5-3Objectives 5-3

What Is a VRF Table? 5-4What Is the Need for Routing Protocol Contexts? 5-5What Are VPN-Aware Routing Protocols? 5-6How Are VRF Tables Used? 5-7Propagating BGP Routes�Outbound 5-8

Example: BGP Route Propagation Outbound 5-8Example: BGP Route Propagation Outbound 5-10

Propagating BGP Routes�Inbound 5-11Propagating Non-BGP Routes�Outbound 5-13Propagating Non-BGP Routes�Inbound 5-15Summary 5-17

Configuring VRF Tables 5-19

Overview 5-19Objectives 5-19

What Are the VRF Configuration Tasks? 5-20Creating VRF Tables and Assigning RDs 5-21

ip vrf 5-21Defaults 5-21rd 5-22Defaults 5-22

Page 9: Implementing cisco mpls

2006 Cisco Systems, Inc. Implementing Cisco MPLS (MPLS) v2.2 vii

Specifying Export and Import RTs 5-23route-target 5-23Defaults 5-24

Using VPN IDs 5-25Configuring VPN IDs 5-26vpn id 5-26Defaults 5-26

Assigning an Interface to a VRF Table 5-27ip vrf forwarding 5-27Defaults 5-27

Typical Configuration to Enable VRFs 5-28Example: MPLS VPN Network 5-28

Summary 5-30

Configuring an MP-BGP Session Between PE Routers 5-31

Overview 5-31Objectives 5-31

Configuring BGP Address Families 5-32router bgp 5-33Defaults 5-33address-family 5-34

Enabling BGP Neighbors 5-35Configuring MP-BGP 5-36Configuring MP-IBGP 5-37

neighbor remote-as 5-38Defaults 5-38neighbor update-source 5-38Defaults 5-38neighbor activate 5-39Defaults 5-39neighbor next-hop-self 5-40Defaults 5-40

Configuring MP-BGP Community Propagation 5-41neighbor send-community 5-42Defaults 5-42

Disabling IPv4 Route Exchange 5-44Example: Disabling IPv4 Route Exchange 5-45

Summary 5-46

Configuring Small-Scale Routing Protocols Between PE and CE Routers 5-47

Overview 5-47Objectives 5-47

Configuring PE-CE Routing Protocols 5-48Selecting the VRF Routing Context for BGP 5-49

address-family ipv4 5-50Defaults 5-50Command Modes 5-50

Configuring Per-VRF Static Routes 5-51ip route vrf 5-51

Configuring RIP PE-CE Routing 5-53Configuring EIGRP PE-CE Routing 5-56

Configuring SOO for EIGRP PE-CE Loop Prevention 5-59set extcommunity 5-61Defaults 5-62ip vrf sitemap 5-62Defaults 5-62

Summary 5-64

Page 10: Implementing cisco mpls

viii Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Monitoring MPLS VPN Operations 5-65

Overview 5-65Objectives 5-65

Monitoring VRFs 5-66show ip vrf 5-66Defaults 5-66

Monitoring VRF Routing 5-70show ip protocols vrf 5-70show ip route vrf 5-71show ip bgp vpnv4 5-72show ip bgp vpnv4 vrf neighbors 5-75Defaults 5-75Usage Guidelines 5-75

Monitoring MP-BGP Sessions 5-76show ip bgp neighbors 5-77Example: Sample Output from show ip bgp neighbors Command 5-78

Monitoring an MP-BGP VPNv4 Table 5-80show ip bgp vpnv4 vrf 5-81Defaults 5-81Usage Guidelines 5-81show ip bgp vpnv4 rd route-distinguisher 5-82Defaults 5-82Usage Guidelines 5-83Example: Configuring a Default RD for Two VRFs 5-83

Monitoring Per-VRF CEF and LFIB Structures 5-84show ip cef vrf 5-85Defaults 5-86Usage Guidelines 5-86show mpls forwarding vrf 5-87Defaults 5-87Usage Guidelines 5-87

Monitoring Labels Associated with VPNv4 Routes 5-88Identifying Other MPLS VPN Monitoring Commands 5-89Summary 5-90

Configuring OSPF as the Routing Protocol Between PE and CE Routers 5-91

Overview 5-91Objectives 5-91

What Is the Enhanced OSPF Hierarchical Model? 5-92Propagating OSPF Customer Routes 5-93Implementing MPLS VPNs as an OSPF Superbackbone 5-96

Example: OSPF Superbackbone Implementation 5-101Configuring OSPF PE-CE Routing 5-104

router ospf 5-106Defaults 5-106

Using the OSPF Down Bit 5-108Example: OSPF Down Bit 5-108Example: OSPF Down Bit 5-110

Optimizing Packet Forwarding Across the MPLS VPN Backbone 5-111Example: Optimizing of Packet Forwarding 5-111

Using the OSPF Tag Field 5-114Example: Routing Loops Across OSPF Domains 5-114Example: OSPF Tag Field�Routing Loop Prevention 5-117

What Is a Sham Link? 5-118Example: Sham Link 5-118

Configuring a Sham Link 5-122Defaults 5-123Command Modes 5-124Example: Sample Sham-Link Configuration 5-124

Summary 5-125

Page 11: Implementing cisco mpls

2006 Cisco Systems, Inc. Implementing Cisco MPLS (MPLS) v2.2 ix

Configuring BGP as the Routing Protocol Between PE and CE Routers 5-127

Overview 5-127Objectives 5-127

Configuring a Per-VRF BGP Routing Context 5-128address-family ipv4 5-129Defaults 5-129Command Modes 5-129Example: Configuring per-VRF BGP Routing Context 5-130

What Are the Reasons for Limiting the Number of Routes in a VRF? 5-131Limiting the Number of Prefixes Received from a BGP Neighbor 5-132

neighbor maximum-prefix 5-132Defaults 5-133

Limiting the Total Number of VRF Routes 5-134maximum routes 5-135Defaults 5-135Example: Limiting the Total Number of VRF Routes 5-136

Identifying AS-Override Issues 5-137neighbor as-override 5-140Defaults 5-140Example: AS-Override 5-141Example: AS-Path Prepending 5-142

Identifying Allowas-in Issues 5-143Example: Using Allowas-in to Support Customer Site Linking Two VPNs 5-146neighbor allowas-in 5-147Defaults 5-147

Implementing SOO for Loop Prevention 5-148set extcommunity 5-150Defaults 5-151neighbor route-map 5-151ip vrf sitemap 5-152Defaults 5-152

Summary 5-154

Troubleshooting MPLS VPNs 5-155

Overview 5-155Objectives 5-155

Identifying Preliminary Steps in MPLS VPN Troubleshooting 5-156Verifying the Routing Information Flow 5-157Validating CE-to-PE Routing Information Flow 5-158Validating PE-to-PE Routing Information Flow 5-159Validating PE-to-CE Routing Information Flow 5-164Identifying the Issues When Verifying the Data Flow 5-165Validating CEF Status 5-166

show cef interface 5-167Usage Guidelines 5-167

Validating the End-to-End LSP 5-170Validating the LFIB Status 5-171Summary 5-172Module Summary 5-173

References 5-174Module Self-Check 5-175

Module Self-Check Answer Key 5-184

Complex MPLS VPNs 6-1

Overview 6-1Module Objectives 6-1

Page 12: Implementing cisco mpls

x Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Using Advanced VRF Import and Export Features 6-3

Overview 6-3Objectives 6-3

What Are Advanced VRF Features? 6-4Configuring Selective VRF Import 6-5

import map 6-6Defaults 6-6Example: Configuring Selective VRF Import 6-7

Configuring Selective VRF Export 6-8set extcommunity 6-9Defaults 6-10export map 6-10Defaults 6-10Example: Configuring Selective VRF Export 6-11

Summary 6-12

Introducing Overlapping VPNs 6-13

Overview 6-13Objectives 6-13

Who Are the Participants in Overlapping VPNs? 6-14What Are Typical Overlapping VPN Usages? 6-15Overlapping VPN Routing 6-16

Example: Overlapping VPN Routing 6-16Overlapping VPN Data Flow 6-18Configuring Overlapping VPNs 6-19

Example: Overlapping VPNs�Configuration Tasks 6-19Example: Configuring Overlapping VPN VRFs 6-21

Summary 6-22

Introducing Central Services VPNs 6-23

Overview 6-23Objectives 6-23

What Are the Access Characteristics of a Central Services VPN? 6-24What Are the Routing Characteristics of a Central Services VPN? 6-25

Example: Central Services VPN Routing 6-25Identifying the Central Services VPN Data Flow Model 6-27Configuring a Central Services VPN 6-28

Example: Configuring a Central Services VPN 6-30Integrating a Central Services VPN with a Simple VPN 6-31Identifying the RD Requirements When Integrating Central Services and Simple VPNs 6-33Identifying the RT Requirements When Integrating Central Services and Simple VPNs 6-34

Example: Configuring VRFs in a Central Services and Simple VPN 6-36Summary 6-37

Introducing the Managed CE Routers Service 6-39

Overview 6-39Objectives 6-39

What Are the Requirements of Managed CE Routers? 6-40What Are the VRF and RD Requirements? 6-41Configuring Managed CE Routers 6-42

Example: Configuring VRFs 6-43Summary 6-44Module Summary 6-45

References 6-45Module Self-Check 6-46

Module Self-Check Answer Key 6-50

Page 13: Implementing cisco mpls

2006 Cisco Systems, Inc. Implementing Cisco MPLS (MPLS) v2.2 xi

Internet Access and MPLS VPNs 7-1

Overview 7-1Module Objectives 7-1

Introducing Internet Access with MPLS VPNs 7-3

Overview 7-3Objectives 7-3

Customer Internet Connectivity Scenarios 7-4Classical Internet Access 7-4Multisite Internet Access 7-5Wholesale Internet Access 7-6

Internet Design Models for Service Providers 7-7Major Design Models 7-8

Internet Access Through Global Routing 7-9Internet Access as a Separate VPN 7-10Disadvantages of Providing Internet Access Through Route Leaking 7-11Summary 7-13

Implementing Separate Internet Access and VPN Services 7-15

Overview 7-15Objectives 7-15

Classical Internet Access for a VPN Customer 7-16Using Separate Subinterfaces 7-17

Example: Internet Access Through Static Routes 7-18Example: Dynamic Internet Access Through a Separate Subinterface 7-19Example: Internet Access Through a Dedicated Subinterface�Traffic Flow 7-20

Accessing the Internet from Every Customer Site 7-21Separate Internet Access Benefits and Limitations 7-22Summary 7-23

Implementing Internet Access as a Separate VPN 7-25

Overview 7-25Objectives 7-25

Internet Access as a Separate VPN 7-26Example: Configuring the Internet Gateway in a Separate VPN 7-28

Implementing Redundant Internet Access 7-29Implementing Classical Internet Access for a VPN Customer 7-30Implementing Internet Access from Every Customer Site 7-32Implementing Wholesale Internet Access 7-33Running an Internet Backbone in a VPN 7-34Summary 7-35Module Summary 7-36

References 7-36Module Self-Check 7-37

Module Self-Check Answer Key 7-40

MPLS TE Overview 8-1

Overview 8-1Module Objectives 8-1

Introducing the TE Concept 8-3

Overview 8-3Objectives 8-3

What Is TE? 8-4Business Drivers for TE 8-6Congestion Avoidance and TE 8-8TE with a Layer 2 Overlay Model 8-9TE with a Layer 3 Model 8-12

Page 14: Implementing cisco mpls

xii Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

TE with the MPLS TE Model 8-14Summary 8-16

References 8-16

Understanding MPLS TE Components 8-17

Overview 8-17Objectives 8-17

Traffic Tunnels: Concepts 8-18Traffic Tunnels: Characteristics 8-20

Traffic Tunnels Attributes 8-21

Network Links and Link Attributes 8-23Constraint-Based Path Computation 8-24TE Processes 8-28Role of RSVP in Path Setup and Trunk Admission Control 8-30

Path Setup with RSVP 8-31Trunk Admission Control with RSVP 8-32

Forwarding Traffic to a Tunnel 8-33Forwarding Traffic to a Tunnel: Autoroute 8-34

Summary 8-36References 8-36

Configuring MPLS TE on Cisco IOS Platforms 8-37

Overview 8-37Objectives 8-37

MPLS TE Configuration Road Map 8-38Enabling Device-Level MPLS TE Support 8-39

ip cef 8-39mpls traffic-eng tunnels (global) 8-40

Enabling MPLS TE Support in IS-IS 8-41mpls traffic-eng 8-41mpls traffic-eng router-id 8-42metric-style wide 8-42

Enabling MPLS TE Support in OSPF 8-44mpls traffic-eng area 8-44mpls traffic-eng router-id 8-45

Enabling Basic MPLS TE on an Interface 8-47mpls ip 8-47mpls traffic-eng tunnels (interface) 8-47ip rsvp bandwidth 8-48

Creating and Configuring a Traffic Tunnel 8-50interface tunnel 8-50ip unnumbered 8-50tunnel destination 8-51Configuring a Traffic Tunnel 8-52tunnel mode mpls traffic-eng 8-53tunnel mpls traffic-eng bandwidth 8-53tunnel mpls traffic-eng priority 8-53ip explicit-path 8-55next-address 8-55tunnel mpls traffic-eng path-option 8-55

Mapping Traffic into Tunnels with Autoroute 8-57tunnel mpls traffic-eng autoroute announce 8-57

Summary 8-59References 8-59

Monitoring Basic MPLS TE on Cisco IOS Platforms 8-61

Overview 8-61Objectives 8-61

Monitoring MPLS TE Tunnels 8-62show ip rsvp interface 8-62show mpls traffic-eng tunnels 8-63

Page 15: Implementing cisco mpls

2006 Cisco Systems, Inc. Implementing Cisco MPLS (MPLS) v2.2 xiii

Monitoring MPLS TE 8-66show mpls traffic-eng autoroute 8-66show ip cef network 8-68show ip cef vrf vrf-name network 8-69

Summary 8-70References 8-70

Module Summary 8-71References 8-71

Module Self-Check 8-72Answer Key 8-75

Page 16: Implementing cisco mpls

MPLS

Course Introduction

OverviewService providers (and enterprises acting as service providers) are faced with many challenges in terms of customer demand, including an ongoing need for value-added services. Conventional IP packet forwarding has several limitations, and more and more service providers realize that something else is needed. Not only must service providers be concerned with protecting their existing infrastructure, but they must also find ways to generate new services that are not currently supportable using existing technologies.

Multiprotocol Label Switching (MPLS) is a high-performance method for forwarding packets through a network. MPLS enables routers at the edge of a network to apply simple labels to packets. This practice allows the edge devices—ATM switches or existing routers in the center of the service provider core—to switch packets according to labels, with minimal lookup overhead. MPLS integrates the performance and traffic-management capabilities of data link Layer 2 with the scalability and flexibility of network Layer 3 routing. When used in conjunction with other standard technologies, MPLS allows service providers the ability to support value-added features that are critical for their networks.

Implementing Cisco MPLS (MPLS) v2.2 is recommended training for individuals seeking certification as a Cisco CCIP®. The focus of this course is on MPLS technology issues as those issues apply to service providers and on how to configure new features and functions in an existing routed environment.

Page 17: Implementing cisco mpls

2 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Learner Skills and Knowledge This subtopic lists the skills and knowledge that learners must possess to benefit fully from the course. The subtopic also includes recommended Cisco learning offerings that learners should complete to benefit fully from this course.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3

Learner Skills and Knowledge

• Cisco CCNA® certification

• Building Scalable Cisco Internetworks (BSCI)

• Configuring BGP on Cisco Routers (BGP)

Note: Practical experience with deploying and operating networks based on Cisco network devices and Cisco IOS software is strongly recommended.

Page 18: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Course Introduction 3

Course Goal and Objectives This topic describes the course goal and objectives.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4

“To design, implement, and verify an MPLS VPN domain capable of multiple customer sites with managed central services and Internet access”

Implementing Cisco MPLS (MPLS)

Course Goal

Upon completing this course, you will be able to meet these objectives:

Describe the features of MPLS

Describe how MPLS labels are assigned and distributed

Configure and troubleshoot MPLS on frame-mode Cisco IOS platforms

Describe the MPLS peer-to-peer architecture and explain the routing and packet-forwarding model in this architecture

Configure, monitor, and troubleshoot VPN operations

Describe how the overlapping model can be used to implement managed services and Internet access

Describe the various Internet access implementations that are available and the benefits and drawbacks of each model; configure, monitor, and troubleshoot basic Internet access

Configure, monitor, and troubleshoot basic MPLS TE functions

Page 19: Implementing cisco mpls

4 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Course Flow This topic presents the suggested flow of the course materials.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5

Wrap-up

LabLab

Complex MPLS VPNs

Lab

MPLS VPN Implementation

Lab

Lab

Complex MPLS VPNs

LabLab

LabFrame-Mode MPLS

Implementation

LabInternet Accessand

MPLS VPNsLab

MPLS VPN Implementation

Label Assignmentand Distribution

Lunch

Lab

Lab

MPLS VPNImplementation

Label Assignmentand Distribution

LabMPLS Concepts

MPLS Traffic Engineering

Overview

Complex MPLS VPNs

MPLS VPN ImplementationMPLS VPN

Technology

Course

Introduction

Course Flow Diagram

AM

PM

Day 1 Day 2 Day 3 Day 4 Day 5

The schedule reflects the recommended structure for this course. This structure allows enough time for the instructor to present the course information and for you to work through the lab activities. The exact timing of the subject materials and labs depends on the pace of your specific class.

Page 20: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Course Introduction 5

Additional References This topic presents the Cisco icons and symbols that are used in this course, as well as information on where to find additional technical references.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6

Cisco Icons and Symbols

Router Workgroup Switch

ATMSwitch

Edge Label SwitchRouter

Line: Serial

Line: Ethernet

Network Cloud,White

Cisco Glossary of Terms For additional information on Cisco terminology, refer to the Cisco Internetworking Terms and Acronyms glossary of terms at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/index.htm.

Page 21: Implementing cisco mpls

6 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Your Training Curriculum This topic presents the training curriculum for this course.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7

Cisco Career Certifications

Expand Your Professional Optionsand Advance Your Career

Cisco CCIP

Professional

CCIE CCSP

CCIPCCIP

CCNACCNA Associate

http://www.cisco.com/go/certifications

ExpertRecommended Training Through Cisco Learning Partners

Required Exam

BSCI

QOS

Building Scalable Cisco Internetworks

Implementing Quality of Service

MPLS Implementing Cisco MPLS

BGP Configuring BGP on Cisco Routers

You are encouraged to join the Cisco Certification Community, a discussion forum open to anyone holding a valid Cisco Career Certification (such as Cisco CCIE®, CCNA®, CCDA®,CCNP®, CCDP®, CCIP®, or CCSP™). It provides a gathering place for Cisco certified professionals to share questions, suggestions, and information about Cisco Career Certification programs and other certification-related topics. For more information, visit http://www.cisco.com/en/US/learning/le3/le2/le41/learning_certification_level_home.html.

Page 22: Implementing cisco mpls

Module 1

MPLS Concepts

OverviewThis module explains the features of Multiprotocol Label Switching (MPLS) compared with those of traditional hop-by-hop IP routing. MPLS concepts and terminology, along with MPLS label format and label switch router (LSR) architecture and operations, are explained in this module.

Module Objectives Upon completing this module, you will be able to describe the features of MPLS. This ability includes being able to meet these objectives:

Describe the basic MPLS concepts

Describe the structure and function of MPLS labels and MPLS label stacks

Describe the different MPLS applications in which you can use MPLS

Page 23: Implementing cisco mpls

1-2 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 24: Implementing cisco mpls

Lesson 1

Introducing Basic MPLS Concepts

OverviewThis lesson discusses the basic concepts and architecture of Multiprotocol Label Switching (MPLS). The lesson provides information about MPLS components and labels. This lesson lays the foundation for subsequent lessons that cover key areas, such as MPLS implementations and Virtual Private Networks (VPNs).

It is important to have a clear understanding of the role of MPLS and the makeup of the devices and components. This understanding will help you have a clear picture of how to differentiate between the roles of certain devices and to understand how information gets transferred across an MPLS domain.

ObjectivesUpon completing this lesson, you will be able to describe the basic MPLS concepts, including some advantages as compared to traditional IP routing. This ability includes being able to meet these objectives:

Describe the foundations of traditional IP routing

Describe the basic features of MPLS

Describe the benefits of MPLS

Describe the main components of the MPLS architecture

Describe the function of the different types of LSRs

Page 25: Implementing cisco mpls

1-4 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are the Foundations of Traditional IP Routing?

This topic describes the foundations of traditional IP routing.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-3

Foundations of Traditional IP Routing

• Routing protocols are used to distribute Layer 3 routing information.

• Forwarding decision is made based on:

– Packet header

– Local routing table

• Routing lookups are independently performed at every hop.

Before basic MPLS functionality is explained, these three foundations of traditional IP routing need to be highlighted:

Routing protocols are used on all devices to distribute routing information.

Each router analyzes the Layer 3 header of each packet compared to the local routing table and makes a decision about where to forward the packet. Regardless of the routing protocol, routers forward packets contingent on a destination address-based routing lookup.

Note The exception to this rule is policy-based routing (PBR), where routers will bypass the

destination-based routing lookup.

The routing lookup is performed independently on every router in the network.

Page 26: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-5

Example: Traditional IP Routing This diagram shows traditional IP routing.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-4

Traditional IP Routing

• Every router may need full Internet routing information.

• Destination-based routing lookup is needed on every hop.

Page 27: Implementing cisco mpls

1-6 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Basic MPLS Features This topic describes the basic features of MPLS.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-5

Basic MPLS Features

• MPLS leverages both IP routing and CEF switching.

• MPLS is a forwarding mechanism in which packets are forwarded based on labels.

• MPLS was designed to support multiple Layer 3 protocols

• Typically, MPLS labels correspond to destination networks (equivalent to traditional IP forwarding).

MPLS is designed to leverage the intelligence associated with IP routing and the switching model associated with Cisco Express Forwarding (CEF) switching.

Note CEF switching will be discussed in detail in the “Frame-Mode MPLS Implementation on

Cisco IOS Platforms” module. In summary, CEF uses a complete IP switching table, the

Forwarding Information Base (FIB) table, to make forwarding decisions. Because the FIB

contains the complete IP switching table, the router can make definitive forwarding decisions

based on the information in it.

MPLS is a packet-forwarding technology that uses appended labels to make forwarding decisions for packets.

Within the MPLS network, the Layer 3 header analysis is done just once (when the packet enters the MPLS domain). Labels are appended to the packet, and then the packet is forwarded into the MPLS domain.

Simple label inspection integrated with CEF switching drives subsequent packet forwarding.

MPLS was designed to support efficiently forwarding packets across the network core based on a simplified header. Label switching is performed regardless of the Layer 3 routing protocol.

MPLS labels typically correspond to Layer 3 destination addresses (equal to destination-based routing). Labels can also correspond to other parameters, such as quality of service (QoS), source address, or a Layer 2 circuit. An MPLS label is a short, 4-byte, fixed-length, locally significant identifier.

Page 28: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-7

Benefits of MPLS This topic describes some of the benefits of MPLS.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-6

Benefits of MPLS

• MPLS supports multiple applications including:

– Unicast and multicast IP routing

– VPN

– TE

– QoS

– AToM

• MPLS decreases forwarding overhead on core routers.

• MPLS can support forwarding of non-IP protocols.

There are several benefits to MPLS:

MPLS decreases the forwarding overhead on the core routers.

MPLS supports multiple useful applications such as those listed here:

— Unicast and multicast IP routing

— VPN

— Traffic engineering (TE)

— QoS

— Any Transport over MPLS (AToM).

Note An overview of these applications will be provided in the “Identifying MPLS Applications”

lesson in this module.

MPLS supports the forwarding of non-IP protocols, because MPLS technologies are applicable to any network layer protocol.

Page 29: Implementing cisco mpls

1-8 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are the MPLS Architecture Components? MPLS consists of these two major components:

Control plane

Data plane

MPLS Control Plane The control plane takes care of the routing information exchange and the label exchange between adjacent devices.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-7

MPLS Architecture: Control Plane

The control plane builds a routing table (Routing Information Base [RIB]) based on the routing protocol. Various routing protocols, such as Open Shortest Path First (OSPF), Interior Gateway Routing Protocol (IGRP), Enhanced Interior Gateway Routing Protocol (EIGRP), Intermediate System-to-Intermediate System (IS-IS), Routing Information Protocol (RIP), and Border Gateway Protocol (BGP), can be used in the control plane for managing Layer 3 routing.

The control plane uses a label exchange protocol to create and maintain labels internally, and to exchange these labels with other devices. The label exchange protocol binds labels to networks learned via a routing protocol. Label exchange protocols include MPLS Label Distribution Protocol (LDP), the older Cisco Tag Distribution Protocol (TDP), and BGP (used by MPLS VPN). Resource Reservation Protocol (RSVP) is used by MPLS TE to accomplish label exchange.

The control plane also builds two forwarding tables, a FIB from the information in the RIB, and a label forwarding information base (LFIB) table based on the label exchange protocol and the RIB. The LFIB table includes label values and associations with the outgoing interface for every network prefix.

Page 30: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-9

MPLS Data Plane The data plane takes care of forwarding based on either destination addresses or labels; the data plane is also known as the forwarding plane.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-8

MPLS Architecture: Data Plane

The data plane is a simple forwarding engine that is independent of the type of routing protocol or label exchange protocol being used. The data plane forwards packets to the appropriate interface based on the information in the LFIB or the FIB tables.

Page 31: Implementing cisco mpls

1-10 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

MPLS LSRs This topic describes the function of two types of MPLS devices.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-9

MPLS Devices: LSRs

• The LSR forwards labeled packets in the MPLS domain.

• The edge LSR forwards labeled packets in the MPLS domain, and it forwards IP packets into and out of the MPLS domain.

The label switch router (LSR) is the basic MPLS device used for most MPLS applications. Here are two definitions:

LSR: A device that implements label distribution procedures and primarily forwards packets based on labels

Edge LSR: An LSR on the edge of an MPLS domain that implements label distribution procedures, forwards packets based on labels, and primarily inserts labels on packets or removes labels for non-MPLS devices

LSRs and edge LSRs are usually capable of doing both label switching and IP routing. Their names are based on their positions in an MPLS domain. Routers that have all interfaces enabled for MPLS are called LSRs because they mostly forward labeled packets. Routers that have some interfaces that are not enabled for MPLS are usually at the edge of an MPLS domain. These routers also forward packets based on IP destination addresses and label them if the outgoing interface is enabled for MPLS.

Note In a service provider MPLS environment, an edge LSR is typically known as a provider edge

(PE) router, and an LSR is known as a provider (P) router.

Page 32: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-11

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-10

Label Switch Routers: Architecture of LSRs

The primary LSR functions are to exchange labels with other LSRs and to forward labeled packets. Therefore, every LSR needs a Layer 3 routing protocol (for example, OSPF, EIGRP, or IS-IS), and a label exchange protocol (for example, LDP or TDP).

LDP populates the LFIB table in the data plane that is used to forward labeled packets.

Note LSRs may not be able to forward unlabeled packets if they do not have sufficient routing

information.

Page 33: Implementing cisco mpls

1-12 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: LSR Architecture The figure illustrates the main components of the control and data planes for MPLS operation on a LSR.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-11

LSR Architecture Example

MPLS router functionality is divided into two major parts: the control plane and the data plane.

In the example LSR architecture, the control plane uses these protocols:

A routing protocol (OSPF), which receives and forwards information about IP network 10.0.0.0/8

A label exchange protocol (LDP), which receives label 24 to be used for packets with destination address 10.0.0.0/8

(A local label 17 is generated and is sent to upstream neighbors so that these neighbors can label packets with the appropriate label.)

The data plane uses an LFIB to forward packets based on labels:

The LFIB receives an entry from LDP, where label 24 is mapped to label 17. When the data plane receives a packet labeled with a 24, it replaces label 24 with label 17 and forwards the packet through the appropriate interfaces.

Note In the example, both packet flow and routing and label updates are from left to right.

Page 34: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-13

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-12

LSRs: Architecture of Edge LSRs

Besides forwarding labeled packets, edge LSRs also forward IP packets into and out of the MPLS domain.

These combinations are possible on an edge LSR:

A received IP packet is forwarded based on the IP destination address (sent as an IP packet.)

A received IP packet is labeled based on the IP destination address and is forwarded as a labeled packet.

A received labeled packet is forwarded after the label is swapped (sent as a labeled packet).

A received labeled packet is forwarded as an IP packet after the label is removed.

These scenarios are possible if the network is not configured properly:

A received labeled packet is dropped if the label is not found in the LFIB table, even if the IP destination exists in the IP forwarding table—also called the FIB.

A received IP packet is dropped if the destination is not found in the FIB table, even if there is an MPLS label-switched path toward the destination.

Page 35: Implementing cisco mpls

1-14 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: Basic MPLS

The figure illustrates a situation in which the intermediary router in the MPLS core does not have to perform a time-consuming routing lookup. Instead, this router simply swaps a label with another label (25 is replaced by 23) and forwards the packet based on the swapped label (23).

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-13

Basic MPLS Example

• MPLS core routers swap labels and forward packets based on simple label lookups.

• MPLS edge routers also perform a routing table lookup, and add or remove labels.

At the egress LSR, the MPLS label is removed, and an IP packet is forwarded out of the MPLS domain.

In larger networks, the result of MPLS labeling is that only the edge routers perform a routing lookup. The core routers simply forward packets based on the labels.

Page 36: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-15

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-14

Summary

• Traditional IP routing forwards packets based on the destination address.

• MPLS forwards packets based on labels.

• MPLS supports multiple applications.

• MPLS has two major architectural components:

– Control plane (exchanges routing information, exchanges labels)

– Data plane (forwards packets)

• LSRs implement label exchange protocols and primarily forward packets based on labels. The role of Edge LSRs is primarily to forward packets into and out of the MPLS domain.

Page 37: Implementing cisco mpls

1-16 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 38: Implementing cisco mpls

Lesson 2

Introducing MPLS Labels and Label Stacks

OverviewThis lesson explains the four fields that make up a Multiprotocol Label Switching (MPLS) label. This lesson also explains how label stacking is used and how labels are forwarded in frame-mode environments.

To fully understand MPLS, it is necessary to have a clear understanding of the format of an MPLS label, and the definition for each field in that label. You also need to know exactly how information is passed from node to node in the network.

ObjectivesUpon completing this lesson, you will be able to describe MPLS labels and MPLS label stacks, including the format of the MPLS label and also when and why a label stack is created. This ability includes being able to meet these objectives:

Describe the features of MPLS labels

Describe the format and fields of an MPLS label

Describe where MPLS labels are inserted in an IP packet

Describe the features of an MPLS label stack

Describe MPLS label operations

Page 39: Implementing cisco mpls

1-18 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are MPLS Labels? This topic describes the features of MPLS labels.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-3

MPLS Labels

• Are 4 byte identifiers used for forwarding decisions

• Define the destination and services for a packet

• Identify a forwarding equivalence class (FEC)

• Have local significance

– Each LSR independently maps a label to an FEC in a label binding.

– Label bindings are exchanged between LSRs.

An MPLS label is a 4-byte, fixed-length, locally significant identifier that is used by network core devices to make forwarding decisions for a packet. Labels define the destination and services for each packet, and identify a forwarding equivalence class (FEC). The label put on a particular packet represents the FEC to which the packet is assigned.

Labels have local significance to a label switch router (LSR). Each LSR in the network makes an independent, local decision regarding which label value to use to represent an FEC. This mapping is known as a label binding.

Each LSR informs its neighbors of the label bindings that it has made.

Note Details on how the label binding are exchanged will be covered in the “Label Assignment

and Distribution” module.

Page 40: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-19

FEC and MPLS Forwarding An FEC is an integral part of MPLS forwarding.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-4

FEC and MPLS Forwarding

• An FEC is a group of packets forwarded:

– In the same manner

– Over the same path

– With the same forwarding treatment

• MPLS packet forwarding consists of:

– Assigning a packet to a specific FEC

– Determining the next hop of each FEC

• MPLS forwarding is connection-oriented.

The FEC is a group of IP packets that are forwarded in the same manner, over the same path, and with the same forwarding treatment. An FEC might correspond to a destination IP subnetwork, but it also might correspond to any traffic class that the edge LSR considers significant. For example, all traffic with a certain value of IP precedence might constitute an FEC.

MPLS packet forwarding consists of these two elements:

At the ingress to the MPLS network, packets are classified and assigned to a specific FEC using a label. No further packet classification is done in the MPLS network.

Throughout the MPLS network, all packets in an FEC are forwarded using the next-hop address for the FEC. The label value changes as the IP packet traverses the network. When a labeled packet is sent from one LSR to the next-hop LSR, the label value carried by the packet is the label value that the next-hop LSR assigned to represent the FEC of the packet.

Note Details on MPLS forwarding will be discussed in the “Frame-Mode MPLS Implementation on

Cisco IOS Platforms » module.

MPLS uses FEC-based forwarding to evolve connectionless IP networks to connection-oriented networks.

Page 41: Implementing cisco mpls

1-20 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Is the MPLS Label Format? This topic describes the format and fields of an MPLS label.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-5

MPLS Label Format

MPLS uses a 32-bit label field that contains the information that follows:

• 20-bit label (a number)

• 3-bit experimental field (typically used to carry IP precedence value)

• 1-bit bottom-of-stack indicator (indicates whether this is the last label before the IP header)

• 8-bit TTL (equal to the TTL in the IP header)

A label contains the fields listed in this table.

Label Fields

Field Description

îđóľ·¬ ´żľ»´ This is the actual label. The values 0 to 15 are reserved.

íóľ·¬ »¨°»®·ł»˛¬ż´ ş·»´Ľ

This field is typically used to define a class of service (CoS) or IP precedence value.

ޱ¬¬±łó±şó­¬ż˝µ ľ·¬ MPLS allows multiple labels to be inserted; this bit determines if this label is the last label in the packet. If this bit is set (1), it indicates that this is the last label.

čóľ·¬ ĚĚÔ ş·»´Ľ This field has the same purpose as the time-to-live (TTL) field in the IP header; it is used to prevent the indefinite looping of packets.

Page 42: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-21

Where Are MPLS Labels Inserted? This topic describes where MPLS labels are inserted in an IP packet.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-6

MPLS Labels

• MPLS technology is intended to be used anywhere regardless of Layer 1 media and Layer 2 encapsulation.

• Frame-mode MPLS is MPLS over a frame-based Layer 2 encapsulation

– The label is inserted between the Layer 2 and Layer 3 headers.

• Cell-mode MPLS is MPLS over ATM.

– The fields in the ATM header are used as the label.

MPLS is designed for use on virtually any media and Layer 2 encapsulation.

Frame-mode MPLS is the typical mode of MPLS, because most Layer 2 encapsulations are frame-based. In frame-mode MPLS, the 32-bit label is inserted between the Layer 2 and Layer 3 headers.

ATM is a special case of Layer 2 encapsulation where fixed-length cells are used.

Note If you are using ATM as a WAN link and the ATM switches do not act as LSRs, you are still

running frame-mode MPLS.

Cell-mode MPLS is MPLS using ATM Layer 2 encapsulation, where the ATM switch is participating as an LSR. In cell-mode MPLS, a label cannot be inserted on every cell; therefore, the virtual path identifier/virtual channel identifier (VPI/VCI) fields in the ATM header are used as a label.

Note Cell-mode MPLS is briefly mentioned here for reference purposes. This course will focus on

frame-mode MPLS, which is more prevalent in the industry.

Page 43: Implementing cisco mpls

1-22 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: MPLS Label Insertion—Frame-Mode MPLS

The figure shows an edge router that receives a normal IP packet.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-7

MPLS Labels: Frame-Mode MPLS

The edge LSR then does these tasks:

The router performs routing lookup to determine the outgoing interface.

The router assigns and inserts a label between the Layer 2 frame header and the Layer 3 packet header, if the outgoing interface is enabled for MPLS and if a next-hop label for the destination exists. This inserted label is also called the shim header.

The router then changes the Layer 2 protocol identifier (PID) or Ethertype value in the Layer 2 frame header to indicate that this is a labeled packet.

The router sends the labeled packet.

Note Other routers in the MPLS core simply forward packets based on the received label.

Page 44: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-23

What Is an MPLS Label Stack? This topic describes the features of an MPLS label stack.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-8

MPLS Label Stack

• Usually only one label is assigned to a packet, but multiple labels in a label stack are supported.

• These scenarios may produce more than one label:

– MPLS VPNs (two labels): The top label points to the egress router, and the second label identifies the VPN.

– MPLS TE (two or more labels): The top label points to the endpoint of the traffic engineering tunnel and the second label points to the destination.

– MPLS VPNs combined with MPLS TE (three or more labels).

Simple MPLS uses just one label in each packet. However, MPLS does allow multiple labels in a label stack to be inserted in a packet.

These applications may add labels to packets:

MPLS Virtual Private Networks (VPNs): With MPLS VPNs, Multiprotocol Border Gateway Protocol (MP-BGP) is used to propagate a second label that is used in addition to the one propagated by Label Distribution Protocol (LDP) or Tag Distribution Protocol (TDP).

Cisco MPLS Traffic Engineering (MPLS TE): MPLS TE uses Resource Reservation Protocol (RSVP) to establish label-switched path (LSP) tunnels. RSVP also propagates labels that are used in addition to the one propagated by LDP or TDP.

A combination of these mechanisms and other advanced features might result in three or more labels being inserted into one packet.

Page 45: Implementing cisco mpls

1-24 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: MPLS Label Stack This figure shows multiple labels in an MPLS label stack.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-10

Example: MPLS Label Stack

• Outer label is used for switching the packet in the MPLS network(points to TE destination)

• Inner labels are used to separate packets at egress points (points to egress router, and identifies VPN)

The outer label is used to switch the MPLS packet across the network. In this case, the outer layer is a traffic engineering (TE) label pointing to the endpoint of a TE tunnel.

The inner labels are ignored by the intermediary routers. In this case, the inner labels are used to point to the egress router and to identify the VPN for the packet.

Page 46: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-25

Example: MPLS Label Stack Format This figure shows the format of multiple labels in a frame-mode MPLS label stack.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-10

Example: MPLS Label Stack Format

• The PID in a Layer 2 header specifies that the payload starts with a label (labels) followed by an IP header.

• The bottom-of-stack bit indicates whether the label is the last label in the stack.

• The receiving router uses the top label only.

An MPLS PID in the Layer 2 header is used to identify every MPLS packet type. These Ethertype values are used to identify Layer 3 protocols with most Layer 2 encapsulations:

Unlabeled IP unicast: PID = 0x0800 identifies that the frame payload is an IP packet.

Labeled IP unicast: PID = 0x8847 identifies that the frame payload is a unicast IP packet with at least one label preceding the IP header. The bottom-of-stack bit indicates when the IP header actually starts.

Labeled IP multicast: PID = 0x8848 identifies that the frame payload is a multicast IP packet with at least one label preceding the IP header. The bottom-of-stack bit indicates when the IP header actually starts.

The top label of the label stack appears first in the packet, and the bottom label appears last. The bottom-of-stack bit in each MPLS label defines if the label is the last label in the packet. If this bit is set to 1, it indicates that this is the last label.

Page 47: Implementing cisco mpls

1-26 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are MPLS Label Operations? This topic describes MPLS label operations used when forwarding packets.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-11

MPLS Label Operations

• An LSR can perform these functions:

– Insert (impose or push) a label or a stack of labels on ingress edge LSR

– Swap a label with a next-hop label or a stack of labels in the core

– Remove (pop) a label on egress edge LSR

An IP packet going through an MPLS domain experiences the following:

On an ingress edge LSR, a label or a stack of labels is inserted (imposed). The label corresponds to the assigned FEC for the packet.

On a core or interior LSR, the top label is swapped with a next-hop label or a stack of labels.

At the egress edge LSR, the label is removed.

Page 48: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-27

Example: MPLS Label Operations—Frame-Mode MPLS This figure shows label operations in an MPLS network using frame-mode MPLS.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-12

MPLS Label Operations: Frame Mode

• On ingress, a label is assigned and imposed.

• LSRs in the core swap labels based on the contents of the label forwarding table.

• On egress, the label is removed and a routing lookup is used to forward the packet.

All LSRs are capable of forwarding IP packets or labeled packets.

In this example, the ingress edge LSR performs a routing lookup and assigns a label.

The middle router simply swaps the label.

The egress edge LSR removes the label and optionally performs a routing lookup.

Page 49: Implementing cisco mpls

1-28 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-13

Summary

• An MPLS label is a 4 byte identifier used for forwarding decisions.

– A MPLS label corresponds to an FEC.

• MPLS frame-mode labels are inserted between the Layer 2 and Layer 3 headers.

• MPLS supports multiple labels in one packet, creating a label stack.

• LSRs can perform these operations:

– Insert (impose) a label on ingress edge LSR

– Swap a label

– Remove (pop) a label on egress edge LSR

Page 50: Implementing cisco mpls

Lesson 3

Identifying MPLS Applications

OverviewThis lesson describes some of the different types of applications with which you can use Multiprotocol Label Switching (MPLS). These applications are discussed at a high level. Interaction among multiple applications is also discussed because there are various methods for exchanging labels. Regardless of the differences in the control plane, all of the applications use a single label-forwarding engine in the data plane.

ObjectivesUpon completing this lesson, you will be able to describe the different MPLS applications with which you can use MPLS. This ability includes being able to meet these objectives:

Describe the various applications that are used with MPLS

Describe the features of MPLS unicast IP routing

Describe the features of MPLS multicast IP routing

Describe MPLS use in VPNs

Describe MPLS use in TE environments

Describe MPLS use in QoS environments

Describe AToM

Identify the interactions that occur between various MPLS applications

Page 51: Implementing cisco mpls

1-30 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Which Applications Are Used with MPLS? This topic describes various applications that are used with MPLS.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.1—1-3

MPLS Applications

• MPLS is already used in many different applications:

– Unicast IP routing

– Multicast IP routing

– MPLS TE

– QoS

– MPLS VPNs (course focus)

– AToM

MPLS is a technology used for the delivery of IP services. MPLS can be used in different applications, as outlined here:

Unicast IP routing is the most common application for MPLS.

Multicast IP routing is treated separately because of different forwarding requirements.

MPLS TE is an add-on to MPLS that provides better and more intelligent link use.

Differentiated QoS can also be provided with MPLS.

MPLS VPNs are implemented using labels to allow overlapping address space between VPNs. MPLS VPN is the focus of this course.

AToM is a solution for transporting Layer 2 packets over an IP or MPLS backbone.

Page 52: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-31

What Is MPLS Unicast IP Routing? This topic describes the features of MPLS unicast IP routing.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.1—1-4

MPLS Unicast IP Routing

• Basic MPLS service supports unicast IP routing.

• MPLS unicast IP routing provides enhancement over traditional IP routing.

– The ability to use labels for packet forwarding:

• Label-based forwarding provides greater efficiency.

• The FEC corresponds to a destination address stored in the IP routing table.

• Labels support connection-oriented services.

– The capability to carry a stack of labels assigned to a packet:

• Label stacks allow implementation of enhanced applications.

Basic MPLS supports unicast IP routing.

There are two significant enhancements that MPLS unicast IP routing provides over traditional IP routing:

The ability to use labels for packet forwarding

The capability to carry a stack of labels assigned to a packet

As discussed in the “Introducing Basic MPLS Concepts” lesson, using labels for packet forwarding increases efficiency in network core devices because the label swapping operation is less CPU intensive than a routing lookup. MPLS can also provide connection-oriented services to IP traffic due to forwarding equivalence class (FEC)-based forwarding.

Note The MPLS unicast IP traffic FEC corresponds to a destination network stored in the IP

routing table.

MPLS support for a label stack allows implementation of enhanced applications, such as Virtual Private Networks (VPNs), traffic engineering (TE), and enhanced quality of service (QoS).

Page 53: Implementing cisco mpls

1-32 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Is MPLS Multicast IP Routing? This topic describes the features of MPLS multicast IP routing.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.1—1-5

MPLS Multicast IP Routing

• MPLS can also support multicast IP routing:

– A dedicated protocol is not needed to support multicast traffic across an MPLS domain.

– Cisco Protocol Independent Multicast Version 2 with extensions for MPLS is used to propagate routing information and labels.

– The FEC is equal to a destination multicast address stored in the multicast routing table.

Multicast IP routing can also use MPLS. Cisco Protocol Independent Multicast (PIM) Version 2 with extensions for MPLS is used to propagate routing information and labels.

The FEC is equal to a destination multicast address.

Page 54: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-33

What Are MPLS VPNs? This topic describes MPLS use in VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.1—1-6

MPLS VPNs

• MPLS VPNs are highly scaleable and support IP services such as:

– Multicast

– Quality of QoS

– Telephony support within a VPN

– Centralized services including content and web hosting to a VPN

• Networks are learned via an IGP from a customer or via BGP from other MPLS backbone routers.

• Labels are propagated via MP-BGP. Two labels are used:

– The top label points to the egress router.

– The second label identifies the outgoing interface on the egress router or a routing table where a routing lookup is performed.

• FEC is equivalent to a VPN site descriptor or VPN routing table.

MPLS enables highly scaleable VPN services to be supported. For each MPLS VPN user, the network appears to function as a private IP backbone over which the user can reach other sites within the VPN organization, but not the sites of any other VPN organization. MPLS VPNs are a common application for service providers. Building VPNs in Layer 3 allows delivery of targeted services to a group of users represented by a VPN.

MPLS VPNs are seen as private intranets, and support IP services such as those listed here:

Multicast

QoS

Telephony support within a VPN

Centralized services including content and web hosting to a VPN

Customer networks are learned via an Interior Gateway Protocol (IGP) (Open Shortest Path First [OSPF], External Border Gateway Protocol [EBGP], Enhanced Interior Gateway RoutingProtocol [EIGRP], Routing Information Protocol version 2 [RIPv2], or static) from a customer, or via Border Gateway Protocol (BGP) from other MPLS backbone routers.

Page 55: Implementing cisco mpls

1-34 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

MPLS VPNs use two labels:

The top label points to the egress router.

The second label identifies the outgoing interface on the egress router or a routing table where a routing lookup is performed.

Label Distribution Protocol (LDP) is needed in the top label to link edge label switch routers (LSRs) with a single label-switched path (LSP) tunnel. Multiprotocol BGP (MP-BGP) is used in the second label to propagate VPN routing information and labels across the MPLS domain. The MPLS VPN FEC is equivalent to a VPN site descriptor or VPN routing table.

Page 56: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-35

What Is MPLS TE? This topic describes MPLS use in TE environments.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.1—1-7

MPLS TE

• MPLS TE supports constraints-based routing

• MPLS TE enables the network administrator to

– Control traffic flow in the network

– Reduce congestion in the network

– Make best use of network resources

• MPLS TE requires OSPF or IS-IS with extensions to hold the entire network topology in their databases.

• OSPF and IS-IS should also have some additional information about network resources and constraints.

• RSVP is used to establish TE tunnels and to propagate labels.

Another application of MPLS is TE. MPLS TE enables an MPLS backbone to replicate and expand upon the TE capabilities of Layer 2 ATM and Frame Relay networks. MPLS TE supports constraint-based routing in which the path for a traffic flow is the shortest path that meets the resource requirements (constraints) of the traffic flow. Factors such as bandwidth requirements, media requirements, and the priority of one traffic flow versus another can be taken into account. TE capabilities enable the administrator of a network to accomplish these goals:

Control traffic flow in the network

Reduce congestion in the network

Make best use of network resources

MPLS TE has these special requirements:

Every LSR must see the entire topology of the network (only OSPF and Intermediate System-to-Intermediate System [IS-IS] hold the entire topology).

Every LSR needs additional information about links in the network. This information includes available resources and constraints. OSPF and IS-IS have extensions to propagate this additional information.

Resource Reservation Protocol (RSVP) is used to establish TE tunnels and to propagate the labels.

Every edge LSR must be able to create an LSP tunnel on demand. RSVP is used to create an LSP tunnel and to propagate labels for TE tunnels.

Page 57: Implementing cisco mpls

1-36 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Is MPLS QoS? This topic describes MPLS use in QoS environments.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.1—1-8

MPLS QoS

• MPLS QoS provides differentiated types of service across an MPLS network.

• MPLS QoS offers:

– Packet classification

– Congestion avoidance

– Congestion management.

• MPLS QoS is an extension to unicast IP routing that provides differentiated services.

• Extensions to LDP are used to propagate different labels for different classes.

• The FEC is a combination of a destination network and a class of service.

MPLS QoS enables network administrators to provide differentiated types of service across an MPLS network. MPLS QoS offers packet classification, congestion avoidance, and congestion management.

Note MPLS QoS functions map nearly one-for-one to IP QoS functions on all interface types.

Differentiated QoS is achieved by using MPLS experimental bits or by creating separate LSP tunnels for different classes. Extensions to LDP are used to create multiple LSP tunnels for the same destination (one for each class).

The FEC for MPLS QoS is equal to a combination of a destination network and a class of service (CoS).

Page 58: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-37

What Is AToM? This topic describes Any Transport over MPLS (AToM).

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.1—1-9

Any Transport over MPLS

• AToM transports Layer 2 traffic over an IP or MPLS backbone.

• AToM accommodates many types of Layer 2 frames, including Ethernet, Frame Relay, ATM, PPP, and HDLC.

• AToM enables connectivity between existing data link layer (Layer 2) networks by using a single, integrated, packet-based network infrastructure.

• AToM forwarding uses two-level labels.

• AToM also offers performance, scalability, and other MPLS enhancements such as TE, fast reroute, and QoS.

AToM is the Cisco solution for transporting Layer 2 traffic over an IP or MPLS backbone. AToM extends the usability of an IP or MPLS backbone by enabling it to offer both Layer 2 and Layer 3 services. The AToM product set accommodates many types of Layer 2 frames, including Ethernet, Frame Relay, ATM, PPP, and High-Level Data Link Control (HDLC), across various Cisco router platforms including Cisco 7200, 7400, 7500, 7600, 10700, and 12000 Series Routers.

AToM enables service providers to supply connectivity between customer sites with existing data link layer (Layer 2) networks by using a single, integrated, packet-based network infrastructure.

AToM uses a directed LDP session between edge LSRs (or provider edge (PE) routers) for setting up and maintaining connections. Directed LDP is unicast based, and establishes a TCP session across potentially multiple hops. Forwarding occurs through the use of two-level labels, switching between the PE routers. The external label (tunnel label), routes the packet over the MPLS backbone to the egress PE from the ingress PE. The virtual circuit (VC) label determines the egress interface, and it binds the Layer 2 egress interface to the tunnel label.

AToM also offers performance, scalability, and new value-added services using other MPLS enhancements such as TE, fast reroute, and QoS.

Note A detailed discussion of AToM is beyond the scope of this course. A general overview of

AToM with links to more detailed information may be found at

http://www.cisco.com/en/US/products/ps6646/products_ios_protocol_option_home.html

A technical overview of AToM may be found at

http://www.cisco.com/en/US/products/ps6603/products_white_paper09186a00804fbda5.shtml

Page 59: Implementing cisco mpls

1-38 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

AToM Examples This topic provides an overview of some AToM technologies.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.1—1-10

Examples of AToM

• Ethernet over MPLS (EoMPS)

– Supports the transport of Ethernet frames across an MPLS core for a particular Ethernet or virtual LAN (VLAN) segment

– Applications include TLS and VPLS

• ATM over MPLS

– Supports two types of transport mechanisms of ATM frames across an MPLS core:

• AAL5-over-MPLS mode

• Cell-relay mode

• Frame Relay over MPLS

– Supports transport of Frame Relay packets over MPLS core

– Carries BECN, FECN, DE, and C/R in a control word header

Ethernet over MPLS (EoMPLS) is the transport of Ethernet frames across an MPLS core. It transports all frames received on a particular Ethernet or VLAN segment, regardless of the destination MAC information. It does not perform MAC learning or MAC lookup for forwarding packets from the Ethernet interface. Some applications include Transparent LAN Services (TLS) between facilities, and Virtual Private LAN Services (VPLS), which is a class of VPN that supports the connection of multiple sites in a single bridged domain over a managed IP or MPLS network.

ATM over MPLS is another supported technology. There are two types of transport mechanisms for ATM over MPLS:

ATM adaptation layer 5 (AAL5)-over-MPLS mode: ATM interface assembles the AAL5 protocol data unit (PDU) with either AAL5 Subnetwork Access Protocol (AAL5 SNAP) or AAL5 multiplexer (AAL5 MUX) encapsulation at the boundary and transports it across the network as a single MPLS packet.

Cell-relay mode: The ATM interface receives cells and transports them across the MPLS core. Cell relay with cell packing is used to send multiple cells in one MPLS frame, improving the efficiency of cell transport.

Frame Relay over MPLS (FRoMPLS) is also supported. In this application, traffic is encapsulated in MPLS packets and forwarded across the MPLS network. When encapsulating FRoMPLS, the Frame Relay header and the frame check sequence (FCS) are stripped from the packet. The bits for backward explicit congestion notification (BECN), forward explicit congestion notification (FECN), discard eligibility (DE), and command/response (C/R) are carried across the MPLS network in the control word header.

Page 60: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-39

What Are the Interactions Between MPLS Applications?

This topic identifies the interactions that occur between MPLS applications.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.1—1-11

Interactions Between MPLS Applications

The figure shows the overall architecture when multiple applications are used.

Regardless of the application, the functionality is always split into the control plane and the data (forwarding) plane, as discussed here:

The applications may use a different routing protocol and a different label exchange protocol in the control plane.

The applications all use a common label-switching data (forwarding) plane.

Edge LSR Layer 3 data planes may differ to support label imposition and disposition.

In general, a label is assigned to an FEC.

Page 61: Implementing cisco mpls

1-40 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.1—1-12

Summary

• MPLS is used in many applications: unicast IP routing, multicast IP routing, MPLS VPNs, MPLS TE, QoS, and AToM.

• Basic MPLS provides unicast IP routing using an IP routing protocol and a label distribution protocol.

• MPLS multicast IP routing does not need a dedicated protocol to support multicast traffic across an MPLS domain.

• MPLS VPNs provide highly scaleable VPNs providing IP services.

• MPLS TE supports constraints-based routing.

• MPLS QoS extends unicast IP routing and provides differentiated services.

• AToM transports Layer 2 traffic over an IP or MPLS backbone.

• Some MPLS applications may use a different routing and label exchange protocol; however, the applications all use the same label-forwarding engine.

Page 62: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-41

Module Summary This topic summarizes the key points that were discussed in this module.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1-1

Module Summary

• MPLS is a new forwarding mechanism in which packets are forwarded based on labels.

• MPLS uses a 32-bit label format, which is inserted between Layer 2 and Layer 3. Labels can be inserted, swapped, or removed.

• MPLS applications can use different routing and label exchange protocols while still using the same label-forwarding engine.

Multiprotocol Label Switching (MPLS) forwards packets based on labels. MPLS can be implemented in ATM networks to provide optimal routing across Layer 2 ATM switches. MPLS uses the concept of a label stack where multiple labels are supported in one packet. You can use MPLS in many applications. When many MPLS applications are being used, all applications use a single label-forwarding engine.

ReferencesFor additional information, refer to these resources:

RFC 3031, Multiprotocol Label Switching Architecture http://www.ietf.org/rfc/rfc3031.txt

RFC 3032, MPLS Label Stack Encodinghttp://www.rfc-editor.org/rfc/rfc3032.tx.

Page 63: Implementing cisco mpls

1-42 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Module Self-Check Use the questions here to review what you learned in this module. The correct answers and solutions are found in the Module Self-Check Answer Key.

Q1) What are three foundations of traditional IP routing? (Choose three.) (Source:

Introducing Basic MPLS Concepts)

A) Routing protocols are used on all devices to distribute routing information. B) Regardless of protocol, routers always forward packets based on the IP

destination address only (except for using PBR). C) Routing lookups are performed on every router. D) Routing is performed by assigning a label to an IP destination.

Q2) Which three statements are true? (Choose three.) (Source: Introducing Basic MPLS

Concepts)

A) MPLS uses labels to forward packets. B) MPLS works only in IP networks. C) MPLS labels can correspond to a Layer 3 destination address, QoS, source

address, or Layer 2 circuit. D) MPLS does not require a routing table lookup on core routers.

Q3) In MPLS TE, which two statements are true? (Choose two.) (Source: Introducing Basic

MPLS Concepts)

A) Traditional IP routing does not support traffic engineering. B) Traditional IP routing would force all traffic to use the same path based on

destination.C) Using MPLS TE, traffic can be forwarded based on parameters such as QoS

and source address. D) MPLS does not support traffic engineering.

Q4) The label distribution protocol (either LDP or TDP) is the responsibility of the _____.

(Source: Introducing Basic MPLS Concepts)

A) data plane B) forwarding plane C) system plane D) control plane

Q5) The MPLS label field consists of how many bits? (Source: Introducing Basic MPLS

Concepts)

A) 64 bitsB) 32 bitsC) 16 bits D) 8 bits

Page 64: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-43

Q6) Which two statements are true? (Choose two.) (Source: Introducing Basic MPLS

Concepts)

A) An edge LSR is a device that inserts labels on packets or removes labels, and forwards packets based on labels.

B) An LSR is a device that primarily labels packets or removes labels. C) An LSR is a device that forwards packets based on labels. D) An end LSR is a device that primarily inserts labels on packets or removes

labels.

Q7) MPLS labels can correspond to which type of addresses? (Source: Introducing Basic

MPLS Concepts)

A) Layer 2 source addresses B) Layer 3 source addresses C) Layer 2 destination addresses D) Layer 3 destination addresses

Q8) Which term is best described as “a simple label-based forwarding engine”? (Source:

Introducing Basic MPLS Concepts)

A) control plane B) ground plane C) data plane D) routing plane

Q9) Which three statements are true? (Choose three.) (Source: Introducing MPLS Labels

and Label Stacks)

A) In frame-mode MPLS, labels are typically inserted between the Layer 2 header and the Layer 3 header.

B) MPLS labels are inserted after the Layer 3 header in frame-mode MPLS. C) In cell-mode MPLS, MPLS uses the VPI/VCI fields as the label. D) MPLS will not work in ATM networks. E) MPLS labels are 32 bits. F) MPLS labels are 64 bits.

Q10) How long is the actual MPLS label contained in the MPLS label field? (Source:

Introducing MPLS Labels and Label Stacks)

A) 32 bits long B) 8 bits long C) 16 bits long D) 20 bits long

Q11) Which two statements are true? (Choose two.) (Source: Introducing MPLS Labels and

Label Stacks)

A) Usually one label is assigned to an IP packet. B) Usually two labels are assigned to an IP packet. C) Two labels will be assigned to an MPLS VPN packet. D) One label will be assigned to an MPLS VPN packet.

Page 65: Implementing cisco mpls

1-44 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q12) What are two normal functions of an edge LSR? (Choose two.) (Source: Introducing

MPLS Labels and Label Stacks)

A) impose labels at the ingress router B) impose labels at the egress router C) pop labels at the ingress router D) pop labels at the egress router

Q13) Cisco routers automatically assign the IP precedence value to which field in the MPLS

label? (Source: Introducing MPLS Labels and Label Stacks)

A) TTL field B) experimental field C) top-of-stack field D) The IP precedence value is not copied to the MPLS field; this value remains in

the IP packet.

Q14) What is NOT a valid Ethertype used to identify Layer 3 protocols with most Layer 2

encapsulations? (Source: Introducing MPLS Labels and Label Stacks)

A) unlabeled IP unicast (PID = 0x0800) B) labeled IP unicast (PID = 0x0847) C) unlabeled IP multicast (PID = 0x8846) D) labeled IP multicast (PID = 0x8848)

Q15) Which two statements are true regarding RSVP? (Choose two.) (Source: Identifying

MPLS Applications)

A) RSVP is used to create an LSP tunnel. B) RSVP propagates labels for TE tunnels. C) RSVP assigns labels for TE tunnels. D) RSVP is not used to create an LSP tunnel.

Q16) When MPLS is used for QoS, which statement is true? (Source: Identifying MPLS

Applications)

A) QoS is achieved by using the protocol bits in the MPLS label field. B) QoS is achieved by using the TTL bits in the MPLS label field. C) QoS is achieved by using the experimental bits in the MPLS label field. D) At this time, QoS is not supported by MPLS.

Q17) In MPLS VPN networks, which statement is true? (Source: Identifying MPLS

Applications)

A) Labels are propagated via LDP or TDP. B) Next-hop addresses instead of labels are used in an MPLS VPN network. C) Labels are propagated via MP-BGP. D) Two labels are used; the top label identifies the VPN, and the bottom label

identifies the egress router.

Page 66: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS Concepts 1-45

Q18) Which two statements are true regarding interactions between MPLS applications?

(Choose two.) (Source: Identifying MPLS Applications)

A) The forwarding plane is the same for all applications. B) Differences exist in the forwarding plane depending on the MPLS application. C) The control plane is the same for all applications. D) Differences exist in the control plane depending on the MPLS application.

Q19) In MPLS VPNs, what does the FEC refer to? (Source: Identifying MPLS Applications)

A) IP destination network B) MPLS ingress router C) core of the MPLS network D) VPN destination network

Page 67: Implementing cisco mpls

1-46 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Module Self-Check Answer Key Q1) A, B, C

Q2) A, C, D

Q3) B, C

Q4) D

Q5) B

Q6) A, C

Q7) D

Q8) C

Q9) A, C, E

Q10) D

Q11) A, C

Q12) A, D

Q13) B

Q14) C

Q15) A, B

Q16) C

Q17) C

Q18) A, D

Q19) D

Page 68: Implementing cisco mpls

Module 2

Label Assignment and Distribution

OverviewThis module describes the assignment and distribution of labels in a Multiprotocol Label Switching (MPLS) network, including neighbor discovery and session establishment procedures. Label distribution, control, and retention modes will also be covered. This module also covers the functions and benefits of penultimate hop popping (PHP).

Module Objectives Upon completing this module, you will be able to describe how MPLS labels are assigned and distributed. This ability includes being able to meet these objectives:

Describe how LDP neighbors are discovered

Describe how the LIB, FIB, and LFIB tables are populated with label information

Describe how convergence occurs in a frame-mode MPLS network

Describe MPLS label allocation, distribution, and retention modes

Page 69: Implementing cisco mpls

2-2 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 70: Implementing cisco mpls

Lesson 1

Discovering LDP Neighbors

OverviewThis lesson takes a detailed look at the Label Distribution Protocol (LDP) neighbor discovery process via hello messages and the type of information that is exchanged. The lesson also describes the events that occur during the negotiation phase of LDP session establishment and concludes with the nonadjacent neighbor discovery process.

This lesson provides an understanding of how an LDP neighbor is discovered and what type of information is sent back and forth between two neighbors. The lesson also discusses situations in which the neighbor is not directly connected to a peer. This information will provide a further understanding of the Multiprotocol Label Switching (MPLS) technology.

ObjectivesUpon completing this lesson, you will be able to describe how LDP neighbors are discovered. This ability includes being able to meet these objectives:

Describe how LDP sessions are established between adjacent neighbors

Describe the contents of an LDP hello message

Describe negotiating label space as it applies to LDP session establishment

Describe how LDP neighbors are discovered

Describe the process of LDP session negotiation between LDP neighbors

Describe how LDP sessions are established between nonadjacent neighbors

Page 71: Implementing cisco mpls

2-4 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Establishing an Adjacent LDP Session This topic describes how LDP sessions are established between neighbors.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-3

LDP Neighbor Session Establishment

• LDP establishes a session in two steps:

– Hello messages are periodically sent on all MPLS-enabled interfaces.

– MPLS-enabled routers respond to received hello messages by attempting to establish a session with the source of the hello messages.

• LDP link hello message is a UDP packet sent to the “all routers on this subnet” multicast address (224.0.0.2).

• TCP is used to establish the session.

• Both TCP and UDP use well-known LDP port number 646.

LDP is a standard protocol used to exchange labels between adjacent routers.

Note Tag Distribution Protocol (TDP) is an older Cisco proprietary protocol that has the same

functionality as LDP. Although the remainder of this lesson will focus on LDP, it should be

noted that TDP, as the predecessor of LDP, works in a similar fashion.

LDP periodically sends hello messages (every 5 seconds). If the label switch router (LSR) is adjacent or one hop from its neighbor, the LSR sends out LDP link hello messages to all the routers on the subnet as User Datagram Protocol (UDP) packets with a multicast destination address of 224.0.0.2 (“all routers on a subnet”) and destination port number of 646. (TDP uses destination port 711.)

A neighboring LSR enabled for LDP will respond by opening a TCP session with the same destination port number 646, and the two routers begin to establish an LDP session through unicast TCP.

Page 72: Implementing cisco mpls

© 2006, Cisco Systems, Inc. Label Assignment and Distribution 2-5

What Are LDP Hello Messages? This topic describes the contents of an LDP link hello message.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-4

LDP Link Hello Message

• Hello messages are sent to all routers reachable through an interface.

• LDP uses well-known port number 646 with UDP for hello messages.

• A 6-byte LDP identifier (TLV) identifies the router (first 4 bytes) and label space (last 2 bytes).

• The source address used for an LDP session can be set by adding the transport address TLV to the hello message.

The contents of an LDP link hello message are as follows:

Destination IP address (224.0.0.2), which reaches all routers on the subnetwork

Destination port, which equals the LDP well-known port number 646

The actual hello message, which may optionally contain a transport address type, length, value (TLV) to instruct the peer to open the TCP session to the transport address instead of the source address found in the IP header

The LDP identifier (LDP ID) is used to uniquely identify the neighbor and the label space.

Note Label space defines the way MPLS assigns labels to destinations. Label space can either be

per-platform or per-interface.

Multiple LDP sessions can be established between a pair of LSRs if they use multiple label spaces.

Page 73: Implementing cisco mpls

2-6 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: Per-Platform Label Space This example illustrates per-platform label space.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-5

Label Space: Per-Platform

• The label forwarding information base (LFIB) on an LSR does not contain an incoming interface.

• The same label can be used on any interface and is announced to all adjacent LSRs.

• The label is announced to adjacent LSRs only once and can be used on any link.

• Per-platform label space is less secure than per-interface label space.

Per-platform label space is used with frame-mode MPLS, where one label is assigned to a destination network and sent to all LDP peers. This label can then be used on any incoming interface. The per-platform label space minimizes the number of LDP sessions and allows upstream label-switched path (LSP) tunnels to span parallel links, because the same label is used on all of those links. However, per-platform label space is less secure than per-interface label space, because untrusted routers could use labels that were never allocated to them.

Page 74: Implementing cisco mpls

© 2006, Cisco Systems, Inc. Label Assignment and Distribution 2-7

Negotiating Label Space This topic describes negotiating label space as it applies to LDP session establishment.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-6

Negotiating Label Space

• LSRs establish one LDP session per label space.

– Per-platform label space requires only one LDP session, even if there are multiple parallel links between a pair of LSRs.

• Per-platform label space is announced by setting the label space ID to 0, for example:

– LDP ID = 1.0.0.1:0

If a pair of routers is connected over two or more parallel links and uses frame-mode MPLS, the routers try to establish multiple sessions by using the same LDP ID. Because the routers are using per-platform label space, this action will result in only one session remaining; the other session will be broken.

Per-platform label space is identified by setting the label space ID to 0 in the LDP ID field.

For all frame-mode interfaces, only one LDP session between a pair of LSRs is used because frame-mode MPLS uses per-platform label space.

Page 75: Implementing cisco mpls

2-8 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Discovering LDP Neighbors This topic describes how LDP neighbors are discovered.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-7

LDP Neighbor Discovery

• An LDP session is established from the router with the higher IP address.

Example: LDP Neighbor Discovery

In the figure, three out of four routers periodically send out LDP hello messages (the fourth router is not MPLS-enabled).

Routers that have the higher IP addresses must initiate the TCP session.

Note The highest IP address of all loopback interfaces on a router is used. If no loopback

interfaces are configured on the router, the highest IP address of a configured interface that

was operational at LDP startup is used.

After the TCP session is established, routers will keep sending LDP hello messages to potentially discover new peers or to identify failures.

Page 76: Implementing cisco mpls

© 2006, Cisco Systems, Inc. Label Assignment and Distribution 2-9

Negotiating LDP Sessions This topic describes the process of LDP neighbor session negotiation between LDP neighbors.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-8

LDP Session Negotiation

• Peers first exchange initialization messages.

• The session is ready to exchange label mappings after receiving the first keepalive.

LDP session negotiation is a three-step process, as follows:

Step 1 Establish the TCP session.

Step 2 Exchange initialization messages.

Step 3 Exchange initial keepalive messages.

Note LDP keepalives are sent every 60 seconds.

After these steps have occurred, the two peers will start exchanging labels for networks that they have in their main routing tables.

Page 77: Implementing cisco mpls

2-10 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Discovering Nonadjacent Neighbors This topic describes how LDP discovers nonadjacent neighbors.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-9

LDP Discovery of Nonadjacent Neighbors

• LDP neighbor discovery of nonadjacent neighbors differs from normal discovery only in the addressing of hello packets:

– Hello packets use unicast IP addresses instead of multicast addresses.

• When a neighbor is discovered, the mechanism to establish a session is the same.

If the LSR is more than one hop from its neighbor, it is not directly connected or adjacent to its neighbor. The LSR can be configured with the mpls ldp neighbor [vrf vrf-name] ip-addresstargeted command to send a directed hello message as a unicast UDP packet specifically addressed to the nonadjacent neighbor LSR. The directed hello message is called an LDP targeted hello.

The rest of the session negotiation is the same as for adjacent routers. The nondirectly connected LSR will respond to the hello message by opening a unicast TCP session with the same destination port number 646, and the two routers begin to establish an LDP session. (If the path between two LSRs has been traffic engineered and has LDP enabled, the LDP session between them is called a targeted session.)

Page 78: Implementing cisco mpls

© 2006, Cisco Systems, Inc. Label Assignment and Distribution 2-11

Example: Applications Using Targeted LDP Sessions This figure lists some applications that use targeted LDP sessions.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-10

Targeted LDP Session Applications

• MPLS Fast Reroute (FRR)

• MPLS Nonstop Forwarding (NSF)

• MPLS LDP Session Protection

Here are some applications that use targeted LDP sessions:

MPLS Fast Reroute (FRR), which is the ability to locally patch traffic onto a backup tunnel in case of a link or node failure with a failover time of 50 ms or lower

MPLS Nonstop Forwarding (NSF), which allows a router to recover from disruption in control plane service (specifically, the LDP component) without losing its MPLS forwarding state

MPLS LDP Session Protection, which provides faster LDP convergence when a link recovers following an outage by maintaining LDP bindings for a period of time

Page 79: Implementing cisco mpls

2-12 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-11

Summary

• UDP multicast is used to discover adjacent LDP neighbors, while TCP is used to establish a session.

• LDP hello messages contain an identifier field that uniquely identifies the neighbor and the label space.

• Per-platform label space requires only one LDP session.

• An LDP session is initiated in TCP from the higher IP address router.

• LDP session negotiation is a three-step process: establishing the TCP session, exchanging initialization messages, and exchanging initial keepalive messages.

• Nonadjacent neighbor discovery is accomplished by using unicast IP addresses instead of multicast.

Page 80: Implementing cisco mpls

Lesson 2

Introducing Typical Label Distribution in Frame-Mode MPLS

OverviewThis lesson discusses how label allocation and distribution function in a frame-mode network. Also covered are penultimate hop popping (PHP) and how the Multiprotocol Label Switching (MPLS) data structures are built. This lesson is essential to understanding the basic fundamentals of how information gets distributed and placed into the appropriate tables for both labeled and unlabeled packet usage.

ObjectivesUpon completing this lesson, you will be able to describe how the Label Information Base (LIB), Forwarding Information Base (FIB), and label forwarding information base (LFIB)tables are populated with label information. This ability includes being able to meet these objectives:

Describe how labels are propagated across a network

Describe the function of LSPs

Describe the function of PHP

Describe the impact that IP aggregation has on LSPs

Describe how labels are allocated in a frame-mode MPLS network

Describe how MPLS labels are distributed and advertised in a frame-mode network

Describe how the LFIB table is populated in an MPLS network

Describe how IP packets cross an MPLS network

Describe how frame-mode loops are detected

Describe the approaches for assigning labels to networks

Page 81: Implementing cisco mpls

2-14 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Propagating Labels Across a Network This topic describes how labels are propagated across a network.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-3

MPLS Unicast IP Routing Architecture

• MPLS introduces a label field that is used for forwarding decisions.

• Although labels are locally significant, they have to be advertised to directly reachable peers.

– One option would be to include this parameter in existing IP routing protocols.

– The other option is to create a new protocol to exchange labels.

• The second option has been used because there are too many existing IP routing protocols that would have to be modified to carry labels.

One application of MPLS is unicast IP routing. A label is assigned to destination IP networks and is later used to label packets sent toward those destinations.

Note In MPLS terminology, a forwarding equivalence class (FEC) in MPLS unicast IP routing

equals an IP destination network.

Standard or vendor-specific routing protocols are used to advertise IP routing information. MPLS adds a new piece of information that must be exchanged between adjacent routers.

Here are the two possible approaches to propagating this additional information (labels) between adjacent routers:

Extend the functionality of existing routing protocols

Create a new protocol dedicated to exchanging labels

The first approach requires much more time and effort because of the large number of different routing protocols: Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), Enhanced Interior Gateway Routing Protocol (EIGRP), Interior Gateway Routing Protocol (IGRP), Routing Information Protocol (RIP), and so on. The first approach also causes interoperability problems between routers that support this new functionality and those that do not. Therefore, the Internet Engineering Task Force (IETF) selected the second approach.

Page 82: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-15

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-4

MPLS Unicast IP Routing Architecture (Cont.)

Example: Building Blocks for IP Forwarding The figure shows the building blocks used by routers to perform traditional IP forwarding.

The control plane consists of a routing protocol that exchanges routing information and maintains the contents of the main routing table. When combined with Cisco Express Forwarding (CEF), the IP forwarding table in the data plane forwards the packets through the router.

The Label Distribution Protocol (LDP) in the control plane exchanges labels and stores them in the Label Information Base (LIB). This information is then used in the data plane to provide MPLS functionality, as follows:

A label is added to the IP forwarding table (FIB) to map an IP prefix to a next-hop label.

A locally generated label is added to the LFIB and mapped to a next-hop label.

These forwarding scenarios are possible when MPLS is enabled on a router:

An incoming IP packet is forwarded by using the FIB table and sent out as an IP packet (the usual CEF switching).

An incoming IP packet is forwarded by using the FIB table and sent out as a labeled IP packet (the default action if there is a label assigned to the destination IP network).

An incoming labeled packet is forwarded by using the LFIB table and sent out as a labeled IP packet.

An incoming labeled packet has its label removed, is inspected against the FIB table, and is forwarded as an IP packet.

Page 83: Implementing cisco mpls

2-16 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-5

MPLS Unicast IP Routing Architecture (Cont.)

Example: Using the FIB Table to Forward Packets

The figure shows a scenario in which IP packets are successfully forwarded by using the FIB table.

Note CEF is the only Layer 3 switching mechanism that uses the FIB table. CEF must be enabled

on all routers running MPLS, and on all ingress interfaces receiving unlabeled IP packets

that are to be propagated as labeled packets.

Labeled packets, on the other hand, are not forwarded because of a lack of information in the LFIB table. Normal MPLS functionality prevents the forwarding from happening, because no adjacent router is going to use a label unless this router previously advertised the label.

The example illustrates that label switching tries to use the LFIB table only if the incoming packet is labeled, even if the destination address is reachable by using the FIB table.

Note The LIB table will hold all locally generated labels by a label switch router (LSR). The LFIB

table contains labels that are used to switch packets.

Page 84: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-17

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-6

MPLS Unicast IP Routing Architecture (Cont.)

Example: Using LDP

The figure shows a router where OSPF is used to exchange IP routing information, and LDP is used to exchange labels. The router has attached the locally significant label 25 to the prefix 10.0.0.0/8 and advertised it to its neighbors. The label 23 has been assigned to prefix 10.0.0.0/8 by the upstream neighbor of the router (to the right in the diagram).

When an incoming IP packet to 10.1.1.1 arrives, it is forwarded by using the FIB table, where a next-hop label dictates that the outgoing packet should be labeled with label 23.

When a downstream router participating in MPLS receives a packet for 10.1.1.1, it will attach the label 25 and forward it to this router. When this router receives the labeled packet, it will swap the label value of 25 with a label value of 23 based on the LFIB table. With this process, the incoming (locally significant) label 25 is swapped with the next-hop label 23.

Page 85: Implementing cisco mpls

2-18 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are LSPs? This topic describes the function of label-switched paths (LSPs).

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-7

Label-Switched Path

• An LSP is a sequence of LSRs that forwards labeled packets of a certain forwarding equivalence class.

– MPLS unicast IP forwarding builds LSPs based on the output of IP routing protocols.

– LDP advertises labels only for individual segments in the LSP.

• LSPs are unidirectional.

– Return traffic uses a different LSP (usually the reverse path because most routing protocols provide symmetrical routing).

• An LSP can take a different path from the one chosen by an IP routing protocol (MPLS TE).

An LSP is a sequence of LSRs that forwards labeled packets for a particular FEC. Each LSR swaps the top label in a packet traversing the LSP. An LSP is similar to Frame Relay or ATM virtual circuits.

In MPLS unicast IP forwarding, the FECs are determined by destination networks found in the main routing table. Therefore, an LSP is created for each entry found in the main routing table. Border Gateway Protocol (BGP) entries are the only exceptions and are covered in the “MPLS Virtual Private Network Technology” module.

An Interior Gateway Protocol (IGP) is used to populate the routing tables in all routers in an MPLS domain. LDP is used to propagate labels for these networks and build LSPs.

LSPs are unidirectional. Each LSP is created over the shortest path, selected by the IGP, toward the destination network. Packets in the opposite direction use a different LSP. The return LSP is usually over the same LSRs, except that packets form the LSP in the opposite order.

Cisco MPLS Traffic Engineering (MPLS TE) can be used to change the default IGP shortest path selection.

Page 86: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-19

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-8

LSP Building

The IP routing protocol determines the path.

Example: IGP Propagates Routing Information

The figure illustrates how an IGP, such as OSPF, IS-IS, or EIGRP, propagates routing information to all routers in an MPLS domain. Each router determines its own shortest path.

LDP, which propagates labels for those networks and routers, adds labels to the FIB and LFIB tables.

Page 87: Implementing cisco mpls

2-20 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

In the figure below, an LSP is created for a particular network. This LSP starts on router A and follows the shortest path, determined by the IGP.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-9

LSP Building (Cont.)

LDP propagates labels to convert the path to an LSP.

Example: LFIB and LIB TablesThe figure shows the contents of LFIB and LIB tables. Frame-mode MPLS uses a liberal label retention mode, which means that each LSR keeps all labels received from LDP peers, even if they are not the downstream peers for network X.

Liberal retention mode is evident after comparing the contents of the LIB and LFIB tables. Only those labels that come from the next-hop router are inserted into the LFIB table.

Note Notice that router G receives a pop label from final destination router I. The pop action

results in the removal of the label rather than swapping labels. This allows the regular IP

packet to be forwarded.

Page 88: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-21

Propagating Labels Using PHP This topic describes the function of PHP.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-10

PHP: Before

• Double lookup is not an optimal way of forwarding labeled packets.

• A label can be removed one hop earlier.

Example: PHP—Before

The figure illustrates how labels are propagated and used in a typical frame-mode MPLS network. The check marks show which tables are used on individual routers. The egress router in this example must do a lookup in the LFIB table to determine whether the label must be removed and if a further lookup in the FIB table is required.

PHP removes the requirement for a double lookup to be performed on egress LSRs.

Page 89: Implementing cisco mpls

2-22 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-11

PHP: After

A label is removed on the router before the last hop within an MPLS domain.

Example: PHP—After

The figure illustrates how a predefined label pop, which corresponds to the pop action in the LFIB, is propagated on the first hop or the last hop, depending on the perspective. The term “pop” means to remove the top label in the MPLS label stack instead of swapping it with the next-hop label. The last router before the egress router therefore removes the top label.

PHP slightly optimizes MPLS performance by eliminating one LFIB lookup.

Page 90: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-23

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-12

PHP

• Penultimate hop popping optimizes MPLS performance(one less LFIB lookup).

• PHP does not work on ATM. (virtual path identifier/virtual channel identifier cannot be removed.)

• The pop or implicit null label uses a reserved value when being advertised to a neighbor.

PHP optimizes MPLS performance by reducing the number of table lookups on the egress router.

Note A pop label is encoded with a value of 3 for LDP or a value of 1 for Tag Distribution Protocol

(TDP). This label instructs upstream routers to remove the label instead of swapping it. What

will be displayed in the LIB table of the router will be “imp-null” rather than the value of 3 or

1.

Page 91: Implementing cisco mpls

2-24 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Is the Impact of IP Aggregation on LSPs? This topic describes the impact that IP aggregation has on LSPs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-13

Impact of IP Aggregation on LSPs

• IP aggregation breaks an LSP into two segments.

• Router C is forwarding packets based on Layer 3 information.

Example: MPLS IP Aggregation Problem

The figure illustrates a potential problem in an MPLS domain.

An IGP propagates the routing information for network 10.1.1.0/24 from router E to other routers in the network. Router C uses a summarization mechanism to stop the proliferation of all subnetworks of network 10.1.0.0/16. Only the summary network 10.1.0.0/16 is sent to routers B and A.

LDP propagates labels concurrently with the IGP. The LSR that is the endpoint of an LSP always propagates the “pop” label.

Router C has both networks in the routing table, as listed here:

10.1.1.0/24 (the original network)

10.1.0.0/16 (the summary)

Router C, therefore, sends a label, 55 in the example, for network 10.1.1.0/24 to router B. Router C also sends a pop label for the new summary network 10.1.0.0/16 that originates on this router. Router B, however, can use the pop label only for the summary network 10.1.0.0/16 because it has no routing information about the more specific network 10.1.1.0/24 because this information was suppressed on router C.

Page 92: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-25

The summarization results in two LSPs for destination network 10.1.1.0/24. The first LSP ends on router C, where a routing lookup is required to assign the packet to the second LSP.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-14

Impact of IP Aggregation on LSPs (Cont.)

• IP aggregation breaks an LSP into two segments.

• Aggregation should not be used where end-to-end LSPs are required, such as with:

– MPLS VPNs

– MPLS TEs

– MPLS-enabled ATM network

– Transit BGP where core routers are not running BGP

Aggregation should also not be used where an end-to-end LSP is required. Typical examples of networks that require end-to-end LSPs are as follows:

An MPLS Virtual Private Network (VPN) backbone

A network that uses MPLS TE

An MPLS-enabled ATM network

A transit BGP autonomous system (AS) where core routers are not running BGP

Page 93: Implementing cisco mpls

2-26 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Allocating Labels in a Frame-Mode MPLS Network

This topic describes how labels are allocated and distributed in a frame-mode MPLS network.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-15

Label Allocation in a Frame-Mode MPLS Network

Label allocation and distribution in a frame-mode MPLS network follows these steps:

• IP routing protocols build the IP routing table.

• Each LSR assigns a label to every destination in the IP routing table independently.

• LSRs announce their assigned labels to all other LSRs.

• Every LSR builds its LIB, LFIB, and FIB data structures based on received labels.

Unicast IP routing and MPLS functionality can be divided into these steps:

Routing information exchange using standard or vendor-specific IP routing protocols (OSPF, IS-IS, EIGRP, and so on)

Generation of local labels (One locally unique label is assigned to each IP destination found in the main routing table and stored in the LIB table.)

Propagation of local labels to adjacent routers, where these labels might be used as next-hop labels (stored in the FIB and LFIB tables to enable label switching)

These data structures contain label information:

The LIB, in the control plane, is the database used by LDP where an IP prefix is assigned a locally significant label that is mapped to a next-hop label that has been learned from a downstream neighbor.

The LFIB, in the data plane, is the database used to forward labeled packets received by the router. Local labels, previously advertised to upstream neighbors, are mapped to next-hop labels, previously received from downstream neighbors.

The FIB, in the data plane, is the database used to forward unlabeled IP packets received by the router. A forwarded packet is labeled if a next-hop label is available for a specific destination IP network. Otherwise, a forwarded packet is not labeled.

Page 94: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-27

Example: Building the FIB Table The figure illustrates that all routers learn about network X via an IGP such as OSPF, IS-IS, or EIGRP.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-16

• IP routing protocols are used to build IP routing tables on all LSRs.

• FIBs are initially built based on IP routing tables with no labeling information.

Label Allocation in a Frame-Mode MPLS Network: Building the IP Forwarding Table

The FIB table on router A contains the entry for network X that is mapped to the IP next-hop address B. At this time, a next-hop label is not available, which means that all packets are forwarded in a traditional fashion (as unlabeled packets).

Page 95: Implementing cisco mpls

2-28 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: Label Allocation

This example illustrates label allocation in a frame-mode MPLS network.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-17

• Every LSR allocates a label for every destination in the IP routing table.

• Labels have local significance.

• Label allocations are asynchronous.

Label Allocation in a Frame-Mode MPLS Network: Allocating Labels

In this example, router B generates a locally significant and locally unique label 25 assigned to IP network X. Router B generates this label independently of other routers (asynchronous allocation of labels).

Note Labels 0 to 15 are reserved. Each LSR independently assigns a local label to each non-BGP

IP prefix in its routing table. Labels are not assigned to BGP routes in the routing table.

Page 96: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-29

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-18

LIB and LFIB structures have to be initialized on the LSR allocating the label.

Label Allocation in a Frame-Mode MPLS Network: LIB and LFIB Setup

When a label is assigned to an IP prefix, it is stored in these two tables:

The LIB table is used to maintain the mapping between the IP prefix (network X), the local label (25), and the next-hop label (not available yet).

The LFIB table is modified to contain the local label mapped to the pop action (label removal). The pop action is used until the next-hop label is received from the downstream neighbor.

Note The FIB table does not yet contain a label for forwarding packets to network X.

Page 97: Implementing cisco mpls

2-30 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-19

• Router A allocates a label for X independently of router B.

Label Allocation in a Frame-Mode MPLS Network: Labels and Table Setup

The FIB, LIB, and LFIB tables are updated similarly on router A after it allocates local label 12 for network X. The tables have specific roles:

The LIB table is used to maintain the mapping between the IP prefix (network X), the local label (12), and the next-hop label (not available yet).

The LFIB table is modified to contain the local label mapped to the pop action (label removal). The pop action is used until the next-hop label is received from the downstream neighbor.

The FIB table does not yet contain a label for forwarding packets to network X.

Page 98: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-31

Distributing and Advertising Labels This topic describes how MPLS labels are distributed and advertised within an MPLS network.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-20

Label Distribution and Advertisement

The allocated label is advertised to all neighbor LSRs, regardless of whether the neighbors are upstream or downstream LSRs for the destination.

Example: Label Distribution and Advertisement

The figure illustrates the next step after a local label has been generated on router B. Router B propagates this label, 25, to all adjacent neighbors where this label can be used as a next-hop label.

Note Because router B cannot predict which routers might use it as the downstream neighbor,

router B sends its local mappings to all LDP neighbors.

Page 99: Implementing cisco mpls

2-32 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-21

Label Distribution and Advertisement: Receiving Label Advertisement

• Every LSR stores the received label in its LIB.

• Edge LSRs that receive the label from their next hop also store the label information in the FIB.

Upon receiving an LDP update, router A can fill in the missing piece in its LIB, LFIB, and FIB tables, as listed here:

Label 25 is stored in the LIB table as the label for network X received from LSR B. (Label 25 is also stored in the LIB tables on routers C and E.)

Label 25 is attached to the IP forwarding entry in the FIB table to enable the MPLS edge functionality (incoming IP packets are forwarded as labeled packets).

The local label in the LFIB table is mapped to outgoing label 25 instead of the pop action (incoming labeled packets can be forwarded as labeled packets).

Page 100: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-33

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-22

Label Distribution and Advertisement: Interim Packet Propagation

Forwarded IP packets are labeled only on the path segments where the labels have already been assigned.

Example: Interim Packet Propagation Through an MPLS Network

The figure shows how an unlabeled IP packet is forwarded based on the information found in the FIB table on router A. Label 25, found in the FIB table, is used to label the packet.

Router B must remove the label because LSR B has not yet received any next-hop label from router C (the action in the LFIB is “pop”).

Note The LFIB on router B is not yet complete.

Router A performs an IP lookup (CEF switching), whereas router B performs a label lookup (label switching) in which the label is removed and a normal IP packet is sent out of router B.

Page 101: Implementing cisco mpls

2-34 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: LDP Update Sent to All Adjacent Routers The figure illustrates how an LDP update, advertising label 47 for network X, from router C is sent to all adjacent routers, including router B.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-23

Label Distribution and Advertisement: Further Label Allocation

Every LSR will eventually assign a label for every destination.

After all routers in an MPLS domain independently distribute their labels as routers A and B did, an LSP tunnel exists for network X spanning from router A to router C.

Note This example discussed only the label allocation and distribution process for one prefix. In

actual practice, the LSRs and edge LSRs would concurrently allocate and distribute labels

for all of the prefixes in their routing table.

Page 102: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-35

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-24

Label Distribution and Advertisement: Receiving Label Advertisement

• Every LSR stores received information in its LIB.

• LSRs that receive their label from their next-hop LSR will also populate the IP forwarding table.

Router B can now map the entry for network X in its FIB, and the local label 25 in its LIB, to the next-hop label 47 received from the downstream neighbor router C.

Page 103: Implementing cisco mpls

2-36 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Populating the LFIB This topic describes how the LFIB table is populated in an MPLS network.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-25

Populating the LFIB

• Router B has already assigned a label to network X and created an entry in the LFIB.

• The outgoing label is inserted in the LFIB after the label is received from the next-hop LSR.

Example: LFIB Population

After router C advertises label 47 to adjacent routers, the LSP tunnel for network X has two hops. The components are as follows:

On router A, network X is mapped to the next-hop label 25 (router B).

On router B, label 25 is mapped to the next-hop label 47 (router C).

Router C still has no next-hop label. Label 47 is therefore mapped to the pop action.

Note In the figure, label distribution is from right to left, and packet forwarding is from left to right.

Page 104: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-37

Propagating Packets Across an MPLS Network This topic describes how IP packets cross an MPLS network.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-26

Packet Propagation Across an MPLS Network

Example: Packet Propagation Through an MPLS Network

The figure illustrates how IP packets are propagated across an MPLS domain. The steps are as follows:

Step 1 Router A labels a packet destined for network X by using the next-hop label 25 (CEF switching by using the FIB table).

Step 2 Router B swaps label 25 with label 47 and forwards the packet to router C (label switching by using the LFIB table).

Step 3 Router C removes the label and forwards the packet to router D (label switching by using the LFIB table).

Page 105: Implementing cisco mpls

2-38 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Detecting Frame-Mode Loops This topic describes how frame-mode loops are detected.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-27

Loop Detection

• LDP relies on loop detection mechanisms built into IGPs that are used to determine the path.

• If, however, a loop is generated (that is, misconfigurationwith static routes), the TTL field in the label header is used to prevent indefinite looping of packets.

• TTL functionality in the label header is equivalent to TTL in the IP headers.

• TTL is usually copied from the IP headers to the label headers (TTL propagation).

Loop detection in an MPLS-enabled network relies on more than one mechanism.

Most routing loops are prevented by the IGP used in the network. MPLS for unicast IP forwarding simply uses the shortest paths determined by the IGP. These paths are typically loop-free.

If, however, a routing loop does occur (for example, because of misconfigured static routes), MPLS labels also contain a time-to-live (TTL) field that prevents packets from looping indefinitely.

The TTL functionality in MPLS is equivalent to that of traditional IP forwarding. Furthermore, when an IP packet is labeled, the TTL value from the IP header is copied into the TTL field in the label. This is called TTL propagation.

Page 106: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-39

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-28

Normal TTL Operation

• Cisco routers have TTL propagation enabled by default.

• On ingress: TTL is copied from IP header to label header.

• On egress: TTL is copied from label header to IP header.

Example: Normal TTL Operation The figure illustrates how the TTL value 5 in the IP header is decreased and copied into the TTL field of the label when a packet enters an MPLS domain.

All other LSRs decrease the TTL field only in the label. The original TTL field is not changed until the last label is removed when the label TTL is copied back into the IP TTL.

TTL propagation provides a transparent extension of IP TTL functionality into an MPLS-enabled network.

Page 107: Implementing cisco mpls

2-40 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-29

Labeled packets are dropped when the TTL is decreased to 0.

TTL and Loop Detection

Example: TTL and Loop Detection The figure illustrates a routing loop between routers B and C. The packet looping between these two routers is eventually dropped because the value of its TTL field reaches 0.

Page 108: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-41

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-30

Disabling TTL Propagation

• TTL propagation can be disabled.

• The IP TTL value is not copied into the TTL field of the label, and the label TTL is not copied back into the IP TTL.

• Instead, the value 255 is assigned to the label header TTL field on the ingress LSR.

• Disabling TTL propagation hides core routers in the MPLS domain.

• Traceroute across an MPLS domain does not show any core routers.

TTL propagation can be disabled to hide the core routers from the end users. Disabling TTL propagation causes routers to set the value 255 into the TTL field of the label when an IP packet is labeled.

The network is still protected against indefinite loops, but it is unlikely that the core routers will ever have to send an Internet Control Message Protocol (ICMP) reply to user-originated traceroute packets.

Page 109: Implementing cisco mpls

2-42 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-31

Traceroute with Disabled TTL Propagation

• The first traceroute packet (ICMP or UDP) that reaches the network is dropped on router A.

• An ICMP TTL exceeded message is sent to the source from router A.

Example: Traceroute with Disabled TTL Propagation These figures illustrate the result of a traceroute across an MPLS network that does not use TTL propagation.

The first traceroute packet—ICMP or User Datagram Protocol (UDP)—that reaches the MPLS network is dropped on the first router (A), and an ICMP reply is sent to the source. This action results in an identification of router A by the traceroute application.

Page 110: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-43

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-32

Traceroute with Disabled TTL Propagation (Cont.)

• The second traceroute packet that reaches the network is dropped on router D.

• An ICMP TTL exceeded message is sent to the source from router D.

The traceroute application increases the initial TTL for every packet that it sends. The second packet, therefore, would be able to reach one hop farther (router B in the example). However, the TTL value is not copied into the TTL field of the label. Instead, router A sets the TTL field of the label to 255. Router B decreases the TTL of the label, and router C removes the label without copying it back into the IP TTL. Router D then decreases the original IP TTL, drops the packet because the TTL has reached zero, and sends an ICMP reply to the source.

The traceroute application has identified router D. The next packets would simply pass through the network.

The final result is that a traceroute application was able to identify the edge LSRs, but not the core LSRs.

Page 111: Implementing cisco mpls

2-44 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-33

Impact of Disabling TTL Propagation

• Traceroute across an MPLS domain does not show core routers.

• TTL propagation has to be disabled on all label switch routers.

• Mixed configurations (some LSRs with TTL propagation enabled and some with TTL propagation disabled) could result in faulty traceroute output.

• TTL propagation can be enabled for forwarded traffic only—traceroute from LSRs does not use the initial TTL value of 255.

Cisco routers have TTL propagation enabled by default.

If TTL propagation is disabled, it must be disabled on all routers in an MPLS domain to prevent unexpected behavior.

TTL can be optionally disabled for forwarded traffic only, which allows administrators to use traceroute from routers to troubleshoot problems in the network.

Page 112: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-45

Allocating Per-Platform Labels This topic describes the approaches for assigning labels to networks.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-34

Per-Platform Label Allocation

• An LFIB on a router usually does not contain an incoming interface.

• The same label can be used on any interface—per-platform label allocation.

• LSR announces a label to an adjacent LSR only once, even if there are parallel links between them.

Here are the two possible approaches for assigning labels to networks:

Per-platform label allocation: One label is assigned to a destination network and announced to all neighbors. The label must be locally unique and valid on all incoming interfaces. This is the default operation in frame-mode MPLS.

Per-interface label allocation: Local labels are assigned to IP destination prefixes on a per-interface basis. These labels must be unique on a per-interface basis.

Example: Per-Platform Label Allocation The figure illustrates how one label (25) is assigned to a network and used on all interfaces. The same label is propagated to both routers A and C.

The figure also shows how one label is sent across one LDP session between routers A and B even though there are two parallel links between the two routers.

Page 113: Implementing cisco mpls

2-46 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-35

Per-Platform Label Allocation: Benefits andDrawbacks of Per-Platform Label Allocation

Benefits:

• Smaller LFIB

• Faster label exchange

Drawback:

• Insecure: Any neighbor LSR can send packets with any label in the LFIB.

A potential drawback of per-platform label allocation is illustrated in the figure, which shows how an adjacent router can send a labeled packet with a label that has not been previously advertised to this router (label spoofing). If label switching has not been enabled on that interface, the packet will be discarded. If label switching has been enabled on this interface, the packet would be forwarded, causing a possible security issue.

On the other hand, per-platform label allocation results in smaller LIB and LFIB tables and a faster exchange of labels.

Page 114: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-47

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-36

Summary

• Labels are propagated across a network either by extending the functionality of existing routing protocols or by creating a new protocol that is dedicated to exchanging labels.

• An LSP is a sequence of LSRs that forward labeled packets of a certain forwarding equivalence class.

• Penultimate hop popping optimizes MPLS performance (one less LFIB lookup).

• IP aggregation can break an LSP into two segments.

• Every LSR assigns a label for every destination in the IP routing table.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-37

Summary (Cont.)

• Although labels are locally significant, they have to be advertised to directly reachable peers.

• Outgoing labels are inserted in the LFIB after the label is received from the next-hop LSR.

• Packets are forwarded using labels from the LFIB table rather than the IP routing table.

• If TTL propagation is disabled, traceroute across an MPLS domain does not show core routers.

• LSR announces a label to an adjacent LSR only once, even if there are parallel links between them.

Page 115: Implementing cisco mpls

2-48 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 116: Implementing cisco mpls

Lesson 3

Introducing Convergence in Frame-Mode MPLS

OverviewThis lesson presents Label Distribution Protocol (LDP) convergence issues and describes how routing protocols and Multiprotocol Label Switching (MPLS) convergence interact. This lesson concludes with a look at link failure, convergence after a link failure, and link recovery.

It is important to understand the convergence times for LDP. It also is important to understand how routing protocols interact with MPLS. This information will ensure a clear understanding of how the various routing tables are built and refreshed during and after a link failure and how recovery in an MPLS network takes place.

ObjectivesUpon completing this lesson, you will be able to describe how convergence occurs in a frame-mode MPLS network. This ability includes being able to meet these objectives:

Describe the MPLS steady-state environment

Describe what happens in the routing tables when a link failure occurs

Describe routing protocol convergence after a link failure

Describe frame-mode MPLS convergence after a link failure

Describe IP and MPLS convergence actions after a link failure has been resolved

Page 117: Implementing cisco mpls

2-50 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Is the MPLS Steady-State Operation? This topic describes an MPLS network steady-state operation.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-3

Steady-State Operation Description

• Occurs after the LSRs have exchanged the labels, and the LIB, LFIB, and FIB data structures are completely populated

MPLS is fully functional when the Interior Gateway Protocol (IGP) and LDP have populated all the tables, as listed here:

Main IP routing (routing information base [RIB]) table

Label Information Base (LIB) table

Forwarding Information Base (FIB) table

Label forwarding information base (LFIB) table

Although it takes longer for LDP to exchange labels (compared with an IGP), a network can use the FIB table in the meantime; therefore, there is no routing downtime while LDP exchanges labels between adjacent LSRs.

Page 118: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-51

What Happens in a Link Failure? This topic describes what happens in the routing tables when a link failure occurs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-4

Link Failure Actions

• Routing protocol neighbors and LDP neighbors are lost after a link failure.

• Entries are removed from various data structures.

Example: Link Failure Actions The figure illustrates how a link failure is handled in an MPLS domain. The steps are as follows:

The overall convergence fully depends on the convergence of the IGP used in the MPLS domain.

When router B determines that router E should be used to reach network X, the label learned from router E can be used to label-switch packets.

LDP stores all labels in the LIB table, even if the labels are not used, because the IGP has decided to use another path.

This label storage is shown in the figure, where two next-hop labels were available in the LIB table on router B. The label status of router B just before MPLS label convergence is as follows:

Label 47 was learned from router C and is currently unavailable; therefore, because of the failure, label 47 has to be removed from the LIB table.

Label 75 was learned from router E and can now be used at the moment that the IGP decides that router E is the next hop for network X.

Page 119: Implementing cisco mpls

2-52 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Is the Routing Protocol Convergence After a Link Failure?

This topic describes the routing protocol convergence that occurs in an MPLS network after a link failure.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-5

Routing Protocol Convergence

• Routing protocols rebuild the IP routing table and the IP forwarding table.

Example: Routing Protocol Convergence

The figure illustrates how two entries are removed, one from the LIB table and one from the LFIB table, when the link between routers B and C fails. This can be described as follows:

Router B has already removed the entry from the FIB table, once the IGP determined that the next hop was no longer reachable.

Router B has also removed the entry from the LIB table and the LFIB table given that the LDP has determined that router C is no longer reachable.

Page 120: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-53

What Is the MPLS Convergence After a Link Failure?

This topic describes MPLS convergence that occurs in an MPLS network after a link failure.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-6

MPLS Convergence

• The LFIB and labeling information in the FIB are rebuilt immediately after the routing protocol convergence, based on labels stored in the LIB.

After the IGP determines that there is another path available, a new entry is created in the FIB table.

This new entry points toward router E, and there is already a label available for network X via router E.

This information is then used in the FIB table and the LFIB table to reroute the LSP tunnel via router E.

Page 121: Implementing cisco mpls

2-54 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-7

MPLS Convergence After a Link Failure

• MPLS convergence in frame-mode MPLS does not affect the overall convergence time.

• MPLS convergence occurs immediately after the routing protocol convergence, based on labels already stored in the LIB.

The overall convergence in an MPLS network is not affected by LDP convergence when there is a link failure.

Frame-mode MPLS uses liberal label retention mode, which enables routers to store all received labels, even if the labels are not being used.

These labels can be used, after the network convergence, to enable immediate establishment of an alternative LSP tunnel.

Page 122: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-55

What Actions Occur in Link Recovery? This topic describes actions in IP and MPLS convergence after a failure has been resolved.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-8

Link Recovery Actions

• Routing protocol neighbors are discovered after link recovery.

Example: Link Recovery Actions

The figure illustrates the state of the routing tables at the time the link between routers B and C becomes available again.

Page 123: Implementing cisco mpls

2-56 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-9

Link Recovery Actions: IP Routing Convergence

• IP routing protocols rebuild the IP routing table.

• The FIB and the LFIB are also rebuilt, but the label informationmight be lacking.

The IGP determines that the link is available again and changes the next-hop address for network X to point to router C. However, when router B also tries to set the next-hop label for network X, it has to wait for the LDP session between routers B and C to be reestablished.

A pop action is used in the LFIB table on router B while the LDP establishes the session between routers B and C. This process adds to the overall convergence time in an MPLS domain. The downtime for network X is not influenced by LDP convergence because normal IP forwarding is used until the new next-hop label is available.

Note Although this behavior has no significant effect on traditional IP routing, it can significantly

influence MPLS Virtual Private Networks (VPNs). This is because the VPN traffic cannot be

forwarded before the LDP session is fully operational.

Page 124: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-57

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-10

Link Recovery Actions:MPLS Convergence

• Routing protocol convergence optimizes the forwarding path after a link recovery.

• The LIB might not contain the label from the new next hop by the time the IGP convergence is complete.

• End-to-end MPLS connectivity might be intermittently broken after link recovery.

• Use MPLS TE for make-before-break recovery.

Link recovery requires that an LDP session be established (reestablished), which adds to the convergence time of LDP.

Networks may be temporarily unreachable because of the convergence limitations of routing protocols.

Cisco MPLS Traffic Engineering (MPLS TE) can be used to prevent longer downtime when a link fails or is recovering.

Page 125: Implementing cisco mpls

2-58 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-11

Summary

• MPLS is fully functional when the LIB, LFIB, and FIB tables are populated.

• Overall network convergence is dependent upon the IGP.

• Upon a link failure, entries are removed from several routing tables.

• MPLS convergence after link failure in a frame-mode network does not affect overall convergence time.

• MPLS data structures after link failure may not contain updated data by the time the IGP convergence is complete.

Page 126: Implementing cisco mpls

Lesson 4

Introducing MPLS Label Allocation, Distribution, and Retention Modes

OverviewIn this lesson, label distribution parameters are discussed. The differences between label distribution parameters are covered, and the default Cisco parameter sets are identified.

There are different modes of operation for Multiprotocol Label Switchingt (MPLS). It is important to have a clear idea of what mode of operation is used under what condition, and if some situations will allow for multiple combinations of these modes.

ObjectivesUpon completing this lesson, you will be able to describe the MPLS label allocation, distribution, and retention modes used in Cisco MPLS networks. This ability includes being able to meet these objectives:

Describe the parameters used in Cisco MPLS label distribution and allocation

Describe the way in which labels are distributed to neighbors in frame-mode MPLS

Describe the way in which labels are allocated to neighbors in frame-mode MPLS

Describe the way in which labels are retained in frame-mode MPLS

Page 127: Implementing cisco mpls

2-60 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Label Distribution Parameters This topic describes the parameters used in frame-mode MPLS label distribution and allocation.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-3

Label Distribution Parameters

Frame-mode MPLS architecture defines several label allocation and distribution parameters:

• Per-platform label space

• Unsolicited downstream label distribution

• Independent label allocation control

• Liberal label retention

Frame-mode MPLS parameters include:

Per-platform label space, where labels must be unique for the entire platform (router)

Note Per-platform label space was discussed in the “Introducing Convergence in Frame-Mode

MPLS” lesson.

Unsolicited downstream distribution of labels, where all routers can asynchronously generate local labels and propagate those labels to adjacent routers

Independent control mode, where all routers can start propagating labels independently of one another

Liberal label retention mode, where unused labels are kept (This applies because multiple labels may be received for a prefix, but only one is used.)

Page 128: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-61

Distributing Labels This topic describes the way in which labels are distributed to neighbors in frame-mode MPLS.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-4

Label Distribution: Unsolicited Downstream

• The label for a prefix is allocated and advertised to all neighbor LSRs, regardless of whether the neighbors are upstream or downstream LSRs for the destination.

Unsolicited downstream distribution of labels is a method where each router independently assigns a label to each destination IP prefix in its routing table. This mapping is stored in the Label Information Base (LIB) table, which sends it to all Label Distribution Protocol (LDP) peers. There is no control mechanism to govern the propagation of labels in an ordered fashion.

Example: Unsolicited Downstream The figure illustrates how router B creates a local label (25) and sends that label to all its neighbors. The same action is taken on other routers after the Interior Gateway Protocol (IGP) has put network X into the main routing table.

Each neighbor then decides upon one of these options regarding the label:

Use the label (if router B is the closest next hop for network X)

Keep the label in the LIB table

Ignore the label

Page 129: Implementing cisco mpls

2-62 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Allocating Labels This topic describes independent control to allocate labels to neighbors in frame-mode MPLS.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-5

Label Allocation: Independent Control

• An LSR can always assign a label for a prefix, even if it has nodownstream label.

• Independent control can be used only for LSRs with Layer 3 capabilities.

Independent control mode for allocating labels is usually combined with unsolicited downstream propagation of labels, where labels can be created and propagated independently of any other label switch router (LSR). When independent control mode is used, an LSR might be faced with an incoming labeled packet where there is no corresponding outgoing label in the label forwarding information base (LFIB) table. An LSR using independent control mode must therefore be able to perform full Layer 3 lookups. Independent control mode can be used only on LSRs with edge LSR functionality.

Page 130: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-63

Retaining Labels This topic describes the liberal label retention mode used in frame-mode MPLS.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-6

Label Retention: Liberal Retention Mode

• Each LSR stores the received label in its LIB, even when the label is not received from a next-hop LSR.

• Liberal label retention mode improves convergence speed.

Liberal label retention mode dictates that each LSR keep all labels received from LDP peers, even if they are not the downstream peers for network X.

Example: Liberal Retention Mode The figure shows how router C receives and keeps the label received from router B for network X, even though router D is the downstream peer.

Page 131: Implementing cisco mpls

2-64 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-7

Summary

• There are four MPLS label distribution parameters: label space, label distribution, label allocation, and label retention.

• Frame-mode MPLS distributes labels using downstream unsolicited label distribution

• Frame-mode MPLS allocates labels to neighbors using independent control

• Frame-mode MPLS uses liberal label retention

Page 132: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-65

Module Summary This topic summarizes the key points that were discussed in this module.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-1

Module Summary

• LDP uses multicast UDP for neighbor discovery and unicastTCP for session establishment

• LDP is used for label distribution

• Overall network convergence is dependent on the IGP, not the MPLS convergence

• Frame-mode MPLS parameters include:

– Per-platform label address space

– Unsolicited downstream label distribution

– Indepedent control for label allocation

– Liberal label retention

In a Multiprotocol Label Switching (MPLS) network, labels are distributed by Label Distribution Protocol (LDP) after neighbor discovery and session establishment. Label information is populated in Label Information Base (LIB), Forwarding Information Base (FIB), and label forwarding information base (LFIB) tables.

ReferencesFor additional information, refer to these resources:

RFC 3031, Multiprotocol Label Switching Architecture http://www.ietf.org/rfc/rfc3031.txt

RFC 3036, LDP Specification http://www.ietf.org/rfc/rfc3036.txt

Page 133: Implementing cisco mpls

2-66 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Module Self-Check Use the questions here to review what you learned in this module. The correct answers and solutions are found in the Module Self-Check Answer Key.

Q1) Which multicast address does LDP use to send hello messages? (Source: Discovering

LDP Neighbors)

A) 224.0.0.1 B) 224.0.0.2 C) 224.0.0.12 D) 224.0.20.0

Q2) What does per-platform label space require? (Source: Discovering LDP Neighbors)

A) only one LDP session B) one session per interface C) multiple sessions for parallel links D) “Per-platform” is not a proper term in MPLS terminology.

Q3) What is the purpose of the LDP identifier in a hello message? (Source: Discovering

LDP Neighbors)

A) contains the source address B) contains the multicast address C) contains the TCP destination port D) uniquely identifies the neighbor and the label space

Q4) LDP sessions are initiated by using which address? (Source: Discovering LDP

Neighbors)

A) the highest IP address B) the loopback address C) the lowest IP address D) whichever LDP neighbor sends the fist hello message

Q5) Exchanging initialization messages is which step in the LDP session negotiation

process? (Source: Discovering LDP Neighbors)

A) first step B) second step C) third step D) not required in LDP session negotiation

Q6) LDP discovers nonadjacent neighbors by broadcasting _____ IP addresses. (Source:

Discovering LDP Neighbors)

Q7) LDP and TDP use which two well-known port numbers? (Choose two.) (Source:

Discovering LDP Neighbors)

A) LDP uses 464. B) LDP uses 646. C) LDP uses 711. D) TDP uses 171. E) TDP uses 646. F) TDP uses 711.

Page 134: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-67

Q8) In frame-mode MPLS networks, the number of LDP sessions that are required between

neighbors is determined by which of these choices? (Source: Discovering LDP

Neighbors)

A) the number of interfaces B) the number of different label spaces C) the number of LDP processes running a router D) the information contained in the source address field of the hello message

response

Q9) Which statement best describes PHP? (Source: Introducing Typical Label Distribution

in Frame-Mode MPLS)

A) PHP works only for TDP and not for LDP. B) PHP works only for LDP and not for TDP. C) PHP optimizes MPLS performance. D) PHP is configurable and by default is disabled.

Q10) Which description applies to per-platform label allocation? (Source: Introducing

Typical Label Distribution in Frame-Mode MPLS)

A) default operation for frame-mode MPLS B) an approach that results in larger LIB and LFIB tables C) an approach that results in slower label exchange D) a future enhancement for MPLS

Q11) Which three of the answer choices are contained in the LFIB? (Choose three.) (Source:

Introducing Typical Label Distribution in Frame-Mode MPLS)

A) local generated label B) outgoing label C) local address D) next-hop address

Q12) When an IP packet is to be label-switched as it traverses an MPLS network, which

table is used to perform the label switching? (Source: Introducing Typical Label

Distribution in Frame-Mode MPLS)

A) LIBB) FIBC) FLIBD) LFIB

Q13) Which statement is correct? (Source: Introducing Typical Label Distribution in Frame-

Mode MPLS)

A) An IP forwarding table resides on the data plane; LDP (or TDP) runs on the control plane; and an IP routing table resides on the data plane.

B) An IP forwarding table resides on the data plane; LDP (or TDP) runs on the control plane; and an IP routing table resides on the control plane.

C) An IP forwarding table resides on the control plane; LDP (or TDP) runs on the control plane; and an IP routing table resides on the data plane.

D) An IP forwarding table resides on the control plane; LDP (or TDP) runs on the control plane; and an IP routing table resides on the control plane.

Page 135: Implementing cisco mpls

2-68 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q14) Which two tables contain label information? (Choose two.) (Source: Introducing

Typical Label Distribution in Frame-Mode MPLS)

A) LIBB) main IP routing table C) FLIBD) LFIB

Q15) What generates a label update? (Source: Introducing Typical Label Distribution in

Frame-Mode MPLS)

A) UDPB) OSPFC) EIGRPD) LDP

Q16) Which two statements are correct? (Choose two.) (Source: Introducing Typical Label

Distribution in Frame-Mode MPLS)

A) LSPs are bidirectional. B) LSPs are unidirectional. C) LDP advertises labels for the entire LSP. D) LDP advertises labels only for individual segments in the LSP.

Q17) Which statement is correct regarding TTL propagation being disabled? (Source:

Introducing Typical Label Distribution in Frame-Mode MPLS)

A) The label TTL is copied back into the IP TTL. B) The IP TTL is copied back into the TTL of the label. C) The IP TL is not copied back into the TTL of the label. D) TTL label propagation can not be disabled.

Q18) What enables routers in a frame-mode MPLS network to store all received labels, even

if they are not being used? (Source: Introducing Convergence in Frame-Mode MPLS)

A) keep-all-labels mode B) liberal label max-all mode C) liberal label retention mode D) A router in a frame-mode network does not keep all labels; the router keeps

only the labels that it will use.

Q19) Which table is NOT used to determine if MPLS is fully functional? (Source:

Introducing Convergence in Frame-Mode MPLS)

A) LIBB) LFIBC) FIBD) FLIB

Q20) Upon a link failure, which three tables are updated to reflect the failed link? (Choose

three.) (Source: Introducing Convergence in Frame-Mode MPLS)

A) LIBB) LFIBC) FIBD) FLIB

Page 136: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-69

Q21) Which statement best describes how a link failure is handled in an MPLS network?

(Source: Introducing Convergence in Frame-Mode MPLS)

A) Overall convergence depends on LDP. B) Overall convergence depends on the IGP that is used. C) Upon a link failure, only LDP convergence is affected. D) Upon a link failure, only the IGP convergence is affected.

Q22) Upon a link recovery, which three tables are updated to reflect the failed link? (Choose

three.) (Source: Introducing Convergence in Frame-Mode MPLS)

A) LFIBB) FLIBC) FIBD) LIB

Q23) Which of the following statements best describes convergence in a frame-mode MPLS

network after a link failure has occurred and been restored? (Source: Introducing

Convergence in Frame-Mode MPLS)

A) MPLS convergence occurs after IGP convergence. B) MPLS convergence occurs before IGP convergence peer to peer. C) If a failure occurs with the IGP, MPLS convergence is not affected. D) If a failure occurs with the IGP, MPLS will not be able to converge after the

IGP failure has been corrected unless the MPLS process is bounced.

Q24) Which statement is NOT a label distribution parameter? (Source: Introducing MPLS

Label Allocation, Distribution, and Retention Modes)

A) label space B) label quality C) label retention D) label allocation and distribution

Q25) Frame-mode MPLS uses ________ label space. (Source: Introducing MPLS Label

Allocation, Distribution, and Retention Modes)

Q26) Which type of label distribution is used in Cisco frame-mode MPLS networks?

(Choose one.) (Source: Introducing MPLS Label Allocation, Distribution, and

Retention Modes)

A) downstream-on-demand B) unsolicited downstream C) solicited downstream D) unsolicited downstream-on-demand

Q27) The mode of label allocation for frame-mode MPLS is ________ control. (Source:

Introducing MPLS Label Allocation, Distribution, and Retention Modes)

Q28) What is the label retention mode used in Cisco frame-mode MPLS networks? (Source:

Introducing MPLS Label Allocation, Distribution, and Retention Modes)

A) totalB) lightC) liberalD) conservative

Page 137: Implementing cisco mpls

2-70 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q29) Which statement is correct? (Source: Introducing MPLS Label Allocation, Distribution,

and Retention Modes)

A) By default, routers with frame interfaces use per-platform label space. B) By default, ATM switches use per-platform label space. C) By default, routers with ATM interfaces use per-platform label space and

conservative label retention mode. D) By default, routers with frame interfaces use conservative label retention mode.

Page 138: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Label Assignment and Distribution 2-71

Module Self-Check Answer Key Q1) B

Q2) A

Q3) D

Q4) A

Q5) B

Q6) unicast

Q7) B, F

Q8) B

Q9) C

Q10) A

Q11) A, B, D

Q12) D

Q13) B

Q14) A, D

Q15) D

Q16) B, D

Q17) C

Q18) C

Q19) D

Q20) A, B, C

Q21) B

Q22) A, C, D

Q23) A

Q24) B

Q25) per-platform

Q26) B

Q27) independent

Q28) C

Q29) A

Page 139: Implementing cisco mpls

2-72 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 140: Implementing cisco mpls

Module 3

Frame-Mode MPLS Implementation on Cisco IOS Platforms

OverviewThis module provides a review of switching implementations, focusing on Cisco Express Forwarding (CEF). The module also covers the details of implementing frame-mode Multiprotocol Label Switching (MPLS) on Cisco IOS platforms, giving detailed configuration, monitoring, and debugging guidelines. In addition, this module includes the advanced topics of controlling time-to-live (TTL) propagation and label distribution.

Module Objectives Upon completing this module, you will be able to describe the tasks and commands necessary to implement MPLS on frame-mode Cisco IOS platforms. This ability includes being able to meet these objectives:

Explain the features of CEF switching

Configure frame-mode MPLS on Cisco IOS platforms

Monitor frame-mode MPLS on Cisco IOS platforms

Troubleshoot frame-mode MPLS problems on Cisco IOS platforms

Page 141: Implementing cisco mpls

3-2 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 142: Implementing cisco mpls

Lesson 1

Introducing CEF Switching

OverviewThis lesson explains the Cisco IOS platform-switching mechanisms by reviewing standard IP switching and Cisco Express Forwarding (CEF) switching, including configuration and monitoring commands.

It is important to understand what part CEF switching plays in a Multiprotocol Label Switching (MPLS) network. CEF must be running as a prerequisite to implementing MPLS on a Cisco router; therefore, an understanding of the purpose of CEF and how it functions will provide an awareness of how the network uses CEF information when forwarding packets.

ObjectivesUpon completing this lesson, you will be able to describe the features of CEF switching. This ability includes being able to meet these objectives:

Describe the various switching mechanisms used by Cisco IOS platforms

Describe the function of standard IP switching on Cisco IOS platforms

Describe the architecture of CEF switching

Configure IP CEF switching

Monitor IP CEF switching

Page 143: Implementing cisco mpls

3-4 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are Cisco IOS Platform-Switching Mechanisms?

This topic describes the various switching mechanisms used by Cisco IOS platforms.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-3

The Cisco IOS platform supports three IP switchingmechanisms:

• Routing table driven switching—process switching

– Full lookup for every packet

• Cache driven switching—fast switching

– Most recent destinations entered in the cache

– First packet always process-switched

• Topology driven switching

– CEF (prebuilt FIB table)

Cisco IOS Platform Switching Mechanisms

The first and the oldest switching mechanism available in Cisco routers is process switching. Because process switching must find a destination in the routing table (possibly a recursive lookup) and construct a new Layer 2 frame header for every packet, it is very slow and is normally not used.

To overcome the slow performance of process switching, Cisco IOS platforms support several switching mechanisms that use a cache to store the most recently used destinations. The cache uses a faster searching mechanism, and it stores the entire Layer 2 frame header to improve the encapsulation performance. The first packet whose destination is not found in the fast-switching cache is process-switched, and an entry is created in the cache. The subsequent packets are switched in the interrupt code using the cache to improve performance.

The latest and preferred Cisco IOS platform-switching mechanism is CEF, which incorporates the best of the previous switching mechanisms. CEF supports per-packet load balancing (previously supported only by process switching), per-source or per-destination load balancing, fast destination lookup, and many other features not supported by other switching mechanisms.

The CEF cache, or Forwarding Information Base (FIB) table, is essentially a replacement for the standard routing table.

Page 144: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-5

Using Standard IP Switching This topic describes the function of standard IP switching on Cisco IOS platforms.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-4

Standard IP Switching Review

There is a specific sequence of events that occurs when process switching and fast switching are used for destinations learned through Border Gateway Protocol (BGP).

Example: Standard IP Switching The figure illustrates this process. Here is a description of the sequence of events:

When a BGP update is received and processed, an entry is created in the routing table.

When the first packet arrives for this destination, the router tries to find the destination in the fast-switching cache. Because the destination is not in the fast-switching cache, process switching has to switch the packet when the process is run. The process performs a recursive lookup to find the outgoing interface. The process switching may possibly trigger an Address Resolution Protocol (ARP) request or find the Layer 2 address in the ARP cache. Finally, it creates an entry in the fast-switching cache.

All subsequent packets for the same destination are fast-switched, as follows:

— The switching occurs in the interrupt code (the packet is processed immediately).

— Fast destination lookup is performed (no recursion).

— The encapsulation uses a pregenerated Layer 2 header that contains the destination and Layer 2 source (MAC) address. (No ARP request or ARP cache lookup is necessary.)

Whenever a router receives a packet that should be fast-switched but the destination is not in the switching cache, the packet is process-switched. A full routing table lookup is performed, and an entry in the fast-switching cache is created to ensure that the subsequent packets for the same destination prefix will be fast-switched.

Page 145: Implementing cisco mpls

3-6 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Is the CEF Switching Architecture? This topic describes the architecture of CEF switching.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-5

CEF Switching Review

CEF uses a different architecture from process switching or any other cache-based switching mechanism. CEF uses a complete IP switching table, the FIB table, which holds the same information as the IP routing table. The generation of entries in the FIB table is not packet-triggered but change-triggered. When something changes in the IP routing table, the change is also reflected in the FIB table.

Because the FIB table contains the complete IP switching table, the router can make definitive decisions based on the information in it. Whenever a router receives a packet that should be CEF-switched, but the destination is not in the FIB, the packet is dropped.

The FIB table is also different from other fast-switching caches in that it does not contain information about the outgoing interface and the corresponding Layer 2 header. That information is stored in a separate table, the adjacency table. The adjacency table is more or less a copy of the ARP cache, but instead of holding only the destination MAC address, it holds the Layer 2 header.

Note If the router carries full Internet routing, enabling CEF may consume additional memory.

Enabling distributed CEF will also affect memory utilization on Versatile Interface Processor

(VIP) modules (Cisco 7500 Series Routers) or line cards (Cisco 12000 Series Internet

Routers), because the entire FIB table will be copied to all VIP modules or line cards.

Page 146: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-7

Configuring IP CEF This topic describes how to configure CEF on Cisco IOS platforms.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-6

·° ˝»ş ĹĽ·­¬®·ľ«¬»ĽĂ

᫬»®ř˝±˛ş·ą÷ý

Configuring IP CEF

˛± ·° ®±«¬»ó˝ż˝¸» ˝»ş

᫬»®ř˝±˛ş·ąó·ş÷ý

• Disables CEF switching on an interface

• Usually not needed

• This command starts CEF switching and creates the FIB table.

• The distributed keyword configures distributed CEF (running on VIP or line cards).

• All CEF-capable interfaces run CEF switching.

ip cefTo enable CEF on the route processor card, use the ip cef global command in global configuration mode. To disable CEF, use the no form of this command. Use the appropriate form of the command:

ip cef [distributed]

no ip cef [distributed]

Syntax Description distributed (optional): Enables the distributed CEF operation. This option distributes the CEF information to the line cards. The line cards perform express forwarding.

CEF is disabled by default, excluding these platforms:

CEF is enabled on Cisco 7100 Series Routers.

CEF is enabled on Cisco 7200 Series Routers.

CEF is enabled on Cisco 7500 Series Routers.

CEF is enabled on Cisco 7600 Series Routers, and distributed CEF is enabled on some Cisco 7600 Series Line Cards.

Distributed CEF is enabled on Cisco 12000 Series Internet Routers.

Page 147: Implementing cisco mpls

3-8 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

ip route-cache cef To enable CEF operation on an interface after the CEF operation has been disabled, use the iproute-cache cef command in interface configuration mode. To disable CEF operation on an interface, use the no form of this command. Use the form that follows of the two commands:

ip route-cache cef

no ip route-cache cef

Syntax Description This command has no arguments or keywords.

Defaults When standard CEF or distributed CEF operations are enabled globally, all interfaces that support CEF are enabled by default.

Page 148: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-9

Monitoring IP CEF This topic describes how to monitor CEF on Cisco IOS platforms.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-7

Monitoring IP CEF

᫬»®ý­¸±© ·° ˝»ş Ľ»¬ż·´×Đ ÝŰÚ ©·¬¸ ­©·¬˝¸·˛ą řĚżľ´» Ę»®­·±˛ ę÷ô ş´żą­ăđ¨đ

ę ®±«¬»­ô đ ®»®»­±´Ş»ô 𠫲®»­±´Ş»Ľ řđ ±´Ľô 𠲻©÷ç ´»żŞ»­ô ďď ˛±Ľ»­ô ďîëëę ľ§¬»­ô ç ·˛­»®¬­ô đ ·˛Şż´·Ľż¬·±˛­đ ´±żĽ ­¸ż®·˛ą »´»ł»˛¬­ô 𠾧¬»­ô đ ®»ş»®»˛˝»­î ÝŰÚ ®»­»¬­ô đ ®»Ş·­·±˛­ ±ş »¨·­¬·˛ą ´»żŞ»­®»ş˝±«˛¬­ć ëěí ´»żşô ëěě ˛±Ľ»

߼¶ż˝»˛˝§ Ěżľ´» ¸ż­ ě żĽ¶ż˝»˛˝·»­đňđňđňđńíîô Ş»®­·±˛ đô ®»˝»·Ş»ďçîňďęčňíňďńíîô Ş»®­·±˛ íô ˝ż˝¸»Ľ żĽ¶ż˝»˛˝§ ¬± Í»®·ż´đńđňďđđ °ż˝µ»¬­ô 𠾧¬»­

¬żą ·˛ş±®łż¬·±˛ ­»¬´±˝ż´ ¬żąć îčşż­¬ ¬żą ®»©®·¬» ©·¬¸ Í»đńđňďđô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć ĄîčŁ

Ş·ż ďçîňďęčňíňďđô Í»®·ż´đńđňďđô đ Ľ»°»˛Ľ»˛˝·»­˛»¨¬ ¸±° ďçîňďęčňíňďđô Í»®·ż´đńđňď𪿴·Ľ ˝ż˝¸»Ľ żĽ¶ż˝»˛˝§¬żą ®»©®·¬» ©·¬¸ Í»đńđňďđô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć ĄîčŁ

᫬»®ý­¸±© ·° ˝»ş Ľ»¬ż·´

show ip cef To display unresolved entries in the FIB table or to display a summary of the FIB, use this form of the show ip cef EXEC command: show ip cef [unresolved | summary].

To display specific entries in the FIB table based on IP address information, use this form of the show ip cef command in EXEC mode: show ip cef [network [mask [longer-prefix]]] [detail].

To display specific entries in the FIB table based on interface information, use this form of the show ip cef command in EXEC mode: show ip cef [type number] [detail].

Page 149: Implementing cisco mpls

3-10 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

The table describes the parameters for the show ip cef command.

show ip cef Syntax Description

Parameter Description

«˛®»­±´Ş»Ľ (Optional) Displays unresolved FIB entries

­«łłż®§ (Optional) Displays a summary of the FIB

˛»¬©±®µ (Optional) Displays the FIB entry for the specified destination network

łż­µ (Optional) Displays the FIB entry for the specified destination network and mask

´±˛ą»®ó°®»ş·¨ (Optional) Displays the FIB entries for all the specific destinations

Ľ»¬ż·´ (Optional) Displays detailed FIB entry information

¬§°» ˛«łľ»® (Optional) Interface type and number for which to display FIB entries

Page 150: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-11

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-8

Summary

• Three different switching mechanisms are used on Cisco IOS platforms: routing table driven, cache driven, and topology driven.

• Entries received with no destination address information are process-switched; subsequent packets are fast-switched.

• Generation of entries in the FIB table is caused by a change trigger; when something in the routing table changes, the change is also reflected in the FIB table.

• CEF is configured globally.

• The show ip cef command is used to monitor CEF operation.

Page 151: Implementing cisco mpls

3-12 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 152: Implementing cisco mpls

Lesson 2

Configuring Frame-Mode MPLS on Cisco IOS Platforms

OverviewThis lesson describes how to configure frame-mode Multiprotocol Label Switching (MPLS) on Cisco IOS platforms. The mandatory configuration tasks, and commands and their correct syntax usage, are discussed in this lesson. The lesson also covers some advanced configurations such as label-switching maximum transmission unit (MTU), IP time-to-live (TTL) propagation, and conditional label distribution. Also discussed in this lesson is the operation of frame-mode MPLS over switched WAN media.

It is important to understand how to enable and configure MPLS to successfully complete the Lab 3-1: Establishing the Core MPLS Environment.

ObjectivesUpon completing this lesson, you will be able to describe how to configure frame-mode MPLS on Cisco IOS platforms. This ability includes being able to meet these objectives:

Describe the MPLS configuration tasks

Configure the MPLS ID on a router

Configure MPLS on a frame-mode interface

Configure a label-switching MTU

Configure IP TTL propagation

Configure conditional label distribution

Configure frame-mode MPLS on switched WAN media

Page 153: Implementing cisco mpls

3-14 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are MPLS Configuration Tasks? This topic describes the MPLS configuration tasks.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-3

MPLS Configuration Tasks

Mandatory:

• Enable CEF switching

• Configure LDP on every label-enabled interface

Optional:

• Configure the MPLS ID

• Configure MTU size for labeled packets

• Configure IP TTL propagation

• Configure conditional label advertising

To enable MPLS, you must first enable Cisco Express Forwarding (CEF) switching. Depending on the Cisco IOS software release, you may need to establish the range for the label pool.

You must enable Label Distribution Protocol (LDP) on the interface by using label switching.

Optionally, the maximum size of labeled packets may be changed.

By default, the TTL field is copied from the IP header and placed in the MPLS label when a packet enters an MPLS network. To prevent core routers from responding with (Internet Control Message Protocol [ICMP]) TTL exceeded messages, disable TTL propagation. If TTL propagation is disabled, the value in the TTL field of the label is 255.

Note Ensure that all routers have TTL propagation either enabled or disabled. If TTL is enabled in

some routers and disabled in others, the result may be that a packet leaving the MPLS

domain will have a larger TTL value than when it entered.

By default, a router will generate and propagate labels for all networks that it has in the routing table. If label switching is required for only a limited number of networks (for example, only for router loopback addresses), configure conditional label advertising.

Page 154: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-15

Configuring the MPLS ID on a Router This topic describes how to configure the MPLS identifier (MPLS ID) on a router.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-4

ł°´­ ´Ľ° ®±«¬»®ó·Ľ ·˛¬»®şż˝» Ĺş±®˝»Ă

᫬»®ř˝±˛ş·ą÷ý

Specifies a preferred interface for determining the LDP router ID:

• Parameters

– interface: Causes the IP address of the specified interface to be used as the LDP router ID, provided that the interface is operational

– force: Alters the behavior of the command to force the use of the named interface as the LDP router ID

Configuring the MPLS ID on a Router

mpls ldp router-id To specify a preferred interface for determining the LDP router ID, use the mpls ldp router-id command in global configuration mode. To remove the preferred interface for determining the LDP router ID, use the no form of this command. This illustrates the two commands:

mpls ldp router-id interface [force]

no mpls ldp router-id

This table describes the parameters for the mpls idp router-id command.

mpls idp router-id Syntax Description

Parameter Description

·˛¬»®şż˝» Causes the IP address of the specified interface to be used as the LDP router ID, provided that the interface is operational

ş±®˝» (Optional) Alters the behavior of the mpls ldp router-idcommand to force the use of the named interface as the LDP router ID

Defaults

The mpls ldp router-id command is disabled.

Page 155: Implementing cisco mpls

3-16 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Configuring MPLS on a Frame-Mode Interface This topic describes how to configure MPLS on a frame-mode interface.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-5

Configuring MPLS on a Frame-Mode Interface

ł°´­ ·°

᫬»®ř˝±˛ş·ąó·ş÷ý

• Enables label switching on a frame-mode interface

• Starts LDP on the interface

ł°´­ ´żľ»´ °®±¬±˝±´ ŬĽ° ¤ ´Ľ° ¤ ľ±¬¸Ă

᫬»®ř˝±˛ş·ąó·ş÷ý

• Starts selected label distribution protocol on the specified interface

mpls ip To enable label switching of IP version 4 (IPv4) packets on an interface, use the mpls ipcommand in interface configuration mode. To disable IP label switching on this interface, use the no form of this command. This illustrates the two commands:

mpls ip

no mpls ip

Syntax Description

This command has no arguments or keywords.

Defaults

Label switching of IPv4 packets is disabled on this interface.

Page 156: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-17

mpls label protocol [tdp | ldp | both] To select the label distribution protocol to be used on an interface, use the mpls label protocolcommand in interface configuration mode. To revert to the default label distribution protocol, use the no form of this command. This illustrates the two commands:

mpls label protocol protocol

no mpls label protocol protocol

This table describes the parameters for the mpls label protocol [tdp | ldp | both] command.

mpls label protocol [tdp | ldp | both] Syntax Description

Parameter Description

¬Ľ° Enables Tag Distribution Protocol (TDP) on an interface

´Ľ° Enables LDP on an interface

ľ±¬¸ Enables TDP and LDP on an interface

Defaults

TDP has been the default label distribution protocol. Starting in Cisco IOS Release 12.4(3), the default MPLS label distribution protocol is LDP.

Page 157: Implementing cisco mpls

3-18 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-6

Configuring MPLS on a Frame-Mode Interface: Example 1

Example: Configuring MPLS on a Frame-Mode Interface The figure shows the configuration steps needed to enable MPLS on an edge label switch router (LSR). The configuration includes an access control list (ACL) that denies any attempt to establish a TDP session from an interface that is not enabled for MPLS. In the example in the figure, router A has the NoTDP access list applied to serial 3/1, which is not enabled for MPLS.

You must globally enable CEF switching, which automatically enables CEF on all interfaces that support it. (CEF is not supported on logical interfaces, such as loopback interfaces.)

Nonbackbone interfaces have an input ACL that denies TCP sessions on the well-known port number 711 (TDP).

Page 158: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-19

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-7

Configuring MPLS on a Frame-Mode Interface: Example 2

When combining Cisco routers with equipment of other vendors, you may need to use standard LDP (MPLS). TDP (tag switching) can be replaced by LDP on point-to-point interfaces. However, you can also use both protocols on shared media if some devices do not support TDP.

Label switching is more or less independent of the distribution protocol, so there should be no problem in mixing the two protocols. TDP and LDP are functionally very similar, and both populate the Label Information Base (LIB) table.

Page 159: Implementing cisco mpls

3-20 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-8

ĐŰëďř˝±˛ş·ą÷ý ·˛¬ ­»® đńđňďďď

ĐŰëďř˝±˛ş·ąó·ş÷ý ł°´­ ·°

ĐŰëďř˝±˛ş·ąó·ş÷ý ł°´­ ´żľ»´ °®±¬±˝±´ ´Ľ°

ĐŰëďř˝±˛ş·ąó·ş÷ýÂĆ

ĐŰëďý­¸±© ®«˛˛·˛ąó˝±˛ş·ą ·˛¬ ­»® đńđňďďď

Ţ«·´Ľ·˛ą ˝±˛ş·ą«®ż¬·±˛ňňň

Ý«®®»˛¬ ˝±˛ş·ą«®ż¬·±˛ ć ďęë ľ§¬»­

˙

·˛¬»®şż˝» Í»®·ż´đńđňďďď °±·˛¬ó¬±ó°±·˛¬

·° żĽĽ®»­­ ďçîňďęčňëňěç îëëňîëëňîëëňîěđ

ł°´­ ´żľ»´ °®±¬±˝±´ ´Ľ°

¬żąó­©·¬˝¸·˛ą ·°

ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďď

»˛Ľ

ĐŰëďý

Verifying MPLS on a Frame-Mode Interface: Example

Example: Verifying MPLS on a Frame-Mode Interface When verifying the MPLS configuration, you will find that depending on the Cisco IOS release, the show running-config command will display some of the ldp commands as tag-switching commands.

Note Starting with Cisco IOS Release 12.4(3), the default MPLS label distribution protocol has

changed from TDP to LDP. If no protocol is explicitly configured by the mpls label protocol

command, LDP is the default label distribution protocol. LDP configuration commands will

be saved by using the MPLS form of the command rather than the tag-switching form.

Before Cisco IOS Release 12.4(3), commands were saved using the tag-switching form

of the command for backward compatibility.

Use caution when upgrading the image on a router that uses TDP. Ensure that the TDP

sessions are established when the new image is loaded. You can accomplish this by issuing

the global configuration command mpls label protocol tdp. Issue this command and save it

to the startup configuration before loading the new image. Alternatively, you can enter the

command and save the running configuration immediately after loading the new image.

Page 160: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-21

Configuring a Label-Switching MTU This topic describes how to configure a label-switching MTU.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-9

Configuring a Label-Switching MTU

ł°´­ ł¬« ľ§¬»­

᫬»®ř˝±˛ş·ąó·ş÷ý

• Label switching increases the maximum MTU requirements on an interface because of the additional label header.

• Interface MTU is automatically increased on WAN interfaces;IP MTU is automatically decreased on LAN interfaces.

• Label-switching MTU can be increased on LAN interfaces (resulting in jumbo frames) to prevent IP fragmentation.

• The jumbo frames are not supported by all LAN switches.

mpls mtu To set the per-interface MTU for labeled packets, use the mpls mtu interface configuration command. This shows these commands:

mpls mtu bytes

no mpls mtu

This table describes the parameters for the mpls mtu command.

mpls mtu Syntax Description

Parameter Description

ľ§¬»­ MTU in bytes

Defaults

The minimum MTU is 64 bytes. The maximum depends on the type of interface medium.

Note The show mpls interface type number detail command can be used to check the MPLS

MTU setting.

Page 161: Implementing cisco mpls

3-22 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-10

Configuring Label-Switching MTU: Example

One way of preventing labeled packets from exceeding the maximum size (and being fragmented as a result) is to increase the MTU size of labeled packets for all segments in the label-switched path (LSP) tunnel. The problem will typically occur on LAN switches, where it is more likely that a device does not support oversized packets (also called jumbo frames or, sometimes, giants or baby giants). Some devices support jumbo frames, and some need to be configured to support them.

The MPLS MTU size is increased automatically on WAN interfaces and needs to be increased manually on LAN interfaces.

The MPLS MTU size has to be increased on all LSRs attached to a LAN segment. Additionally, the LAN switches used to implement switched LAN segments need to be configured to support jumbo frames. No additional configuration is necessary for shared LAN segments implemented with hubs.

A different approach is needed if a LAN switch does not support jumbo frames. The problem may be even worse for networks that do not allow ICMP MTU discovery messages to be forwarded to sources of packets and if the Don’t Fragment bit (DF bit) is strictly used. This situation can be encountered where firewalls are used.

Page 162: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-23

Configuring IP TTL Propagation This topic describes how to configure IP TTL propagation.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-11

Configuring IP TTL Propagation

˛± ł°´­ ·° °®±°żąż¬»ó¬¬´

᫬»®ř˝±˛ş·ą÷ý

• By default, IP TTL is copied into the MPLS label at label imposition, and the MPLS label TTL is copied (back) into the IP TTL at label removal.

• This command disables IP TTL and label TTL propagation.

– TTL value of 255 is inserted in the label header.

• The TTL propagation has to be disabled on ingress and egress edge LSRs.

mpls ip propagate-ttl To set the TTL value on output when the IP packets are being encapsulated in MPLS, use the mpls ip propagate-ttl command in privileged EXEC mode. To disable this feature, use the noform of this command. This illustrates these two commands:

mpls ip propagate-ttl

no mpls ip propagate-ttl

Syntax Description

This command has no optional keywords or arguments.

Defaults

The MPLS TTL value on packet output is set based on the IP TTL value on packet input.

Page 163: Implementing cisco mpls

3-24 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-12

Configuring IP TTL Propagation:Example

Example: Configuring IP TTL Propagation The figure illustrates typical traceroute behavior in an MPLS network. Because the label header of a labeled packet carries the TTL value from the original IP packet, the routers in the path can drop packets when the TTL is exceeded. Traceroute will therefore show all the routers in the path. This is the default behavior.

In the example, router C1 is executing a trace command that results in this behavior. The steps for this process are as follows:

Step 1 The first packet is an IP packet with TTL=1. Router A decreases the TTL and drops the packet because it reaches 0. An ICMP TTL exceeded message is sent to the source.

Step 2 The second packet sent is an IP packet with TTL=2. Router A decreases the TTL, labels the packet (the TTL from the IP header is copied into the label), and forwards the packet to router B.

Step 3 Router B decreases the TTL value, drops the packet, and sends an ICMP TTL exceeded message to the source.

Step 4 The third packet (TTL=3) experiences a similar processing to the previous packets, except that router C is not the one dropping the packet based on the TTL in the IP header. Router B, because of penultimate hop popping (PHP), previously removed the label, and the TTL was copied back to the IP header (or second label).

The fourth packet (TTL=4) reaches the final destination, where the TTL of the IP packet is examined.

Page 164: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-25

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-13

Configuring IP TTL Propagation:Disabling IP TTL Propagation Example

If TTL propagation is disabled, the TTL value is not copied into the label header. Instead, the label TTL field is set to 255. The probable result is that the TTL field in the label header will not decrease to 0 for any router inside the MPLS domain (unless there is a forwarding loop inside the MPLS network).

If the traceroute command is used, ICMP replies are received only from those routers that see the real TTL stored in the IP header.

Example: Disabling IP TTL Propagation In the figure, router C1 is executing the traceroute command, but the core routers do not copy the TTL to and from the label. This situation results in this behavior:

Step 1 The first packet is an IP packet with TTL=1. Router A decreases the TTL, drops the packet, and sends an ICMP TTL exceeded message to the source.

Step 2 The second packet is an IP packet with TTL=2. Router A decreases the TTL, labels the packet, and sets the TTL to 255.

Step 3 Router B decreases the TTL in the label to 254 and forwards a labeled packet with TTL set to 254.

Step 4 Router C removes the label, decreases the IP TTL, and sends the packet to the next-hop router (C2). The packet has reached the final destination.

Note The egress MPLS router may, in some cases, be seen in the trace printout, for example, if

the route toward C2 is carried in Border Gateway Protocol (BGP), not in the Interior Gateway

Protocol (IGP).

Page 165: Implementing cisco mpls

3-26 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-14

˛± ł°´­ ·° °®±°żąż¬»ó¬¬´ Ĺş±®©ż®Ľ»Ľ ¤ ´±˝ż´Ă

᫬»®ř˝±˛ş·ą)#

Selectively disables IP TTL propagation for:

• Forwarded traffic (Traceroute does not work for transit traffic labeled by this router.)

• Local traffic (Traceroute does not work from the router but works for transit traffic labeled by this router.)

Configuring IP TTL Propagation:Extended Options

mpls ip propagate-ttl Use the mpls ip propagate-ttl global configuration command to control generation of the TTL field in the label when the label is first added to the IP packet. By default, this command is enabled, which means that the TTL field is copied from the IP header and inserted into the MPLS label. This aspect allows a trace command to show all of the hops in the network.

To use a fixed TTL value (255) for the first label of the IP packet, use the no form of the mplsip propagate-ttl command. This action hides the structure of the MPLS network from a tracecommand. Specify the types of packets to be hidden by using the forwarded and localarguments. Specifying no mpls ip propagate-ttl forwarded allows the structure of the MPLS network to be hidden from customers but not from the provider. Here are the most common applications of this command:

mpls ip propagate-ttl [forwarded | local]

no mpls ip propagate-ttl [forwarded | local]

This table describes the parameters for the mpls ip propagate-ttl command.

mpls ip propagate-ttl Syntax Description

Parameter Description

ş±®©ż®Ľ»Ľ (Optional) Hides the structure of the MPLS network from a tracecommand only for forwarded packets; prevents the tracecommand from showing the hops for forwarded packets

´±˝ż´ (Optional) Hides the structure of the MPLS network from a tracecommand only for local packets; prevents the trace command from showing the hops only for local packets

Page 166: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-27

Defaults

By default, this command is enabled. The TTL field is copied from the IP header. A tracecommand shows all of the hops in the network.

Usage Guidelines

By default, the mpls ip propagate-ttl command is enabled, and the IP TTL value is copied to the MPLS TTL field during label imposition. To disable TTL propagation for all packets, use the no mpls ip propagate-ttl command. To disable TTL propagation only for forwarded packets, use the no mpls ip propagate-ttl forwarded command. This action allows the structure of the MPLS network to be hidden from customers, but not from the provider.

This feature supports the Internet Engineering Task Force (IETF) document “ICMP Extensions for Multiprotocol Label Switching.”

Page 167: Implementing cisco mpls

3-28 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-15

Configuring IP TTL Propagation:Disabling IP TTL Propagation Example

Typically, a service provider likes to hide the backbone network from outside users but allow inside traceroute to work for easier troubleshooting of the network.

This goal can be achieved by disabling TTL propagation for forwarded packets only, as described here:

If a packet originates in the router, the real TTL value is copied into the label TTL.

If the packet is received through an interface, the TTL field in a label is assigned a value of 255.

The result is that someone using traceroute on a provider router will see all of the backbone routers. Customers will see only edge routers.

The opposite behavior can be achieved by using the no mpls ip propagate-ttl local command, although this is not usually desired.

Page 168: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-29

Configuring Conditional Label Distribution This topic describes how to configure conditional label distribution.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-16

ł°´­ ´Ľ° żĽŞ»®¬·­»ó´żľ»´­ Ĺş±® °®»ş·¨óż˝˝»­­ó´·­¬ Ŭ± °»»®ó

ż˝˝»­­ó´·­¬ĂĂ

᫬»®ř˝±˛ş·ą÷ý

• By default, labels for all destinations are announced to all LDP or TDP neighbors.

• This command enables you to selectively advertise some labels to some LDP or TDP neighbors.

• Conditional label advertisement works only over frame-mode interfaces.

• Parameters:

– for —The IP access list that selects thedestinations for which the labels will be generated

– to —The IP access list that selects the MPLSneighbors that will receive the labels

Conditional Label DistributionConfiguration

mpls ldp advertise-labels To control the distribution of locally assigned (incoming) labels by means of LDP, use thempls ldp advertise-labels command in global configuration mode. This command is used to control which labels are advertised to which LDP neighbors. To prevent the distribution of locally assigned labels, use the no form of this command, as shown here:

mpls ldp advertise-labels [for prefix-access-list [to peer-access-list]]

no mpls ldp advertise-labels [for prefix-access-list [to peer-access-list]]

This table describes the parameters for the mpls idp advertise-labels command.

mpls idp advertise-labels Syntax Description

Parameter Description

ş±® °®»ş·¨óż˝˝»­­ó´·­¬ (Optional) This parameter specifies which destinations should have their labels advertised.

¬± °»»®óż˝˝»­­ó´·­¬ (Optional) This parameter specifies which LSR neighbors should receive label advertisements. An LSR is identified by its router ID, which consists of the first 4 bytes of its 6-byte LDP identifier.

Page 169: Implementing cisco mpls

3-30 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-17

• The customer is already running IP infrastructure.

• MPLS is needed only to support MPLS VPN services:

– Labels should be generated only for loopback interfaces (BGP next hops) of all routers.

– All loopback interfaces are in one contiguous address block (192.168.254.0/24).

Conditional Label DistributionConfiguration: Example

Example: Conditional Label Distribution Configuration The example here describes where conditional label advertising can be used. The existing network still performs normal IP routing, but the MPLS LSP tunnel between the loopback interfaces of the LSR routers is needed to enable MPLS Virtual Private Network (VPN) functionality.

Using one contiguous block of IP addresses for loopbacks on provider edge (PE) routers can simplify the configuration of conditional advertising.

Page 170: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-31

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-18

·° ˝»ş

˙

·˛¬»®şż˝» ­»®·ż´ đńđ

ł°´­ ·°

˙

·˛¬»®şż˝» ­»®·ż´ đńď

ł°´­ ·°

˙

·˛¬»®şż˝» »¬¸»®˛»¬ ďńđ

ł°´­ ·°

Conditional Label DistributionConfiguration Steps

Step 1: Enable CEF and label switching.

·° ˝»ş

ł°´­ ·°

ł°´­ ·°

ł°´­ ·°

In the first step, CEF switching and MPLS have to be enabled on all core interfaces. The MPLS MTU size may be adjusted on the LAN interfaces.

Page 171: Implementing cisco mpls

3-32 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-19

Conditional Label DistributionConfiguration Steps (Cont.)

Step 2: Enable conditional label advertisement.

˙

˙ Ü·­żľ´» Ľ»şż«´¬ żĽŞ»®¬·­ł»˛¬ ł»˝¸ż˛·­ł

˙

˛± ł°´­ ´Ľ° żĽŞ»®¬·­»ó´żľ»´­

˙

˙ ݱ˛ş·ą«®» ˝±˛Ľ·¬·±˛ż´ żĽŞ»®¬·­ł»˛¬­

˙

ł°´­ ´Ľ° żĽŞ»®¬·­»ó´żľ»´­ ş±® ç𠬱 çď

˙

ż˝˝»­­ó´·­¬ çđ °»®ł·¬ ·° ďçîňďęčňîëěňđ đňđňđňîëë

ż˝˝»­­ó´·­¬ çď °»®ł·¬ ·° ż˛§

˛± ł°´­ ´Ľ° żĽŞ»®¬·­»ó´żľ»´­

ł°´­ ´Ľ° żĽŞ»®¬·­»ó´żľ»´­ ş±® ç𠬱 çď

˙

ż˝˝»­­ó´·­¬ çđ °»®ł·¬ ďçîňďęčňîëěňđ đňđňđňîëë

ż˝˝»­­ó´·­¬ çď °»®ł·¬ ż˛§

In the second step, disable label propagation and enable conditional label advertising. Within the mpls ldp advertise-labels command, specify the neighbors to which the labels are to be sent and the networks for which the labels are to be advertised.

Example: Enabling Conditional Label Advertisement In the figure, the labels for all networks permitted by ACL 90 are sent to all neighbors matched by ACL 91 (in this example, this would be all TDP or LDP neighbors).

Page 172: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-33

Configuring Frame-Mode MPLS on Switched WAN Media

This topic describes how to configure frame-mode MPLS on switched WAN media.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-20

Configuring Frame-Mode MPLS on Switched WAN Media

Why:

• Run MPLS over ATM networks that do not support MPLS.

• This could be the potential first phase in ATM network migration.

How:

• Configure MPLS over ATM point-to-point subinterfaces on the routers.

When an underlying ATM infrastructure that does not support cell-mode MPLS is used, MPLS can still be used across point-to-point permanent virtual circuits (PVCs). The MPLS configuration is equal to that on any other Layer 2 media.

This activity could be the first phase of an ATM network migration.

Page 173: Implementing cisco mpls

3-34 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-21

• Routers view the ATM PVC as a frame-mode MPLS interface.

• TDP or LDP is run between the adjacent routers.

• Many LSPs can be established over one ATM PVC.

• The ATM network is not aware of MPLS between the routers.

Configuring Frame-Mode MPLS on Switched WAN Media:MPLS over ATM Forum PVCs

If frame-mode MPLS on an ATM interface is enabled, TDP or LDP neighbor relationships are established between the two PVC endpoint routers and not with the attached ATM switch.

Labeling of packets happens at the process level (in software), while segmentation and reassembly happen on the interface (in hardware), regardless of the type of packet.

Switching is performed based on the virtual path identifier/virtual channel identifier (VPI/VCI) value in the ATM header that is used for this particular PVC, and is not related to Layer 3 IP information.

Page 174: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-35

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-22

• Create a point-to-point ATM subinterface.

• Configure ATM PVC on the subinterface.

• Start label switching and LDP or TDP on the interface.

Configuring Frame-Mode MPLS on Switched WAN Media: MPLS over ATM Forum PVCs (Cont.)

Configuring frame-mode MPLS on an ATM interface involves using the same interface command (mpls ip). Because this implementation is frame-mode MPLS (versus cell-mode) over ATM, the interface is defined as a point-to-point subinterface.

The ATM parameters are not related to MPLS, because the labeled traffic is using a standard ATM Forum point-to-point PVC.

Page 175: Implementing cisco mpls

3-36 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-23

• Create a point-to-point or multipoint Frame Relay subinterface.

• Configure Frame Relay DLCI on the subinterface.

• Start label switching and LDP or TDP on the interface.

Configuring Frame-Mode MPLS on Switched WAN Media:MPLS over Frame Relay Networks

Enabling MPLS on a Frame Relay PVC, also called a data-link connection identifier (DLCI), is no different from doing so on any other point-to-point media.

Routers insert a label between the frame and the IP header. The TDP or LDP session is established between the two IP endpoints connected through a Frame Relay network.

Page 176: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-37

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-24

Summary

• Some of the MPLS configuration tasks are mandatory and some are optional.

• The command specifies a preferred interface for determining the LDP router ID.

• Use the or commands to enable MPLS (interface level).

• Label switching increases maximum MTU size on an interface.

• TTL propagation must be disabled on ingress and egress edge LSRs.

• Conditional label advertisement works only on frame-mode interfaces.

• When frame-mode MPLS on an ATM interface is enabled, LDP relationships are established between the PVC endpoints and not with the attached ATM switch.

Page 177: Implementing cisco mpls

3-38 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 178: Implementing cisco mpls

Lesson 3

Monitoring Frame-Mode MPLS on Cisco IOS Platforms

OverviewThis lesson describes the procedures for monitoring Multiprotocol Label Switching (MPLS) on Cisco IOS platforms by listing the syntax and parameter descriptions; looking at interfaces, neighbor nodes, and Label Information Base (LIB) and label forwarding information base (LFIB) tables; and outlining the usage guidelines for the commands.

It is very important to know what commands you can use to verify correct operation of MPLS in the network. The information here will help you when you encounter problems with frame-mode interfaces that have MPLS running in the network.

ObjectivesUpon completing this lesson, you will be able to describe how to use monitoring commands in frame-mode MPLS on Cisco IOS platforms. This ability includes being able to meet these objectives:

Monitor MPLS

Monitor LDP

Monitor label switching

Debug MPLS and LDP

Page 179: Implementing cisco mpls

3-40 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Monitoring MPLS This topic describes how to monitor MPLS.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-3

­¸±© ł°´­ ´Ľ° °ż®żł»¬»®­

᫬»®ý

• Displays LDP parameters on the local router

MPLS Monitoring Commands

­¸±© ł°´­ ·˛¬»®şż˝»­

᫬»®ý

• Displays MPLS status on individual interfaces

­¸±© ł°´­ ´Ľ° Ľ·­˝±Ş»®§

᫬»®ý

• Displays all discovered LDP neighbors

show mpls ldp parameters To display available Label Distribution Protocol (LDP) parameters, use the show mpls ldp parameters command in privileged EXEC mode.

Syntax Description

This command has no arguments or keywords.

show mpls interfaces To display information about one or more interfaces that have the MPLS feature enabled, use the show mpls interfaces [interface] [detail] command in EXEC mode.

The table describes the parameters for the show mpls interfaces command.

show mpls interfaces Syntax Description

Parameter Description

·˛¬»®şż˝» (Optional) Defines the interface about which to display label-switching information

Ľ»¬ż·´ (Optional) Displays detailed label-switching information for the specified interface

Page 180: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-41

show mpls ldp discovery To display the status of the LDP discovery process (Hello protocol), use these commands in privileged EXEC mode:

show mpls ldp discovery [vrf vpn-name]

show mpls ldp discovery [all]

The show mpls ldp discovery command displays all MPLS-enabled interfaces and the neighbors that are present on the interfaces.

show mpls ldp discovery Syntax Description

Parameter Description

Ş®ş Ş°˛ó˛żł» (Optional) Displays the neighbor discovery information for the specified Virtual Private Network (VPN) routing or forwarding instance (vpn-name)

ż´´ (Optional) Displays LDP discovery information for all VPNs when the all keyword is specified alone in this command, including those in the default routing domain

Page 181: Implementing cisco mpls

3-42 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-4

Đ®±¬±˝±´ Ş»®­·±˛ć ďܱ©˛­¬®»żł ´żľ»´ °±±´ć ł·˛ ´żľ»´ć ďęĺ łż¨ ´żľ»´ć

ďđđđđđĹݱ˛ş·ą«®»Ľć ł·˛ ´żľ»´ć ďđđđĺ łż¨ ´żľ»´ć ďçççĂ

Í»­­·±˛ ¸±´Ľ ¬·ł»ć ďčđ ­»˝ĺ µ»»° ż´·Ş» ·˛¬»®Şż´ć ęđ ­»˝

Ü·­˝±Ş»®§ ¸»´´±ć ¸±´Ľ¬·ł»ć ďë ­»˝ĺ ·˛¬»®Şż´ć ë ­»˝Ü·­˝±Ş»®§ ¬ż®ą»¬»Ľ ¸»´´±ć ¸±´Ľ¬·ł»ć ďčđ ­»˝ĺ ·˛¬»®Şż´ć

ë ­»˝Ü±©˛­¬®»żł ±˛ Ü»łż˛Ľ łż¨ ¸±° ˝±«˛¬ć îëëÔÜĐ ş±® ¬ż®ą»¬»Ľ ­»­­·±˛­ÔÜĐ ·˛·¬·ż´ńłż¨·ł«ł ľż˝µ±şşć ďëńďîđ ­»˝ÔÜĐ ´±±° Ľ»¬»˝¬·±˛ć ±şş

᫬»®ý­¸±© ł°´­ ´Ľ° °ż®żł»¬»®­

MPLS Monitoring Commands:show mpls ldp parameters

The table describes the significant fields in the display.

Page 182: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-43

show mpls ldp parameters Field Description

Field Description

Protocol version This field indicates the version of LDP running on the platform.

Downstream label pool This field describes the range of labels available for the platform to assign for label-switching purposes. The available labels range from the smallest value (min label) to the largest label value (max label), with a modest number of labels at the low end of the range (reserved labels), reserved for diagnostic purposes.

Session hold time This field indicates the time that an LDP session is to be maintained with an LDP peer without receiving LDP traffic or an LDP keepalive message from the peer.

Keepalive interval This field indicates the interval of time between consecutive transmissions of LDP keepalive messages to an LDP peer.

Discovery hello This field indicates the amount of time to remember that a neighbor platform wants an LDP session without receiving an LDP hello message from the neighbor (hold time), and the time interval between the transmissions of consecutive LDP hello messages to neighbors (interval).

Discovery targeted hello This field indicates the amount of time to remember that a neighbor platform wants an LDP session when one of the these situations occurs:

The neighbor platform is not directly connected to the router.

The neighbor platform has not sent an LDP hello message. This intervening interval is known as hold time.

This field also indicates the time interval between the transmissions of consecutive hello messages to a neighbor not directly connected to the router.

LDP for targeted sessions This field reports the parameters that have been set by the mplsldp neighbor targeted command.

LDP initial/maximum backoff This field reports the parameters that have been set by the mplsldp backoff command.

Page 183: Implementing cisco mpls

3-44 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-5

᫬»®ý­¸±© ł°´­ ·˛¬»®şż˝»­×˛¬»®şż˝» Í»®·ż´đńđć

×Đ ´żľ»´·˛ą »˛żľ´»Ľ ř´Ľ°÷ÔÍĐ Ě«˛˛»´ ´żľ»´·˛ą »˛żľ´»ĽĚżą Ú®żł» λ´ż§ Ě®ż˛­°±®¬ ¬żąą·˛ą ˛±¬ »˛żľ´»ĽĚżąą·˛ą ±°»®ż¬·±˛ż´Úż­¬ Í©·¬˝¸·˛ą Ę»˝¬±®­ć

×Đ ¬± ÓĐÔÍ Úż­¬ Í©·¬˝¸·˛ą Ę»˝¬±®ÓĐÔÍ Ě«®ľ± Ę»˝¬±®

ÓĚË ă ďëđđײ¬»®şż˝» Í»®·ż´đńíć

×Đ ´żľ»´·˛ą »˛żľ´»Ľ ř´Ľ°÷ÔÍĐ Ě«˛˛»´ ´żľ»´·˛ą ˛±¬ »˛żľ´»ĽĚżą Ú®żł» λ´ż§ Ě®ż˛­°±®¬ ¬żąą·˛ą ˛±¬ »˛żľ´»ĽĚżąą·˛ą ±°»®ż¬·±˛ż´Úż­¬ Í©·¬˝¸·˛ą Ę»˝¬±®­ć

×Đ ¬± ÓĐÔÍ Úż­¬ Ú»ż¬«®» Í©·¬˝¸·˛ą Ę»˝¬±®ÓĐÔÍ Ú»ż¬«®» Ę»˝¬±®

ÓĚË ă ďëđđ

MPLS Monitoring Commands: show mpls interfaces

The show mpls interfaces command will show only those interfaces on which MPLS has been configured.

The table describes the significant fields in the display.

show mpls interfaces Field Description

Field Description

Interface Interface name

IP “Yes” if IP label switching (sometimes called hop-by-hop label switching) has been enabled on this interface

Tunnel “Yes” if label-switched path (LSP) tunnel labeling has been enabled on this interface

Tagging operational Operational state; “Yes” if labeled packets can be sent over this interface

Labeled packets can be sent over an interface if an MPLS protocol is configured on the interface and the required Layer 2 negotiations have occurred.

Page 184: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-45

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-6

MPLS Monitoring Commands:show mpls ldp discovery

᫬»®ý­¸±© ł°´­ ´Ľ° Ľ·­˝±Ş»®§Ô±˝ż´ ÔÜР׼»˛¬·ş·»®ć

ďçîňďęčňíňďđîćđÜ·­˝±Ş»®§ ͱ«®˝»­ć

ײ¬»®şż˝»­ćÍ»®·ż´ďńđňďř´Ľ°÷ć ¨ł·¬ń®»˝Ş

ÔÜР׼ć ďçîňďęčňíňďđďćđÍ»®·ż´ďńđňîř´Ľ°÷ć ¨ł·¬ń®»˝Ş

ÔÜР׼ć ďçîňďęčňíňďđđćđ

show mpls ldp discovery The table describes the significant fields in the display.

Page 185: Implementing cisco mpls

3-46 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

show mpls ldp discovery Field Description

Field Description

Local LDP Identifier This field indicates the LDP identifier (LDP ID) for the local router. An LDP ID is a 6-byte construct displayed in the form “IP address:number”.

By convention, the first 4 bytes of the LDP ID constitute the router ID; integers, starting with 0, constitute the final 2 bytes of the IP address:number construct.

Interfaces This field lists the interfaces that are engaging in LDP discovery activity, as described here:

The xmit field indicates that the interface is transmitting LDP discovery hello packets.

The recv field indicates that the interface is receiving LDP discovery hello packets.

The (ldp) or (tdp) field indicates the label distribution protocol configured for the interface.

The LDP (or Tag Distribution Protocol [TDP]) identifiers indicate LDP (or TDP) neighbors discovered on the interface.

Targeted Hellos This field lists the platforms to which targeted hello messages are being sent, as described here:

The xmit, recv, and (ldp) or (tdp) fields are as described for the Interfaces field.

The active field indicates that this label switch router (LSR) has initiated targeted hello messages.

The passive field indicates that the neighbor LSR has initiated targeted hello messages and that this LSR is configured to respond to the targeted hello messages from the neighbor.

Page 186: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-47

Monitoring LDP This topic describes how to monitor LDP.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-7

­¸±© ł°´­ ´Ľ° ˛»·ą¸ľ±®

᫬»®ý

• Displays individual LDP neighbors

LDP Monitoring Commands

­¸±© ł°´­ ´Ľ° ˛»·ą¸ľ±® Ľ»¬ż·´

᫬»®ý

• Displays more details about LDP neighbors

­¸±© ł°´­ ´Ľ° ľ·˛Ľ·˛ą­

᫬»®ý

• Displays LIB

• show mpls ldp bindings [network {mask | length} [longer-prefixes]] [local-label label [- label]} [remote-label label [- label] [neighbor address][local]

show mpls ldp neighbor To display the status of LDP sessions, use these show mpls ldp neighbor commands in privileged EXEC mode:

show mpls ldp neighbor [vrf vpn-name] [address] [interface] [detail]

show mpls ldp neighbor [all]

show mpls ldp neighbor Syntax Description

Parameter Description

vrf vpn-name (Optional) Displays the LDP neighbors for the specified VPN routing or forwarding instance (vpn-name)

address (Optional) Identifies the neighbor with this IP address

interface (Optional) Defines the LDP neighbors accessible over this interface

detail (Optional) Displays information in long form

all (Optional) Displays LDP neighbor information for all VPNs when the all keyword is specified alone in this command, including those in the default routing domain

Page 187: Implementing cisco mpls

3-48 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

show mpls ldp bindings To display the contents of the LIB, use this show mpls ldp bindings command in privileged EXEC mode: show mpls ldp bindings [network {mask | length} [longer-prefixes]] [local-label label [-label]] [remote-label label [-label]] [neighbor address] [local].

show mpls ldp bindings Syntax Description

Parameter Description

vrf vpn-name (Optional) This parameter displays the label bindings for the specified VPN routing or forwarding instance (vpn-name).

network (Optional) This parameter defines the destination network number.

mask (Optional) This parameter specifies the network mask, written as A.B.C.D.

length (Optional) This parameter specifies the mask length (1 to 32 characters).

longer-prefixes (Optional) This parameter selects any prefix that matches mask with a length from 1 to 32 characters.

local-label label-label (Optional) This parameter displays entries matching local label values. Use the label-label argument to indicate the label range.

remote-label label-label (Optional) This parameter displays entries matching the label values assigned by a neighbor router. Use the label-label argument to indicate the label range.

neighbor address (Optional) This parameter displays the label bindings assigned by the selected neighbor.

local (Optional) This parameter displays the local label bindings.

Page 188: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-49

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-8

LDP Monitoring Commands:show mpls ldp neighbor detail

᫬»®ý­¸±© ł°´­ ´Ľ° ˛»·ą¸ľ±® Ľ»¬ż·´Đ»»® ÔÜР׼»˛¬ć ďçîňďęčňíňďđđćđĺ Ô±˝ż´ ÔÜР׼»˛¬ ďçîňďęčňíňďđîćđ

ĚÝĐ ˝±˛˛»˝¬·±˛ć ďçîňďęčňíňďđđňęěę Š ďçîňďęčňíňďđîňďďđđđͬż¬»ć Ń°»®ĺ Ó­ą­ ­»˛¬ń®˝ŞĽć íďďéńíďďîĺ ܱ©˛­¬®»żłĺ Ôż­¬ Ě×Ţ ®»Ş ­»˛¬îË° ¬·ł»ć î©ěĽĺ Ë×Üć ěĺ Đ»»® ׼ đĺÔÜĐ Ľ·­˝±Ş»®§ ­±«®˝»­ć

Í»®·ż´đńđĺ Í®˝ ×Đ żĽĽ®ć ďíđňđňđňî ¸±´Ľ¬·ł»ć ďëđđđ ł­ô ¸»´´± ·˛¬»®Şż´ć ëđđđ ł­

߼Ľ®»­­»­ ľ±«˛Ľ ¬± °»»® ÔÜР׼»˛¬ćďçîňďęčňíňďđ ďçîňďęčňíňďě ďçîňďęčňíňďđđ

Đ»»® ¸±´Ľ¬·ł»ć ďčđđđđ ł­ĺ Őß ·˛¬»®Şż´ć ęđđđđ ł­ĺ Đ»»® ­¬ż¬»ć »­¬żľ

The status of the LDP session is indicated by “State: Oper” (operational).

show mpls ldp neighbor To display the status of LDP sessions, issue these show mpls ldp neighbor commands in privileged EXEC mode:

show mpls ldp neighbor [vrf vpn-name] [address] [interface] [detail]

show mpls ldp neighbor [all]

Usage Guidelines

The show mpls ldp neighbor command can provide information about all LDP neighbors, or the information can be limited to the following:

Neighbor with specific IP address

LDP neighbors known to be accessible over a specific interface

Page 189: Implementing cisco mpls

3-50 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

This table describes the significant fields in the display.

show mpls ldp neighbor Field Description

Field Description

Peer LDP Ident This field displays the LDP ID of the neighbor (peer) for this session.

Local LDP Ident This field displays the LDP ID for the local LSR for this session.

TCP connection This field displays the TCP connection used to support the LDP session, shown in the format that follows:

peer IP address.peer port

local IP address.local port

State This field displays the state of the LDP session. Generally, this is “Oper” (operational), but “transient” is another possible state.

Msgs sent/rcvd This field displays number of LDP messages sent to and received from the session peer. The count includes the transmission and receipt of periodic keepalive messages, which are required for maintenance of the LDP session.

Downstream on demand This field indicates that the downstream-on-demand method of label distribution is being used for this LDP session. When the downstream-on-demand method is used, an LSR advertises its locally assigned (incoming) labels to its LDP peer only when the peer requests them.

Downstream This field Indicates that the downstream method of label distribution is being used for this LDP session. When the downstream method is used, an LSR advertises all of its locally assigned (incoming) labels to its LDP peer (subject to any configured access list restrictions).

Up time This field displays the length of time that the LDP session has existed.

LDP discovery sources This field displays the source (or sources) of LDP discovery activity that led to the establishment of this LDP session.

Addresses bound to peer LDP Ident

This field displays the known interface addresses of the LDP session peer. These are addresses that might appear as next-hop addresses in the local routing table. They are used to maintain the LFIB.

Peer holdtime This field displays the time that it takes to remove the relationship if no keepalives are received within this period.

KA interval This field displays the keepalive interval.

Peer state This field shows the status of the neighbor relationship.

Page 190: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-51

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-9

LDP Monitoring Commands:show mpls ldp bindings

᫬»®ý­¸±© ł°´­ ´Ľ° ľ·˛Ľ·˛ą­

¬·ľ »˛¬®§ć ďđňďđîňđňđńďęô ®»Ş îç´±˝ż´ ľ·˛Ľ·˛ąć ´żľ»´ć îę®»ł±¬» ľ·˛Ľ·˛ąć ´­®ć ďéîňîéňíîňîçćđô ´żľ»´ć îę

¬·ľ »˛¬®§ć ďđňîďďňđňéńíîô ®»Ş íî´±˝ż´ ľ·˛Ľ·˛ąć ´żľ»´ć îé®»ł±¬» ľ·˛Ľ·˛ąć ´­®ć ďéîňîéňíîňîçćđô ´żľ»´ć îč

¬·ľ »˛¬®§ć ďđňîîđňđňéńíîô ®»Ş íí´±˝ż´ ľ·˛Ľ·˛ąć ´żľ»´ć îč®»ł±¬» ľ·˛Ľ·˛ąć ´­®ć ďéîňîéňíîňîçćđô ´żľ»´ć îç

show mpls ldp bindings To display the contents of the LIB, use this show mpls ldp bindings command in privileged EXEC mode: show mpls ldp bindings [vrf vpn-name] [network {mask | length} [longer-prefixes]] [local-label label [-label]] [remote-label label [-label]] [neighbor address] [local].

show mpls ldp bindings Syntax Description

Parameter Description

vrf vpn-name (Optional) This parameter displays the label bindings for the specified VPN routing or forwarding instance (vpn-name).

network (Optional) This parameter defines the destination network number.

mask (Optional) This parameter specifies the network mask, written as A.B.C.D.

length (Optional) This parameter specifies the mask length (1 to 32 characters).

longer-prefixes (Optional) This parameter selects any prefix that matches maskwith a length from 1 to 32 characters.

local-label label-label (Optional) This parameter displays entries matching local label values. Use the label-label argument to indicate the label range.

remote-label label-label (Optional) This parameter displays entries matching the label values assigned by a neighbor router. Use the label-labelargument to indicate the label range.

neighbor address (Optional) This parameter displays the label bindings assigned by the selected neighbor.

local (Optional) This parameter displays the local label bindings.

Page 191: Implementing cisco mpls

3-52 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Usage Guidelines

The show mpls ldp bindings command displays label bindings learned by the LDP or TDP.

ExamplesThis sample output from the show mpls ldp bindings command displays the contents of the entire LIB.

᫬»®ďý­¸±© ł°´­ ´Ľ° ľ·˛Ľ·˛ą­

ďđňçîňđňđńďęô ®»Ş îč

´±˝ż´ ľ·˛Ľ·˛ąć ´żľ»´ć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ´­®ć ďéîňîéňíîňîçćđô ´żľ»´ć ·ł°ó˛«´´

ďđňďđîňđňđńďęô ®»Ş îç

´±˝ż´ ľ·˛Ľ·˛ąć ´żľ»´ć îę

®»ł±¬» ľ·˛Ľ·˛ąć ´­®ć ďéîňîéňíîňîçćđô ´żľ»´ć îę

ďđňďđëňđňđńďęô ®»Ş íđ

´±˝ż´ ľ·˛Ľ·˛ąć ´żľ»´ć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ´­®ć ďéîňîéňíîňîçćđô ´żľ»´ć ·ł°ó˛«´´

ďđňîđëňđňđńďęô ®»Ş íď

´±˝ż´ ľ·˛Ľ·˛ąć ´żľ»´ć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ´­®ć ďéîňîéňíîňîçćđô ´żľ»´ć ·ł°ó˛«´´

ďđňîďďňđňéńíîô ®»Ş íî

´±˝ż´ ľ·˛Ľ·˛ąć ´żľ»´ć îé

®»ł±¬» ľ·˛Ľ·˛ąć ´­®ć ďéîňîéňíîňîçćđô ´żľ»´ć îč

ďđňîîđňđňéńíîô ®»Ş íí

´±˝ż´ ľ·˛Ľ·˛ąć ´żľ»´ć îč

®»ł±¬» ľ·˛Ľ·˛ąć ´­®ć ďéîňîéňíîňîçćđô ´żľ»´ć îç

ççňďđďňđňđńďęô ®»Ş íë

´±˝ż´ ľ·˛Ľ·˛ąć ´żľ»´ć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ´­®ć ďéîňîéňíîňîçćđô ´żľ»´ć ·ł°ó˛«´´

ďđđňďđďňđňđńďęô ®»Ş íę

´±˝ż´ ľ·˛Ľ·˛ąć ´żľ»´ć îç

®»ł±¬» ľ·˛Ľ·˛ąć ´­®ć ďéîňîéňíîňîçćđô ´żľ»´ć ·ł°ó˛«´´

ďéďňęçňîđěňđńîěô ®»Ş íé

´±˝ż´ ľ·˛Ľ·˛ąć ´żľ»´ć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ´­®ć ďéîňîéňíîňîçćđô ´żľ»´ć ·ł°ó˛«´´

ďéîňîéňíîňđńîîô ®»Ş íč

´±˝ż´ ľ·˛Ľ·˛ąć ´żľ»´ć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ´­®ć ďéîňîéňíîňîçćđô ´żľ»´ć ·ł°ó˛«´´

îďđňďđňđňđńďęô ®»Ş íç

´±˝ż´ ľ·˛Ľ·˛ąć ´żľ»´ć ·ł°ó˛«´´

Page 192: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-53

Monitoring Label Switching This topic describes how to monitor label switching.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-10

­¸±© ł°´­ ş±®©ż®Ľ·˛ąó¬żľ´»

᫬»®ý

• Displays contents of LFIB

Monitoring Label Switching

­¸±© ·° ˝»ş Ľ»¬ż·´

᫬»®ý

• Displays label or labels attached to a packet during label imposition on edge LSR

show mpls forwarding-table To display the contents of the MPLS LFIB, use this show mpls forwarding-table command in privileged EXEC mode: show mpls forwarding-table [{network {mask | length} | labels label[-label]| interface interface | next-hop address | lsp-tunnel [tunnel-id]}] [detail].

show ip cef To display entries in the FIB that are unresolved or to display a summary of the FIB, use the this form of the show ip cef command in privileged EXEC mode: show ip cef [unresolved |summary].

To display specific entries in the FIB based on IP address information, use this form of the show ip cef command in privileged EXEC mode: show ip cef [network [mask [longer-prefix]]] [detail].

To display specific entries in the FIB based on interface information, use this form of the show ip cef command in privileged EXEC mode: show ip cef [type number] [detail].

Page 193: Implementing cisco mpls

3-54 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-11

Monitoring Label Switching:show mpls forwarding-table

᫬»®ý­¸±© ł°´­ ş±®©ż®Ľ·˛ąó¬żľ´» áßňŢňÝňÜ Ü»­¬·˛ż¬·±˛ °®»ş·¨Ľ»¬ż·´ Ü»¬ż·´»Ľ ·˛ş±®łż¬·±˛·˛¬»®şż˝» Óż¬˝¸ ±«¬ą±·˛ą ·˛¬»®şż˝»´żľ»´­ Óż¬˝¸ ´żľ»´ Şż´«»­´­°ó¬«˛˛»´ ÔÍĐ Ě«˛˛»´ ·Ľ˛»¨¬ó¸±° Óż¬˝¸ ˛»¨¬ ¸±° ˛»·ą¸ľ±®Ş®ş ͸±© »˛¬®·»­ ş±® ż ĘĐŇ

᫬·˛ąńÚ±®©ż®Ľ·˛ą ·˛­¬ż˛˝»¤ Ń«¬°«¬ ł±Ľ·ş·»®­ä˝®â

show mpls forwarding-table To display the contents of the MPLS LFIB, use this show mpls forwarding-table command in privileged EXEC mode: show mpls forwarding-table [{network {mask | length} | labels label[-label]| interface interface | next-hop address | lsp-tunnel [tunnel-id]}] [detail].

show mpls forwarding-table Syntax Description

Parameter Description

network (Optional) Displays destination network number

mask Displays IP address of destination mask whose entry is to be shown

length Displays number of bits in mask of destination

labels label-label (Optional) Shows only entries with specified local labels

interface interface (Optional) Shows only entries with specified outgoing interface

next-hop address (Optional) Shows only entries with specified neighbor as next hop

lsp-tunnel tunnel-id (Optional) Shows only entries with specified LSP tunnel, or all LSP tunnel entries

detail (Optional) Displays information in long form (includes length of encapsulation, length of MAC string, maximum transmission unit (MTU), and all labels)

Page 194: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-55

Examples: show mpls forwarding table Command Output This is a sample output from the show mpls forwarding table command.

᫬»®ý­¸±© ł°´­ ş±®©ż®Ľ·˛ąó¬żľ´»

Ô±˝ż´ Ń«¬ą±·˛ą Đ®»ş·¨ ާ¬»­ ¬żą Ń«¬ą±·˛ą Ň»¨¬ ر°

¬żą ¬żą ±® ĘÝ ±® Ě«˛˛»´ ׼ ­©·¬˝¸»Ľ ·˛¬»®şż˝»

îę ˲¬żąą»Ľ ďđňîëíňđňđńďę đ ۬ěńđńđ ďéîňîéňîíîňę

îč ďńíí ďđňďëňđňđńďę đ ßĚđńđňď °±·˛¬î°±·˛¬

îç б° ¬żą ďđňçďňđňđńďę đ Ř­ëńđ °±·˛¬î°±·˛¬

ďńíę ďđňçďňđňđńďę đ ßĚđńđňď °±·˛¬î°±·˛¬

íđ íî ďđňîëđňđňçéńíî đ ۬ěńđńî ďđňçîňđňé

íî ďđňîëđňđňçéńíî đ Ř­ëńđ °±·˛¬î°±·˛¬

íě îę ďđňééňđňđńîě đ ۬ěńđńî °±·˛¬î°±·˛¬

îę ďđňééňđňđńîě đ Ř­ëńđ °±·˛¬î°±·˛¬

íë ˲¬żąą»ĽĹĚĂ ďđňďđđňďđđňďđďńíî đ Ě«ď °±·˛¬î°±·˛¬

íę б° ¬żą ďęčňďňđňđńďę đ Ř­ëńđ °±·˛¬î°±·˛¬

ďńíé ďęčňďňđňđńďę đ ßĚđńđňď °±·˛¬î°±·˛¬

[T] = Forwarding through an LSP tunnel.

Note View additional tagging information with the detail option.

Page 195: Implementing cisco mpls

3-56 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-12

Monitoring Label Switching:show mpls forwarding-table detail

᫬»®ý­¸±© ł°´­ ş±®©ż®Ľ·˛ąó¬żľ´» Ľ»¬ż·´Ô±˝ż´ Ń«¬ą±·˛ą Đ®»ş·¨ ާ¬»­ ¬żą Ń«¬ą±·˛ą Ň»¨¬ ر° ¬żą ¬żą ±® ĘÝ ±® Ě«˛˛»´ ׼ ­©·¬˝¸»Ľ ·˛¬»®şż˝» éđ б° ¬żą ďçîňďęčňíňíńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

ÓßÝń۲˝ż°­ăěńěô ÓĚËăďëđěô Ěżą ͬż˝µĄŁďčÚďččěé ұ ±«¬°«¬ ş»ż¬«®» ˝±˛ş·ą«®»Ľ

Đ»®ó°ż˝µ»¬ ´±żĽó­¸ż®·˛ąéď б° ¬żą ďçîňďęčňíňěńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

ÓßÝń۲˝ż°­ăěńěô ÓĚËăďëđěô Ěżą ͬż˝µĄŁďčÚďččěé ұ ±«¬°«¬ ş»ż¬«®» ˝±˛ş·ą«®»Ľ

Đ»®ó°ż˝µ»¬ ´±żĽó­¸ż®·˛ąéî ďę ďçîňďęčňďňçéńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

ÓßÝń۲˝ż°­ăěńčô ÓĚËăďëđđô Ěżą ͬż˝µĄďęŁďčÚďččěé đđđďđđđđұ ±«¬°«¬ ş»ż¬«®» ˝±˛ş·ą«®»Ľ

Đ»®ó°ż˝µ»¬ ´±żĽó­¸ż®·˛ą

The table describes the significant fields in the display.

Page 196: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-57

show mpls forwarding table Field Description

Field Description

Local tag This field displays the label assigned by this router.

Outgoing tag or VC This field displays the label assigned by the next hop or virtual path identifier/virtual channel identifier (VPI/VCI) used to get to next hop. Some of the entries that you can specify in this column are as follows:

[T]: Forwarding is through an LSP tunnel.

untagged: There is no label for the destination from the next hop, or label switching is not enabled on the outgoing interface.

Pop tag: The next hop advertised an implicit null label for the destination, and this router popped the top label.

Prefix or Tunnel ID This field displays the address or tunnel to which packets with this label are going.

Bytes tag switched This field displays the number of bytes switched with this incoming label.

Outgoing interface This field displays the interface through which packets with this label are sent.

Next Hop This field displays the IP address of the neighbor that assigned the outgoing label.

MAC/Encaps This field displays the length in bytes of Layer 2 header, and length in bytes of packet encapsulation, including Layer 2 header and label header.

MTU This field displays the MTU of the labeled packet.

Tag Stack This field displays all the outgoing labels. If the outgoing interface is transmission convergence-ATM (TC-ATM), the virtual circuit descriptor (VCD) is also shown.

18F18847 00010000 This field displays the actual encapsulation in hexadecimal form. There is a space shown between Layer 2 and the label header.

Page 197: Implementing cisco mpls

3-58 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-13

Monitoring Label Switching:show ip cef detail

᫬»®ý­¸±© ·° ˝»ş ďçîňďęčňîđňđ Ľ»¬ż·´ďçîňďęčňîđňđńîěô Ş»®­·±˛ îíô ˝ż˝¸»Ľ żĽ¶ż˝»˛˝§ ¬± Í»®·ż´ďńđňîđ °ż˝µ»¬­ô 𠾧¬»­

¬żą ·˛ş±®łż¬·±˛ ­»¬´±˝ż´ ¬żąć íí¬żą ®»©®·¬» ©·¬¸ Í»ďńđňîô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć ĄíîŁ

Ş·ż ďçîňďęčňíňďđô Í»®·ż´ďńđňîô đ Ľ»°»˛Ľ»˛˝·»­˛»¨¬ ¸±° ďçîňďęčňíňďđô Í»®·ż´ďńđň´·Ľ żĽ¶ż˝»˛˝§¬żą ®»©®·¬» ©·¬¸ Í»ďńđňîô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć ĄíîŁ

show ip cef detail To display detailed FIB entry information for all FIB entries, use this show ip cef detailcommand in privileged EXEC mode: show ip cef [type number] [detail].

show ip cef detail Syntax Description

Parameter Description

unresolved (Optional) Displays unresolved FIB entries

summary (Optional) Displays a summary of the FIB

network (Optional) Displays the FIB entry for the specified destination network

mask (Optional) Displays the FIB entry for the specified destination network and mask

longer-prefix (Optional) Displays FIB entries for all more specific destinations

detail (Optional) Displays detailed FIB entry information

type number (Optional) Displays interface type and number for which to display FIB entries

Usage Guidelines

The show ip cef command without any keywords or arguments shows a brief display of all FIB entries.

The show ip cef detail command shows detailed FIB entry information for all FIB entries.

Page 198: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-59

Debugging MPLS and LDP This topic describes how to debug MPLS and LDP.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-14

Ľ»ľ«ą ł°´­ ´Ľ° ňňň

᫬»®ý

• Debugs TDP adjacencies, session establishment, and label bindings exchange

Debugging MPLS and LDP

Ľ»ľ«ą ł°´­ ´ş·ľ ›

᫬»®ý

• Debugs LFIB events: label creations, removals, rewrite, and so on

Ľ»ľ«ą ł°´­ °ż˝µ»¬­ Ĺ·˛¬»®şż˝»Ă

᫬»®ý

• Debugs labeled packets switched by the router

A large number of debug commands are associated with MPLS on Cisco IOS platforms. The debug mpls ldp commands debug various aspects of LDP protocol, from label distribution to exchange of the application layer data between adjacent LDP-speaking routers.

Note Use debug commands with caution. Enabling debugging can disrupt operation of the

router under high load conditions. Before you start a debug command, always consider

the output that the command may generate and the amount of time this may take. You

should also look at your CPU load before debugging by using the show processes

cpu command. Verify that you have ample CPU available before beginning the

debugging process.

The debug mpls lfib commands display LFIB-related events (allocation of new labels, removal of labels, and so on).

The debug mpls packets command displays all labeled packets switched by the router (through the specified interface).

Caution Use the debug mpls packets command with care, because it generates output for every

packet processed.

Furthermore, enabling the debug mpls packets command causes fast and distributed label

switching to be disabled for the selected interfaces. To avoid adversely affecting other

system activity, use this command only when traffic on the network is at a minimum.

Page 199: Implementing cisco mpls

3-60 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

debug mpls packets To display labeled packets switched by the host router, use the debug mpls packets command in privileged EXEC mode. To disable debugging output, use the no form of this command. This illustrates these two commands:

debug mpls packets [interface]

no debug mpls packets [interface]

debug mpls packets Syntax Description

Field Description

Hs0/0 Displays the identifier for the interface on which the packet was received or transmitted

Recvd Displays the packet received

Xmit Displays the packet transmitted

CoS Displays the class of service (CoS) field from the packet label header

TTL Displays the time-to-live (TTL) field from the packet label header

(no tag) Displays the last label popped off the packet and transmitted unlabeled

Tag(s) Displays a list of labels on the packet, ordered from the top of the stack to the bottom

Page 200: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-61

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-15

Summary

• The command will show only those interfaces that have had mpls enabled.

• Use the command to display the LIB table.

• Use the command to display the LFIB table.

• Use the command with care because it causes fast and distributed switching to be disabled.

Page 201: Implementing cisco mpls

3-62 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 202: Implementing cisco mpls

Lesson 4

Troubleshooting Frame-Mode MPLS on Cisco IOS Platforms

OverviewThis lesson looks at some of the common issues that arise in Multiprotocol Label Switching (MPLS) networks. For each issue discussed, there is a recommended troubleshooting procedure to resolve the issue.

It is very important to know what commands you can use to verify correct operation of MPLS in the network. The information here will help you when you encounter problems with frame-mode interfaces that have MPLS running in the network.

ObjectivesUpon completing this lesson, you will be able to describe how to troubleshoot frame-mode MPLS problems on Cisco IOS platforms. This ability includes being able to meet these objectives:

Identify the common issues that arise in MPLS networks

Solve LDP session startup issues

Solve label allocation issues that can arise in MPLS networks

Solve label distribution issues that can arise in MPLS networks

Solve packet-labeling issues that can arise in MPLS networks

Solve intermittent MPLS failures

Solve packet propagation issues in MPLS networks

Page 203: Implementing cisco mpls

3-64 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are Common Frame-Mode MPLS Issues? This topic identifies some of the common frame-mode issues that arise in MPLS networks.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-3

• The LDP session does not start.

• Labels are not allocated.

• Labels are not distributed.

• Packets are not labeled, although the labels have been distributed.

• MPLS intermittently breaks after an interface failure.

• Large packets are not propagated across the network.

Symptoms of Common Frame-Mode MPLS Issues

Here are the common issues that can be encountered while you are troubleshooting a frame-mode MPLS network:

The Label Distribution Protocol (LDP) session does not start.

The LDP session starts, but the labels are not allocated or distributed.

Labels are allocated and distributed, but the forwarded packets are not labeled.

MPLS stops working intermittently after an interface failure, even on interfaces totally unrelated to the failed interface.

Large IP packets are not propagated across the MPLS backbone, even though the packets were successfully propagated across the pure IP backbone.

This discussion will cover each of these issues and provide recommended steps for troubleshooting them.

Page 204: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-65

Solving LDP Session Startup Issues This topic describes how to solve LDP session startup issues found in MPLS networks.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-4

LDP Session Startup Issues

• Symptom

– LDP neighbors are not discovered.

• The show mpls ldp discovery command does not display expected LDP neighbors.

• Diagnosis

– MPLS is not enabled on the adjacent router.

• Verification

– Verify with the show mpls interface command on the adjacent router.

Diagnosis: If MPLS is enabled on an interface, but no neighbors are discovered, it is likely that MPLS is not enabled on the neighbor.

The router is sending discovery messages, but the neighbor is not replying because it does not have LDP enabled.

Solution: Enable MPLS on the neighboring router.

Page 205: Implementing cisco mpls

3-66 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-5

LDP Session Startup Issues (Cont.)

• Symptom

– LDP neighbors are not discovered.

• Diagnosis

– There is a label distribution protocol mismatch—TDP on one end, LDP on the other end.

• Verification

– Verify with the show mpls interface detail command on both routers.

Diagnosis: Another possibility is that the neighbor has a different label distribution protocol enabled on the interface, such as when LDP is enabled on one end and Tag Distribution Protocol (TDP) is enabled on the other end.

Solution: Use one of these solutions:

Change the label distribution protocol on this end.

Change the label distribution protocol on the other end.

Enable both label distribution protocols on this end.

Enable both label distribution protocols on the other end.

Page 206: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-67

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-6

LDP Session Startup Issues (Cont.)

• Symptom

– LDP neighbors are not discovered.

• Diagnosis

– Packet filter drops LDP neighbor discovery packets.

• Verification

– Verify access list presence with the command.

– Verify access list contents with the command.

Diagnosis: MPLS configurations match on both ends, but the session still does not get established. Check whether there are any input access lists that deny discovery messages.

Solution: Remove or change the access list to allow User Datagram Protocol (UDP) packets with source and destination port number 646 (711 for TDP).

Make sure that the access list also allows TCP to and from port 646 (711 for TDP).

Page 207: Implementing cisco mpls

3-68 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-7

LDP Session Startup Issues (Cont.)

• Symptom

– LDP neighbors are discovered; the LDP session is not established.

• The show mpls ldp neighbor command does not display a neighbor in operational state.

• Diagnosis

– The connectivity between loopback interfaces is broken; the LDP session is usually established between loopback interfaces of adjacent LSRs.

• Verification

– Verify connectivity with the extended command.

Diagnosis: LDP neighbors are exchanging hello packets, but the LDP session is never established.

Solution: Check the reachability of the loopback interfaces, because they are typically used to establish the LDP session. Make sure that the loopback addresses are exchanged via the Interior Gateway Protocol (IGP) used in the network.

Page 208: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-69

Solving Label Allocation Issues This topic describes how to solve label allocation issues that could arise in MPLS networks.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-8

Label Allocation Issues

• Symptom

– Labels are not allocated for local routes.

• The command does not display any labels.

• Diagnosis

– CEF is not enabled.

• Verification

– Verify with the command.

Diagnosis: Labels are not allocated for any or some of the local routes. Use the show ip cefcommand to verify whether Cisco Express Forwarding (CEF) switching is enabled on all MPLS-enabled interfaces.

Solution: Enable CEF switching by using the ip cef command in global configuration mode or the ip route-cache cef command in interface mode.

Page 209: Implementing cisco mpls

3-70 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Solving Label Distribution Issues This topic describes how to solve label distribution issues that can arise in MPLS networks.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-9

Label Distribution Issues

• Symptom

– Labels are allocated, but not distributed.

• Using the command on the adjacent LSR does not display labels from this LSR.

• Diagnosis

– There are problems with conditional label distribution.

• Verification

– Debug label distribution with the .

– Examine the neighbor LDP router IP address with the command.

– Verify that the neighbor LDP router IP address is matched by the access list specified in the command.

Symptom: Labels are generated for local routes on one label switch router (LSR) but are not received on neighboring LSRs.

Solution: Check whether conditional label advertising is enabled and verify both access lists that are used with the command.

Page 210: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-71

Solving Packet-Labeling Issues This topic describes how to solve packet-labeling issues that can arise in MPLS networks.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-10

Packet Labeling Issues

• Symptom

– Labels are distributed, but packets are not labeled.

• Using the command does not show that labeled packets are being sent.

• Diagnosis

– CEF is not enabled on the input interface (potentially because of a conflicting feature being configured).

• Verification

– Verify with the command.

Symptom: Labels exist, but packets are not labeled. The show interface accounting command does not display any labeled packets.

Solution: Enable CEF switching by using the ip route-cache cef interface command and make sure that there is no feature enabled on the interface that is not supported in combination with CEF switching. Verify whether CEF is enabled on an individual interface with the show cef interface command.

Page 211: Implementing cisco mpls

3-72 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-11

Packet Labeling Issues: show cef interface

᫬»®ý­¸±© ˝»ş ·˛¬»®şż˝»

Í»®·ż´ďńđňď ·­ «° ř·şÁ˛«łľ»® ďë÷

ײ¬»®˛»¬ żĽĽ®»­­ ·­ ďçîňďęčňíňëńíđ

×ÝÓĐ ®»Ľ·®»˝¬­ ż®» ż´©ż§­ ­»˛¬

Đ»® °ż˝µ»¬ ´±żĽľż´ż˛˝·˛ą ·­ Ľ·­żľ´»Ľ

×Đ «˛·˝ż­¬ ÎĐÚ ˝¸»˝µ ·­ Ľ·­żľ´»Ľ

ײľ±«˛Ľ ż˝˝»­­ ´·­¬ ·­ ˛±¬ ­»¬

Ń«¬ľ±«˛Ľ ż˝˝»­­ ´·­¬ ·­ ˛±¬ ­»¬

×Đ °±´·˝§ ®±«¬·˛ą ·­ Ľ·­żľ´»Ľ

ײ¬»®şż˝» ·­ łż®µ»Ľ ż­ °±·˛¬ ¬± °±·˛¬ ·˛¬»®şż˝»

Řż®Ľ©ż®» ·Ľľ ·­ Í»®·ż´ďńđ

Úż­¬ ­©·¬˝¸·˛ą ¬§°» ëô ·˛¬»®şż˝» ¬§°» ęě

×Đ ÝŰÚ ­©·¬˝¸·˛ą »˛żľ´»Ľ

×Đ ÝŰÚ ĘĐŇ Úż­¬ ­©·¬˝¸·˛ą ¬«®ľ± Ş»˝¬±®

ײ°«¬ şż­¬ ş´żą­ đ¨ďđđđô Ń«¬°«¬ şż­¬ ş´żą­ đ¨đ

·ş·˛Ľ»¨ íří÷

Í´±¬ ď Í´±¬ «˛·¬ đ ĘÝ óď

Ě®ż˛­ł·¬ ´·ł·¬ ż˝˝«ł«´ż¬±® đ¨đ řđ¨đ÷

×Đ ÓĚË ďëđđ

᫬»®ý­¸±© ˝»ş ·˛¬»®şż˝»

×Đ ÝŰÚ ­©·¬˝¸·˛ą »˛żľ´»Ľ

show cef interface The show cef interface command is used in privileged EXEC mode to display CEF interface information.

The table describes the parameters for the show cef interface type number [detail] command.

show cef interface Syntax Descriptions

Parameter Description

type number Displays interface number and the number about which to display CEF-related information

detail (Optional) Displays detailed CEF information for the specified interface port number

Usage Guidelines The show cef interface command is available on routers that have route processor (RP) cards and line cards.

You can use this command to show the CEF state on an individual interface.

Page 212: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-73

The table describes the significant fields in the display.

show cef interface Field Descriptions

Field Description

interface type number is {up | down}

Indicates status of the interface

Internet address Displays Internet address of the interface

ICMP redirects are {always sent | never sent}

Indicates how packet forwarding is configured

Per-packet load balancing Displays status of load balancing in use on the interface (enabled or disabled)

Inbound access list {# | Not set} Displays number of access lists defined for the interface

Outbound access list Displays number of access lists defined for the interface

Hardware idb is type number Displays interface type and number configured

Fast switching type Indicates switching mode in use—used for troubleshooting

IP Distributed CEF switching {enabled | disabled}

Indicates the switching path used

Slot n Slot unit n Displays the slot number

Transmit line accumulator Indicates the maximum number of packets allowed in the transmit queue

IP MTU Displays the value of the maximum transmission unit (MTU) size set on the interface

Page 213: Implementing cisco mpls

3-74 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Solving Intermittent MPLS Failures This topic describes how to solve intermittent MPLS failures.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-12

Intermittent MPLS Failures After Interface Failure

• Symptom

– The overall MPLS connectivity in a router intermittently breaks after an interface failure.

• Diagnosis

– The IP address of a physical interface is used for the LDP (or TDP) identifier. Configure a loopback interface on the router.

• Verification

– Verify the local LDP identifier with the command.

Symptom: MPLS connectivity is established, labels are exchanged, and packets are labeled and forwarded. However, an interface failure can sporadically stop an MPLS operation on unrelated interfaces in the same router.

Details: LDP sessions are established between IP addresses that correspond to the LDP LSR identifier (ID). The LDP LSR ID is assigned using the algorithm that is also used to assign an Open Shortest Path First (OSPF) or a Border Gateway Protocol (BGP) router ID.

This algorithm selects the highest IP address of an active interface if there are no loopback interfaces configured on the router. If that interface fails, the LDP LSR ID is lost and the TCP session carrying the LDP data is torn down, resulting in loss of all neighbor-assigned label information.

The symptom can be easily verified with the show mpls ldp neighbors command, which displays the local and remote LSR ID. Verify that both of these IP addresses are associated with a loopback interface.

Solution: Configure a loopback interface on the LSR.

Note The LDP LSR ID will change only after the router is reloaded.

Page 214: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-75

Solving Packet Propagation Issues This topic describes how to solve packet propagation issues in an MPLS network.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-13

Packet Propagation Issues

• Symptom

– Large packets are not propagated across the network.

• Use of the extended command with varying packet sizes fails for packet sizes close to 1500 packets.

– In some cases, MPLS might work, but MPLS VPN will fail.

• Diagnosis

– There are label MTU issues or switches that do not support jumbo frames in the forwarding path.

• Verification

– Issue the command through the forwarding path; identify all LAN segments in the path.

– Verify the label MTU setting on routers attached to LAN segments.

– Check for low-end switches in the transit path.

Symptom: Packets are labeled and sent, but they are not received on the neighboring router. A LAN switch between the adjacent MPLS-enabled routers may drop the packets if it does not support jumbo frames. In some cases, MPLS might work, but MPLS Virtual Private Network (VPN) will fail.

Solution: Change the MPLS MTU size, taking into account the maximum number of labels that may appear in a packet.

Page 215: Implementing cisco mpls

3-76 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-14

Summary

• Some common frame-mode issues are as follows: LDP session does not start, labels are not allocated or distributed, and MPLS intermittently breaks after an interface failure.

• One LDP session startup issue is when LSP neighbors are not discovered.

• A label allocation issue is one in which the labels are not allocated for local routes.

• Labels may be allocated but not distributed correctly.

• Ensure that there are no conflicts between CEF and any other configured features; otherwise, packets might not be labeled.

• Use loopback IP addresses, not a configured interface IP address, to avoid MPLS connectivity intermittently breaking down.

• Large packets are not propagated across the network.

Page 216: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-77

Module Summary This topic summarizes the key points that were discussed in this module.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-1

Module Summary

• CEF must be running as a prerequisite to running MPLS on a Cisco router.

• Frame-mode MPLS requires CEF switching and MPLS enabled on appropriate interfaces. Optional items include MPLS ID, MTU, IP TTL, and conditional label advertisement.

• When you encounter problems with frame-mode MPLS interfaces, it is helpful to know the procedures for monitoring MPLS on Cisco IOS platforms.

• When you verify correct operation of MPLS in the network, you will also need to know the recommended troubleshooting procedures.

There are many detailed configuration, monitoring, and debugging guidelines when

implementing frame-mode Multiprotocol Label Switching (MPLS) on Cisco IOS platforms.

Advanced technologies, such as time-to-live (TTL) propagation and label distribution, are also

critical when switching implementations.

ReferencesFor additional information, refer to these resources:

Cisco Express Forwarding Overview http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca7cb.html

Configuring Cisco Express Forwarding http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca7cc.html

Multiprotocol Label Switching Overviewhttp://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca7cc.html

Page 217: Implementing cisco mpls

3-78 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Module Self-Check Use the questions here to review what you learned in this module. The correct answers and solutions are found in the Module Self-Check Answer Key.

Q1) What is another name for topology-driven switching? (Source: Introducing CEF

Switching)

A) CEFB) fast switching C) cache switching D) process switching

Q2) What is the command to monitor CEF? (Source: Introducing CEF Switching)

A) Router#show cefB) Router#show mpls ip cefC) Router#show ip cefD) Router#show mpls cef

Q3) What is the command to enable CEF on a Cisco router? (Source: Introducing CEF

Switching)

A) Router(config)#mpls ip cefB) Router(config)#ip mpls cefC) Router(config)#cefD) Router(config)#ip cef

Q4) In CEF switching, what is the difference between the adjacency table and the ARP

cache? (Source: Introducing CEF Switching)

A) The adjacency table holds the Layer 2 header, and the ARP cache does not. B) The ARP cache holds the Layer 2 header, and the adjacency table does not. C) Both the adjacency table and the ARP cache hold the Layer 2 header. D) Neither the adjacency table nor the ARP cache holds the Layer 2 header.

Q5) What happens to a packet that should be fast-switched but the destination is not in the

switching cache? (Source: Introducing CEF Switching)

A) The packet is dropped. B) The packet is cache-switched. C) The packet is process-switched. D) CEF switching is used.

Q6) If IP TTL propagation is not allowed, what is the value that is placed in the MPLS

header? (Source: Configuring Frame-Mode MPLS on Cisco IOS Platforms)

A) 0B) 1C) 254D) 255

Q7) The MPLS MTU is increased to _____ to support 1500-byte IP packets and MPLS

stacks up to 3 levels deep. (Source: Configuring Frame-Mode MPLS on Cisco IOS

Platforms)

Page 218: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-79

Q8) What is the correct command to enable MPLS in Cisco IOS software? (Source:

Configuring Frame-Mode MPLS on Cisco IOS Platforms)

A) Router(config)#ip mplsB) Router(config-if)#ip mplsC) Router(config)#mpls ipD) Router(config-if)#mpls ip

Q9) Which two steps are NOT mandatory to enable MPLS? (Choose two.) (Source:

Configuring Frame-Mode MPLS on Cisco IOS Platforms)

A) Enable CEF switching. B) Configure the size of the label pool. C) Configure the MTU size for labeled packets. D) Configure LDP (or TDP) on every interface that will run MPLS.

Q10) What needs to be configured to specify which neighbors would selectively receive

label advertisements? (Source: Configuring Frame-Mode MPLS on Cisco IOS

Platforms)

A) Controlled label distribution needs to be configured. B) Conditional label distribution needs to be configured. C) Unsolicited label distribution needs to be configured. D) All neighbors will receive all labels.

Q11) If frame-mode MPLS is run on ATM interfaces, LDP or LDP neighbor relationships

are established between the _____ routers. (Source: Configuring Frame-Mode MPLS

on Cisco IOS Platforms)

Q12) Which command is used to display information about the LDP Hello protocol timers?

(Source: Monitoring Frame-Mode MPLS on Cisco IOS Platforms)

A) show ip cefB) show mpls ldp parametersC) show ldp forwarding-tableD) show mpls ldp discovery

Q13) Which command is used to display the contents of the LIB table? (Source: Monitoring

Frame-Mode MPLS on Cisco IOS Platforms)

A) show mpls ldp labelsB) show mpls ldp bindingsC) show mpls ldp neighborsD) show mpls forwarding-table

Q14) Which command is used to display the contents of the LFIB table? (Source: Monitoring

Frame-Mode MPLS on Cisco IOS Platforms)

A) show mpls ldp labelsB) show mpls ldp bindingsC) show mpls ldp neighborsD) show mpls forwarding-table

Page 219: Implementing cisco mpls

3-80 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q15) Which command would NOT be used to debug MPLS or LDP? (Source: Monitoring

Frame-Mode MPLS on Cisco IOS Platforms)

A) debug mpls ldpB) debug mpls lfibC) debug mpls packetsD) debug mpls ldp neighbors

Q16) Which two of the answer choices would cause an LDP (or TDP) session NOT to be

established between two LSRs? (Choose two.) (Source: Troubleshooting Frame-Mode

MPLS on Cisco IOS Platforms)

A) an access list that allows TCP/UDP port number 646 B) an access list that allows TCP/UDP port number 711 C) an access list that does not allow TCP/UDP port number 646 D) an access list that does not allow TCP/UDP port number 711

Q17) Which command is issued to troubleshoot label allocation issues? (Source:

Troubleshooting Frame-Mode MPLS on Cisco IOS Platforms)

A) show cefB) show lfibC) show ip cefD) show mpls lfib

Q18) Which command is issued to see if labels are being distributed from the local LSR?

(Source: Troubleshooting Frame-Mode MPLS on Cisco IOS Platforms)

A) show mpls ldp lib (on the local router) B) show mpls ldp lib (on the remote router) C) show mpls ldp bindings (on the local router) D) show mpls ldp bindings (on the remote router)

Q19) Which command displays CEF interface information? (Source: Troubleshooting

Frame-Mode MPLS on Cisco IOS Platforms)

A) router#show mpls cef interfaceB) router#show cef interfaceC) router(config)#show cef interfaceD) router(config)#show mpls cef interface

Q20) To reduce the chances of having intermittent MPLS failures because of an interface

failing, a _____ address should be configured. (Source: Troubleshooting Frame-Mode

MPLS on Cisco IOS Platforms)

Q21) A LAN switch is in the network path between two LSRs. It has been discovered that

large packets are not being propagated across the network. Which of the answer

choices represents the most possible cause? (Source: Troubleshooting Frame-Mode

MPLS on Cisco IOS Platforms)

A) The precedence bit has not been set in the MPLS label. B) The TTL has not been set correctly to address this issue. C) The MTU size has not been set correctly to address this issue. D) This is not a legal configuration. LSRs must be directly connected.

Page 220: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Frame-Mode MPLS Implementation on Cisco IOS Platforms 3-81

Module Self-Check Answer Key Q1) A

Q2) C

Q3) D

Q4) A

Q5) C

Q6) D

Q7) 1512

Q8) D

Q9) B, C

Q10) B

Q11) PVC endpoint

Q12) B

Q13) B

Q14) D

Q15) D

Q16) C, D

Q17) C

Q18) D

Q19) B

Q20) loopback

Q21) C

Page 221: Implementing cisco mpls

3-82 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 222: Implementing cisco mpls

Module 4

MPLS VPN Technology

OverviewThis module introduces Virtual Private Networks (VPNs) and two major VPN design options: the overlay VPN and the peer-to-peer VPN. The module also introduces VPN terminology and topologies, and describes Multiprotocol Label Switching (MPLS) VPN architecture and operations. This module details various customer edge-provider edge (CE-PE) routing options and Border Gateway Protocol (BGP) extensions (route targets and extended community attributes) that allow Internal Border Gateway Protocol (IBGP) to transport customer routes over a provider network. The MPLS VPN forwarding model is also covered together with how it integrates with core routing protocols.

Module Objectives Upon completing this module, you will be able to describe the MPLS peer-to-peer architecture and explain the routing and packet-forwarding model in this architecture. This ability includes being able to meet these objectives:

Identify the major terminology and topology of VPNs

Describe the characteristics of the different VPN topologies

Describe the major architectural components of an MPLS VPN

Identify the routing requirements for MPLS VPNs

Describe how packets are forwarded in an MPLS VPN environment

Page 223: Implementing cisco mpls

4-2 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 224: Implementing cisco mpls

Lesson 1

Introducing VPNs

OverviewThis lesson explains the concept of Virtual Private Networks (VPNs), and explains the VPN terminology that is also used by the Multiprotocol Label Switching (MPLS) VPN architecture. The lesson looks at why VPNs were first introduced, and also explains the differences between the overlay and peer-to-peer VPN models, how they are implemented, and the benefits and drawbacks of each implementation.

It is important to understand the background of VPNs, because you should be able to determine when an organization might need a VPN, and explain how MPLS VPNs can help save time and money. Understanding the different types of VPNs will allow you to recognize where the various types of VPNs would be best used in their associated networks.

ObjectivesUpon completing this lesson, you will be able to identify the major terminology and topology of VPNs. This ability includes being able to meet these objectives:

Describe the connectivity of traditional router-based networks

Describe the advantages of VPN connectivity as compared to traditional router-based networks

Identify the two major VPN implementation models

— Describe the characteristics and technologies of overlay VPNs

— Describe the characteristics and technologies of peer-to-peer VPNs

— Describe the benefits of each type of VPN model

— Describe the drawbacks of each VPN model

Page 225: Implementing cisco mpls

4-4 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Traditional Router-Based Network Connectivity This topic describes the connectivity of traditional router-based networks.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-3

Traditional Router-Based Networks

Traditional router-based networks connect customer sites through routers connected via dedicated point-to-point links.

Traditional router-based networks were implemented with dedicated point-to-point links connecting customer sites. The cost of this approach was comparatively high for these reasons:

The dedicated point-to-point links prevented any form of statistical infrastructure sharing on the service provider side, resulting in high costs for the end user.

Every link required a dedicated port on a router, resulting in high equipment costs.

Page 226: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-5

Advantages of VPNs This topic describes the advantages of VPN connectivity as compared to traditional router-based networks.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-4

Virtual Private Networks

• VPNs replace dedicated point-to-point links with emulated point-to-point links sharing common infrastructure.

• Customers use VPNs primarily to reduce their operational costs.

VPNs were introduced very early in the history of data communications with technologies such as X.25 and Frame Relay, which use virtual circuits to establish the end-to-end connection over a shared service provider infrastructure. Although X.25 and Frame Relay are sometimes considered legacy technologies and obsolete, they still share these basic benefits with modern VPNs:

The dedicated links of traditional router-based networks have been replaced with a common infrastructure that emulates point-to-point links for the customer, resulting in statistical sharing of the service provider infrastructure.

Statistical sharing of the infrastructure enables the service provider to offer connectivity for a lower price, resulting in lower operational costs for the end user.

Example: VPNs The figure shows the statistical sharing, where the customer premises equipment (CPE) router on the left has one physical connection to the provider edge (PE) device, and two virtual circuits have been provisioned. Virtual circuit #1 provides connectivity to the top CPE router on the right. Virtual circuit #2 provides connectivity to the bottom CPE router on the right.

Page 227: Implementing cisco mpls

4-6 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

VPN Terminology This topic identifies the terminology used in describing VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-5

VPN Terminology

There are many conceptual models and terminologies describing various VPN technologies and implementations. The terminology is generic enough to cover nearly any VPN technology or implementation and is thus extremely versatile.

The major parts of an overall VPN solution are always those listed here:

Provider network (P-network): The common infrastructure that the service provider uses to offer VPN services to customers

Customer network (C-network): The part of the overall customer network that is still exclusively under customer control

Customer sites: Contiguous parts of the C-network

A typical C-network implemented with any VPN technology would contain islands of connectivity under customer control (customer sites) connected together via the service provider infrastructure (P-network).

Page 228: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-7

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-6

VPN Terminology (Cont.)

Here is a description of the devices that enable the overall VPN solution, which are named based on their position in the network:

The customer router that connects the customer site to the service provider network is called a customer edge (CE) router, or CE device. Traditionally, this device is called CPE.

Service provider devices to which customer devices are attached are called PE devices. In traditional switched WAN implementations, these devices would be Frame Relay or X.25 edge switches. In an MPLS implementation, these devices would be the edge label switch routers (edge LSRs).

Service provider devices that provide only data transport across the service provider backbone, and have no customers attached to them, are called provider (P) devices. In traditional switched WAN implementations, these devices would be core (or transit) switches. In an MPLS implementation, these devices would be the LSRs.

Note The connecting device is still called a CE device even if it is not a router. For example, a

packet assembler/disassembler (PAD) is a CE device.

Page 229: Implementing cisco mpls

4-8 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are the VPN Implementation Models? This topic describes the two major VPN implementation models.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-7

VPN Implementation Models

VPN services can be offered based on two major models:

• Overlay VPNs, in which the service provider provides virtual point-to-point links between customer sites

• Peer-to-peer VPNs, in which the service provider participates in the customer routing

Traditional VPN implementations were all based on the overlay model, in which the service provider sold virtual circuits between customer sites as a replacement for dedicated point-to-point links. The overlay model had a number of drawbacks, which are identified in this lesson. To overcome these drawbacks (particularly in IP-based customer networks), a new model called the peer-to-peer VPN was introduced. In the peer-to-peer VPN model, the service provider actively participates in customer routing.

Page 230: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-9

What Are Overlay VPN Technologies? This topic describes the characteristics and technologies of overlay VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-8

Overlay VPNs: Hub-and-Spoke Topology

The hub-and-spoke topology is the simplest overlay VPN topology—all remote sites are linked with a single virtual circuit to a central CE router. The routing is also extremely simple—static routing or a distance vector protocol such as Routing Information Protocol (RIP) is more than adequate. If a dynamic routing protocol such as RIP is used, split-horizon updates must be disabled at the hub router or point-to-point subinterfaces must be used at the hub router to overcome the split-horizon problem.

Page 231: Implementing cisco mpls

4-10 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-9

Overlay VPNs:Redundant Hub-and-Spoke Topology

A typical redundant hub-and-spoke topology introduces central site redundancy (more complex topologies might also introduce router redundancy at spokes).

Each remote site is linked with two central routers via two virtual circuits. The two virtual circuits can be used for load sharing or in a primary circuit with backup circuit configuration.

Page 232: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-11

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-10

Overlay VPNs:Layer 2 Implementation

This is the traditional switched WAN solution:

• The service provider establishes Layer 2 virtual circuits between customer sites.

• The customer is responsible for all higher layers.

A Layer 2 overlay VPN implementation is the traditional switched WAN model, implemented with technologies such as X.25, Frame Relay, ATM, and Switched Multimegabit Data Service (SMDS). The service provider is responsible for transport of Layer 2 frames between customer sites, and the customer is responsible for all higher layers.

Page 233: Implementing cisco mpls

4-12 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-11

Overlay VPNs:IP Tunneling

VPN is implemented with IP-over-IP tunnels:

• Tunnels are established with GRE or IPsec.

• GRE is simpler (and quicker); IPsec provides authentication and security.

With the success of IP and associated technologies, some service providers started to implement pure IP backbones to offer VPN services based on IP. In other cases, customers wanted to take advantage of the low cost and universal availability of the Internet to build low-cost private networks over it.

Whatever the business reasons behind it, Layer 3 VPN implementations over the IP backbone always involve tunneling—encapsulation of protocol units at a certain layer of the Open Systems Interconnection (OSI) reference model into protocol units at the same or higher layer of the OSI model.

Two well-known tunneling technologies are IP Security (IPsec) and generic routing encapsulation (GRE). GRE is fast and simple to implement and supports multiple routed protocols, but it provides no security and is thus unsuitable for deployment over the Internet. An alternative tunneling technology is IPsec, which provides network layer authentication and optional encryption to make data transfer over the Internet secure. IPsec supports only the IP routed protocol.

Page 234: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-13

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-12

Overlay VPNs:Layer 2 Forwarding

• VPN is implemented with PPP-over-IP tunnels.

• VPN is usually used in access environments (dialup, digital subscriber line).

Yet another tunneling technique was first implemented in dialup networks, where service providers wanted to tunnel customer dialup data encapsulated in PPP frames over an IP backbone to the customer central site. To make the service provider transport transparent to the customer, PPP frames are exchanged between the customer sites (usually a dialup user and a central site) and the customer is responsible for establishing Layer 3 connectivity above PPP.

Here are three well-known PPP forwarding implementations:

Layer 2 Forwarding Protocol (L2F Protocol)

Layer 2 Tunneling Protocol (L2TP)

Point-to-Point Tunneling Protocol (PPTP)

Page 235: Implementing cisco mpls

4-14 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-13

Overlay VPNs:Layer 3 Routing

• The service provider infrastructure appears as point-to-point links to customer routes.

• Routing protocols run directly between customer routers.

• The service provider does not see customer routes and is responsible only for providing point-to-point transport of customer data.

From the Layer 3 perspective, the P-network is invisible to the customer routers, which are linked with emulated point-to-point links. The routing protocol runs directly between customer routers that establish routing adjacencies and exchange routing information.

The service provider is not aware of customer routing and has no information about customer routes. The responsibility of the service provider is purely the point-to-point data transport between customer sites.

The overlay VPN model has a number of drawbacks, most significantly the need for customers to establish point-to-point links or virtual circuits between sites. The formula to calculate how many point-to-point links or virtual circuits are needed in the worst case is ([n][n-1])/2, where nis the number of sites to be connected. For example, if you need to have full mesh connectivity between four sites, you will need a total of six point-to-point links or virtual circuits: (4 * (4-1)) / 2. This leads to scalability issues.

Page 236: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-15

What Are Peer-to-Peer VPN Technologies? This topic describes the characteristics and technologies of peer-to-peer VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-14

Peer-to-Peer VPNs:Implementation Techniques

To overcome the scalability issue and provide the customer with optimum data transport across the service provider backbone, the peer-to-peer VPN concept was introduced. Here, the service provider actively participates in customer routing, accepting customer routes, transporting those customer routes across the service provider backbone, and finally propagating them to other customer sites.

Page 237: Implementing cisco mpls

4-16 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-15

Peer-to-Peer VPNs:Packet Filters

The first peer-to-peer VPN solutions appeared with the widespread deployment of IP in service provider networks. Architectures similar to that of the Internet were used to build them. Special provisions were taken into account to transform the architecture, which was targeted toward public backbones (Internet), into a solution in which customers would be totally isolated and be able to exchange corporate data securely.

The more common peer-to-peer VPN implementation allowed a PE router to be shared between two or more customers. Packet filters were used on the shared PE routers to isolate the customers. In this implementation, it was common for the service provider to allocate a portion of its address space to each customer and manage the packet filters on the PE routers to ensure full reachability between sites of a single customer and isolation between separate customers.

Page 238: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-17

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-16

Peer-to-Peer VPNs:Controlled Route Distribution

Maintaining packet filters is a mundane and error-prone task. Some service providers have thus implemented more innovative solutions based on controlled route distribution. In this approach, the customer has a dedicated PE router. The core service provider (P) routers contain all customer routes, and the dedicated PE routers contain only the routes of a single customer. This approach requires a dedicated PE router per customer per point of presence (POP). Customer isolation is achieved solely through lack of routing information on the PE router.

Example: Controlled Route Distribution

In the figure, the PE router for customer A, using route filtering between the P router and the PE routers, learns only routes belonging to customer A, and the PE router for customer B learns only routes belonging to customer B. Border Gateway Protocol (BGP) with BGP communities is usually used inside the provider backbone, because it offers the most versatile route-filtering tools.

Note Default routes used anywhere in the C-network or P-network break isolation between

customers and have to be avoided.

Page 239: Implementing cisco mpls

4-18 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are the Benefits of VPNs? This topic describes the benefits of the two VPN models.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-17

Benefits of VPN Implementations

• Overlay VPN:

– Well-known and easy to implement

– Service provider does not participate in customer routing

– Customer network and service provider network are well-isolated

• Peer-to-peer VPN:

– Guarantees optimum routing between customer sites

– Easier to provision an additional VPN

– Only sites provisioned, not links between them

Each VPN model has a number of benefits. For example, overlay VPNs have these advantages:

Overlay VPNs are well-known and easy to implement from both customer and service provider perspectives.

The service provider does not participate in customer routing, making the demarcation point between service provider and customer easier to manage.

On the other hand, peer-to-peer VPNs provide these advantages:

Optimum routing between customer sites without any special design or configuration effort

Easy provisioning of additional VPNs or customer sites, because the service provider provisions only individual sites, not the links between individual customer sites

Page 240: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-19

What Are the Drawbacks of VPNs? This topic describes the drawbacks of the VPN models.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-18

Drawbacks of VPN Implementations

• Overlay VPN:

– Implementing optimum routing requires a full mesh of virtual circuits.

– Virtual circuits have to be provisioned manually.

– Bandwidth must be provisioned on a site-to-site basis.

– Overlay VPNs always incur encapsulation overhead.

• Peer-to-peer VPN:

– The service provider participates in customer routing.

– The service provider becomes responsible for customer convergence.

– PE routers carry all routes from all customers.

– The service provider needs detailed IP routing knowledge.

Each VPN model also has a number of drawbacks. Overlay VPNs have these disadvantages:

Overlay VPNs require a full mesh of virtual circuits between customer sites to provide optimum intersite routing.

All virtual circuits between customer sites have to be provisioned manually, and the bandwidth must be provisioned on a site-to-site basis (which is not always easy to achieve).

The IP-based overlay VPN implementations (with IPsec or GRE) incur high encapsulation overhead—ranging from 20 bytes to 80 bytes per transported datagram.

The major drawbacks of peer-to-peer VPNs arise from service provider involvement in customer routing, such as these disadvantages:

The service provider becomes responsible for correct customer routing and for fast convergence of the C-network following a link failure.

The service provider PE routers have to carry all customer routes that were hidden from the service provider in the overlay VPN model.

The service provider needs detailed IP routing knowledge, which is not readily available in traditional service provider teams.

Page 241: Implementing cisco mpls

4-20 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-19

Summary

• Traditional router-based networks connect via dedicated point-to-point links.

• VPNs use emulated point-to-point links sharing a common infrastructure.

• The two major VPN models are overlay VPN and peer-to-peer VPN.

– Overlay VPNs use well-known technologies and are easy to implement.

– Overlay VPN virtual circuits must be provisioned manually.

– Peer-to-peer VPNs guarantee optimum routing between customer sites.

– Peer-to-peer VPNs require that the service provider participate in customer routing.

Page 242: Implementing cisco mpls

Lesson 2

Categorizing VPNs

Overview This lesson explains how Virtual Private Networks (VPNs) can be categorized based on business needs or connectivity requirements.

It is important to understand the different categories of VPNs and to know into which environments those VPNs can be applied.

Objectives Upon completing this lesson, you will be able to describe the characteristics of the different VPN topology categories. This ability includes being able to meet these objectives:

Identify the major business categories for VPNs

Describe the characteristics of extranet VPNs

Identify the major connectivity categories for VPNs

Describe the characteristics of central services extranet VPNs

Describe the characteristics of managed network VPNs

Page 243: Implementing cisco mpls

4-22 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are the Business Categories for VPNs? This topic describes how VPNs can be categorized based on business needs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�4-3

VPN Business Category

VPNs can be categorized based on the business needs that they fulfill:

• Intranet VPNs connect sites within an organization.

• Extranet VPNs connect different organizations in a secure way.

• Access VPNs (VPDNs) provides dialup access into a customer network.

Here is a list of some very popular VPN categories that classify VPNs based on the business needs that they fulfill:

Intranet VPN: Intranet VPNs connect sites within an organization. Security mechanisms are usually not deployed in an intranet, because all sites belong to the same organization.

Extranet VPN: Extranet VPNs connect different organizations. Extranets usually rely on security mechanisms to ensure the protection of participating individual organizations. Security mechanisms are usually the responsibility of individual participating organizations.

Access VPN: Access VPNs are virtual private dial-up networks (VPDNs) that provide dialup access into a customer network.

Page 244: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-23

What Are Extranet VPNs? This topic describes the characteristics of extranet VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�4-4

Extranet VPNs:Overlay VPN Implementation

In an overlay implementation of an extranet, organizations are linked with dedicated virtual circuits.

Example: Overlay VPN�Extranet VPNs This figure illustrates an overlay VPN implementation of an extranet. Traffic between two organizations can flow only if one of these conditions is met:

There is a direct virtual circuit between the organizations.

A third organization linked with both organizations is willing to provide transit traffic capability to those organizations. Because establishing virtual circuits between two organizations is always associated with costs, the transit traffic capability is almost never granted free of charge.

Page 245: Implementing cisco mpls

4-24 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: Peer-to-Peer VPN Extranet VPNs This figure illustrates a peer-to-peer VPN implementation of an extranet.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�4-5

Extranet VPNs:Peer-to-Peer VPN Implementation

Peer-to-peer VPN implementation of an extranet VPN is very simple compared with overlay VPN implementation—all sites are connected to the provider network (P-network), and optimum routing between sites is enabled by default.

The cost model of peer-to-peer implementation is also simpler—usually every organization pays its connectivity fees for participation in the extranet and gets full connectivity to all other sites.

Page 246: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-25

What Are the Connectivity Categories for VPNs? This topic identifies the major connectivity categories for VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�4-6

VPN Connectivity Category

VPNs can also be categorized according to the connectivity required between sites:

• Simple VPN: Every site can communicate with every other site.

• Overlapping VPNs: Some sites participate in more than one simple VPN.

• Central services VPN: All sites can communicate with central servers but not with each other.

• Managed network: A dedicated VPN is established to manage CE routers.

The VPNs discussed so far have usually been very simple in terms of connectivity, as described here:

In most cases, full connectivity between sites is required. (In an overlay implementation of either an intranet or extranet VPN, this requirement usually means that a common site acts as a transit site).

In an overlay implementation of an extranet VPN, the connectivity is limited to sites that have direct virtual circuits established between them.

Here are descriptions of a number of advanced VPN topologies with more complex connectivity requirements:

Overlapping VPN connectivity, in which a site participates in more than one VPN

Central services VPNs, in which the sites are split into two classes: server sites, which can communicate with all other sites, and client sites, which can communicate only with the servers, not with other clients

Network management VPNs, which are used to manage customer edge (CE) devices in scenarios where the service provider owns and manages the devices

Page 247: Implementing cisco mpls

4-26 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Is the Central Services Extranet? This topic describes the characteristics of central services extranet VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�4-7

Central Services Extranet

A service provider can integrate the business and connectivity attributes of VPNs to offer a central services extranet to its customers. For example, a service provider can provide international Voice over IP (VoIP) service.

Example: Central Services Extranet

The figure illustrates this example. Every customer of this service can access voice gateways in various countries but cannot access other customers using the same service.

Page 248: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-27

What Is a Managed Network Implementation? This topic describes the characteristics of managed network VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�4-8

Managed NetworkOverlay VPN Implementation

A managed network VPN is traditionally implemented in combination with overlay VPN services. Dedicated virtual circuits are deployed between any managed CE router and the central network management system (NMS) router to which the NMS is connected.

This managed network VPN implementation is sometimes called a “rainbow” implementation because the physical link between the NMS router and the core of the service provider network carries a number of virtual circuits—one circuit per managed router.

Page 249: Implementing cisco mpls

4-28 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: Hybrid Implementation

The network diagram shows an interesting scenario in which a peer-to-peer VPN and an overlay VPN implementation can be used together to provide end-to-end service to the customer.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�4-9

Central Services Extranet:Hybrid (Overlay + Peer-to-Peer) Implementation

The VoIP service is implemented with a central services extranet topology, which is in turn implemented with a peer-to-peer VPN. Connectivity between provider edge (PE) routers in the peer-to-peer VPN and customer routers is implemented with an overlay VPN based on Frame Relay. The PE routers of the peer-to-peer VPN and the CE routers act as CE devices of the Frame Relay network.

Page 250: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-29

Summary This topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�4-10

Summary

• There are three VPN business categories: intranet VPN, extranet VPN, and access VPN.

• In an extranet VPN, organizations are linked with dedicated virtual circuits.

• There are four VPN connectivity categories: simple VPN, overlapping VPN, central service VPN, and managed network.

• A central services extranet enables customers to access common servers for services.

• Managed networks allow customer CE devices to be owned and managed by the service provider.

Page 251: Implementing cisco mpls

4-30 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 252: Implementing cisco mpls

Lesson 3

Introducing MPLS VPN Architecture

OverviewThis lesson explains the Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) architecture, route information propagation, route distinguishers (RDs), route targets (RTs), and virtual routing tables.

It is important to understand how the MPLS VPN architecture is structured, what the components of that architecture are, and how the components are used. This knowledge will help later when you begin to look at design issues and configuration parameters.

ObjectivesUpon completing this lesson, you will be able to describe the major architectural components of an MPLS VPN. This ability includes being able to meet these objectives:

Describe the drawbacks of traditional peer-to-peer VPNs

Describe the features of the MPLS VPN architecture

Describe the architecture of a PE router in an MPLS VPN

Describe the different methods of propagating routing information across the provider network

Describe the features of RDs

Describe the features of RTs

Describe how complex VPNs have redefined the meaning of VPNs

Describe the impact of complex VPN topologies on virtual routing tables

Page 253: Implementing cisco mpls

4-32 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are the Drawbacks of Traditional Peer-to-Peer VPNs?

This topic describes the drawbacks of the traditional peer-to-peer VPN implementation model.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-3

Drawbacks of Traditional Peer-to-Peer VPNs

• Shared PE router:

– All customers share the same (provider-assigned or public) address space.

– High maintenance costs are associated with packet filters.

– Performance is lower—each packet has to pass a packet filter.

• Dedicated PE router:

– All customers share the same address space.

– Each customer requires a dedicated router at each POP.

Pre-MPLS implementations of peer-to-peer VPNs all share a common drawback. Customers have to share the same global address space, either using their own public IP addresses or relying on provider-assigned IP addresses. In both cases, connecting a new customer to a peer-to-peer VPN service usually requires IP renumbering inside the customer network (C-network)—an operation most customers are reluctant to perform.

Peer-to-peer VPNs based on packet filters also incur high operational costs associated with packet filter maintenance and performance degradation because of heavy use of packet filters.

Peer-to-peer VPNs implemented with per-customer provider edge (PE) routers are easier to maintain and can provide optimum routing performance, but they are usually more expensive because every customer requires a dedicated router in every point of presence (POP). Thus, this approach is usually used if the service provider has only a small number of large customers.

Page 254: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-33

What Is the MPLS VPN Architecture? This topic describes the features of the MPLS VPN architecture.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-4

MPLS VPN Architecture

An MPLS VPN combines the best features of an overlay VPN and a peer-to-peer VPN:

• PE routers participate in customer routing, guaranteeing optimum routing between sites and easy provisioning.

• PE routers carry a separate set of routes for each customer (similar to the dedicated PE router approach).

• Customers can use overlapping addresses.

The MPLS VPN architecture offers service providers a peer-to-peer VPN architecture that combines the best features of overlay VPNs (support for overlapping customer address spaces) with the best features of peer-to-peer VPNs. This list describes these characteristics:

PE routers participate in customer routing, guaranteeing optimum routing between customer sites.

Note In an MPLS VPN implementation, the PE router is the edge label switch router (edge LSR).

PE routers carry a separate set of routes for each customer, resulting in perfect isolation between customers.

Customers can use overlapping addresses.

Page 255: Implementing cisco mpls

4-34 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-5

MPLS VPN Architecture:Terminology

Note:

• PE Router = Edge LSR

• P Router = LSR

MPLS VPN terminology divides the overall network into a customer-controlled part (the C-network) and a provider-controlled part (the provider network [P-network]). Contiguous portions of the C-network are called sites and are linked with the P-network via customer edge (CE) routers. The CE routers are connected to the PE routers, which serve as the edge devices of the P-network. The core devices in the P-network, the provider routers (P routers), provide transit transport across the provider backbone and do not carry customer routes.

Note In an MPLS VPN implementation, the P router is the LSR.

Page 256: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-35

What Is the Architecture of a PE Router in an MPLS VPN?

This topic describes the architecture of a PE router in an MPLS VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-6

PE Router Architecture

• PE router in an MPLS VPN uses virtual routing tables to implement the functionality of customer dedicated PE routers.

The architecture of a PE router in an MPLS VPN is very similar to the architecture of a POP with customer-dedicated PE routers used in the dedicated-router peer-to-peer VPN model. The only difference is that the whole architecture is condensed into one physical device with the PE router in an MPLS VPN. Each customer is assigned an independent routing table (virtual routing table or VRF) that corresponds to the customer dedicated PE router in the traditional peer-to-peer model. Routing across the provider backbone is performed by another routing process that uses a global IP routing table corresponding to the intra-POP P router in the traditional peer-to-peer model.

Note Cisco IOS software implements isolation between customers via virtual routing and

forwarding tables (VRF). The whole PE router is still configured and managed as a single

device, not as a set of virtual routers.

Page 257: Implementing cisco mpls

4-36 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are the Methods of Propagating Routing Information Across the P-Network?

This topic describes the different methods of propagating routing information across the P-network.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-7

Propagation of Routing InformationAcross the P-Network

Question: How will PE routers exchange customer routing information?

Option #1: Run a dedicated IGP for each customer across the P-network.

This is the wrong answer for these reasons:• The solution does not scale.• P routers carry all customer routes.

Although virtual routing tables provide isolation between customers, the data from these routing tables still needs to be exchanged between PE routers to enable data transfer between sites attached to different PE routers. Therefore, a routing protocol is needed that will transport all customer routes across the P-network, while maintaining the independence of individual customer address spaces.

An obvious solution, implemented by various VPN vendors, is to run a separate routing protocol for each customer. There are two common implementations that require that a per-customer routing protocol be run between PE routers:

1. The P routers participate in customer routing and pass the customer routing information between PE routers.

2. The PE routers are connected via point-to-point tunnels, for example IP Security (IPsec), thereby hiding the customer routing from the P routers.

The separate routing protocol for each customer is very simple to implement (and often used by some customers), but is not appropriate in service provider environments because it simply does not scale. The specific problems are as follows:

The PE routers have to run a large number of routing protocols.

The P routers have to carry all customer routes.

Page 258: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-37

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-8

Propagation of Routing InformationAcross the P-Network (Cont.)

Question: How will PE routers exchange customer routing information?

Option #2: Run a single routing protocol that will carry all customer routes inside the provider backbone.

Better answer, but still not good enough:

• P routers carry all customer routes.

A better approach to the route propagation problem is to deploy a single routing protocol that can exchange all customer routes across the P-network. Although this approach is better than the previous one, the P routers are still involved in customer routing; therefore, the proposal retains some of the same scalability issues of the previous one.

Page 259: Implementing cisco mpls

4-38 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-9

Propagation of Routing InformationAcross the P-Network (Cont.)

Question: How will PE routers exchange customer routing information?

Option #3: Run a single routing protocol that will carry all customer routes between PE routers. Use MPLS labels to exchange packets between PE routers.

The best answer:

• P routers do not carry customer routes; the solution is scalable.

The best solution to the customer route propagation issue is to run a single routing protocol between PE routers that will exchange all customer routes without the involvement of the P routers. This solution is scalable. Some of the benefits of this approach are as follows:

The number of routing protocols running between PE routers does not increase with an increasing number of customers.

The P routers do not carry customer routes.

Page 260: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-39

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-10

Propagation of Routing InformationAcross the P-Network (Cont.)

Question: Which protocol can be used to carry customer routes between PE routers?

Answer: The number of customer routes can be very large. BGP is the onlyrouting protocol that can scale to a very large number of routes.

Conclusion:BGP is used to exchange customer routes directly between PE routers.

The next design decision to be made is the choice of the routing protocol running between PE routers. Given that the total number of customer routes is expected to be very large, the only well-known protocol with the required scalability is Border Gateway Protocol (BGP). In fact, BGP is used in the MPLS VPN architecture to transport customer routes directly between PE routers.

Page 261: Implementing cisco mpls

4-40 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-11

Propagation of Routing InformationAcross the P-Network (Cont.)

Question: How will information about the overlapping subnetworks of two customers be propagated via a single routing protocol?

Answer: Extend the customer addresses to make them unique.

MPLS VPN architecture differs in an important way from traditional peer-to-peer VPN solutions: MPLS VPNS support overlapping customer address spaces.

With the deployment of a single routing protocol (BGP) exchanging all customer routes between PE routers, an important issue arises: how can BGP propagate several identical prefixes, belonging to different customers, between PE routers?

The only solution to this dilemma is the expansion of customer IP prefixes with a unique prefix that makes them unique even if they had previously overlapped. A 64-bit prefix called the RD is used in MPLS VPNs to convert non-unique 32-bit customer addresses into 96-bit unique addresses that can be transported between PE routers.

Page 262: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-41

What Are RDs? This topic describes the features of an RD.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-12

Route Distinguishers

• The 64-bit route distinguisher is prepended to an IPv4 address to make it globally unique.

• The resulting address is a VPNv4 address.

• VPNv4 addresses are exchanged between PE routers via BGP.

– BGP that supports address families other than IPv4 addresses is called MP-BGP.

• A similar process is used in IPv6:

– 64-bit route distinguisher is prepended to a 16-byte IPv6 address.

– The resulting 24-byte address is a unique VPNv6 address.

The RD is used only to transform non-unique 32-bit customer IP version 4 (IPv4) addresses into unique 96-bit VPN version 4 (VPNv4) addresses (also called VPN IPv4 addresses).

Note Although the course will focus on VPNv4, in an IP version 6 (IPv6) implementation, the

theory is the same. Multiprotocol Border Gateway Protocol (MP-BGP) is enhanced to carry

IPv6 in a VPN known as VPN version 6 (VPNv6), which uses a new VPNv6 address family.

The VPNv6 address family consists of an 8-byte RD followed by a 16-byte IPv6 prefix. This

combination forms a unique VPNv6 identifier of 24 bytes.

VPNv4 addresses are exchanged only between PE routers; they are never used between CE routers. Between PE routers, BGP must therefore support the exchange of traditional IPv4 prefixes and the exchange of VPNv4 prefixes. A BGP session between PE routers is consequently called an MP-BGP session.

Note The MPLS VPN implementation in Cisco IOS Release 12.4 and earlier supports only MPLS

VPN services within a single autonomous system (AS). In such a scenario, the BGP session

between PE routers is always an Internal Border Gateway Protocol (IBGP) session.

Page 263: Implementing cisco mpls

4-42 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-13

Route Distinguishers (Cont.)

Customer route propagation across an MPLS VPN network is done using this process:

Step 1 The CE router sends an IPv4 routing update to the PE router.

Step 2 The PE router prepends a 64-bit RD to the IPv4 routing update, resulting in a globally unique 96-bit VPNv4 prefix.

Step 3 The VPNv4 prefix is propagated via a Multiprotocol Internal Border Gateway Protocol (MP-IBGP) session to other PE routers.

Page 264: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-43

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-14

Route Distinguishers (Cont.)

Step 4 The receiving PE routers strip the RD from the VPNv4 prefix, resulting in an IPv4 prefix.

Step 5 The IPv4 prefix is forwarded to other CE routers within an IPv4 routing update.

Page 265: Implementing cisco mpls

4-44 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-15

RDs: Usage in an MPLS VPN

• The RD has no special meaning.

• The RD is used only to make potentially overlapping IPv4 addresses globally unique.

• The RD is used as a VPN identifier, but this design could not support all topologies required by the customers.

The RD has no special meaning or role in MPLS VPN architecture; its only function is to make overlapping IPv4 addresses globally unique. The RD value has a local significance on the router where it is configured.

Note Because there has to be a unique one-to-one mapping between RD and virtual routing and

forwarding instances (VRFs), the RD could be viewed as the virtual routing and forwarding

(VRF) identifier in the Cisco implementation of an MPLS VPN.

The RD is configured at the PE router as part of the setup of the VPN site. The RD is not configured on the CE router, and is not visible to the customer.

Simple VPN topologies require only one RD per customer, raising the possibility that the RD could serve as a VPN identifier. This design, however, would not allow implementation of more complex VPN topologies, such as when a customer site belongs to multiple VPNs.

Page 266: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-45

Is the RD Enough? This topic describes why RDs are not sufficient to identify VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-16

Requirements:

• All sites of one customer need to communicate.

• Central sites of both customers need to communicate with VoIP gateways and other central sites.

• Other sites from different customers do not communicate with each other.

Is the RD Enough?VoIP Service Sample

To illustrate the need for a more versatile VPN indicator than the RD, consider the Voice over IP (VoIP) service.

Example: VoIP Service Sample

The figure illustrates the need for a more versatile VPN indicator than the RD. The connectivity requirements of the VoIP service are as follows:

All sites of a single customer need to communicate.

The central sites of different customers subscribed to the VoIP service need to communicate with the VoIP gateways (to originate and receive calls in the public voice network) and also with other central sites to exchange intercompany voice calls.

Note Additional security measures would have to be put in place at central sites to ensure that the

central sites exchange only VoIP calls with other central sites. Otherwise, the corporate

network of a customer could be compromised by another customer who is using the VoIP

service.

Page 267: Implementing cisco mpls

4-46 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: Connectivity Requirements

The connectivity requirements of the VoIP service are illustrated in the figure.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-17

Example: Connectivity Requirements

Three VPNs are needed to implement the desired connectivity: two customer VPNs and a shared VoIP VPN. Central customer sites participate in the customer VPN and in the VoIP VPN.

Note The POP-X and POP-Y VoIP gateways were attached to PE router X and PE router Y in the

previous graphic.

The RD (again, a single entity prepended to an IPv4 route) cannot indicate that a site participates in more than one VPN. A method is needed in which a set of VPN identifiers can be attached to a route to indicate its membership in several VPNs.

Page 268: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-47

What Are RTs? This topic describes the features of an RT.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-18

RTs: Why Are They Needed?

• Some sites have to participate in more than one VPN.

• The RD cannot identify participation in more than one VPN.

• RTs were introduced in the MPLS VPN architecture to support complex VPN topologies.

– A different method is needed in which a set of identifiers can be attached to a route.

RTs were introduced into the MPLS VPN architecture to support identifying a site that participates in more than one VPN.

Page 269: Implementing cisco mpls

4-48 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-19

RTs: What Are They?

• RTs are additional attributes attached to VPNv4 BGP routes to indicate VPN membership.

• Extended BGP communities are used to encode these attributes.

– Extended communities carry the meaning of the attribute together with its value.

• Any number of RTs can be attached to a single route.

RTs are attributes that are attached to a VPNv4 BGP route to indicate its VPN membership. The extended BGP communities of routing updates are used to carry the RT of that update, thus identifying to which VPN the update belongs.

As with standard BGP communities, a set of extended communities can be attached to a single BGP route, satisfying the requirements of complex VPN topologies.

Extended BGP communities are 64-bit values. The semantics of the extended BGP community are encoded in the high-order 16 bits of the value, making those bits useful for a number of different applications, such as MPLS VPN RTs.

Page 270: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-49

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-20

RTs: How Do They Work?

• Export RTs:

– Identifying VPN membership

– Appended to the customer route when it is converted into a VPNv4 route

• Import RTs:

– Associated with each virtual routing table

– Select routes to be inserted into the virtual routing table

MPLS VPN RTs are attached to a customer route at the moment that it is converted from an IPv4 route to a VPNv4 route by the PE router. The RTs attached to the route are called export RTs and are configured separately for each virtual routing table in a PE router. Export RTs identify a set of VPNs in which sites associated with the virtual routing table belong.

When the VPNv4 routes are propagated to other PE routers, those routers need to select the routes to import into their virtual routing tables. This selection is based on import RTs. Each virtual routing table in a PE router can have a number of configured import RTs that identify the set of VPNs from which the virtual routing table is accepting routes.

In overlapping VPN topologies, RTs are used to identify VPN membership. Advanced VPN topologies (for example, central services VPNs) use RTs in more complex scenarios.

Page 271: Implementing cisco mpls

4-50 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

How Have Complex VPNs Redefined the Meaning of VPNs?

This topic describes how complex VPNs have redefined the meaning of VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-21

VPNs Redefined

With the introduction of complex VPN topologies, VPNs have had to be redefined:

• A VPN is a collection of sites sharing common routing information.

• A site can be part of different VPNs.

• A VPN can be seen as a community of interest (closed user group).

• Complex VPN topologies are supported by multiple virtual routing tables on the PE routers.

With the introduction of complex VPN topologies, the definition of a VPN has needed to be changed. A VPN is simply a collection of sites sharing common routing information. In traditional switched WAN terms (for example, in X.25 terminology), such a concept would be called a closed user group (CUG).

In the classic VPN, all sites connected to a VPN shared a common routing view. In complex VPNs, however, a site can be part of more than one VPN. This results in differing routing requirements for sites that belong to a single VPN and those that belong to more than one VPN. These routing requirements have to be supported with multiple virtual routing tables on the PE routers.

Page 272: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-51

What Is the Impact of Complex VPN Topologies on Virtual Routing Tables?

This topic describes the impact of complex VPN topologies on virtual routing tables.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-22

Impact of Complex VPN Topologies on Virtual Routing Tables

• A virtual routing table in a PE router can be used only for sites with identical connectivity requirements.

• Complex VPN topologies require more than one virtual routing table per VPN.

• As each virtual routing table requires a distinct RD value, the number of RDs in the MPLS VPN network increases.

A single virtual routing table can be used only for sites with identical connectivity requirements. Complex VPN topologies, therefore, require more than one virtual routing table per VPN.

Note If sites with different requirements are associated with the same virtual routing table, some

of the sites might be able to access destinations that should not be accessible to them.

Because each virtual routing table requires a distinctive RD, the number of RDs in an MPLS VPN network increases with the introduction of overlapping VPNs. Moreover, the simple association between RD and VPN that was true for simple VPNs is also gone.

Page 273: Implementing cisco mpls

4-52 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: Impact of Complex VPN Topologies on Virtual Routing Tables

To illustrate the requirements for multiple virtual routing tables, consider a VoIP service with three VPNs (customer A, customer B, and a VoIP VPN).

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-23

Impact of Complex VPN Topologies on Virtual Routing Tables (Cont.)

The virtual routing table needs of this service are as follows:

1. All sites of customer A (apart from the central site) can share the same virtual routing table because they belong to a single VPN.

2. The same is true for all sites of customer B (apart from the central site).

3. The VoIP gateways participate only in the VoIP VPN and can belong to a single virtual routing table.

4. Central site A has unique connectivity requirements—it has to see sites of customer A and sites in the VoIP VPN and, consequently, requires a dedicated virtual routing table.

5. Likewise, central site B requires a dedicated virtual routing table.

Therefore, in this example, five different VRF tables are needed to support three VPNs. There is no one-to-one relationship between the number of VRFs and the number of VPNs.

Page 274: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-53

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-24

Summary

• There are several drawback to traditional peer-to-peer VPNs.

• MPLS VPN architecture combines the best features of the overlay and peer-to-peer VPN models.

• The architecture of a PE router in an MPLS VPN uses separate virtual routers containing the routes of each customers inside one physical router.

• The most scalable method of exchanging customer routes across a provider network is the use of a single BGP routing protocol from PE router to PE router.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-25

Summary (Cont.)

• Route distinguishers transform non-unique 32-bit addresses into 96-bit unique addresses.

• Route targets are used to identify VPN membership in overlapping topologies.

• VPNs are now considered a collection of sites sharing common routing information.

• Placing sites with different routing requirements in the same virtual routing table will result in inconsistent routing.

Page 275: Implementing cisco mpls

4-54 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 276: Implementing cisco mpls

Lesson 4

Introducing the MPLS VPN Routing Model

OverviewThis lesson explains the routing requirements for Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs). The lesson offers address and routing perspectives from the customer and service provider side, and it discusses how routing tables appear on provider edge (PE) routers. This lesson also discusses MPLS VPN end-to-end information flow, Multiprotocol Border Gateway Protocol (MP-BGP), updates, and display formats.

It is important to understand how information is routed in an MPLS VPN, and how the routing tables are viewed and interpreted. This lesson will help you to get a clear understanding of the similarities and differences between the global routing table and the virtual routing tables that are created in an MPLS VPN.

ObjectivesUpon completing this lesson, you will be able to identify the routing requirements for MPLS VPNs. This ability includes being able to meet these objectives:

Describe the routing requirements for MPLS VPNs

Describe the MPLS VPN routing model for CE routers, PE routers, and P routers

Describe how IPv4 is used to provide support for existing Internet routing

Identify the routing tables implemented in the PE router to support MPLS VPNs

Describe the end-to-end flow of routing updates in an MPLS VPN

Describe how an MPLS VPN determines which routes are distributed to a CE router

Page 277: Implementing cisco mpls

4-56 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

MPLS VPN Routing Requirements and Model This topic describes the routing requirements and model for MPLS VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-3

MPLS VPN Routing Requirements

• CE routers have to run standard IP routing software.

• PE routers have to support MPLS VPN services and IP routing.

• P routers have no VPN routes.

The designers of MPLS VPN technology were faced with these routing requirements:

Customer edge (CE) routers should not be MPLS VPN-aware; CE routers should run standard IP routing software.

PE routers must support MPLS VPN services and traditional Internet services.

To make the MPLS VPN solution scalable, provider routers (P routers) must not carry VPN routes.

Page 278: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-57

What Is the MPLS VPN Routing Model? This section describes the MPLS VPN routing model for CE routers, PE routers, and P routers.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-4

MPLS VPN Routing:CE Router Perspective

• The CE routers run standard IP routing software and exchange routing updates with the PE router.

– EBGP, OSPF, RIPv2, EIGRP, and static routes are supported.

• The PE router appears as another router in the C-network.

The MPLS VPN backbone should look like a standard corporate backbone to the CE routers. The CE routers run standard IP routing software and exchange routing updates with the PE routers, which appear to them as normal routers in the customer network (C-network).

Note Since Cisco IOS Release 12.2, the choice of routing protocols that can be run between a CE

router and a PE router includes Enhanced Interior Gateway Routing Protocol (EIGRP),

Routing Information Protocol version 2 (RIPv2), Open Shortest Path First (OSPF), External

Border Gateway Protocol (EBGP), and static routes.

Page 279: Implementing cisco mpls

4-58 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-5

MPLS VPN Routing:Overall Customer Perspective

• To the customer, the PE routers appear as core routers connected via a BGP backbone.

• The usual BGP and IGP design rules apply.

• The P routers are hidden from the customer.

From the customer perspective, the MPLS VPN backbone looks like an intracompany Border Gateway Protocol (BGP) backbone with PE routers performing route redistribution between individual sites and the core backbone. The standard design rules used for enterprise BGP backbones can be applied to the design of the C-network.

The P routers are hidden from customer view; the internal topology of the BGP backbone is therefore transparent to the customer.

Page 280: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-59

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-6

MPLS VPN Routing:P Router Perspective

• P routers do not participate in MPLS VPN routing and do not carry VPN routes.

• P routers run backbone IGP with the PE routers and exchange information about global subnetworks (core links and loopbacks).

From the P router perspective, the MPLS VPN backbone looks even simpler—the P routers do not participate in MPLS VPN routing and do not carry VPN routes. The P routers run only a backbone Interior Gateway Protocol (IGP) with other P routers and with PE routers, and exchange information about core subnetworks. BGP deployment on P routers is not needed for proper MPLS VPN operation; it might be needed, however, to support traditional Internet connectivity that has not yet been migrated to MPLS.

Page 281: Implementing cisco mpls

4-60 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-7

MPLS VPN Routing:PE Router Perspective

PE routers:

• Exchange VPN routes with CE routers via per-VPN routing protocols

• Exchange core routes with P routers and PE routers via core IGP

• Exchange VPNv4 routes with other PE routers via MP-IBGP sessions

The PE routers are the only routers in MPLS VPN architecture that see all routing aspects of the MPLS VPN. PE routers are able to perform these exchanges:

PE routers exchange IP version 4 (IPv4) VPN routes with CE routers via various routing protocols running in the virtual routing tables.

PE routers exchange VPN version 4 (VPNv4) routes via Multiprotocol Internal Border Gateway Protocol (MP-IBGP) sessions with other PE routers.

PE routers exchange core routes with P routers and other PE routers via core IGP.

Page 282: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-61

Existing Internet Routing Support This topic describes how IPv4 is used to provide support for existing Internet routing.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-8

Support for Existing Internet Routing

PE routers can run standard IPv4 BGP in the global routing table:

• PE routers exchange Internet routes with other PE routers.

• CE routers do not participate in Internet routing.

• P routers do not need to participate in Internet routing.

The routing requirements for PE routers also extend to supporting Internet connectivity—PE routers have to exchange Internet routes with other PE routers. The CE routers cannot participate in Internet routing if the Internet routing is performed in global address space. The P routers could participate in Internet routing; however, Internet routing should be disabled on the P routers to make the network core more stable.

Page 283: Implementing cisco mpls

4-62 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Routing Tables on PE Routers This topic identifies the routing tables implemented in the PE router to support MPLS VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-9

Routing Tables on PE Routers

PE routers contain a number of routing tables:

• The global routing table contains core routes (filled with core IGP) and Internet routes (filled with IPv4 BGP).

• The VRF tables contains routes for sites of identical routing requirements from local (IPv4 VPN) and remote (VPNv4 via MP-BGP) CE routers.

The PE routers fulfill various routing requirements imposed on them by using a number of IP routing tables. Here are some examples:

The global IP routing table (the IP routing table that is always present in a Cisco IOS software-based router even if it is not supporting an MPLS VPN) contains all core routes (inserted by the core IGP) and the Internet routes (inserted from the global IPv4 BGP table).

The virtual routing and forwarding (VRF) tables contain sets of routes for sites with identical routing requirements. The VRFs are filled with intra-VPN IGP information exchanged with the CE routers and with VPNv4 routes received through MP-BGP sessions from the other PE routers.

Page 284: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-63

Identifying End-to-End Routing Update Flow This topic describes the end-to-end flow of routing updates in an MPLS VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-10

End-to-End Routing Update Flow

PE routers receive IPv4 routing updates from CE routers and install them in the appropriate VRF table.

These figures provide an overview of end-to-end routing information flow in an MPLS VPN network.

Example: End-to-End Routing Update Flow

The figure here illustrates how PE routers receive IPv4 routing updates from the CE routers and install them in the appropriate VRF table.

Page 285: Implementing cisco mpls

4-64 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-11

PE routers export VPN routes from VRF tables into MP-BGP and propagate them as VPNv4 routes to other PE routers.

End-to-End Routing Update Flow (Cont.)

The customer routes from VRF tables are exported as VPNv4 routes into MP-BGP and propagated to other PE routers.

Current MPLS VPN implementation in Cisco IOS software (up to Cisco IOS Release12.4) supports MPLS VPN services only within the scope of a single autonomous system (AS). The MP-BGP sessions between the PE routers are therefore Internal Border Gateway Protocol (IBGP) sessions and were subject to the IBGP split-horizon rules. Either a full mesh of MP-IBGP sessions is required between PE routers or route reflectors need to be used.

Page 286: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-65

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-12

End-to-End Routing Update Flow:MP-BGP Update

An MP-BGP update contains these elements:

• VPNv4 address

• Extended communities (route targets, optionally SOO)

• Label used for VPN packet forwarding

• Any other BGP attribute (for example, AS path, local preference, MED, standard community)

An MP-BGP update exchange between PE routers contains these elements:

VPNv4 address

Extended BGP communities (route targets [RTs] are required; Site of Origin [SOO] is optional)

Label used for VPN packet forwarding

Note The “Forwarding MPLS VPN Packets” lesson explains how this label is used in the MPLS

label stack.

Mandatory BGP attributes (for example, AS path)

Optionally, the MP-BGP update can contain any other BGP attribute; for example, local preference, multi-exit discriminator (MED), or standard BGP community.

Page 287: Implementing cisco mpls

4-66 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-13

• The receiving PE router imports the incoming VPNv4 routes into the appropriate VRF based on route targets attached to the routes.

• The routes installed in the VRFs are propagated to the CE routers.

End-to-End Routing Update Flow (Cont.)

The PE routers receiving MP-BGP updates import the incoming VPNv4 routes into their VRFs based on RTs attached to the incoming routes and on import RTs configured in the VRFs. The VPNv4 routes installed in the VRFs are converted to IPv4 routes and then propagated to the CE routers.

Page 288: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-67

Route Distribution to CE Routers This topic describes how an MPLS VPN determines which routes are distributed to a CE router.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-14

Route Distribution to CE Routers

• A route is installed in the site VRF if it matches the import route target attribute.

• Route distribution to CE sites is driven by the following:

– Route targets

– SOO attribute if defined

The RTs attached to a route and the import RTs configured in the VRF drive the propagation of the routes to the CE router.

Incoming VPNv4 routes are imported into VRFs on the receiving PE router only if at least one RT attached to the route matches at least one import RT configured in the VRF.

When BGP is used to connect the CE and PE, the SOO attribute attached to the VPNv4 route can also help control the IPv4 route propagation to the CE routers. A route inserted into a VRF is not propagated to a CE router if the SOO attached to the route is equal to the SOO attribute associated with the CE router. The SOO can thus be used to prevent routing loops in MPLS VPN networks with multihomed sites.

To be distributed to the CE, routes need to be installed in the VRF, and not have a conflicting SOO.

Page 289: Implementing cisco mpls

4-68 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: Extending MPLS VPNs with VRF-LiteThis topic discusses extending MPLS VPNs with Multi-VRF CE (VRF-lite).

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-15

What Is Multi-VRF CE (VRF-Lite)?

• Multi-VRF CE (VRF-lite) is an application based on VRF implementation.

– VRF-lite supports multiple overlapping and independent VRFs on the CE router.

• The CE router separates traffic between client networks using VRFs.

• There is no MPLS functionality on the CE router.

– No label exchange between the CE and PE router.

– No labeled packet flow between the CE and PE router.

• Any routing protocol supported by normal VRF can be used in a Multi-VRF CE implementation.

Although MPLS VPNs provide security and privacy as traffic travels through the provider network, the CE router has no mechanism to guarantee private networks across its LAN networks. To provide privacy, each client or organization is traditionally placed in a separate VLAN or on a separate CE router. VRF-lite extends limited PE functionality to a CE router. VRF-lite allows the CE router the ability to maintain separate VRF tables to extend the privacy and security of an MPLS VPN down to a branch office or interface.

The CE router using VRF-lite can isolate traffic by placing each client or organization in a separate VRF with its own IP address space. Each interface or subinterface contains its own IP address space to separate each different client.

Similar to MPLS VRFs, routes are installed in the appropriate VRF with VRF-lite. However, the CE router does not run MPLS.

Note With VRF-lite, there is no label exchange, there is no Label Distribution Protocol (LDP)

adjacency, and there is no labeled packet flow between PE and CE router.

The CE router needs a routing protocol or static routes to propagate routes from each specific VRF on the CE router to the same VRF on the PE router.

Note Additional information on VRF-lite is outside the scope of this course.

Page 290: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-69

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-16

Summary

• In MPLS VPNs:

– CE routers run standard protocols (static, RIPv2, OSPF, EIGRP, EBGP) to the PE routers.

– PE routers provide the VPN routing and services via MP-BGP.

– P routers do not participate in VPN routing, and only provide core IGP backbone routing to the PE routers.

• The PE router functions are extended to carry regular Internet routing via IPv4 BGP in addition to the MP-BGP.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-17

Summary (Cont.)

• PE routers separate the global IPv4 BGP routing table from each unique customer VPNv4 MP-BGP routing table.

• The ingress PE router receives CE customer IPv4 updates and exports these IPv4 routes to other PE routers via MP-BGP.

• The egress PE router imports the VPNv4 routes and forwards them to the CE router as an IPv4 update.

Page 291: Implementing cisco mpls

4-70 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 292: Implementing cisco mpls

Lesson 5

Forwarding MPLS VPN Packets

OverviewThis lesson explains how forwarding across a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) backbone occurs, identifies how labels get propagated, and explains the effects of summarization in the core.

It is important to understand how packets are forwarded across an MPLS VPN backbone, because this understanding will help you when you try to isolate problems in the network. This lesson explains how the far-end label is sent to the ingress provider edge (PE) router and how that information is shared.

ObjectivesUpon completing this lesson, you will be able to describe how packets are forwarded in an MPLS VPN environment. This ability includes being able to meet these objectives:

Describe the end-to-end MPLS VPN forwarding mechanisms

Describe the operation of PHP in an MPLS VPN environment

Describe how labels are propagated between PE routers

Describe the effects of MPLS VPNs on label propagation

Describe the effects of MPLS VPNs on packet forwarding

Page 293: Implementing cisco mpls

4-72 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are the End-to-End VPN Forwarding Mechanisms?

This topic describes the end-to-end MPLS VPN forwarding mechanisms.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-3

VPN Packet Forwarding Across an MPLS VPN Backbone: Approach 1

Approach 1: The PE routers will label the VPN packets with an LDP label for the egress PE router, and forward the labeled packets across the MPLS backbone.

Results:• The P routers perform the label switching, and the packet reaches the

egress PE router.• Because the egress PE router does not know which VRF to use for

packet switching, the packet is dropped.

A simple MPLS-oriented approach to MPLS VPN packet forwarding across the MPLS VPN backbone would be to label the customer packet with the label assigned by Label Distribution Protocol (LDP) for the egress PE router. The core routers consequently would never see the customer IP packet; instead, the core routers would see just a labeled packet targeted toward the egress PE router. The core routers would perform simple label-switching operations, eventually delivering the customer packet to the egress PE router. Unfortunately, the customer IP packet would contain no VPN or virtual routing and forwarding (VRF) information that could be used to perform VRF lookup on the egress PE router. The egress PE router would not know which VRF to use for packet lookup and would have to drop the packet.

Page 294: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-73

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-4

VPN Packet Forwarding Across an MPLS VPN Backbone: Approach 2

Result:

• The P routers perform label switching using the top label, and the packet reaches the egress PE router. The top label is removed.

• The egress PE router performs a lookup on the VPN label and forwards the packet toward the CE router.

Approach 2: The PE routers will label the VPN packets with a label stack, using the LDP label for the egress PE router as the top label, and the VPN label assigned by the egress PE router as the second label in the stack.

An MPLS label stack can be used to tell the egress PE router what to do with the VPN packet. When using the label stack, the ingress PE router labels the incoming IP packet with two labels. The top label in the stack is the LDP label for the egress PE router; this label guarantees that the packet will traverse the MPLS VPN backbone and arrive at the egress PE router. The second label in the stack is assigned by the egress PE router, and tells how to forward the incoming VPN packet. The second label could point directly toward an outgoing interface, in which case the egress PE router would perform label lookup only on the VPN packet. The second label could also point to a VRF, in which case the egress PE router would first perform a label lookup to find the target VRF, and then perform an IP lookup within the VRF.

Both methods of implementing second labels are used in Cisco IOS software. The second label in the stack points toward an outgoing interface whenever the customer edge (CE) router is the next hop of the VPN route. The second label in the stack points to the VRF table for aggregate VPN routes, VPN routes pointing to a null interface, and routes for directly connected VPN interfaces.

The two-level MPLS label stack satisfies these MPLS VPN forwarding requirements:

The P routers perform label switching on the LDP-assigned label toward the egress PE router.

The egress PE router performs label switching on the second label (which it has previously assigned) and either forwards the IP packet toward the CE router or performs another IP lookup in the VRF pointed to by the second label in the stack.

Page 295: Implementing cisco mpls

4-74 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Is VPN PHP? This topic describes operation of penultimate hop popping (PHP) in an MPLS VPN environment.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-5

VPN PHP

• Penultimate hop popping on the LDP label can be performed on the last P router.

• The egress PE router performs label lookup only on theVPN label, resulting in faster and simpler label lookup.

• IP lookup is performed only once—in the ingress PE router.

PHP is the removal of the top label in the stack on the hop prior to the egress router. PHP can be performed in frame-based MPLS networks. In these networks, the last provider router (P router) in the label-switched path (LSP) tunnel pops the LDP label (as previously requested by the egress PE router through LDP), and the PE router receives a labeled packet that contains only the VPN label. In most cases, a single label lookup performed on that packet in the egress PE router is enough to forward the packet toward the CE router. The full IP lookup through the Forwarding Information Base (FIB) is performed only once, in the ingress PE router, even without PHP.

Page 296: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-75

Propagating VPN Labels Between PE Routers This topic describes how labels are propagated between PE routers.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-6

VPN Label Propagation

Question: How will the ingress PE router get the second label in the label stack from the egress PE router?

Answer: Labels are propagated in MP-BGP VPNv4 routing updates.

The previous figures showed that an MPLS label stack with the second label is required for proper MPLS VPN operation. This label was allocated by the egress PE router. This label has to be propagated from the egress PE router to the ingress PE routers to enable proper packet forwarding. Multiprotocol Border Gateway Protocol (MP-BGP) was chosen as the propagation mechanism. Every MP-BGP update thus carries a label assigned by the egress PE router together with the 96-bit VPN version 4 (VPNv4) prefix.

Page 297: Implementing cisco mpls

4-76 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: VPN Label Propagation Between PE Routers

The figure illustrates VPN label propagation between PE routers.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-7

Step 1: A VPN label is assigned to every VPN route by the egressPE router.

VPN Label Propagation (Cont.)

Step 2: The VPN label is advertised to all other PE routers in an MP-BGPupdate.

Step 3: A label stack is built in the VRF table.

These steps describe the label propagation between PE routers:

Step 1 The egress PE router assigns a label to every VPN route received from the attached CE routers and to every summary route summarized inside the PE router. This label is then used as the second label in the MPLS label stack by the ingress PE routers when labeling VPN packets.

Note In the graphic, the VPN label 38 for destination 192.168.10.0 is assigned by the egress PE

router.

The VPN labels assigned locally by the PE router can be inspected with the show mpls forwarding vrf vrf-name command.

Step 2 The VPN labels assigned by the egress PE routers are advertised to all other PE routers together with the VPNv4 prefix in MP-BGP updates.

The labels can be inspected with the show ip bgp vpnv4 all labels command on the ingress PE router.

The routes that have an input label but no output label are the routes received from the CE routers (and the input label was assigned by the local PE router). The routes with an output label but no input label are the routes received from the other PE routers (and the output label was assigned by the remote PE router).

Page 298: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-77

Step 3 The ingress PE router has two labels associated with a remote VPN route: a label for the Border Gateway Protocol (BGP) next hop assigned by the next-hop P router via LDP—and taken from the local Label Information Base (LIB)—and also the label assigned by the remote PE router and propagated via MP-BGP update. Both labels are combined in a label stack and installed in the VRF table.

The label stack in the VRF table can be inspected using the show ip cef vrf vrf-name detailcommand. The tags imposed values in the output displays the MPLS label stack. The first label in the MPLS label stack is the LDP label forwarded toward the egress PE router, and the second label is the VPN label advertised by the egress PE router.

Page 299: Implementing cisco mpls

4-78 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are the Effects of MPLS VPNs on Label Propagation?

This topic describes the effects of MPLS VPNs on label propagation.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-8

MPLS VPNs and Label Propagation

• The VPN label must be assigned by the BGP next hop.

• The BGP next hop should not be changed in the MP-IBGP update propagation.

– Do not use the command on confederation boundaries.

• The PE router must be the BGP next hop.

– Use the command on the PE router.

• The label must be reoriginated if the next hop is changed.

– A new label is assigned every time that the MP-BGP update crosses the AS boundary where the next hop is changed.

MPLS VPN packet forwarding works correctly only if the router specified as the BGP next hop in the incoming BGP update is the same router as the one that assigned the second label in the label stack. Here are three scenarios that can cause the BGP next hop to be different from the IP address of the PE router assigning the VPN label:

If the customer route is received from the CE router via an External Border Gateway Protocol (EBGP) session, the next hop of the VPNv4 route is still the IP address of the CE router (the BGP next hop of an outgoing Internal Border Gateway Protocol [IBGP] update is always identical to the BGP next hop of the incoming EBGP update). You have to configure the next-hop-self command on the MP-BGP sessions between PE routers to make sure that the BGP next hop of the VPNv4 route is always the IP address of the PE router, regardless of the routing protocol used between the PE router and the CE router.

The BGP next hop should not change inside an autonomous system (AS). It can change, however, if you use the next-hop-self command on an inter-AS boundary inside a BGP confederation or if you use inbound the route-map command on a PE route to change the next hop (a strongly discouraged practice). To prevent this situation, never change the BGP next hop with the route-map or next-hop-self commands inside an AS.

The BGP next hop is always changed on an EBGP session. If the MPLS VPN network spans multiple public autonomous systems (not just autonomous systems within a BGP confederation), special provisions must be made in the AS boundary routers to reoriginate the VPN label at the same time that the BGP next hop is changed. This functionality is supported by Cisco IOS Releases 12.1(4)T, 12.2, and later.

Page 300: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-79

What Are the Effects of MPLS VPNs on Packet Forwarding?

This topic describes the effects of MPLS VPNs on packet forwarding.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-9

MPLS VPNs and Packet Forwarding

• The VPN label of the BGP route is understood only by the egress PE router.

• An end-to-end LSP tunnel is required between the ingress and egress PE routers.

• BGP next-hop addresses must be IGP routes.

– LDP labels will be assigned to addresses in the global routing table.

– LDP labels are not assigned to BGP routes (BGP routes receive VPN labels).

• BGP next hops announced in IGP must not be summarized in the core network.

– Summarization breaks the LSP tunnel.

For successful propagation of MPLS VPN packets across an MPLS backbone, there must be an unbroken LSP tunnel between PE routers. This is because the second label in the stack is recognized only by the egress PE router that has originated it, and will not be understood by any other router should it ever become exposed.

Here are two scenarios that could cause the LSP tunnel between PE routers to break:

If the IP address of the PE router is announced as a BGP route, it will have no corresponding LDP label and the label stack will not be built correctly. The IP address of the PE router must be announced in the global routing table.

If the P routers perform summarization of the address range within which the IP address of the egress PE router lies, the LSP tunnel will be disrupted at the summarization point, as illustrated in the figure.

Page 301: Implementing cisco mpls

4-80 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: Summarization in the Core

In the figure, the P router summarizes the loopback address of the egress PE router.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-10

MPLS VPNs and Packet Forwarding:Summarization in the Core

The LSP tunnel is broken at a summarization point, so the summarizing router needs to perform full IP lookup. In a frame-based MPLS network, the P router would request PHP for the summary route, and the upstream P router (or a PE router) would remove the LDP label, exposing the VPN label to the P router. Because the VPN label is assigned not by the P router but by the egress PE router, the label will not be understood by the P router and the VPN packet will be dropped or misrouted.

Page 302: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-81

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-11

Summary

• PE routers forward packets across the MPLS VPN backbone using label stacking.

• The last P router in the LSP tunnel pops the LDP label, and the PE router receives a labeled packet that contains only the VPN label.

• Labels are propagated between PE routers using MP-BGP.

• BGP next hops should not be announced as BGP routes.

• LDP labels are not assigned to BGP routes.

Page 303: Implementing cisco mpls

4-82 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Module Summary This topic summarizes the key points that were discussed in this module.

© 2005 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4-1

Module Summary

• VPNs replace dedicated links with virtual point-to-point links on common infrastructure, reducing operating costs for customers.

• VPNs are categorized based on business need or connectivity requirement.

• MPLS VPNs prepends RDs to make unique customer addresses, and forwards traffic based on RTs.

• PE routers provide customer VPN routing and services through MP-BGP, while CE routers run standard IP routing protocols

• Label stacking is used in forwarding packets across the MPLS VPN backbone.

The two major Virtual Private Network (VPN) design options—overlay VPN and peer-to-peer VPN—have many benefits and drawbacks. The VPN topology categories and architectural components help determine the method for forwarding packets in a Multiprotocol Label Switching (MPLS) VPN environment.

ReferencesFor additional information, refer to these resources:

Access Cisco.com for additional information about VPNs.

Page 304: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-83

Module Self-Check Use the questions here to review what you learned in this module. The correct answers and solutions are found in the Module Self-Check Answer Key.

Q1) Traditional router-based networks that connected customer sties were implemented

using which type of links? (Source: Introducing VPNs)

A) PVCB) dedicated point-to-point C) SVCD) emulated point-to-point

Q2) VPNs are implemented using which type of links? (Source: Introducing VPNs)

A) emulated point-to-point B) dedicated point-to-point C) PVCD) PSTN

Q3) Which two network elements are contained in the P-network? (Choose two.) (Source:

Introducing VPNs)

A) P device B) CE device C) PE device D) CPE device

Q4) What is a characteristic of an overlay VPN? (Source: Introducing VPNs)

A) PE routers carry all routes from all customers. B) An overlay VPN guarantees optimum routing between customer sites. C) The service provider participates in the customer routing. D) The service provider provides virtual point-to-point links between customer

sites.

Q5) In the traditional switched WAN model for Layer 2 VPN implementation, what is the

service provider responsible for? (Source: Introducing VPNs)

A) packet filtering B) transport of Layer 2 frames C) routing updates D) encapsulation of protocols

Q6) The peer-to-peer VPN concept was introduced to help overcome what type of

drawback? (Source: Introducing VPNs)

______________________________________________________________________

______________________________________________________________________

Page 305: Implementing cisco mpls

4-84 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q7) How is a peer-to-peer VPN implemented using packet filters? (Source: Introducing

VPNs)

______________________________________________________________________

______________________________________________________________________

Q8) How do you implement a peer-to-peer VPN based on controlled route distribution?

(Source: Introducing VPNs)

______________________________________________________________________

______________________________________________________________________

Q9) Which VPN type does NOT require the service provider to participate in customer

routing? (Source: Introducing VPNs)

A) overlay B) peer-to-peer C) central services D) access VPNs

Q10) For which VPN type is it easier to provision an additional VPN? (Source: Introducing

VPNs)

A) overlay B) peer-to-peer C) central services D) access VPNs

Q11) Which VPN type requires the PE router to carry all routes from all customers? (Source:

Introducing VPNs)

A) overlay B) peer-to-peer C) central services D) access VPNs

Q12) Which VPN type requires the service provider to participate in customer routing?

(Source: Introducing VPNs)

A) overlay B) peer-to-peerC) central services D) access VPNs

Page 306: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-85

Q13) Describe the use of address space and packet routing in each of these peer-to-peer

implementations. (Source: Introducing VPNs)

Shared PE router

______________________________________________________________________

Dedicated PE router

______________________________________________________________________

Q14) Which connectivity category should you use if all sites must have connectivity with

each other? (Source: Introducing VPNs)

A) simple B) overlappingC) peer-to-peerD) hub-and-spoke E) central services

Q15) Which connectivity category should you use if all sites must have connectivity to a

server provided by the service provider? (Source: Introducing VPNs)

A) simple B) overlappingC) peer-to-peerD) hub-and-spoke E) central services

Q16) What are the connectivity requirements of a managed network VPN? (Source:

Introducing VPNs)

A) The service provider is restricted to access of the P-network. B) The service provider is granted access to the entire C-network. C) The service provider is restricted to access of the managed CE routers. D) The service provider grants the customer access to the PE routers but not the P

routers.

Q17) Which VPN topology has many sites connecting to a central site? (Source:

Categorizing VPNs)

A) simple B) overlappingC) peer-to-peerD) hub-and-spoke E) central services

Page 307: Implementing cisco mpls

4-86 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q18) When you are using a dynamic routing protocol such as RIP in a redundant hub-and-

spoke topology, which statement is true? (Source: Categorizing VPNs)

A) Static routing must be used to provide connectivity from remote site to remote site.

B) Split-horizon updates must be disabled at the hub router if static routing is used.

C) Split-horizon updates must be disabled at the hub router if point-to-point subinterfaces are not used.

D) Split-horizon updates must be enabled at the remote site router when point-to-point subinterfaces are not used.

Q19) Identify the criteria that a customer should consider when determining where virtual

circuits are established in a partial mesh topology. (Source: Categorizing VPNs)

______________________________________________________________________

______________________________________________________________________

Q20) Which component of the VPN business category is used to connect different

organizations? (Source: Categorizing VPNs)

A) intranet VPNs B) Internet VPNsC) access VPNs D) extranet VPNs

Q21) Which component of the VPN business category relies on security mechanisms to

ensure protection of participating individual organizations? (Source: Categorizing

VPNs)

A) intranet VPNs B) Internet VPNsC) access VPNs D) extranet VPNs

Q22) Which implementation of the VPN business category provides the most cost-effective

model? (Source: Categorizing VPNs)

A) overlay B) peer-to-peerC) central services D) access VPNs

Q23) Which component of the VPN connectivity category provides full connectivity

between sites? (Source: Categorizing VPNs)

A) simple B) overlappingC) central services D) managed services

Page 308: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-87

Q24) Describe the connectivity in a central services extranet. (Source: Categorizing VPNs)

______________________________________________________________________

______________________________________________________________________

Q25) Describe the connectivity in a managed network VPN. (Source: Categorizing VPNs)

______________________________________________________________________

______________________________________________________________________

Q26) Which routers are MPLS VPNs aware of? (Source: Introducing MPLS VPN

Architecture)

Q27) Which traditional VPN module can the architecture of a PE router in an MPLS VPN be

compared to? (Source: Introducing MPLS VPN Architecture)

Q28) Which protocol is used to transport customer routes directly between PE routers?

(Source: Introducing MPLS VPN Architecture)

A) RIPB) VPNC) BGPD) OSPF

Q29) What is the function of the RD in an MPLS VPN? (Source: Introducing MPLS VPN

Architecture)

______________________________________________________________________

Q30) What is the function of the RT in MPLS VPNs? (Source: Introducing MPLS VPN

Architecture)

______________________________________________________________________

Q31) How has the introduction of complex VPN topologies redefined the meaning of a

VPN? (Source: Introducing MPLS VPN Architecture)

______________________________________________________________________

Page 309: Implementing cisco mpls

4-88 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q32) What could happen if two different sites with different requirements are associated

with the same virtual routing table? (Source: Introducing MPLS VPN Architecture)

______________________________________________________________________

Q33) In which two ways do MPLS VPNs support overlapping customer address spaces?

(Choose two.) (Source: Introducing MPLS VPN Architecture)

A) by implementing unique RDs for each customer B) by implementing unique RTs for each customer C) by implementing different LSPs for each customer D) by implementing virtual routing spaces for each customer

Q34) Which statement is true if you use the P-network IGP to propagate customer routing

information across the P-network? (Source: Introducing MPLS VPN Architecture)

A) The PE router must be VPN-aware. B) The P router must be VPN-aware. C) Customers can use overlapping address spaces. D) The P router must carry all of the customer routes.

Q35) Why do MPLS VPNs implement route targets? (Source: Introducing MPLS VPN

Architecture)

A) to identify different customer VPNs B) to allow a site to participate on more than one VPN C) to convert a customer address to an MP-BGP address D) to convert a non-unique IP address into a unique VPNv4 address

Q36) Which routing protocol does the CE router run? (Source: Introducing the MPLS VPN

Routing Model)

A) any IP routing protocol B) any VPN-aware BGP protocol C) any VPN-aware IP routing protocol D) any VPN-aware link-state protocol

Q37) Which type of routers exchange VPNv4 routes? (Source: Introducing the MPLS VPN

Routing Model)

A) PB) CEC) PE

Q38) Which protocol would a PE router use to support an existing Internet routing scheme?

(Source: Introducing the MPLS VPN Routing Model)

A) IS-ISB) EIGRPC) BGP IPv4 D) BGP VPNv4

Page 310: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-89

Q39) Identify the routing tables implemented in the PE router to support an MPLS VPN and

describe their contents. (Source: Introducing the MPLS VPN Routing Model)

______________________________________________________________________

Q40) What BGP function do MPLS VPNs use to transport RTs? (Source: Introducing the

MPLS VPN Routing Model)

Q41) How does the PE router know in which VRF table to install received routes for a

customer? (Source: Introducing the MPLS VPN Routing Model)

Q42) What is the impact of an MPLS VPN on CE routers? (Source: Introducing the MPLS

VPN Routing Model)

A) The CE routers must support BGP. B) The CE routers must run a link-state protocol. C) The CE routers can run any standard IP routing protocol. D) The IGP of the CE routers must be upgraded to a VPN-aware IGP.

Q43) Why would IPv4 routing be enabled on the PE router? (Source: Introducing the MPLS

VPN Routing Model)

A) to support the MPLS VPN route update B) to support the MPLS VPN route target exports C) to support an existing Internet routing scheme D) to support the transport of MP-BGP extended communities

Q44) Which two types of routes would an MPLS VPN install into the VRF? (Choose two.)

(Source: Introducing the MPLS VPN Routing Model)

A) those routes received via an IPv4 update B) those routes received via a VPNv4 update C) those routes received via the core IGP update D) those routes received via the customer IGP update

Q45) What will happen if the SOO attached to the route is equal to the SOO attribute

associated with the CE router? (Source: Introducing the MPLS VPN Routing Model)

A) The route will not be inserted into the VRF. B) The route will not be inserted into the global table. C) The route will be inserted into a VRF but not propagated to a CE router. D) The route will be inserted into a VRF but not propagated to neighboring PE

routers.

Q46) Why does the label stack contain two labels when supporting MPLS VPNs? (Source:

Forwarding MPLS VPN Packets)

______________________________________________________________________

Page 311: Implementing cisco mpls

4-90 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q47) Why is the VPN label not popped during the PHP process? (Source: Forwarding MPLS

VPN Packets)

______________________________________________________________________

Q48) Which protocol is used to transport VPN labels between PE routers? (Source:

Forwarding MPLS VPN Packets)

A) LDPB) RSVPC) MP-BGPD) the core IGP

Q49) In MPLS VPNs, why must the BGP next hop be set to the egress router in all MP-

IBGP updates? (Source: Forwarding MPLS VPN Packets)

______________________________________________________________________

Q50) What scenarios would cause the LSP tunnel between PE routers to break? (Source:

Forwarding MPLS VPN Packets)

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

Q51) How can P routers forward VPN packets if they do not have VPN routes? (Source:

Forwarding MPLS VPN Packets)

A) They forward based upon the LSP label. B) They forward based upon the VPN label. C) They forward based upon the MP-BGP next hop. D) They forward based upon a routing table lookup of the IP address.

Q52) Which router assigns the VPN label? (Source: Forwarding MPLS VPN Packets)

A) PB) egress CE C) egress PE D) ingress CE E) ingress PE

Page 312: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-91

Q53) What is used to identify the label that will be used to transport the VPN packet to the

egress router? (Source: Forwarding MPLS VPN Packets)

A) the IGP least-cost path B) the EBGP next-hop address C) the MP-IBGP next-hop address D) the VPN label entry in the LFIB

Q54) What is the impact of changing a BGP next hop on an MP-BGP update at

confederation boundaries? (Source: Forwarding MPLS VPN Packets)

A) The packet will be forwarded but over a suboptimal route. B) Packet forwarding for the affected destination will be interrupted. C) The first P router of the confederation that receives the packet will have to

perform a routing table lookup to identify the MP-IBGP next hop. D) The ingress PE router will forward an MPLS packet to the router identified as

the next hop, where it will be converted to an IP packet and forwarded via MP-IBGP.

Page 313: Implementing cisco mpls

4-92 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Module Self-Check Answer Key Q1) B

Q2) A

Q3) A, C

Q4) D

Q5) B

Q6) the need for customers to establish point-to-point links or virtual circuits between sites

Q7) The service provider allocates portions of its address space to the customers and manages the packet filters

on the PE routers to ensure full reachability between sites of a single customer and isolation between

customers.

Q8) The core service provider routers (P routers) contain all customer routes, and the PE routers contain only

routes of a single customer.

Q9) A

Q10) B

Q11) B

Q12) B

Q13) Shared PE router: All customers share the same (provider-assigned or public) address space. The PE router

contains all customer routes. Packet filters are used to provide isolation between customers.

Dedicated PE router: All customers share the same address space. The P routers contain all customer

routes. A route filter is used to forward the routes of each customer to the dedicated PE router of that

customer.

Q14) A

Q15) E

Q16) C

Q17) D

Q18) C

Q19) The virtual circuits in a partial mesh can be established based on a wide range of criteria, such as traffic

pattern between sites, availability of physical infrastructure, and cost considerations.

Q20) D

Q21) D

Q22) B

Q23) A

Q24) All customer sites can connect to the server sites.

All server sites can not connect to the customer sites.

Customer sites can not connect to each other.

Q25) Dedicated virtual circuits are deployed between any managed CE router and the central NMS router.

Q26) PE routers

Q27) the dedicated PE router peer-to-peer model

Page 314: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Technology 4-93

Q28) C

Q29) The RD is used to transform the non-unique IP addresses of the customer into unique VPNv4 addresses.

Q30) The RT attaches a set of VPN identifiers to a route that indicate its membership in several VPNs. This

capability allows one site to be a member of more than one VPN.

Q31) A site can be part of more than one VPN, resulting in differing routing requirements for sites that belong to

a single VPN and those belonging to multiple VPNs.

Q32) Some of the sites might be able to access destinations that they should not be able to access.

Q33) A, D

Q34) D

Q35) B

Q36) A

Q37) C

Q38) C

Q39) global IP routing table—contains all core IGP routes and the IPv4 routes; VRFs—contain CE routes and

VPNv4 routes

Q40) extended communities

Q41) Customer routes are identified by the RT contained in the extended BGP community.

Q42) C

Q43) C

Q44) B, D

Q45) C

Q46) The first label indicates the LSP that will be used to reach the egress router. The second label indicates the

VPN that the packet belongs to.

Q47) The egress router needs the label to identify which VPN the packet belongs to.

Q48) C

Q49) The BGP next hop is used to identify which LSP will be used to get to the egress router. If the IP address

of the PE router is announced as a BGP route, it will have no corresponding LDP label and the label stack

will not be built correctly.

Q50) If the IP address of the PE router is announced as a BGP route, it will have no corresponding LDP label

and the label stack will not be built correctly.

If the P routers perform summarization of the address range within which the IP address of the egress PE

router lies, the LSP tunnel will be disrupted at the summarization point.

Q51) A

Q52) C

Q53) C

Q54) B

Page 315: Implementing cisco mpls

4-94 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 316: Implementing cisco mpls

Module 5

MPLS VPN Implementation

OverviewThis module covers Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) implementation on Cisco IOS platforms. The module describes the concepts of virtual routing and forwarding (VRF) tables, the interaction between customer-to-provider routing protocols, and Multiprotocol Border Gateway Protocol (MP-BGP) in the service provider backbone, and also advanced MPLS VPN-specific routing protocol features. This module continues with a description of MPLS VPN monitoring and debugging commands that are available on Cisco IOS platforms and concludes with a troubleshooting lesson describing failure scenarios, identifying symptoms, and providing remedial action.

Module Objectives Upon completing this module, you will be able to configure, monitor, and troubleshoot VPN

operations. This ability includes being able to meet these objectives:

Describe the usage of VRF instances in an MPLS VPN environment

Configure VRF tables

Configure MP-BGP sessions between PE routers

Configure small-scale routing protocols (static, RIP, and EIGRP) between CE and PE routers

Monitor MPLS VPN operations

Configure OSPF as the routing protocol between CE and PE routers

Configure BGP as the routing protocol between CE and PE routers

Troubleshoot MPLS VPN operations

Page 317: Implementing cisco mpls

5-2 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 318: Implementing cisco mpls

Lesson 1

Using MPLS VPN Mechanisms of Cisco IOS Platforms

Overview This lesson first introduces the virtual routing and forwarding (VRF) table, the major data structure associated with Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) implementation on Cisco IOS platforms. The lesson describes the other MPLS VPN attributes that are associated with a VRF instance, and explains the need for routing protocol contexts and the interaction of routing protocol contexts, VRFs, and Multiprotocol Border Gateway Protocol (MP-BGP).

Having a clear understanding of how information is exchanged using VRFs and routing protocol contexts will make it easier to configure VRFs in your network.

Objectives Upon completing this lesson, you will be able to describe the usage of VRF tables in an MPLS VPN environment. This ability includes being able to meet these objectives:

Describe the characteristics of a VRF table

Describe the need for routing protocol contexts

Describe the characteristics of VPN-aware routing protocols

Describe how VRF tables are used

Describe the outbound BGP route propagation process in an MPLS VPN implementation

Describe the inbound BGP route propagation process in an MPLS VPN implementation

Describe the outbound non-BGP route propagation process in an MPLS VPN implementation

Describe the inbound non-BGP route propagation process in an MPLS VPN implementation

Page 319: Implementing cisco mpls

5-4 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Is a VRF Table? This topic describes the characteristics of a VRF table.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-3

VRF Table

• A VRF is the routing and forwarding instance for a set of sites with identical connectivity requirements.

• Data structures associated with a VRF are as follows:

– IP routing table

– CEF table

– Set of rules and routing protocol parameters (routing protocol contexts)

– List of interfaces that use the VRF

• Other information associated with a VRF is as follows:

– Route distinguisher

– Set of import and export route targets

The major data structure associated with MPLS VPN implementation on Cisco IOS platforms is the VRF table. This data structure encompasses an IP routing table identical in function to the following:

The global IP routing table in Cisco IOS software

A Cisco Express Forwarding (CEF) table identical in function to the global CEF forwarding table (Forwarding Information Base [FIB])

Specifications for routing protocols running inside the VRF instance

A VRF is a routing and forwarding instance that you can use for a single VPN site or for many sites connected to the same provider edge (PE) router if and only if these sites share exactly the same connectivity requirements.

Other MPLS VPN attributes associated with a VRF table are as follows:

The route distinguisher (RD), which is prepended (for example, RD + IP address) to all routes exported from the VRF into the global VPN version 4 (VPNv4)—also called VPN IP version 4 (IPv4) Border Gateway Protocol (BGP) table

A set of export route targets (RTs), which are attached to any route exported from the VRF

A set of import RTs, which are used to select VPNv4 routes that are to be imported into the VRF

Page 320: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-5

What Is the Need for Routing Protocol Contexts? This topic describes the need for routing protocol contexts.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-4

Need for Routing Protocol Contexts

• There are two backbones with overlapping addresses.

• RIP is running in both VPNs.• RIP in VPN A has to be different from

RIP in VPN B.• Cisco IOS software supports only one

RIP process per router.

Traditional Cisco IOS software can support a number of different routing protocols. In some cases, even several completely isolated copies of the same routing protocol are supported. For example, several Open Shortest Path First (OSPF) processes can be used.

It is important to understand that for several important routing protocols, such as Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), Intermediate System-to-Intermediate System (IS-IS), or BGP, Cisco IOS software supports only a single copy of the protocol running in the router. These protocols cannot be used directly between PE and customer edge (CE) routers in VPN environments because each VPN (or, more precisely, each VRF) needs a separate, isolated copy of the routing protocol to prevent undesired route leakage between VPNs. Furthermore, VPNs can use overlapping IP address spaces (for example, each VPN could use subnetworks of network 10.0.0.0), which would also lead to routing confusions if all VPNs shared the same copy of the routing protocol.

Page 321: Implementing cisco mpls

5-6 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are VPN-Aware Routing Protocols? This topic describes the characteristics of VPN-aware routing protocols.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-5

VPN-Aware Routing Protocols

Routing context = routing protocol run in one VRF:

• Supported by VPN-aware routing protocols:

– External BGP (EBGP), EIGRP, OSPF, RIP version 2 (RIPv2), IS-IS, static routes

• Implemented as several instances of a single routing process (EIGRP, EBGP, RIPv2, IS-IS) or as several routing processes (OSPF)

• Independent per-instance router variables for each instance

“Routing contexts” were introduced in Cisco IOS software to support the need for separate isolated copies of VPN routing protocols. Routing contexts can be implemented as separate routing processes (in OSPF), similar to traditional Cisco IOS software implementation, or as separate isolated “instances” of the same routing protocol.

If the routing contexts are implemented as instances of the same routing protocol, each instance contains its own independent routing protocol parameters. Examples would include networks over which the routing protocol is run, timers, authentication parameters, passive interfaces, and neighbors. This independence allows the network designer maximum flexibility in implementing routing protocols between PE and CE routers.

Page 322: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-7

How Are VRF Tables Used? This topic describes how VRF tables are used in an MPLS VPN implementation.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-6

VRF Table

• Contains routes that should be available to a particular set of sites

• Analogous to standard Cisco IOS software routing table; supports same set of mechanisms

• VPN interfaces (physical interface, subinterfaces, logical interfaces) assigned to VRFs:

– Many interfaces per VRF

– Each interface assignable to only one VRF

The routes received from VRF routing protocol instances or from dedicated VRF routing processes are inserted into the IP routing table contained within the VRF. This IP routing table supports exactly the same set of mechanisms as the standard Cisco IOS software routing table. These mechanisms include filter mechanisms (distribute lists or prefix lists) and interprotocol route selection mechanisms (administrative distances).

The per-VRF Forwarding Information Base (FIB) table is built from the per-VRF routing table. This table is used to forward all the packets received through the interfaces associated with the VRF. Any interface can be associated with a VRF, be it a physical interface, subinterface, or a logical interface, as long as it supports CEF switching.

Note The requirement to support CEF switching on inbound VRF interfaces prevents certain

media or encapsulation types from being used for VPN connectivity. More notable examples

in mainstream Cisco IOS Release 12.1 include dialer interfaces, ISDN interfaces, and

Switched Multimegabit Data Service (SMDS) interfaces. Some restrictions are already lifted

in Cisco IOS Release 12.1T. Refer to the release notes of the Cisco IOS platform that you

are using for details about the interfaces and media types supporting CEF switching.

There is no limit to the number of interfaces associated with one VRF (other than the number of interfaces supported by the router). However, each interface can be assigned to only one VRF because the router needs to uniquely identify the forwarding table to be used for packets received over an interface.

Page 323: Implementing cisco mpls

5-8 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Propagating BGP Routes�Outbound This topic describes the outbound BGP route propagation process in an MPLS VPN implementation.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-7

• Two VPNs are attached to the same PE router.• Each VPN is represented by a VRF.

BGP Route Propagation�Outbound

This figure and the next figures illustrate the interactions between VRF instances of routing processes, VRF routing tables, and the global VPNv4 BGP routing process.

Example: BGP Route Propagation Outbound

The network contains two VPN customers. Ordinarily, the customer sites would be connected to a number of PE routers. This example focuses only on a single PE router, which contains two VRFs—one for each customer. Each customer is connected to the PE router, which is running BGP. CE-BGP-A is the CE router for customer A and is associated with VRF-A (VPN-A). CE-BGP-B is the CE router for customer B and is associated with VRF-B (VPN-B).

Page 324: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-9

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-8

• BGP-speaking CE routers announce their prefixes to the PE router via BGP.

• The instance of BGP process associated with the VRF of the PE-CE interface collects the routes and inserts them into the VRF routing table.

BGP Route Propagation�Outbound (Cont.)

The CE routers are BGP neighbors of the PE router. The BGP-speaking CE routers announce their networks via External Border Gateway Protocol (EBGP) sessions to the PE router. The PE router associates each BGP neighbor relationship with individual VRFs. The routes received from each VRF routing protocol instance are inserted into the IP routing table contained within that VRF.

A per-VRF forwarding table, FIB, is built from the per-VRF routing table and is used to forward all the packets received through the interfaces associated with the VRF.

Page 325: Implementing cisco mpls

5-10 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-9

• The route distinguishers are prepended during the route export to the BGP routes from the VRF instance of the BGP process to convert them into VPNv4 prefixes. Route targets are attached to these prefixes.

• VPNv4 prefixes are propagated to other PE routers.

BGP Route Propagation�Outbound (Cont.)

This figure illustrates the interactions between VRF instances of routing processes, VRF routing tables, and the global VPNv4 BGP routing process.

Example: BGP Route Propagation Outbound The BGP routes received from BGP-speaking CE routers are copied into the MP-BGP table for further propagation to other PE routers. This is the export process.

The IP prefixes are prepended with the RD, and the set of RTs (extended BGP communities) configured as export RTs for the VRF is attached to the resulting VPNv4 route.

Note There is not a separate per-VRF BGP table and global MP-BGP table in Cisco IOS software.

Page 326: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-11

Propagating BGP Routes�Inbound This topic describes the inbound BGP route propagation process in an MPLS VPN implementation.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-10

• VPNv4 prefixes are received from other PE routers.

• The VPNv4 prefixes are inserted into proper VRF routing tables based on their route targets and import route targets configured in VRFs.

• The route distinguisher is removed during this process.

BGP Route Propagation�Inbound

As other PE routers start originating VPNv4 routes, the MP-BGP process in the PE router receives the routes. The routes are filtered based on RT attributes attached to them, and are inserted into the proper per-VRF IP routing tables based on the import RTs configured for individual VRFs. The RD that was prepended by the originating PE router is removed before the route is inserted into the per-VRF IP routing table.

Page 327: Implementing cisco mpls

5-12 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-11

BGP Route Propagation�Inbound (Cont.)

• Routes are received from backbone MP-BGP and imported into a VRF.

• IPv4 routes are forwarded to EBGP CE neighbors attached to that VRF.

The Multiprotocol Internal Border Gateway Protocol (MP-IBGP) VPNv4 routes received from other PE routers and selected by the import RTs of a VRF are automatically propagated as 32-bit IPv4 routes to all BGP-speaking CE neighbors of the PE router.

Page 328: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-13

Propagating Non-BGP Routes�Outbound This topic describes the outbound non-BGP route propagation process in an MPLS VPN implementation. The example will discuss the case of RIP-speaking CE routers, but a similar process would support other non-BGP protocols.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-12

• RIP-speaking CE routers announce their prefixes to the PE router via RIP.

• The instance of RIP process associated with the VRF of the PE-CE interface collects the routes and inserts them into the VRF routing table.

Non-BGP Route Propagation�Outbound

RIP-speaking CE routers identify the correct instance of RIP on the PE router when an inbound PE interface is associated with a VRF. This association allows CE routers to announce their networks to the appropriate per-VRF routing table.

Page 329: Implementing cisco mpls

5-14 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-13

• The RIP routes entered in the VRF routing table are redistributed into BGP for further propagation into the MPLS VPN backbone.

• Redistribution between RIP and BGP has to be configured for properMPLS VPN operation.

Non-BGP Route Propagation�Outbound (Cont.)

MP-BGP is used in the MPLS VPN backbone to carry VPN routes (prefixed with the RD) as 96-bit VPNv4 routes between the PE routers. The backbone BGP process looks exactly like a standard Internal Border Gateway Protocol (IBGP) setup from the perspective of the VRF. The per-VRF RIP routes therefore must be redistributed into the per-VRF instance of the BGP process to allow them to be propagated through the backbone MP-BGP process to other PE routers.

Caution Failure to redistribute non-BGP routes into the per-VRF instance of BGP is one of the most

common MPLS VPN configuration errors.

Should there be an overlap between an inbound RIP update and an inbound EBGP update, the standard route selection mechanism (administrative distance) is used in the per-VRF IP routing table and the EBGP route takes precedence over the RIP route. EBGP precedence results from the fact that the administrative distance of EBGP routes (20) is better than the administrative distance of RIP routes (120).

Page 330: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-15

Propagating Non-BGP Routes�Inbound This topic describes the inbound route propagation process in an MPLS VPN implementation.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-14

Non-BGP Route Propagation�Inbound

• MP-IBGP routes imported into a VRF are redistributed into the instanceof RIP configured for that VRF.

• Redistribution between BGP and RIP has to be configured for end-to-end RIP routing between CE routers.

The MP-IBGP routes, although they are inserted in the per-VRF IP routing table, are notpropagated to RIP-speaking CE routers automatically. To propagate these MP-IBGP routes to the RIP-speaking CE routers, you must manually configure the redistribution between per-VRF instance of BGP and per-VRF instance of RIP.

Page 331: Implementing cisco mpls

5-16 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-15

Non-BGP Route Propagation�Inbound(Cont.)

• Routes redistributed from BGP into a VRF instance of RIP are sent toRIP-speaking CE routers.

When the IBGP routes from the per-VRF IP routing table are successfully redistributed into the per-VRF instance of the RIP process, the RIP process announces these routes to RIP-speaking CE routers, thus achieving transparent end-to-end connectivity between the CE routers.

Page 332: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-17

Summary This topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-16

Summary

• A VRF table is a routing and forwarding instance that associates additional attributes such as RD, import RT, and export RT to routing entries.

• Routing contexts allow multiple copies of routing protocols to run concurrently as separate VRF instances to prevent undesired route leakage between VPNs.

• VPN-aware routing protocols allow separation of routing tables either as separate routing processes (OSPF) or separate isolated instances of the same protocol (BGP, EIGRP, RIPv2).

• A VRF table is used to logically separate routing information from different VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2�5-17

Summary (Cont.)

• Outbound BGP route propagation starts with CE BGP updates. Because the protocol source is BGP, MP-BGP can directly prepend RDs and RTs to the respective inbound instances of CE BGP updates.

• Inbound BGP route propagation filters routes based on RT into respective instances of VRF.

• Outbound non-BGP route propagation starts with CE protocols other than BGP. Therefore, an additional step of redistribution is required before prepending RD and RT.

• Inbound non-BGP route propagation filters routes based on RT into respective VRF instances. Redistribution is required for route propagation with non-BGP speaking CEs.

Page 333: Implementing cisco mpls

5-18 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 334: Implementing cisco mpls

Lesson 2

Configuring VRF Tables

OverviewThis lesson explains how to configure virtual routing and forwarding (VRF) tables, listing the configuration tasks, syntax, and definitions of commands used for the creation of VRFs. The lesson also provides an example of a Virtual Private Network (VPN) configuration.

It is important to know how to configure and apply a VRF table onto a routing interface. It is essential to understand the command syntax for the configurations that you want to deploy in your network. This lesson will provide you with the information that will enable you to succeed at such tasks.

ObjectivesUpon completing this lesson, you will be able to describe how to configure VRF tables. This ability includes being able to meet these objectives:

Identify the tasks that are required to configure a VRF table

Create a VRF table and assign RDs

Specify export and import RTs

Describe the optional use of VPN IDs

Assign an interface to a VRF table

Describe a typical Cisco IOS configuration that enables VRF

Page 335: Implementing cisco mpls

5-20 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are the VRF Configuration Tasks? This topic identifies the tasks required to configure a VRF table.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-3

VRF Configuration Tasks

VRF configuration tasks:

• Create a VRF table

• Assign RD to the VRF

• Specify export and import route targets

• (Optional) Configure a VPN ID

• Assign interfaces to VRFs

Configuring a VRF table and starting deployment of a Multiprotocol Label Switching (MPLS) VPN service for a customer consists of these four mandatory steps:

Create a new VRF table.

Assign a unique route distinguisher (RD) to the VRF.

Note You must assign a unique RD to every VRF created in a provider edge (PE) router. The

same RD might be used in multiple PE routers, based on customer connectivity

requirements. The same RD should be used on all PE routers for simple VPN service.

Specify import and export route targets (RTs) for the VRF.

Note Import and export RTs should be equal to the RD for simple VPN service.

Assign interfaces to VRFs.

Page 336: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-21

Creating VRF Tables and Assigning RDs This topic describes how to create a VRF table and assign RDs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-4

·° Ş®ş ˛żł»

᫬»®ř˝±˛ş·ą÷ý

• This command creates a new VRF or enters configuration of an existing VRF.

• VRF names are case-sensitive.

• VRF is not operational unless you configure RD.

• VRF names have only local significance.

®Ľ ®±«¬»óĽ·­¬·˛ą«·­¸»®

᫬»®ř˝±˛ş·ąóŞ®ş÷ý

• This command assigns a route distinguisher to a VRF.

• You can use ASN:nn or A.B.C.D:nn format for RD.

• Each VRF in a PE router has to have a unique RD.

Creating VRF Tables and Assigning RDs

ip vrf To configure a VRF routing table, use the ip vrf command in global configuration mode. To remove a VRF routing table, use the no form of this command.

ip vrf vrf-name

no ip vrf vrf-name

This table describes the parameters for the ip vrf command.

Syntax Description

Parameter Description

Ş®şó˛żł» Name assigned to a VRF.

Defaults No VRFs are defined. No import or export lists are associated with a VRF. No route maps are associated with a VRF.

Page 337: Implementing cisco mpls

5-22 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

rdTo create routing and forwarding tables for a VRF, use the rd command in VRF configuration submode: rd route-distinguisher.

This table describes the parameters for the rd command.

Syntax Description

Parameter Description

route-distinguisher Adds an 8-byte value to an IP version 4 (IPv4) prefix to create a VPN version 4 (VPNv4) prefix

The RD can be specified in one of these two formats:

16-bit autonomous system (AS) number followed by a 32-bit decimal number (ASN:nn)

32-bit IP address followed by a 16-bit decimal number (A.B.C.D:nn)

Defaults

There is no default. An RD must be configured for a VRF table to be functional.

Note Once a VRF has been defined using the ip vrf command and a RD has been assigned

using the rd command, the VRF is operational. After local interfaces are bound to the VRF

with the ip vrf forwarding command, the interfaces will appear in the routing display of the

VRF table.

Page 338: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-23

Specifying Export and Import RTs This topic describes how to specify export and import RTs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-5

®±«¬»ó¬ż®ą»¬ »¨°±®¬ ÎĚ

᫬»®ř˝±˛ş·ąóŞ®ş÷ý

• Specifies an RT to be attached to every route exported from this VRF to MP-BGP.

• Allows specification of many export RTs—all to be attached to every exported route.

®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ÎĚ

᫬»®ř˝±˛ş·ąóŞ®ş÷ý

• Specifies an RT to be used as an import filter—only routes matching the RT are imported into the VRF.

• Allows specification of many import RTs—any route where at least one RT attached to the route matches any import RT is imported into the VRF.

Because of implementation issues, at least one export route target must also be an import route target of the same VRF in Cisco IOS Release 12.4(T) and earlier.

Specifying Export and Import RTs

route-target To create an RT extended community for a VRF, use the route-target command in VRF submode. To disable the configuration of an RT community option, use the no form of this command.

route-target {import | export | both} route-target-ext-community

no route-target {import | export | both} route-target-ext-community

This table describes the parameters for the route-target command.

Syntax Description

Parameter Description

import VPNv4 routes that contain an extended community value that matches the route-target-ext-community field that will be imported into the VRF

export The value in the route-target-ext-community field that will be inserted into the extended community for routes exported from the VRF to VPNv4

both Sets the value used by both the import and export process to the valued indicated in the route-target-ext-community field

route-target-ext-community The RT extended community attribute for the VRF

Page 339: Implementing cisco mpls

5-24 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Similar to RDs, the RTs can be specified in one of these two formats:

16-bit AS number followed by a 32-bit decimal number (ASN:nn)

32-bit IP address followed by a 16-bit decimal number (A.B.C.D:nn)

Defaults

There are no defaults. A VRF has no RT extended community attributes associated with it until specified by the route-target command.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-6

®±«¬»ó¬ż®ą»¬ ľ±¬¸ ÎĚ

᫬»®ř˝±˛ş·ąóŞ®ş÷ý

• In cases where the export RT matches the import RT, use this form of the route-target command.

Sample router configuration for simple customer VPN:

Specifying Export and Import RTs (Cont.)

·° Ş®ş Ý«­¬±ł»®ÁßŢÝ

®Ľ ęëďéíćďë

®±«¬»ó¬ż®ą»¬ »¨°±®¬ ęëďéíćďë

®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ęëďéíćďë

Whenever an RT is both an import and an export RT for a VRF, you can use the route-targetboth command to simplify the configuration. For example, the two route-target configuration lines in the sample router configuration in the figure could be entered with a single command: route-target both 12703:15.

Page 340: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-25

Using VPN IDs This topic defines VPN identifiers (VPN IDs) and discusses how to configure them.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-7

What Is a VPN ID?

• A VPN identifier (VPN ID) allows you to identify VPNs by an ID number

– Not used to control distribution of routing information

– Not used to associate IP addresses with VPN IDs in routing updates

– Is stored on the VRF structure for a VPN

• Has the following elements:

– OUI (three-octet hex number)

– A VPN index (four-octet hex number identifying VPN within the company)

• Configure all PE routers that belong to the same VPN with the same VPN ID.

• Make the VPN ID unique to the Service Provider network

Multiple VPNs can be configured in a router. You can use a VRF name (a unique ASCII string) to reference a specific VPN configured in the router. Alternately, you can use a VPN ID to identify a particular VPN in the router as described in RFC 2685. The VPN ID is stored in the corresponding VRF structure for the VPN.

Note Configuration of a VPN ID for a VPN is optional. You can still use a VRF name to identify

configured VPNs in the router. The VPN name is not affected by the VPN ID configuration.

These are two independent mechanisms to identify VPNs.

The MPLS VPN ID feature is not used to control the distribution of routing information or to associate IP addresses with MPLS VPN ID numbers in routing updates.

Each VPN ID defined by RFC 2685 consists of these elements:

An Organizational Unique Identifier (OUI), a three-octet hex number. The IEEE Registration Authority assigns OUIs to any company that manufactures components under the International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 8802 standard. The OUI is used to generate universal LAN MAC addresses and protocol identifiers for use in local and metropolitan area network applications. For example, an OUI for Cisco Systems is 00-03-6B (hex).

A VPN index, a four-octet hex number, which identifies the VPN within the company.

To ensure that the VPN has a consistent VPN ID, assign the same VPN ID to all the routers in the service provider network that services that VPN.

Page 341: Implementing cisco mpls

5-26 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

You can use several applications to manage VPNs using the VPN ID, such as Dynamic Host Configuration Protocol (DHCP) and RADIUS server.

Configuring VPN IDs This section discusses how to configure VPN IDs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-8

·° Ş®ş Ş®şó˛żł»

᫬»®ř˝±˛ş·ą÷ý

Configuring VPN IDs

Ş°˛ ·Ľ ±«·ćŞ°˛ó·˛Ľ»¨

᫬»®ř˝±˛ş·ąóŞ®ş÷ý

• This command assigns the VPN ID to the VRF.

• This command creates a VRF routing table and a CEF forwarding table, and enters VRF configuration mode.

vpn id To assign a VPN ID to a VRF, use the vpn id command in the VRF configuration submode. To disable the configuration of an RT community option, use the no form of this command.

vpn id oui:vpn-index

no vpn id oui:vpn-index

This table describes the parameters for the vpn id command.

Syntax Description

Parameter Description

oui This parameter is an OUI. The IEEE organization assigns this identifier to companies. The OUI is restricted to three octets.

vpn-index This value identifies the VPN within the company. This VPN index is restricted to four octets.

Defaults

By default, the VPN ID is not set.

Page 342: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-27

Assigning an Interface to a VRF Table This topic describes how to assign an interface to a VRF table.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-9

·° Ş®ş ş±®©ż®Ľ·˛ą Ş®şó˛żł»

᫬»®ř˝±˛ş·ąó·ş÷ý

• This command associates an interface with the specified VRF.

• The existing IP address is removed from the interface when interface is put into VRF—the IP address must be reconfigured.

• CEF switching must be enabled on the interface.

·° ˝»ş

˙

·˛¬»®şż˝» ­»®·ż´ đńđ

·° Ş®ş ş±®©ż®Ľ·˛ą Ý«­¬±ł»®ÁßŢÝ

·° żĽĽ®»­­ ďđňđňđňď îëëňîëëňîëëňîëî

Sample router configuration:

Assigning an Interface to a VRF Table

ip vrf forwarding To associate a VRF with an interface or subinterface, use the ip vrf forwarding command in interface configuration mode. To disassociate a VRF, use the no form of this command.

ip vrf forwarding vrf-name

no ip vrf forwarding vrf-name

This table describes the parameters for the ip vrf forwarding command.

Syntax Description

Parameter Description

vrf-name Name assigned to a VRF

Defaults The default for an interface is the global routing table.

Note When an interface is configured with a particular VRF, its IP address is removed from the

interface and from the global routing table. This action occurs based on the assumption that

the address is not valid across multiple routing tables, and the address should be

reconfigured after the interface is associated to a VRF.

Page 343: Implementing cisco mpls

5-28 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Typical Configuration to Enable VRFs This topic describes a typical Cisco IOS configuration that enables VRFs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-10

MPLS VPN Network Example

• The network supports two VPN customers.

• Customer A runs RIP and BGP with the service provider; customer B uses only RIP.

• Both customers use network 10.0.0.0.

To illustrate the use of MPLS VPN configuration commands, you can look at a configuration of the PE router in a sample network.

Example: MPLS VPN Network

The figure illustrates a configuration of the PE router in a sample network with two VPN customers. Customer A (with four sites) is using Border Gateway Protocol (BGP) and Routing Information Protocol (RIP) as the provider edge-customer edge (PE-CE) routing protocol, and customer B (with two sites) is using only RIP. Both customers use private IP address space (subnetworks of network 10.0.0.0).

Page 344: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-29

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-11

MPLS VPN Network Example (Cont.)

The configuration steps that you perform on the PE router so far are as follows:

Step 1 Configure VRFs for customer A and customer B.

Step 2 Assign RDs and RTs to the VRFs. Only one RD per customer is used on all PE routers in this MPLS VPN backbone, because these customers require only simple VPN connectivity. To simplify the configuration and troubleshooting process, the RTs are made equal to the RDs.

Step 3 Assign PE-CE interfaces to individual VRFs.

Page 345: Implementing cisco mpls

5-30 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-12

Summary

There are four required VRF configuration tasks:

• Create a VRF table

– Use the ip vrf command

• Assign RD to the VRF

– Use the rd command

• Specify export and import RTs

– Use the route-target command

• Assign interfaces to VRFs.

– Use the ip vrf forwarding command, and reconfigure the IP address

Configuring a numeric VPN ID is optional.

– Use the vpn id command

Page 346: Implementing cisco mpls

Lesson 3

Configuring an MP-BGP Session Between PE Routers

OverviewThis lesson explains the Border Gateway Protocol (BGP) process in a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN)-enabled router, listing the configuration tasks, steps, syntax, and descriptions. The lesson also discusses BGP community propagation and provides a Multiprotocol Internal Border Gateway Protocol (MP-IBGP) configuration example.

Most of the configuration in an MPLS VPN depends on how the provider edge (PE) routers are configured. Having a good grasp of exactly what is being configured and why will help greatly to ensure that your MPLS VPN network operates as smoothly as possible.

ObjectivesUpon completing this lesson, you will be able to describe how to configure Multiprotocol Border Gateway Protocol (MP-BGP) in an MPLS VPN backbone. This ability includes being able to meet these objectives:

Configure BGP address families

Describe the requirements for enabling BGP neighbors in an MPLS VPN environment

Identify the process steps involved in configuring MP-BGP in an MPLS VPN environment

Configure MP-IBGP in an MPLS VPN environment

Configure MP-BGP community propagation in an MPLS VPN environment

Disable IPv4 route exchange in an MPLS VPN environment

Page 347: Implementing cisco mpls

5-32 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Configuring BGP Address Families This topic describes how to configure BGP address families.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-3

Configuring BGP Address Families

• The BGP process in an MPLS VPN-enabled router performs three separate tasks:

– Global BGP routes (Internet routing) are exchanged as in traditional BGP setup.

– VPNv4 prefixes are exchanged through MP-BGP.

– VPN routes are exchanged with CE routers through per-VRF External Border Gateway Protocol sessions.

• Address families (routing protocol contexts) are used to configure these three tasks in the same BGP process.

Independently from the MPLS VPN architecture, the PE router can use BGP IP version 4 (IPv4) route updates to receive and propagate Internet routes in scenarios where the PE routers are also used to provide Internet connectivity to customers.

The MPLS VPN architecture uses the BGP routing protocol in these two different ways:

VPN version 4 (VPNv4) routes are propagated across an MPLS VPN backbone using MP-BGP between the PE routers.

BGP can be used as the provider edge-customer edge (PE-CE) routing protocol to exchange VPN routes between the PE routers and the CE routers.

All three route exchange mechanisms take place in one BGP process (because only one BGP process can be configured per router). The routing protocol contexts (called address families from the router configuration perspective) are used to configure all three independent route exchange mechanisms.

Page 348: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-33

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-4

®±«¬»® ľą° ż­ó˛«łľ»®

᫬»®ř˝±˛ş·ą÷ý

• Selects global BGP routing process

żĽĽ®»­­óşżł·´§ Ş°˛Şě

᫬»®ř˝±˛ş·ąó®±«¬»®÷ý

• Selects configuration of VPNv4 prefix exchanges under MP-BGP sessions

żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ş®şó˛żł»

᫬»®ř˝±˛ş·ąó®±«¬»®÷ý

• Selects configuration of per-VRF PE-CE EBGP parameters

Configuring BGP Address Families (Cont.)

Use the address-family command in router configuration mode to select the routing context that you would like to configure, as follows:

Internet routing (global IP routing table) is the default address family that you configure when you start configuring the BGP routing process.

To configure MP-BGP sessions between the PE routers, use the address-family vpnv4command.

To configure BGP between the PE routers and the CE routers within individual virtual routing and forwarding (VRF) tables, use the address-family ipv4 vrf vrf-name command.

router bgp To configure the BGP routing process, use the router bgp command in global configuration mode. To remove a routing process, use the no form of this command.

router bgp as-number

no router bgp as-number

This table describes the router bgp command.

Syntax Description

Parameter Description

ż­ó˛«łľ»® Displays the number of an autonomous system (AS) that identifies the router to other BGP routers and tags the routing information passed along

Defaults No BGP routing process is enabled by default.

Page 349: Implementing cisco mpls

5-34 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

address-familyTo enter the address family submode for configuring routing protocols, such as BGP, Routing Information Protocol (RIP), and static routing, use the address-family command in global configuration mode. To disable the address family submode for configuring routing protocols, use the no form of this command.

VPNv4 unicast:

— address-family vpnv4 [unicast]

— no address-family vpnv4 [unicast]

IPv4 unicast:

— address-family ipv4 [unicast]

— no address-family ipv4 [unicast]

IPv4 unicast with CE router:

— address-family ipv4 [unicast] vrf vrf-name

— no address-family ipv4 [unicast] vrf vrf-name

This table describes the address-family command.

Syntax Description

Parameter Description

·°Şě Configures sessions that carry standard IPv4 address prefixes

Ş°˛Şě Configures sessions that carry customer VPNv4 prefixes, each of which has been made globally unique by adding an 8-byte route distinguisher (RD)

«˛·˝ż­¬ (Optional) Specifies unicast prefixes

Ş®ş Ş®şó˛żł» Specifies the name of a VPN VRF to associate with submode commands

Page 350: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-35

Enabling BGP Neighbors This topic describes the requirements for enabling BGP neighbors in an MPLS VPN environment.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-5

BGP Neighbors

• MP-BGP neighbors are configured under the BGP routing process:

– These neighbors need to be activated for each global address family that they support.

– Per-address-family parameters can be configured for these neighbors.

• VRF-specific EBGP neighbors are configured under corresponding address families.

MPLS VPN architecture defines these two types of BGP neighbors:

Global BGP neighbors (other PE routers) with which the PE router can exchange multiple types of routes (These neighbors are defined in the global BGP definition and only have to be activated for individual address families.)

Per-VRF BGP neighbors (the CE routers), which are configured and activated within the address-family ipv4 vrf vrf-name command

Page 351: Implementing cisco mpls

5-36 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Configuring MP-BGP This topic identifies the process steps involved in configuring MP-BGP in an MPLS VPN environment.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-6

Configuring MP-BGP

MPLS VPN MP-BGP configuration steps:

• Configure MP-BGP neighbor under BGP routing process.

• Configure BGP address family VPNv4.

• Activate configured BGP neighbor for VPNv4 route exchange.

• Specify additional parameters for VPNv4 route exchange (filters, next hops, and so on).

Configure BGP connectivity between two PE routers in these four steps:

Step 1 Configure the remote PE router as a global BGP neighbor in BGP router configuration mode.

Step 2 Define the parameters that affect all BGP route exchange (for example, source address for the TCP session) on the global BGP neighbor.

Step 3 Select the VPNv4 address family and activate the BGP neighbor for VPNv4 route exchange.

Step 4 Configure additional VPNv4-specific BGP parameters (filters, next-hop processing, route maps) within the VPNv4 address family.

Note IPv4-specific BGP parameters are still configured under the BGP router configuration mode;

there is no special IPv4 address family.

Page 352: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-37

Configuring MP-IBGP This topic describes how to configure MP-IBGP in an MPLS VPN environment.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-7

®±«¬»® ľą° ż­ó˛«łľ»®˛»·ą¸ľ±® ·°óżĽĽ®»­­ ®»ł±¬»óż­ ż­ó˛«łľ»®˛»·ą¸ľ±® ·°óżĽĽ®»­­ «°Ľż¬»ó­±«®˝» ·˛¬»®şż˝»ó¬§°»

·˛¬»®şż˝»ó˛«łľ»®

᫬»®ř˝±˛ş·ą÷ý

• All MP-BGP neighbors have to be configured under global BGP routing configuration.

• MP-IBGP sessions have to run between loopback interfaces.

żĽĽ®»­­óşżł·´§ Ş°˛Şě

᫬»®ř˝±˛ş·ąó®±«¬»®÷ý

• This command starts configuration of MP-BGP routing for VPNv4 route exchange.

• The parameters that apply only to MP-BGP exchange of VPNv4 routes between already configured IBGP neighbors are configured under this address family.

Configuring MP-IBGP

The initial commands needed to configure an MP-IBGP session between PE routers are as follows:

The neighbor ip-address remote-as as-number command configures the neighboring PE router.

The neighbor ip-address update-source interface-type interface-number command configures the source address used for the TCP session carrying BGP updates and the IP address used as the BGP next hop for VPNv4 routes.

The address-family vpnv4 command allows you to enter VPNv4 configuration mode, where the additional VPNv4-specific parameters have to be configured on the BGP neighbor.

Page 353: Implementing cisco mpls

5-38 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

neighbor remote-as To add an entry to the BGP neighbor table, use the neighbor remote-as command in router configuration mode. To remove an entry from the table, use the no form of this command.

neighbor {ip-address | peer-group-name} remote-as as-number

no neighbor {ip-address | peer-group-name} remote-as as-number

This table describes the neighbor remote-as command.

Syntax Description

Parameter Description

·°óżĽĽ®»­­ Neighbor IP address

°»»®óą®±«°ó˛żł» Name of BGP peer group

ż­ó˛«łľ»® AS to which the neighbor belongs

Defaults There are no BGP neighbor peers.

neighbor update-source To have the Cisco IOS software allow internal BGP sessions to use any operational interface for TCP connections, use the neighbor update-source command in router configuration mode. To restore the interface assignment to the closest interface, which is called the “best local address,” use the no form of this command.

neighbor {ip-address | peer-group-name} update-source interface-type

no neighbor {ip-address | peer-group-name} update-source interface-type

This table describes the neighbor update-source command.

Syntax Description

Parameter Description

·°óżĽĽ®»­­ IP address of the BGP-speaking neighbor

°»»®óą®±«°ó˛żł» Name of BGP peer group

·˛¬»®şż˝»ó¬§°» Loopback interface

Defaults The default is the best local address.

Page 354: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-39

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-8

˛»·ą¸ľ±® ·°óżĽĽ®»­­ ż˝¬·Şż¬»

᫬»®ř˝±˛ş·ąó®±«¬»®óżş÷ý

• The BGP neighbor defined under BGP router configuration has to be activated for VPNv4 route exchange.

˛»·ą¸ľ±® ·°óżĽĽ®»­­ ˛»¨¬ó¸±°ó­»´ş

᫬»®ř˝±˛ş·ąó®±«¬»®óżş÷ý

• The next-hop-self keyword can be configured on the MP-IBGP session for MPLS VPN configuration if EBGP is being run with a CE neighbor.

Configuring MP-IBGP (Cont.)

After you define the remote PE router as a global BGP neighbor, you must activate it for VPNv4 route exchange.

neighbor activate To enable the exchange of information with a BGP neighboring router, use the neighboractivate command in router configuration mode. To disable the exchange of an address with a neighboring router, use the no form of this command.

neighbor {ip-address | peer-group-name} activate

no neighbor {ip-address | peer-group-name} activate

This table describes the neighbor activate command.

Syntax Description

Parameter Description

·°óżĽĽ®»­­ IP address of the neighboring router

°»»®óą®±«°ó˛żł» Name of BGP peer group

Defaults The exchange of addresses with neighbors is enabled by default for the IPv4 address family. For all other address families, address exchange is disabled by default. You can explicitly activate the default command by using the appropriate address family submode.

Page 355: Implementing cisco mpls

5-40 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

neighbor next-hop-self To disable next-hop processing of BGP updates on the router, use the neighbor next-hop-self command in router configuration mode. To disable this feature, use the no form of this command.

neighbor {ip-address | peer-group-name} next-hop-self

no neighbor {ip-address | peer-group-name} next-hop-self

This table describes the neighbor next-hop-self command.

Syntax Description

Parameter Description

·°óżĽĽ®»­­ IP address of the BGP-speaking neighbor

°»»®óą®±«°ó˛żł» Name of BGP peer group

Defaults Default is disabled.

Page 356: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-41

Configuring MP-BGP Community Propagation This topic describes how to configure MP-BGP community propagation in an MPLS VPN environment.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-9

˛»·ą¸ľ±® ·°óżĽĽ®»­­ ­»˛Ľó˝±łł«˛·¬§ Ĺ­¬ż˛Ľż®Ľ ¤ »¨¬»˛Ľ»Ľ ¤ ľ±¬¸Ă

᫬»®ř˝±˛ş·ąó®±«¬»®óżş÷ý

• This command with the option is enabled by default by Cisco IOS software after the BGP neighbor has been activated for VPNv4 route exchange.

• The command can be used to enable propagation of standard BGP communities attached to VPNv4 prefixes.

• Usage guidelines:

– Extended BGP communities attached to VPNv4 prefixes have to be exchanged between MP-BGP neighbors for proper MPLS VPN operation.

– To propagate standard BGP communities between

MP-BGP neighbors, use the option.

MP-BGP Community Propagation

MPLS VPN architecture introduced the “extended community” BGP attribute. BGP still supports the “standard community” attribute, which has not been superseded by the extended communities. The default community propagation behavior for standard BGP communities has not changed. Community propagation still needs to be configured manually. Extended BGP communities are propagated by default because their propagation is mandatory for successful MPLS VPN operation.

The neighbor send-community command was extended to support standard and extended communities. Use this command to configure propagation of standard and extended communities if your BGP design relies on use of standard communities. An example of this would be to propagate quality of service (QoS) information across the network.

Page 357: Implementing cisco mpls

5-42 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

neighbor send-community To specify that BGP community attributes that are attached to a BGP route should be sent to a BGP neighbor, use the neighbor send-community command in router configuration mode. To remove the entry, use the no form of this command.

neighbor {ip-address | peer-group-name} send-community [extended | both]

no neighbor {ip-address | peer-group-name} send-community

This table describes the neighbor send-community command.

Syntax Description

Parameter Description

·°óżĽĽ®»­­ Neighbor IP address

°»»®óą®±«°ó˛żł» Name of BGP peer group

Defaults

BGP communities are not propagated to any neighbor.

Page 358: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-43

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-10

MP-BGP BGP Community Propagation (Cont.)

The configuration example provided in the “Configuring VRF Tables” lesson continues here with configuration of MP-IBGP sessions on the PE router. This table describes the steps that you need to perform.

Configuration of MP-IBGP Sessions

Step Action

1 Define a loopback interface that will serve as the BGP next hop for VPNv4 routes and as the source address for the IBGP session.

2 Configure the remote PE router as the global BGP neighbor.

3 Specify the source address for the TCP session.

4 Select the VPNv4 address family.

5 Activate the remote PE router for VPNv4 route exchange.

6 Disable next-hop processing for VPNv4 route exchange. This action guarantees that the loopback 0 interface will always be the BGP next hop for VPNv4 routes propagated by this router to its MP-IBGP neighbors.

7 Configure propagation of standard and extended communities.

Page 359: Implementing cisco mpls

5-44 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Disabling IPv4 Route Exchange This topic describes how to disable IPv4 route exchange in an MPLS VPN environment.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-11

˛± ľą° Ľ»şż«´¬ ·°Şě󫲷˝ż­¬

᫬»®ř˝±˛ş·ąó®±«¬»®÷ý

• The exchange of IPv4 routes between BGP neighbors is enabled by default—every configured neighbor will also receive IPv4 routes.

• This command disables the default exchange of IPv4 routes—neighbors that need to receive IPv4 routes have to be activated for IPv4 route exchange.

• Use this command when the same router carries Internet and VPNv4 routes and you do not want to propagate Internet routes to some PE neighbors.

Disabling IPv4 Route Exchange

The BGP configuration discussed so far is appropriate for scenarios where the PE routers provide Internet and VPN connectivity. If the PE routers provide only VPN connectivity, they do not need Internet routing, and the IPv4 route exchange should be disabled. Here are the two ways of disabling IPv4 route exchange:

To disable IPv4 route exchange for only a few neighbors, your best option is to disable the IPv4 route exchange on a neighbor-by-neighbor basis by using the no neighbor activate command.

To disable IPv4 route exchange for most (or all) of the neighbors, you can use the no bgp default ipv4-unicast command. After you enter this command, you must manually activate IPv4 route exchange for each configured global BGP neighbor.

Page 360: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-45

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-12

• Neighbor 172.16.32.14 receives only Internet routes.

• Neighbor 172.16.32.15 receives only VPNv4 routes.

• Neighbor 172.16.32.27 receives Internet and VPNv4 routes.

®±«¬»® ľą° ęëďéí˛± ľą° Ľ»şż«´¬ ·°Şě󫲷˝ż­¬˛»·ą¸ľ±® ďéîňďęňíîňďě ®»ł±¬»óż­ ęëďéí˛»·ą¸ľ±® ďéîňďęňíîňďë ®»ł±¬»óż­ ęëďéí˛»·ą¸ľ±® ďéîňďęňíîňîé ®»ł±¬»óż­ ęëďéí

˙ ß˝¬·Şż¬» ×ĐŞě ®±«¬» »¨˝¸ż˛ą»

˛»·ą¸ľ±® ďéîňďęňíîňďě ż˝¬·Şż¬»˛»·ą¸ľ±® ďéîňďęňíîňîé ż˝¬·Şż¬»

˙ ͬ»°ýî Š ĘĐŇŞě ®±«¬» »¨˝¸ż˛ą»

żĽĽ®»­­óşżł·´§ Ş°˛Şě˛»·ą¸ľ±® ďéîňďęňíîňďë ż˝¬·Şż¬»˛»·ą¸ľ±® ďéîňďęňíîňîé ż˝¬·Şż¬»

Disabling IPv4 Route Exchange (Cont.)

In this example, only a subset of BGP neighbors needs to receive IPv4 routes.

Example: Disabling IPv4 Route Exchange

In the figure, the default propagation of IPv4 routes is thus disabled. IPv4 route exchange—and VPNv4 route exchange—is manually activated on a neighbor-by-neighbor basis:

Neighbor 172.16.32.14 receives only Internet routes based on the IPv4 activation.

Neighbor 172.16.32.15 receives only VPNv4 routes based on the VPNv4 activation.

Neighbor 172.16.32.27 receives Internet and VPNv4 routes based on both IPv4 and VPNv4 activations.

Page 361: Implementing cisco mpls

5-46 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-13

Summary

• Use the command to select the routing context that you want to configure.

• Use the router bgp command to configure the BGP routing process, and configure VRF-specific EBGP neighbors under corresponding address families.

• To configure MPLS VPN MP-BGP, you need to:

– Configure MP-BGP neighbors.

– Configure MP-BGP address family to start VPNv4 routing.

– Activate configured MP-BGP neighbors.

– Specify additional parameters for VPNv4 route exchange.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-14

Summary (Cont.)

• These commands are used to configure MP-IBGP:

– neighbor remote-as

– neighbor update-source

– neighbor activate

– neighbor next-hop-self

• Use the neighbor send-community command to support standard and extended communities.

• There are two ways to disable IPv4 route exchange:

– no neighbor activate command

– no bgp default ipv4-unicast command.

Page 362: Implementing cisco mpls

Lesson 4

Configuring Small-Scale Routing Protocols Between PE and CE Routers

OverviewThis lesson explains the provider edge-customer edge (PE-CE) routing protocol configuration steps and the various routing protocols that you can run between PE and CE routers. These protocols include Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), and static routes.

It is important to understand not only what you can configure between provider edge (PE) and customer edge (CE) routers when you are setting up Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs), but also how to accomplish the configuration successfully. This lesson looks at the configuration parameters that you need to configure an MPLS VPN PE-CE routing exchange.

ObjectivesUpon completing this lesson, you will be able to describe how to configure small-scale routing protocols between PE and CE routers. This ability includes being able to meet these objectives:

Identify the requirements for configuring PE-CE routing protocols

Select the VRF routing context for BGP on the PE router

Configure per-VRF static routes

Configure a RIP PE-CE routing session

Configure an EIGRP PE-CE routing session

Page 363: Implementing cisco mpls

5-48 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Configuring PE-CE Routing Protocols This topic identifies the requirements for configuring PE-CE routing protocols.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-3

PE-CE Routing Protocols

• PE-CE routing protocols are configured for individual VRFs.

• Per-VRF routing protocols can be configured in two ways:

– Per-VRF parameters are specified in routing contexts, which are selected with the address-family command.

– A separate OSPF process has to be started for each VRF.

• Prior to Cisco IOS Release 12.3(4)T, the overall number of routing processes per router was limited to 32, of which only 28 were available for VRF assignment.

After you configure virtual routing and forwarding instances (VRFs) and establish Multiprotocol Internal Border Gateway Protocol (MP-IBGP) connectivity between PE routers, you have to configure routing protocols between the PE router and the attached CE routers. The PE-CE routing protocols need to be configured for individual VRFs. Sites in the same VPN but in different VRFs cannot share the same PE-CE routing protocol.

Note The per-VRF configuration of the PEvirtual-CE routing protocols is another good reason for

grouping as many sites into a VRF as possible.

The per-VRF routing protocols can be configured in these two ways:

Per-VRF routing protocols can be configured as individual address families belonging to the same routing process (similar to what you have already seen for Border Gateway Protocol [BGP]).

Per-VRF routing protocols can be configured as separate routing processes. This option is used for more complex routing protocols that need to maintain a separate topology database for each VRF (for example, Open Shortest Path First [OSPF]).

Note Prior to Cisco IOS Release 12.3(4)T, Cisco IOS software implementation limits the overall

number of routing protocols in a router to 32. Two routing methods are predefined (static

and connected), and two routing protocols are needed for proper MPLS VPN backbone

operation—BGP and backbone Interior Gateway Protocol (IGP). The number of PE-CE

routing processes was therefore limited to 28.

This restriction was removed for MPLS in Cisco IOS Release 12.3(4)T.

Page 364: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-49

Selecting the VRF Routing Context for BGP This topic describes how to select the VRF routing context for BGP.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-4

®±«¬»® ľą° ż­ó˛«łľ»®

żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ş®şó˛żł»

ňňň ұ˛óŢŮĐ ®»Ľ·­¬®·ľ«¬·±˛ ňňň

᫬»®ř˝±˛ş·ą÷ý

• Select the per-VRF BGP context with the command.

• Configure CE External Border Gateway Protocol neighbors in VRF context, not in global BGPconfiguration.

• All non-BGP per-VRF routes have to be redistributed into a per-VRF BGP context to be propagated by MP-BGP to other PE routers.

Configuring the VRF Routing Context Within BGP

Select the VRF routing context with the address-family ipv4 vrf vrf-name command in the RIP and BGP routing processes. All per-VRF routing protocol parameters (network numbers, passive interfaces, neighbors, filters, and so on) are configured under this address family.

Note Common parameters defined in router configuration mode are inherited by all address

families defined for this routing process and can be overridden for each individual address

family.

Page 365: Implementing cisco mpls

5-50 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

address-family ipv4 To enter address family configuration mode for configuring routing sessions, such as BGP, that use standard IP version 4 (IPv4) address prefixes, use the address-family ipv4 command in router configuration mode. To disable address family configuration mode, use the no form of this command.

address-family ipv4 [multicast | unicast | vrf vrf-name]

no address-family ipv4 [multicast | unicast | vrf vrf-name]

This table describes the address-family ipv4 command.

Syntax Description

Parameter Description

ł«´¬·˝ż­¬ (Optional) Specifies IPv4 multicast address prefixes

«˛·˝ż­¬ (Optional) Specifies IPv4 unicast address prefixes

Ş®ş Ş®şó˛żł» (Optional) Specifies the name of the VRF instance to associate with subsequent IPv4 address family configuration mode commands

Defaults

IPv4 address prefixes are not enabled. Unicast address prefixes are the default when IPv4 address prefixes are configured.

Command ModesThis command is used in router configuration mode.

Page 366: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-51

Configuring Per-VRF Static Routes This topic describes how to configure per-VRF static routes.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-5

·° ®±«¬» Ş®ş Ý«­¬±ł»®ÁßŢÝ ďđňđňđňđ îëëňđňđňđ ­»®·ż´đńđ ďđňîëđňđňî

˙

®±«¬»® ľą° ęëďéí

żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬±ł»®ÁßŢÝ

®»Ľ·­¬®·ľ«¬» ­¬ż¬·˝

Configuring Per-VRF Static Routes

·° ®±«¬» Ş®ş Ş®şó˛żł» °®»ş·¨ łż­µ Ĺ·˛¬»®şż˝» ·˛¬»®şż˝»ó

˛«łľ»®Ă Ų»¨¬ó¸±°óżĽĽ®»­­Ă

᫬»®ř˝±˛ş·ą÷ý

• This command configures per-VRF static routes.

• The route is entered in the VRF table.

• You must specify a next-hop IP address if you are not using a point-to-point interface.

Sample router configuration:

ip route vrf To establish static routes for a VRF, use the ip route vrf command in global configuration mode. To disable static routes, use the no form of this command.

ip route vrf vrf-name prefix mask [interface {interface-number}] [next-hop-address][global] [distance] [permanent] [tag tag]

no ip route vrf vrf-name prefix mask [interface {interface-number}] [next-hop-address][global] [distance] [permanent] [tag tag]

Note You must specify a next-hop IP address if you are not using a point-to-point interface.

Page 367: Implementing cisco mpls

5-52 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

This table describes the ip route vrf command.

Syntax Description

Parameter Description

Ş®şó˛żł» Name of the VRF for the static route

°®»ş·¨ IP route prefix for the destination, in dotted decimal notation

łż­µ Prefix mask for the destination, in dotted decimal notation

˛»¨¬ó¸±°óżĽĽ®»­­ (Optional) IP address of the next hop (the forwarding router that can be used to reach that network)

·˛¬»®şż˝» (Optional) Type of network interface to use: ATM, Ethernet, loopback, Packet over SONET (POS), or null

·˛¬»®şż˝»ó˛«łľ»® (Optional) Number identifying the network interface to use

ą´±ľż´ (Optional) Specifies that the given next-hop address be in the non-VRF routing table

Ľ·­¬ż˛˝» (Optional) An administrative distance for this route

°»®łż˛»˛¬ (Optional) Specifies that this route will not be removed, even if the interface shuts down

¬żą ¬żą (Optional) Label (tag) value that can be used for controlling redistribution of routes through route maps

Page 368: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-53

Configuring RIP PE-CE Routing This topic describes how to configure a RIP PE-CE routing session.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-6

Configuring RIP PE-CE Routing

• A routing context is configured for each VRF running RIP.

• RIP parameters have to be specified in the VRF.

• Some parameters configured in the RIP process are propagated to routing contexts (for example, RIP version).

• Only RIPv2 is supported.

Configuring RIP as the PE-CE routing protocol is even easier than configuring BGP. Start the configuration of the individual routing context with the address-family ipv4 vrf vrf-namecommand in router configuration mode. You can enter all standard RIP parameters in the per-VRF routing context. Global RIP parameters entered in the scope of RIP router configuration are inherited by each routing context and can be overwritten if needed in each routing context.

Note Only RIP version 2 (RIPv2) not RIP version 1 (RIPv1) is supported as the PE-CE routing

protocol. It is good configuration practice to configure the RIP version as a global RIP

parameter using the version 2 command in router configuration mode.

Page 369: Implementing cisco mpls

5-54 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-7

®±«¬»® ®·°

Ş»®­·±˛ î

żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ş®şó˛żł»

®»Ľ·­¬®·ľ«¬» ľą° ż­ó˛«łľ»® ł»¬®·˝ ¬®ż˛­°ż®»˛¬

᫬»®ř˝±˛ş·ą÷ý

Configuring RIP PE-CE Routing:RIP Metric Propagation

• BGP routes must be redistributed back into RIP.

• The RIP hop count has to be manually set for routes redistributed into RIP.

• For end-to-end RIP networks, the following applies:

– On the sending end, the RIP hop count is copied into the BGP MED.

– On the receiving end, the metric transparent option copies the BGP MED into the RIP hop count, resulting in a consistent end-to-end RIP hop count.

• When you are using RIP with other protocols, the metric must be manually set.

The IGP metric is always copied into the multi-exit discriminator (MED) attribute of the BGP route when an IGP route is redistributed into BGP. Within standard BGP implementation, the MED attribute is used only as a route selection criterion. The MED attribute is not copied back into the IGP metric. The IGP metric has to be specified in the redistribute command or by using the default-metric command in router configuration mode.

The MPLS VPN extension to the redistribute command (metric transparent option) allows the MED attribute to be inserted as the IGP metric of a route redistributed from BGP back into RIP. This extension gives transparent end-to-end (from the customer perspective) RIP routing, as described here:

By default, the RIP hop count is inserted into the BGP attribute MED when the RIP route is redistributed into BGP by the ingress PE router.

You can configure the value of the MED attribute (the original RIP hop count) to be copied into the RIP hop count when the BGP route is redistributed back into RIP. This action causes the whole MPLS VPN backbone to appear as a single hop to the CE routers.

Note You should not change the MED value within BGP if you use the redistribute metric

transparent command.

Page 370: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-55

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-8

Configuring RIP PE-CE Routing:Example

The RIP configuration in this sample network (and described here) is very easy:

The RIP routing process is configured. The RIP version is configured as the global RIP parameter.

The RIP routing context is configured for every VRF where you want to run RIP as the PE-CE routing protocol. The directly connected networks (configured on interfaces in the VRF) over which you want to run RIP are specified to have standard RIP configuration.

Redistribution from BGP into RIP with metric propagation is configured.

The BGP routing context is configured for every VRF. Redistribution of RIP routes into BGP has to be configured for every VRF for which you have configured the RIP routing context.

Page 371: Implementing cisco mpls

5-56 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Configuring EIGRP PE-CE Routing This topic describes how to configure an EIGRP PE-CE routing session.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-9

• Provides EIGRP with the capability to redistribute routes through a VPN cloud

• Requires configuration of only the PE routers

• Imposes no upgrade or configuration changes to customer equipment

• Supports SOO capabilities to filter VPN traffic

Configuring EIGRP PE-CE Routing

MPLS VPN support for EIGRP between PE and CE provides EIGRP with the capability to redistribute routes through a BGP VPN cloud. This feature is configured only on PE routers, requiring no upgrade or configuration changes to customer equipment. This feature also introduces EIGRP support for MPLS and BGP extended community attributes such as Site of Origin (SOO).

Page 372: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-57

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-10

®±«¬»® »·ą®° °®±˝»­­ó·Ľ

żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ş®şó˛żł»

ż«¬±˛±ł±«­ó­§­¬»ł ż­ó˛«łľ»®

®»Ľ·­¬®·ľ«¬» ľą° ż­ó˛«łľ»® ł»¬®·˝ ł»¬®·˝óŞż´«»

᫬»®ř˝±˛ş·ą)#

Configuring EIGRP PE-CE Routing:EIGRP Metric Propagation

• Enables the EIGRP AS number of the CE under the address family.

• Configures per-instance AS number.

• Configures router redistribution.

• External routes received without the configured metric are not to be advertised to the CE router.

– The metric can be configured in the redistribute statement using the redistribute command or configured with the default-metric command.

The IGP metric is always copied into the MED attribute of the BGP route when an IGP route is redistributed into BGP. Within standard BGP implementation, the MED attribute is used only as a route selection criterion. The MED attribute is not copied back into the IGP metric. The metric must be configured for routes from external EIGRP autonomous systems and non-EIGRP networks before these routes can be redistributed into an EIGRP CE router. The metric can be configured in the redistribute statement using the redistribute (IP) command or configured with the default-metric (EIGRP) command.

Page 373: Implementing cisco mpls

5-58 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-11

Configuring EIGRP PE-CE Routing:Example

The EIGRP configuration in this sample network (and described here) is very easy:

The EIGRP routing process is configured. The EIGRP process is configured as the global EIGRP parameter. Notice that this PE-CE configuration varies from traditional EIGRP configuration by deferring the definition of the autonomous system (AS) number in the routing context.

The EIGRP routing context is configured for every VRF where you want to run EIGRP as the PE-CE routing protocol. The directly connected networks (configured on interfaces in the VRF) over which you want to run EIGRP are specified to have standard EIGRP configuration.

Redistribution from BGP into the customer routing context EIGRP with metric propagation is configured.

The BGP routing context is configured for every VRF. Redistribution of the customer routing context EIGRP routes into BGP has to be configured for every VRF for which you have configured the EIGRP routing context.

Note Use of the no auto-summary command is recommended to prevent undesirable results in

MPLS VPN. Use of the default auto-summary command can result in the same summary

being received from multiple other sites based on network class and, therefore, you would

not be able to determine which site to use for a more specific route.

Page 374: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-59

Configuring SOO for EIGRP PE-CE Loop Prevention This topic describes how to configure EIGRP MPLS VPN PE-CE SOO for an EIGRP PE-CE routing session to prevent routing loops.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-12

Implementing EIGRP SOO for Loop Prevention

In this multihomed scenario, a routing loop exists.

Note SOO is needed only for customer networks with multihomed sites. Loops can never occur in

customer networks that have only stub sites.

Page 375: Implementing cisco mpls

5-60 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-13

• The SOO extended community can be used to prevent loops in dual-homed scenarios.

• All PE routers supporting EIGRP MPLS VPNs must support the SOO extended community.

• A unique SOO value must be configured for each VPN site. This value must be used on the PE-CE interface.

• The SOO attribute is configured through a route-map command.

Implementing EIGRP SOO for Loop Prevention (Cont.)

The EIGRP MPLS VPN PE-CE SOO feature provides SOO support for EIGRP-to-BGP and BGP-to-EIGRP redistribution. The SOO extended community is a BGP extended community attribute that is used to identify routes that have originated from a site so that the readvertisement of that prefix back to the source site can be prevented. The SOO extended community uniquely identifies the site from which a PE router has learned a route. SOO support provides the capability to filter MPLS VPN traffic on a per-EIGRP site basis. SOO filtering is configured at the interface level and is used to manage MPLS VPN traffic and to prevent routing loops from occurring in complex and mixed network topologies, such as EIGRP VPN sites that contain both VPN and backdoor links.

The configuration of the SOO extended community allows MPLS VPN traffic to be filtered on a per-site basis. The SOO extended community is configured in an inbound BGP route map on the PE router, and is applied to the interface with the ip vrf sitemap command. The SOO extended community can be applied to all exit points at the customer site for more specific filtering, but must be configured on all interfaces of PE routers that provide VPN services to CE routers.

Page 376: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-61

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-14

®±«¬»ółż° ˛żł» °»®ł·¬ ­»Ż

­»¬ »¨¬˝±łł«˛·¬§ ­±± »¨¬»˛Ľ»Ľó˝±łł«˛·¬§óŞż´«»

᫬»®ř˝±˛ş·ą÷ý

• Creates a route map that sets the SOO attribute

·° Ş®ş ş±®©ż®Ľ·˛ą Ş®şó˛żł»

·° Ş®ş ­·¬»łż° ®±«¬»ółż°ó˛żł»

·° żĽĽ®»­­ ·°óżĽĽ®»­­ ­«ľ˛»¬ółż­µ

᫬»®ř˝±˛ş·ąó·ş÷ý

• Applies a route map that sets SOO extended community attribute to inbound routing updates received from this interface

Implementing EIGRP SOO for Loop Prevention (Cont.)

set extcommunity To set the extended communities attribute, use the set extcommunity command in route map configuration mode. To delete the entry, use the no form of this command.

set extcommunity {rt extended-community-value [additive] | soo extended-community-value}

no set extcommunity

set extcommunity extcommunity-type community-number [additive]

no set extcommunity extcommunity-type community-number [additive]

Page 377: Implementing cisco mpls

5-62 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

This table describes the parameters for the set extcommunity command.

Syntax Description

Parameter Description

®¬ Specifies the route target (RT) extended community attribute

­±± Specifies the SOO extended community attribute

»¨¬»˛Ľ»Ľó˝±łł«˛·¬§óŞż´«»

Specifies the value to be set

The value can be one of these combinations:

autonomous-system-number:network-number

ip-address:network-number

The colon is used to separate the AS number from the network number or the IP address from the network number.

żĽĽ·¬·Ş» (Optional) Adds space after the closing parenthesis; adds the extended community to the already existing extended communities

Defaults

No BGP extended community attributes are set by the route map.

ip vrf sitemap To set the SOO extended community attribute, use the ip vrf sitemap command in interface configuration mode. To delete the entry, use the no form of this command.

ip vrf sitemap route-map-name

no ip vrf sitemap route-map-name

This table describes the parameters for the ip vrf sitemap command.

Syntax Description

Parameter Description

®±«¬»ółż°ó˛żł» Sets the name of the route map to be used

Defaults

No route map is used to set the SOO extended community attribute.

Page 378: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-63

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-15

Implementing EIGRP SOO for Loop Prevention (Cont.)

In this example, a route map SOO_Support with a specific SOO value of 101:2 was defined. The newly defined route map is then applied to vrf Customer-EIGRP-A1 that connects the EIGRP neighbor (CE-EIGRP-A2 router) to the PE-Site-Y router.

Page 379: Implementing cisco mpls

5-64 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-16

Summary

• The per-VRF routing protocols can be configured in two ways: as individual address families belonging to the same routing process or as separate routing processes.

• Use the address-family ipv4 vrf vrf-name command to select the VRF routing context.

• Use the ip route vrf command to establish static routes.

• Use the address-family ipv4 vrf vrf-name command to start the configuration of individual routing context.

• Use the redistribute command to configure the metric that is copied into the MED attribute of the BGP route.

• Use the SOO extended community to prevent loops in EIGRP dual-homed scenarios.

Page 380: Implementing cisco mpls

Lesson 5

Monitoring MPLS VPN Operations

OverviewThis lesson presents the commands, syntax, and descriptions for monitoring virtual routing and forwarding (VRF) routing, Multiprotocol Border Gateway Protocol (MP-BGP) sessions, and Virtual Private Network (VPN) status.

It is important to understand the network that you configure and ensure that it is operating optimally. This lesson will explain how to monitor a Multiprotocol Label Switching (MPLS) VPN network to ensure that the network is functioning smoothly.

ObjectivesUpon completing this lesson, you will be able to describe how to monitor MPLS VPN operations. This ability includes being able to meet these objectives:

Monitor VRF information

Monitor VRF routing

Monitor MP-BGP sessions

Monitor an MP-BGP VPNv4 table

Monitor per-VRF CEF and LFIB structures

Monitor labels associated with VPNv4 routes

Identify the command syntax that is used with other MPLS VPN monitoring commands

Page 381: Implementing cisco mpls

5-66 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Monitoring VRFs This topic describes how to monitor VRF information.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-3

­¸±© ·° Ş®ş

᫬»®ý

• Displays the list of all VRFs configured in the router

­¸±© ·° Ş®ş Ľ»¬ż·´

᫬»®ý

• Displays detailed VRF configuration

­¸±© ·° Ş®ş ·˛¬»®şż˝»­

᫬»®ý

• Displays interfaces associated with VRFs

Monitoring VRFs

show ip vrf To display the set of defined VRFs and associated interfaces, use the show ip vrf command in EXEC mode: show ip vrf [{brief | detail | interfaces}] [vrf-name] [output-modifiers].

This table describes the parameters for the show ip vrf command.

Syntax Description

Parameter Description

ľ®·»ş (Optional) Displays concise information on the VRF (or VRFs) and associated interfaces

Ľ»¬ż·´ (Optional) Displays detailed information on the VRF (or VRFs) and associated interfaces

·˛¬»®şż˝»­ (Optional) Displays detailed information about all interfaces bound to a particular VRF or to any VRF

Ş®şó˛żł» (Optional) Displays the name assigned to a VRF

±«¬°«¬ół±Ľ·ş·»®­ (Optional) For a list of associated keywords and arguments, use context-sensitive help

Defaults When no optional parameters are specified, the command shows concise information about all configured VRFs.

Page 382: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-67

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-4

Monitoring VRFs:show ip vrf

᫬»®ý­¸±© ·° Ş®şŇżł» Ü»şż«´¬ ÎÜ ×˛¬»®şż˝»­Í·¬»ßî ďđíćíđ Í»®·ż´ďńđňîđÍ·¬»Ţ ďđíćďď Í»®·ż´ďńđňďđđÍ·¬»Č ďđíćîđ ۬¸»®˛»¬đńđ᫬»®ý

The show ip vrf command displays concise information about the VRF (or VRFs) and associated interfaces. This table describes the fields displayed by this command.

Field Description

Fields Description

Name Specifies the VRF name

Default RD Specifies the default route distinguisher (RD)

Interfaces Specifies the network interfaces

Page 383: Implementing cisco mpls

5-68 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-5

Monitoring VRFs: show ip vrf detail

᫬»®ý­¸±© ·° Ş®ş Ľ»¬ż·´ĘÎÚ Í·¬»ßîĺ Ľ»şż«´¬ ÎÜ ďđíćíđ

ײ¬»®şż˝»­ćÍ»®·ż´ďńđňîđ

ݱ˛˛»˝¬»Ľ żĽĽ®»­­»­ ż®» ˛±¬ ·˛ ą´±ľż´ ®±«¬·˛ą ¬żľ´»Ň± ۨ°±®¬ ĘĐŇ ®±«¬»ó¬ż®ą»¬ ˝±łł«˛·¬·»­×ł°±®¬ ĘĐŇ ®±«¬»ó¬ż®ą»¬ ˝±łł«˛·¬·»­

ÎĚćďđíćďđұ ·ł°±®¬ ®±«¬»ółż°Ű¨°±®¬ ®±«¬»ółż°ć ßî

ĘÎÚ Í·¬»Ţĺ Ľ»şż«´¬ ÎÜ ďđíćďďײ¬»®şż˝»­ć

Í»®·ż´ďńđňďđđݱ˛˛»˝¬»Ľ żĽĽ®»­­»­ ż®» ˛±¬ ·˛ ą´±ľż´ ®±«¬·˛ą ¬żľ´»Ű¨°±®¬ ĘĐŇ ®±«¬»ó¬ż®ą»¬ ˝±łł«˛·¬·»­

ÎĚćďđíćďď׳°±®¬ ĘĐŇ ®±«¬»ó¬ż®ą»¬ ˝±łł«˛·¬·»­

ÎĚćďđíćďď ÎĚćďđíćîđұ ·ł°±®¬ ®±«¬»ółż°Ň± »¨°±®¬ ®±«¬»ółż°

To display detailed information on the VRFs and associated interfaces, use the show ip vrf detail command. This table describes the additional fields shown by this command.

Additional Field Description

Field Description

Interfaces Specifies the network interfaces

Export Specifies VPN route target (RT) export communities

Import Specifies VPN RT import communities

Page 384: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-69

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-6

Monitoring VRFs: show ip vrf interfaces

᫬»®ý­¸±© ·° Ş®ş ·˛¬»®şż˝»­×˛¬»®şż˝» ×Đó߼Ľ®»­­ ĘÎÚ Đ®±¬±˝±´Í»®·ż´ďńđňîđ ďëđňďňíďňíé Í·¬»ßî «°Í»®·ż´ďńđňďđđ ďëđňďňíîňíí Í·¬»Ţ «°Ű¬¸»®˛»¬đńđ ďçîňďęčňîîňí Í·¬»Č «°

To display the interfaces bound to a particular VRF (or interfaces bound to any VRF), use the show ip vrf interfaces command, which displays the fields described in this table.

show ip vrf interfaces Field Description

Field Description

Interface Specifies the network interfaces for a VRF

IP-Address Specifies the IP address of a VRF interface

VRF Specifies the VRF name

Protocol Displays the state of the protocol (up or down) for each VRF interface

Page 385: Implementing cisco mpls

5-70 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Monitoring VRF Routing This topic describes how to monitor VRF routing.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-7

­¸±© ·° °®±¬±˝±´­ Ş®ş Ş®şó˛żł»

᫬»®ý

• Displays the routing protocols configured in a VRF

­¸±© ·° ®±«¬» Ş®ş Ş®şó˛żł»

᫬»®ý

• Displays the VRF routing table

­¸±© ·° ľą° Ş°˛Şě Ş®ş Ş®şó˛żł»

᫬»®ý

• Displays per-VRF BGP parameters

Monitoring VRF Routing

These three commands can be used to monitor VRF routing:

The show ip protocols vrf command displays the summary information about routing protocols running in a VRF.

The show ip route vrf command displays the VRF routing table.

The show ip bgp vpnv4 vrf command displays the VRF Border Gateway Protocol (BGP) table.

show ip protocols vrf To display the routing protocol information associated with a VRF, use the show ip protocols vrf command in EXEC mode: show ip protocols vrf vrf-name.

This table describes the parameters for the show ip protocols vrf command.

Syntax Description

Parameter Description

Ş®şó˛żł» Specifies the name assigned to the VRF

Page 386: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-71

show ip route vrf To display the IP routing table associated with a VRF, use the show ip route vrf command in EXEC mode: show ip route vrf vrf-name [connected] [protocol [as-number] [tag] [output-modifiers]] [list number [output-modifiers]] [profile] [static [output-modifiers]] [summary[output-modifiers]] [supernets-only [output-modifiers]] [traffic-engineering [output-modifiers]].

This table describes the parameters for the show ip route vrf command.

Syntax Description

Parameter Description

Ş®şó˛żł» Specifies the name assigned to the VRF

˝±˛˛»˝¬»Ľ (Optional) Displays all connected routes in a VRF

°®±¬±˝±´ (Optional) To specify a routing protocol, use one of these keywords: bgp, egp, eigrp, hello, igrp, isis, ospf, or rip

ż­ó˛«łľ»® (Optional) Specifies the autonomous system (AS) number

¬żą (Optional) Specifies Cisco IOS software routing area label

±«¬°«¬ół±Ľ·ş·»®­ (Optional) For a list of associated keywords and arguments, use context-sensitive help

´·­¬ ˛«łľ»® (Optional) Specifies the IP access list to display

°®±ş·´» (Optional) Displays the IP routing table profile

­¬ż¬·˝ (Optional) Displays static routes

­«łłż®§ (Optional) Displays a summary of routes

­«°»®˛»¬­ó±˛´§ (Optional) Displays supernet entries only

¬®żşş·˝ó»˛ą·˛»»®·˛ą (Optional) Displays only traffic-engineered routes

Page 387: Implementing cisco mpls

5-72 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

show ip bgp vpnv4 To display VPN address information from the BGP table, use the show ip bgp vpnv4 command in EXEC mode: show ip bgp vpnv4 {all | rd route-distinguisher | vrf vrf-name} [ip-prefix/length [longer-prefixes] [output-modifiers]] [network-address [mask] [longer-prefixes][output-modifiers]] [cidr-only] [community] [community-list] [dampened-paths] [filter-list][flap-statistics] [inconsistent-as] [neighbors] [paths [line]] [peer-group] [quote-regexp][regexp] [summary] [labels].

This table describes the parameters for the show ip bgp vpnv4 command.

Syntax Description

Parameter Description

ż´´ Displays the complete VPN version 4 (VPNv4) database

®Ľ ®±«¬»óĽ·­¬·˛ą«·­¸»® Displays Network Layer Reachability Information (NLRI) prefixes that have a matching RD

Ş®ş Ş®şó˛żł» Displays NLRI prefixes associated with the named VRF

·°ó°®»ş·¨ń´»˛ą¬¸ (Optional) Displays the IP prefix address (in dotted decimal notation) and length of mask (0 to 32)

´±˛ą»®ó°®»ş·¨»­ (Optional) Displays the entry, if any, that exactly matches the specified prefix parameter, and all entries that match the prefix in a “longest-match” sense—that is, prefixes for which the specified prefix is an initial substring

±«¬°«¬ół±Ľ·ş·»®­ (Optional) For a list of associated keywords and arguments, use context-sensitive help

˛»¬©±®µóżĽĽ®»­­ (Optional) Displays the IP address of a network in the BGP routing table

łż­µ (Optional) Displays the mask of the network address, in dotted decimal notation

˝·Ľ®ó±˛´§ (Optional) Displays only routes that have non-natural net masks

˝±łł«˛·¬§ (Optional) Displays routes matching this community

˝±łł«˛·¬§ó´·­¬ (Optional) Displays routes matching this community list

Ľżł°»˛»Ľó°ż¬¸­ (Optional) Displays paths suppressed on account of dampening (BGP route from peer is up and down)

ş·´¬»®ó´·­¬ (Optional) Displays routes conforming to the filter list

ş´ż°ó­¬ż¬·­¬·˝­ (Optional) Displays flap statistics of routes

·˛˝±˛­·­¬»˛¬óż­ (Optional) Displays only routes that have inconsistent autonomous systems of origin

˛»·ą¸ľ±®­ (Optional) Displays details about TCP and BGP neighbor connections

°ż¬¸­ (Optional) Displays path information

´·˛» (Optional) Displays a regular expression to match the BGP AS paths

°»»®óą®±«° (Optional) Displays information about peer groups

Ż«±¬»ó®»ą»¨° (Optional) Displays routes matching the AS path “regular expression”

Page 388: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-73

Parameter Description

®»ą»¨° (Optional) Displays routes matching the AS path “regular expression”

­«łłż®§ (Optional) Displays BGP neighbor status

¬żą­ (Optional) Displays incoming and outgoing BGP labels for each NLRI

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-8

Monitoring VRF Routing: show ip protocols vrf

᫬»®ý­¸±© ·° °®±¬±˝±´ Ş®ş Í·¬»Č᫬·˛ą Đ®±¬±˝±´ ·­ ţ®·°ţ

Í»˛Ľ·˛ą «°Ľż¬»­ »Ş»®§ íđ ­»˝±˛Ľ­ô ˛»¨¬ Ľ«» ·˛ ďđ ­»˝±˛Ľ­×˛Şż´·Ľ żş¬»® ďčđ ­»˝±˛Ľ­ô ¸±´Ľ Ľ±©˛ ďčđô ş´«­¸»Ľ żş¬»® îěđŃ«¬ą±·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­×˛˝±ł·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­Î»Ľ·­¬®·ľ«¬·˛ąć ®·°ô ľą° ęëđíďÜ»şż«´¬ Ş»®­·±˛ ˝±˛¬®±´ć ­»˛Ľ Ş»®­·±˛ îô ®»˝»·Ş» Ş»®­·±˛ îײ¬»®şż˝» Í»˛Ľ λ˝Ş Ě®·ąą»®»Ľ Î×Đ Ő»§ó˝¸ż·˛Ű¬¸»®˛»¬đńđ î î

᫬·˛ą ş±® Ň»¬©±®µ­ćďçîňďęčňîîňđ

᫬·˛ą ײş±®łż¬·±˛ ͱ«®˝»­ćŮż¬»©ż§ Ü·­¬ż˛˝» Ôż­¬ Ë°Ľż¬»

Ü·­¬ż˛˝»ć řĽ»şż«´¬ ·­ ďîđ÷

The show ip protocols vrf command displays summary information about all routing protocol instances active in the specified VRF. The fields displayed by this command are shown in this table.

Field Description

Field Description

Gateway Displays the IP address of the router ID for all routers in the network

Distance Displays the metric used to access the destination route

Last Update Displays the last time that the routing table was updated from the source

Page 389: Implementing cisco mpls

5-74 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-9

᫬»®ý­¸±© ·° ®±«¬» Ş®ş Í·¬»ßîݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô × ó ×ŮÎĐô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»żŇď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» îŰď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» îô Ű ó ŰŮĐ· ó ×Íó×Íô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óîô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»ô ± ó ŃÜÎĐ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

Ń îđíňďňîđňđńîě ĹďďđńéčîĂ Ş·ż ďëđňďňíďňíčô đîćëîćďíô Í»®·ż´ďńđňîđîđíňďňîňđńíî ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­

Ń îđíňďňîňď ĹďďđńéčîĂ Ş·ż ďëđňďňíďňíčô đîćëîćďíô Í»®·ż´ďńđňîđîđíňďňďňđńíî ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­

Ţ îđíňďňďňď ĹîđđńďĂ Ş·ż ďçîňďęčňíňďđíô đďćďěćíîŢ îđíňďňďíëňđńîě ĹîđđńéčîĂ Ş·ż ďçîňďęčňíňďđďô đîćđëćíčŢ îđíňďňďíěňđńîě ĹîđđńďĂ Ş·ż ďçîňďęčňíňďđďô đîćđëćíčŢ îđíňďňďđňđńîě ĹîđđńďĂ Ş·ż ďçîňďęčňíňďđíô đďćďěćíî› ®»­¬ Ľ»´»¬»Ľ ›

Monitoring VRF Routing:show ip route vrf

The show ip route vrf command displays the contents of the VRF IP routing table in the same format used by the show ip route command.

Page 390: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-75

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-10

Monitoring VRF Routing:show ip bgp vpnv4 vrf neighbors

᫬»®ý­¸±© ·° ľą° Ş°˛Şě Ş®ş Í·¬»Ţ ˛»·ą¸ľ±®­ŢŮĐ ˛»·ą¸ľ±® ·­ ďëđňďňíîňíěô Ş®ş Í·¬»Ţô ®»ł±¬» ßÍ ęëđíîô »¨¬»®˛ż´ ´·˛µ

ŢŮĐ Ş»®­·±˛ ěô ®»ł±¬» ®±«¬»® ×Ü îđíňîňďđňďŢŮĐ ­¬ż¬» ă Ű­¬żľ´·­¸»Ľô «° ş±® đîćđďćěďÔż­¬ ®»żĽ đđćđđćëęô ¸±´Ľ ¬·ł» ·­ ďčđô µ»»°ż´·Ş» ·˛¬»®Şż´ ·­ ęđ ­»˝±˛Ľ­Ň»·ą¸ľ±® ˝ż°żľ·´·¬·»­ć᫬» ®»ş®»­¸ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»ĽßĽĽ®»­­ şżł·´§ ×ĐŞě ˲·˝ż­¬ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľ

λ˝»·Ş»Ľ ëěç ł»­­żą»­ô 𠲱¬·ş·˝ż¬·±˛­ô đ ·˛ Ż«»«»Í»˛¬ ęěę ł»­­żą»­ô 𠲱¬·ş·˝ż¬·±˛­ô đ ·˛ Ż«»«»Î±«¬» ®»ş®»­¸ ®»Ż«»­¬ć ®»˝»·Ş»Ľ đô ­»˛¬ đÓ·˛·ł«ł ¬·ł» ľ»¬©»»˛ żĽŞ»®¬·­»ł»˛¬ ®«˛­ ·­ íđ ­»˝±˛Ľ­

Ú±® żĽĽ®»­­ şżł·´§ć ĘĐŇŞě ˲·˝ż­¬Ě®ż˛­´ż¬»­ żĽĽ®»­­ şżł·´§ ×ĐŞě ˲·˝ż­¬ ş±® ĘÎÚ Í·¬»ŢŢŮĐ ¬żľ´» Ş»®­·±˛ ěďęô ˛»·ą¸ľ±® Ş»®­·±˛ ěďęײĽ»¨ ěô Ńşş­»¬ đô Óż­µ đ¨ďđݱłł«˛·¬§ ż¬¬®·ľ«¬» ­»˛¬ ¬± ¬¸·­ ˛»·ą¸ľ±®î ż˝˝»°¬»Ľ °®»ş·¨»­ ˝±˛­«ł» ďî𠾧¬»­Đ®»ş·¨ żĽŞ»®¬·­»Ľ ďđéô ­«°°®»­­»Ľ đô ©·¬¸Ľ®ż©˛ ęí

› ®»­¬ Ľ»´»¬»Ľ ›

show ip bgp vpnv4 vrf neighbors To display BGP neighbors configured in a VRF, use the show ip bgp vpnv4 vrf neighborscommand in privileged EXEC mode: show ip bgp vpnv4 {all | vrf vrf-name} neighbors.

This table describes the parameters for the show ip bgp vpnv4 vrf neighbors command.

Syntax Description

Parameter Description

Ş°˛Şě Specifies VPNv4 information

ż´´ Displays the complete VPNv4 database

Ş®ş Ş®şó˛żł» Displays neighbors associated with the named VRF

˛»·ą¸ľ±®­ Displays details about TCP and BGP neighbor connections

Defaults This command has no default values.

Usage Guidelines

Use this command to display detailed information about BGP neighbors associated with the MPLS VPN architecture.

Page 391: Implementing cisco mpls

5-76 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Monitoring MP-BGP Sessions This topic describes how to monitor MP-BGP sessions

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-11

­¸±© ·° ľą° ˛»·ą¸ľ±®­

᫬»®ý

• This command displays global BGP neighbors and the protocols negotiated with these neighbors.

Monitoring MP-BGP Sessions

The show ip bgp neighbors command is described in detail in Cisco IOS documentation. This command is used to monitor BGP sessions with other PE routers and the address families negotiated with these neighbors.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-12

Monitoring MP-BGP Sessions:show ip bgp neighbors

᫬»®ý­¸±© ·° ľą° ˛»·ą¸ľ±® ďçîňďęčňíňďđďŢŮĐ ˛»·ą¸ľ±® ·­ ďçîňďęčňíňďđďô ®»ł±¬» ßÍ íô ·˛¬»®˛ż´ ´·˛µŢŮĐ Ş»®­·±˛ ěô ®»ł±¬» ®±«¬»® ×Ü ďçîňďęčňíňďđďŢŮĐ ­¬ż¬» ă Ű­¬żľ´·­¸»Ľô «° ş±® đîćďëćííÔż­¬ ®»żĽ đđćđđćííô ¸±´Ľ ¬·ł» ·­ ďčđô µ»»°ż´·Ş» ·˛¬»®Şż´ ·­ ęđ ­»˝±˛Ľ­Ň»·ą¸ľ±® ˝ż°żľ·´·¬·»­ć᫬» ®»ş®»­¸ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»ĽßĽĽ®»­­ şżł·´§ ×ĐŞě ˲·˝ż­¬ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»ĽßĽĽ®»­­ şżł·´§ ĘĐŇŞě ˲·˝ż­¬ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľ

λ˝»·Ş»Ľ ďěďé ł»­­żą»­ô 𠲱¬·ş·˝ż¬·±˛­ô đ ·˛ Ż«»«»Í»˛¬ ďéîç ł»­­żą»­ô î ˛±¬·ş·˝ż¬·±˛­ô đ ·˛ Ż«»«»Î±«¬» ®»ş®»­¸ ®»Ż«»­¬ć ®»˝»·Ş»Ľ çô ­»˛¬ îçÓ·˛·ł«ł ¬·ł» ľ»¬©»»˛ żĽŞ»®¬·­»ł»˛¬ ®«˛­ ·­ ë ­»˝±˛Ľ­

Ú±® żĽĽ®»­­ şżł·´§ć ×ĐŞě ˲·˝ż­¬ŢŮĐ ¬żľ´» Ş»®­·±˛ ďččô ˛»·ą¸ľ±® Ş»®­·±˛ ďččײĽ»¨ îô Ńşş­»¬ đô Óż­µ đ¨ěď ż˝˝»°¬»Ľ °®»ş·¨»­ ˝±˛­«ł» íę ľ§¬»­Đ®»ş·¨ żĽŞ»®¬·­»Ľ íîîô ­«°°®»­­»Ľ đô ©·¬¸Ľ®ż©˛ îíđ

ňňň ݱ˛¬·˛«»Ľ

Page 392: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-77

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-13

Monitoring MP-BGP Sessions:show ip bgp neighbors (Cont.)

᫬»®ý­¸±© ·° ľą° ˛»·ą¸ľ±® ďçîňďęčňíňďđď

ňňň ݱ˛¬·˛«»Ľ

Ú±® żĽĽ®»­­ şżł·´§ć ĘĐŇŞě ˲·˝ż­¬ŢŮĐ ¬żľ´» Ş»®­·±˛ ěďęô ˛»·ą¸ľ±® Ş»®­·±˛ ěďęײĽ»¨ îô Ńşş­»¬ đô Óż­µ đ¨ěŇŰČĚÁŘŃĐ ·­ ż´©ż§­ ¬¸·­ ®±«¬»®Ý±łł«˛·¬§ ż¬¬®·ľ«¬» ­»˛¬ ¬± ¬¸·­ ˛»·ą¸ľ±®ę ż˝˝»°¬»Ľ °®»ş·¨»­ ˝±˛­«ł» íę𠾧¬»­Đ®»ş·¨ żĽŞ»®¬·­»Ľ ěíďô ­«°°®»­­»Ľ đô ©·¬¸Ľ®ż©˛ ďďí

ݱ˛˛»˝¬·±˛­ »­¬żľ´·­¸»Ľ éĺ Ľ®±°°»Ľ ęÔż­¬ ®»­»¬ đîćďčćííô Ľ«» ¬± Đ»»® ˝´±­»Ľ ¬¸» ­»­­·±˛

ňňň λ­¬ Ľ»´»¬»Ľ

show ip bgp neighbors To display information about the TCP and BGP connections to neighbors, use the show ip bgp neighbors command in EXEC mode: show ip bgp neighbors [neighbor-address] [received-routes | routes | advertised-routes | {paths regexp} | dampened-routes].

This table describes the parameters for the show ip bgp neighbors command.

Syntax Description

Parameter Description

˛»·ą¸ľ±®óżĽĽ®»­­ (Optional) Displays the address of the neighbor whose routes you have learned from

If you omit this argument, all neighbors will be displayed.

®»˝»·Ş»Ľó®±«¬»­ (Optional) Displays all received routes (both accepted and rejected) from the specified neighbor

®±«¬»­ (Optional) Displays all routes that are received and accepted

This parameter is a subset of the output from the received-routes keyword.

żĽŞ»®¬·­»Ľó®±«¬»­ (Optional) Displays all the routes that the router has advertised to the neighbor

°ż¬¸­ ®»ą»¨° (Optional) Matches the paths received

Ľżł°»˛»Ľó®±«¬»­ (Optional) Displays the dampened routes to the neighbor at the IP address specified

Page 393: Implementing cisco mpls

5-78 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: Sample Output from show ip bgp neighbors Command

This table describes the fields shown in the sample output.

Field Descriptions

Field Description

BGP neighbor IP address of the BGP neighbor and its AS number

If the neighbor is in the same AS as the router, the link between them is internal; otherwise, the link is considered external.

remote AS AS of the neighbor

external link

internal link

Indicates that this peer is either an External Border Gateway Protocol (EBGP) peer or an IBGP peer

BGP version BGP version being used to communicate with the remote router

The router ID (an IP address) of the neighbor is also specified.

remote router ID IP address of the neighbor

BGP state Internal state of this BGP connection

up for Amount of time, in seconds, that the underlying TCP connection has been in existence

Last read Time that BGP last read a message from this neighbor

hold time Maximum amount of time that can elapse between messages from the peer

keepalive interval Time period, in seconds, between sending keepalive packets, which helps ensure that the TCP connection is up

Neighbor capabilities BGP capabilities advertised and received from this neighbor

Note: A state of “advertised and received” indicates an active neighbor relationship.

Here is sample output from the show ip bgp neighbors command:

᫬»®ý ­¸ ·° ľą° ˛»· ďçîňďęčňďđđňďîç

ŢŮĐ ˛»·ą¸ľ±® ·­ ďçîňďęčňďđđňďîçô ®»ł±¬» ßÍ ęëđđďô ·˛¬»®˛ż´ ´·˛µ

ŢŮĐ Ş»®­·±˛ ěô ®»ł±¬» ®±«¬»® ×Ü ďçîňďęčňďđđňďîç

ŢŮĐ ­¬ż¬» ă Ű­¬żľ´·­¸»Ľô «° ş±® ëĽđď¸

Ôż­¬ ®»żĽ đđćđđćëęô ¸±´Ľ ¬·ł» ·­ ďčđô µ»»°ż´·Ş» ·˛¬»®Şż´ ·­ ęđ ­»˝±˛Ľ­

Ň»·ą¸ľ±® ˝ż°żľ·´·¬·»­ć

᫬» ®»ş®»­¸ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľř±´Ľ ú ˛»©÷

߼Ľ®»­­ şżł·´§ ×ĐŞě ˲·˝ż­¬ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľ

߼Ľ®»­­ şżł·´§ ĘĐŇŞě ˲·˝ż­¬ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľ

Ú±® żĽĽ®»­­ şżł·´§ć ×ĐŞě ˲·˝ż­¬ ŢŮĐ ¬żľ´» Ş»®­·±˛ íďô ˛»·ą¸ľ±® Ş»®­·±˛ íď

ײĽ»¨ ďô Ńşş­»¬ đô Óż­µ đ¨î Í»˛¬ Î˝ŞĽ Đ®»ş·¨ ż˝¬·Ş·¬§ć óóóó óóóó

Page 394: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-79

Đ®»ş·¨»­ Ý«®®»˛¬ć đ íđ řݱ˛­«ł»­ ďěě𠾧¬»­÷ Đ®»ş·¨»­ ̱¬ż´ć đ íđ ׳°´·˝·¬ É·¬¸Ľ®ż©ć đ đ ۨ°´·˝·¬ É·¬¸Ľ®ż©ć đ đ Ë­»Ľ ż­ ľ»­¬°ż¬¸ć ˛ńż íđ Ë­»Ľ ż­ ł«´¬·°ż¬¸ć ˛ńż đ Ń«¬ľ±«˛Ľ ײľ±«˛Ľ Ô±˝ż´ б´·˝§ Ü»˛·»Ľ Đ®»ş·¨»­ć óóóóóóóó óóóóóóó Ţ»­¬°ż¬¸ ş®±ł ¬¸·­ °»»®ć íđ ˛ńż ̱¬ż´ć íđ đ Ň«łľ»® ±ş ŇÔÎ×­ ·˛ ¬¸» «°Ľż¬» ­»˛¬ć łż¨ đô ł·˛ đ Ú±® żĽĽ®»­­ şżł·´§ć ĘĐŇŞě ˲·˝ż­¬ ŢŮĐ ¬żľ´» Ş»®­·±˛ íđô ˛»·ą¸ľ±® Ş»®­·±˛ íđ ײĽ»¨ ěô Ńşş­»¬ đô Óż­µ đ¨ďđ ŇŰČĚÁŘŃĐ ·­ ż´©ż§­ ¬¸·­ ®±«¬»® ݱłł«˛·¬§ ż¬¬®·ľ«¬» ­»˛¬ ¬± ¬¸·­ ˛»·ą¸ľ±® Í»˛¬ Î˝ŞĽ Đ®»ş·¨ ż˝¬·Ş·¬§ć óóóó óóóó Đ®»ş·¨»­ Ý«®®»˛¬ć ç ď řݱ˛­«ł»­ îëę ľ§¬»­÷ Đ®»ş·¨»­ ̱¬ż´ć ďč ď ׳°´·˝·¬ É·¬¸Ľ®ż©ć ç đ ۨ°´·˝·¬ É·¬¸Ľ®ż©ć đ đ Ë­»Ľ ż­ ľ»­¬°ż¬¸ć ˛ńż ě Ë­»Ľ ż­ ł«´¬·°ż¬¸ć ˛ńż đ Ń«¬ľ±«˛Ľ ײľ±«˛Ľ Ô±˝ż´ б´·˝§ Ü»˛·»Ľ Đ®»ş·¨»­ć óóóóóóóó óóóóóóó ĘĐŇ ×ł°±®¬»Ľ °®»ş·¨ć í ˛ńż Ţ»­¬°ż¬¸ ş®±ł ¬¸·­ °»»®ć ď ˛ńż ̱¬ż´ć ě đ Ň«łľ»® ±ş ŇÔÎ×­ ·˛ ¬¸» «°Ľż¬» ­»˛¬ć łż¨ ěô ł·˛ đ

ř±«¬°«¬ ±ł·¬¬»Ľ÷

This table describes the fields shown in the sample output.

Field Descriptions

Field Description

Address family IPv4 Unicast: IPv4 unicast-specific properties of this neighbor

Address family VPNv4 VPNv4-specific properties of this neighbor

Note For detailed information, please consult the Cisco IOS reference manual.

Page 395: Implementing cisco mpls

5-80 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Monitoring an MP-BGP VPNv4 Table This topic describes how to monitor an MP-BGP VPNv4 table.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-14

­¸±© ·° ľą° Ş°˛Şě ż´´

᫬»®ý

• Displays whole VPNv4 table.

­¸±© ·° ľą° Ş°˛Şě Ş®ş Ş®ş -˛żł»

᫬»®ý

• Displays only BGP parameters (routes or neighbors) associated with specified VRF.

• Any BGP command can be used with these parameters.

­¸±© ·° ľą° Ş°˛Şě ®Ľ ®±«¬»óĽ·­¬·˛ą«·­¸»®

᫬»®ý

• Displays only BGP parameters (routes or neighbors) associated with the specified RD.

Monitoring an MP-BGP VPNv4 Table

The show ip bgp vpnv4 command displays IP version 4 (IPv4) BGP information and VPNv4 BGP information. To display VPNv4 BGP information, use one of these keywords:

all to display the whole contents of the VPNv4 BGP table

vrf vrf-name to display VPNv4 information associated with the specified VRF

rd route-distinguisher to display VPNv4 information associated with the specified RD

Page 396: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-81

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-15

Monitoring an MP-BGP VPNv4 Table:show ip bgp vpnv4 vrf-name

᫬»®ý­¸±© ·° ľą° Ş°˛Şě Ş®ş Í·¬»ßîŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ěďęô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčňíňďđîͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸Î±«¬» Ü·­¬·˛ą«·­¸»®ć ďđíćíđ řĽ»şż«´¬ ş±® Ş®ş Í·¬»ßî÷öâ ďëđňďňíďňíęńíđ đňđňđňđ đ íîéęč áöâ·ďëđňďňíďňďîčńíđ ďçîňďęčňíňďđď đ ďđđ đ áöâ·ďëđňďňíďňďíîńíđ ďçîňďęčňíňďđď đ ďđđ đ áöâ·îđíňďňďňďńíî ďçîňďęčňíňďđí ď ďđđ đ ęëđíď ·öâ îđíňďňîňďńíî ďëđňďňíďňíč éčî íîéęč áöâ·îđíňďňďđňđ ďçîňďęčňíňďđí ď ďđđ đ ęëđíď ·öâ îđíňďňîđňđ ďëđňďňíďňíč éčî íîéęč áöâ·îđíňďňďîéňíńíî ďçîňďęčňíňďđď ď ďđđ đ áöâ·îđíňďňďîéňěńíî ďçîňďęčňíňďđď éčî ďđđ đ áöâ·îđíňďňďíěňđ ďçîňďęčňíňďđď ď ďđđ đ áöâ·îđíňďňďíëňđ ďçîňďęčňíňďđď éčî ďđđ đ á

show ip bgp vpnv4 vrf To display VPNv4 information from the BGP database associated with a VRF, use the show ip bgp vpnv4 vrf command in privileged EXEC mode: show ip bgp vpnv4 vrf vrf-name [ip-prefix/length [longer-prefixes] [output-modifiers]] [network-address [mask] [longer-prefixes][output-modifiers]] [cidr-only] [community][community-list] [dampened-paths] [filter-list][flap-statistics] [inconsistent-as] [neighbors] [paths [line]] [peer-group] [quote-regexp][regexp] [summary] [tags].

This table describes the syntax for the show ip bgp vpnv4 vrf command.

Syntax Description

Parameter Description

Ş®ş Ş®şó˛żł» Displays NLRI prefixes associated with the named VRF

Defaults This command has no default values.

Usage Guidelines Use this command to display VPNv4 information that is associated with a VRF from the BGP database. A similar command—show ip bgp vpnv4 all—displays all available VPNv4 information. The show ip bgp vpnv4 summary command displays BGP neighbor status.

Page 397: Implementing cisco mpls

5-82 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-16

Monitoring an MP-BGP VPNv4 Table:show ip bgp vpnv4 rd route-distinguisher

᫬»®ý­¸±© ·° ľą° Ş°˛Şě ®Ľ ďđíćíđ îđíňďňďîéňíŢŮĐ ®±«¬·˛ą ¬żľ´» »˛¬®§ ş±® ďđíćíđćîđíňďňďîéňíńíîô Ş»®­·±˛ ďęěĐż¬¸­ć řď żŞż·´żľ´»ô ľ»­¬ ýďô ¬żľ´» Í·¬»ßî÷

ұ¬ żĽŞ»®¬·­»Ľ ¬± ż˛§ °»»®Ô±˝ż´ô ·ł°±®¬»Ľ °ż¬¸ ş®±ł ďđíćďđćîđíňďňďîéňíńíî

ďçîňďęčňíňďđď řł»¬®·˝ ďđ÷ ş®±ł ďçîňďęčňíňďđď řďçîňďęčňíňďđď÷

Ń®·ą·˛ ·˛˝±ł°´»¬»ô ł»¬®·˝ ďô ´±˝ż´°®»ş ďđđô Şż´·Ľô·˛¬»®˛ż´ô ľ»­¬

ۨ¬»˛Ľ»Ľ ݱłł«˛·¬§ć ÎĚćďđíćďđ

show ip bgp vpnv4 rd route-distinguisherTo display all VPNv4 routes that contain a specified RD, use the show ip bgp vpnv4 rd command in privileged EXEC mode: show ip bgp vpnv4 rd route-distinguisher [ip-prefix/length [longer-prefixes] [output-modifiers]] [network-address [mask] [longer-prefixes][output-modifiers]] [cidr-only] [community][community-list] [dampened-paths] [filter-list][flap-statistics] [inconsistent-as] [paths [line]] [quote-regexp] [regexp] [summary] [tags].

This table describes the syntax for the show ip bgp vpnv4 rd route-distinguisher command.

Syntax Description

Parameter Description

®Ľ ®±«¬»óĽ·­¬·˛ą«·­¸»® Displays NLRI prefixes that have a matching RD

Defaults There is no default. An RD must be configured for a VRF to be functional.

Page 398: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-83

Usage Guidelines An RD creates a VRF and specifies the default RD for a VPN. The RD is added to the beginning of the customer IPv4 prefixes to change them into globally unique VPN IPv4 prefixes.

Either an RD is an AS-relative RD, in which case it is composed of an AS number and an arbitrary number, or it is an IP-address-relative RD, in which case it is composed of an IP address and an arbitrary number.

You can enter an RD in either of these formats:

16-bit AS number: your 32-bit number

— For example, 101:3.

32-bit IP address: your 16-bit number

— For example, 192.168.122.15:1.

Example: Configuring a Default RD for Two VRFs This example shows how to configure a default RD for two VRFs. The example illustrates the use of both AS-relative and IP-address-relative RDs:

᫬»®ř˝±˛ş·ą÷ý ·° Ş®ş Ş®şÁľ´«»

᫬»®ř˝±˛ş·ąóŞ®ş÷ý ®Ľ ďđđćí

᫬»® ř˝±˛ş·ąóŞ®ş÷ý »¨·¬

᫬»®ř˝±˛ş·ą÷ý ·° Ş®ş Ş®şÁ®»Ľ

᫬»®ř˝±˛ş·ąóŞ®ş÷ý ®Ľ ďéíňďíňđňďîćîđđ

Page 399: Implementing cisco mpls

5-84 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Monitoring Per-VRF CEF and LFIB Structures This topic describes how to monitor per-VRF Cisco Express Forwarding (CEF) and label forwarding information base (LFIB) structures.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-17

­¸±© ·° ˝»ş Ş®ş Ş®şó˛żł»

᫬»®ý

• Displays per-VRF CEF table

­¸±© ·° ˝»ş Ş®ş Ş®şó˛żł» ·°ó°®»ş·¨ Ľ»¬ż·´

᫬»®ý

• Displays details of an individual CEF entry, including label stack

­¸±© ł°´­ ş±®©ż®Ľ·˛ą Ş®ş Ş®şó˛żł»

᫬»®ý

• Displays labels allocated by an MPLS VPN for routes in the specified VRF

Monitoring per-VRF CEF and LFIB Structures

These three commands can be used to display per-VRF FIB and LFIB structures:

The show ip cef vrf command displays the VRF Forwarding Information Base (FIB).

The show ip cef vrf detail command displays detailed information about a single entry in the VRF FIB.

The show mpls forwarding vrf command displays all labels allocated to VPN routes in the specified VRF.

Page 400: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-85

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-18

The show ip cef command can also display the label stack associated with the MP-IBGP route.

Monitoring per-VRF CEF and LFIB Structures (Cont.)

᫬»®ý­¸±© ·° ˝»ş Ş®ş Í·¬»ßî îđíňďňďňď îëëňîëëňîëëňîëë Ľ»¬ż·´îđíňďňďňďńíîô Ş»®­·±˛ ëéô ˝ż˝¸»Ľ żĽ¶ż˝»˛˝§ ¬± Í»®·ż´ďńđňîđ °ż˝µ»¬­ô 𠾧¬»­

¬żą ·˛ş±®łż¬·±˛ ­»¬´±˝ż´ ¬żąć ĘĐŇ󮱫¬»ó¸»żĽşż­¬ ¬żą ®»©®·¬» ©·¬¸ Í»ďńđňîô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć Ąîę íçŁ

Ş·ż ďçîňďęčňíňďđíô đ Ľ»°»˛Ľ»˛˝·»­ô ®»˝«®­·Ş»˛»¨¬ ¸±° ďçîňďęčňíňďđô Í»®·ż´ďńđňî Ş·ż ďçîňďęčňíňďđíńí´·Ľ ˝ż˝¸»Ľ żĽ¶ż˝»˛˝§¬żą ®»©®·¬» ©·¬¸ Í»ďńđňîô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć Ąîę íçŁ

show ip cef vrf To display the CEF forwarding table associated with a VRF, use the show ip cef vrf command in privileged EXEC mode: show ip cef vrf vrf-name [ip-prefix [mask [longer-prefixes]] [detail] [output-modifiers]] [interface interface-number] [adjacency [interface interface-number] [detail] [discard] [drop] [glean] [null] [punt] [output-modifiers]] [detail [output-modifiers]] [non-recursive [detail] [output-modifiers]] [summary [output-modifiers]] [traffic[prefix-length] [output-modifiers]] [unresolved [detail] [output-modifiers]].

The label stack in the VRF table can be inspected using the show ip cef vrf vrf-name detailcommand. The tags imposed values in the output displays the MPLS label stack. The first label in the MPLS label stack is the Label Distribution Protocol (LDP) label forwarded toward the egress provider edge (PE) router, and the second label is the VPN label advertised by the egress PE router.

Page 401: Implementing cisco mpls

5-86 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

This table describes the syntax for the show ip cef vrf command.

Syntax Description

Parameter Description

Ş®şó˛żł» Name assigned to the VRF

·°ó°®»ş·¨ (Optional) IP prefix of entries to show, in dotted decimal notation (A.B.C.D)

łż­µ (Optional) Mask of the IP prefix, in dotted decimal notation

´±˛ą»®ó°®»ş·¨»­ (Optional) Displays table entries for all of the more specific routes

Ľ»¬ż·´ (Optional) Displays detailed information for each CEF table entry

±«¬°«¬ół±Ľ·ş·»®­ (Optional) For a list of associated keywords and arguments, use context-sensitive help

·˛¬»®şż˝» (Optional) Type of network interface to use: ATM, Ethernet, loopback, Packet over SONET (POS), or null

·˛¬»®şż˝»ó˛«łľ»® Number identifying the network interface to use

żĽ¶ż˝»˛˝§ (Optional) Displays all prefixes resolving through adjacency

Ľ·­˝ż®Ľ Discards adjacency

Ľ®±° Drops adjacency

ą´»ż˛ Gleans adjacency

˛«´´ Null adjacency

°«˛¬ Punts adjacency

˛±˛ó®»˝«®­·Ş» (Optional) Displays only nonrecursive routes

­«łłż®§ (Optional) Displays a CEF table summary

¬®żşş·˝ (Optional) Displays traffic statistics

°®»ş·¨ó´»˛ą¬¸ (Optional) Displays traffic statistics by prefix size

«˛®»­±´Ş»Ľ (Optional) Displays only unresolved routes

Defaults This command has no default values.

Usage Guidelines Used with the vrf-name argument, the show ip cef vrf command shows a shortened display of the CEF table.

Used with the detail keyword, the show ip cef vrf command shows detailed information for all CEF table entries.

Page 402: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-87

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-19

Monitoring per-VRF CEF and LFIB Structures (Cont.)

᫬»®ý­¸±© ł°´­ ş±®©ż®Ľ·˛ą Ş®ş Í·¬»ßîÔ±˝ż´ Ń«¬ą±·˛ą Đ®»ş·¨ ާ¬»­ ¬żą Ń«¬ą±·˛ą Ň»¨¬ ر°¬żą ¬żą ±® ĘÝ ±® Ě«˛˛»´ ׼ ­©·¬˝¸»Ľ ·˛¬»®şż˝»îę ßąą®»ąż¬» ďëđňďňíďňíęńíđĹĘĂ đíé ˲¬żąą»Ľ îđíňďňîňďńíîĹĘĂ đ Í»ďńđňîđ °±·˛¬î°±·˛¬íč ˲¬żąą»Ľ îđíňďňîđňđńîěĹĘĂ đ Í»ďńđňîđ °±·˛¬î°±·˛¬

᫬»®ý­¸±© ł°´­ ş±®©ż®Ľ·˛ą Ş®ş Í·¬»ßî ¬żą­ íé Ľ»¬ż·´Ô±˝ż´ Ń«¬ą±·˛ą Đ®»ş·¨ ާ¬»­ ¬żą Ń«¬ą±·˛ą Ň»¨¬ ر°¬żą ¬żą ±® ĘÝ ±® Ě«˛˛»´ ׼ ­©·¬˝¸»Ľ ·˛¬»®şż˝»íé ˲¬żąą»Ľ îđíňďňîňďńíîĹĘĂ đ Í»ďńđňîđ °±·˛¬î°±·˛¬

ÓßÝń۲˝ż°­ăđńđô ÓĚËăďëđěô Ěżą ͬż˝µĄŁĘĐŇ ®±«¬»ć Í·¬»ßî

Đ»®ó°ż˝µ»¬ ´±żĽó­¸ż®·˛ą

show mpls forwarding vrf To display label-forwarding information for advertised VRF routes, use the show mpls forwarding vrf command in EXEC mode.

show mpls forwarding vrf vrf-name [ip-prefix/length [mask]] [detail] [output-modifiers]

This table describes the parameters for the show mpls forwarding vrf command.

Syntax Description

Parameter Description

Ş®şó˛żł» Displays NLRI prefixes associated with the named VRF

·°ó°®»ş·¨ń´»˛ą¬¸ (Optional) Displays IP prefix address (in dotted decimal notation) and length of mask (0 to 32)

łż­µ (Optional) Displays destination network mask in dotted decimal notation

Ľ»¬ż·´ (Optional) Displays detailed information on the VRF routes

±«¬°«¬ół±Ľ·ş·»®­ (Optional) For a list of associated keywords and arguments, use context-sensitive help

Defaults This command has no default behavior or values.

Usage Guidelines Use this command to display label-forwarding entries associated with a particular VRF or IP prefix.

Page 403: Implementing cisco mpls

5-88 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Monitoring Labels Associated with VPNv4 Routes

This topic describes how to monitor labels associated with VPNv4 routes.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-20

­¸±© ·° ľą° Ş°˛Şě Ĺ ż´´ ¤ ®Ľ Şż´«» ¤ Ş®ş Ş®şó˛żł» Ă ´żľ»´­

᫬»®ý

• Displays labels associated with VPNv4 routes

Monitoring Labels Associated with VPNv4 Routes

᫬»®ý­¸±© ·° ľą° Ş°˛Şě ż´´ ´żľ»´­

Ň»¬©±®µ Ň»¨¬ ر° ײ ´żľ»´ńŃ«¬ ´żľ»´Î±«¬» Ü·­¬·˛ą«·­¸»®ć ďđđćď řŞ®şď÷

îňđňđňđ ďđňîđňđňęđ íěń˛±´żľ»´ďđňđňđňđ ďđňîđňđňęđ íëń˛±´żľ»´ďîňđňđňđ ďđňîđňđňęđ îęń˛±´żľ»´

ďđňîđňđňęđ îęń˛±´żľ»´ďíňđňđňđ ďđňďëňđňďë ˛±´żľ»´ńîę

You can use the show ip bgp vpnv4 all labels command to display tags assigned to local or remote VRF routes by the local or remote PE router. This command displays labels associated with all VPNv4 routes when you use the all keyword. This command can also display tags associated with a specified RD or VRF.

This table describes the fields displayed by this command.

Field Descriptions

Field Description

Network Displays the network address from the BGP table

Next Hop Specifies the BGP next-hop address

In tag Displays the label (if any) assigned by this router

Out tag Displays the label assigned by the BGP next-hop router

Page 404: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-89

Identifying Other MPLS VPN Monitoring Commands

This topic identifies the command syntax that is used with other MPLS VPN monitoring commands.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-21

¬»´˛»¬ ¸±­¬ ńŞ®ş Ş®şó˛żł»

᫬»®ý

• Performs PE-CE Telnet through specified VRF

°·˛ą Ş®ş Ş®şó˛żł» ·°óżĽĽ®»­­

᫬»®ý

• Performs ping based on VRF routing table

¬®ż˝» Ş®ş Ş®şó˛żł» ·°óżĽĽ®»­­

᫬»®ý

• Performs VRF-based traceroute

Other MPLS VPN Monitoring Commands

These three additional Cisco IOS software monitoring commands are VRF-aware:

The telnet command can be used to connect to a customer edge (CE) router from a PE router using the /vrf option.

The ping vrf command can be used to ping a destination host reachable through a VRF.

The trace vrf command can be used to trace a path toward a destination reachable through a VRF.

Page 405: Implementing cisco mpls

5-90 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-22

Summary

• Use the following commands to monitor VRF information:

– show ip vrf

– show ip vrf detail

– show ip vrf interfaces

• Use the following commands to monitor VRF routing:

– show ip protocols vrf vrf-name

– show ip route vrf vrf-name

– show ip bgp vpnv4 vrf vrf-name

• Use the show ip bgp neighbors command to monitor MP-BGP sessions.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-23

Summary (Cont.)

• Use the show ip bgp vpnv4 command to monitor an MP-BGP VPNv4 table.

• Use these commands to monitor the per-VRF CEF and LFIB structures:

– show ip cef vrf

– show ip cef vrf detail

– show mpls forwarding vrf vrf-name

• Use the show ip bgp vpnv4 all labels command to monitor MP-BGP VPNv4 labels.

• Other commands to monitor MPLS VPN are as follows:

– telnet ip-address /vrf vrf-name

– ping vrf vrf-name ip-address

– trace vrf vrf-name ip-address

Page 406: Implementing cisco mpls

Lesson 6

Configuring OSPF as the Routing Protocol Between PE and CE Routers

OverviewThis lesson explains the provider edge-customer edge (PE-CE) routing protocol configuration steps required when you are running Open Shortest Path First (OSPF) between PE and CE routers, and the issues that may be encountered.

It is important to understand not only what you can configure between provider edge (PE) and customer edge (CE) routers when you are setting up Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs), but also how to accomplish the configuration successfully. This lesson looks at the configuration parameters that you need to configure an MPLS VPN PE-CE routing exchange.

ObjectivesUpon completing this lesson, you will be able to describe how to configure OSPF as the routing protocol between PE and CE routers. This ability includes being able to meet these objectives:

Describe the features of the OSPF hierarchical model

Describe the propagation of OSPF customer routes across the MPLS VPN backbone

Describe how an MPLS VPN is implemented as an OSPF superbackbone

Configure a PE-CE OSPF routing session

Describe how the OSPF down bit is used to address the route loop issue

Describe how packet forwarding is optimized across the MPLS VPN

Describe how the OSPF tag field is used to address the root loop issue

Describe the features of a sham link

Configure a sham link

Page 407: Implementing cisco mpls

5-92 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Is the Enhanced OSPF Hierarchical Model? This topic describes the features of the enhanced OSPF hierarchical model.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-3

OSPF Hierarchical Model

• OSPF divides a network into areas, all of them linked through the backbone (Area 0).

• Areas could correspond to individual sites from an MPLS VPN perspective.

The OSPF routing protocol was designed to support hierarchical networks with a central backbone. The network running OSPF is divided into areas. All areas have to be directly connected to the backbone area (Area 0). The whole OSPF network (backbone area and any other connected areas) is called the OSPF domain.

The OSPF areas in the customer network can correspond to individual sites, but these other options are often encountered:

A single area could span multiple sites (for example, the customer decides to use an area per region, but the region contains multiple sites).

The backbone area could be extended into individual sites.

Note Please refer to the Building Scalable Cisco Internetworks (BSCI) course for background

information on OSPF.

Page 408: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-93

Propagating OSPF Customer Routes This topic describes the propagation of OSPF customer routes across the MPLS VPN backbone.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-4

OSPF in an MPLS VPN Routing Model

• From the customer perspective, an MPLS VPN-based network has a BGP backbone with IGP running at customer sites.

• Redistribution between IGP and BGP is performed to propagate customer routes across the MPLS VPN backbone.

The MPLS VPN routing model introduces a Border Gateway Protocol (BGP) backbone into the customer network. Isolated copies of the Interior Gateway Protocol (IGP) run at every site, and Multiprotocol Border Gateway Protocol (MP-BGP) is used to propagate routes between sites. Redistribution between customer IGP—running between PE routers and CE routers—and the backbone MP-BGP is performed at every PE router.

Page 409: Implementing cisco mpls

5-94 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-5

OSPF in an MPLS VPN Routing Model:OSPF-BGP Redistribution Issue

The IGP-BGP redistribution introduced by the MPLS VPN routing model does not fit well into customer networks running OSPF. When an OSPF customer is migrated to an MPLS VPN implementation, any route that is redistributed into OSPF from another routing protocol will now be redistributed as an external OSPF route. The OSPF routes received by one PE router are propagated across the MPLS backbone and redistributed back into OSPF at another site as external OSPF routes.

Note Remember that link-state advertisement (LSA)1 and LSA 2 never leave the OSPF area.

Page 410: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-95

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-6

OSPF in an MPLS VPN Routing Model:Classic OSPF-BGP Redistribution

• OSPF route type is not preserved when the OSPF route is redistributed into BGP.

• All OSPF routes from a site are inserted as external (type 5 LSA) routes into other sites.

• Result: OSPF route summarization and stub areas are hard to implement.

• Conclusion: MPLS VPN must extend the classic OSPF-BGP routing model.

With the traditional OSPF-BGP redistribution, the OSPF route type (internal or external route) is not preserved when the OSPF route is redistributed into BGP. When that same route is redistributed back into OSPF, it is always redistributed as an external OSPF route.

This list identifies some of the caveats associated with external OSPF routes:

External routes cannot be summarized.

External routes are flooded across all OSPF areas.

External routes could use a different metric type that is not comparable to OSPF cost.

External routes are not inserted in stub areas or not-so-stubby areas (NSSAs).

Internal routes are always preferred over external routes, regardless of their cost.

Because of all these caveats, migrating an OSPF customer toward an MPLS VPN service might have a severe impact on the routing of that customer. The MPLS VPN architecture must therefore extend the classic OSPF-BGP routing model to support transparent customer migration.

Page 411: Implementing cisco mpls

5-96 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Implementing MPLS VPNs as an OSPF Superbackbone

This topic describes how an MPLS VPN is implemented as an OSPF superbackbone.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-7

OSPF Superbackbone: OSPF-BGP Hierarchy Issue

• OSPF Area 0 might extend into individual sites.

• The MPLS VPN backbone has to become a superbackbonefor OSPF.

The MPLS VPN architecture extends the OSPF architecture by introducing another backbone above OSPF Area 0, the superbackbone. The OSPF superbackbone is implemented with MP-BGP between the PE routers but is otherwise transparent to the OSPF routers. The architecture even allows disjointed OSPF backbone areas (Area 0) at MPLS VPN customer sites.

Page 412: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-97

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-8

OSPF in MPLS VPNs:Goals

• OSPF between sites shall not use normal OSPF-BGP redistribution.

• OSPF continuity must be provided across the MPLS VPN backbone:– Internal OSPF routes should remain internal OSPF routes.

– External routes should remain external routes.

– OSPF metrics should be preserved.

• CE routers run standard OSPF software.

Here are the goals that have to be met by the OSPF superbackbone:

The superbackbone shall not use standard OSPF-BGP redistribution.

OSPF continuity must be provided between OSPF sites, as follows:

— Internal OSPF routes must remain internal OSPF routes.

— External OSPF routes must remain external OSPF routes.

— Non-OSPF routes redistributed into OSPF must appear as external OSPF routes in OSPF.

— OSPF metrics and metric types (external 1 or external 2) have to be preserved.

The OSPF superbackbone shall be transparent to the CE routers that run standard OSPF software.

Page 413: Implementing cisco mpls

5-98 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-9

OSPF Superbackbone:Route Propagation Example

The MPLS VPN superbackbone appears as another layer of hierarchy in the OSPF architecture. The PE routers that connect regular OSPF areas to the superbackbone therefore appear as OSPF Area Border Routers (ABRs) in the OSPF areas to which they are attached. In Cisco IOS implementation, ABRs also appear as Autonomous System Boundary Routers (ASBRs) in nonstub areas.

From the perspective of a standard OSPF-speaking CE router, the PE routers insert interarea routes from other areas into the area in which the CE router is present. The CE routers are not aware of the superbackbone or of other OSPF areas present beyond the MPLS VPN superbackbone.

With the OSPF superbackbone architecture, the following describes how the continuity of OSPF routing is preserved:

The OSPF intra-area route—described in the OSPF router LSA or network LSA—is inserted into the OSPF superbackbone by redistributing the OSPF route into MP-BGP. Route summarization can be performed on the redistribution boundary by the PE router.

The MP-BGP route is propagated to other PE routers and inserted as an OSPF route into other OSPF areas.

Note Because the superbackbone appears as another area behind the PE router (acting as ABR),

the MP-BGP route derived from the intra-area route is always inserted as an interarea route.

The interarea route can then be propagated into other OSPF areas by ABRs within the

customer site.

Page 414: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-99

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-10

OSPF Superbackbone:Rules

OSPF superbackbone behaves exactly like Area 0 in regular OSPF:

• PE routers are advertised as Area Border Routers.

• Routes redistributed from BGP into OSPF appear as interarea summary routes or as external routes (based on their original LSA type) in other areas.

• Routes from Area 0 at one site appear as interarea routes in Area 0 at another site.

Here is a summary of the OSPF superbackbone rules:

PE routers advertise themselves as ABRs. The superbackbone appears as another area to the CE routers.

Routes redistributed into MP-BGP from OSPF will appear as interarea routes in other OSPF sites if the original route was an intra-area or interarea route, and as external routes if the original route was an external route.

Note As a consequence of the second rule, routes from the backbone area at one site appear as

interarea routes (not as backbone routes) in backbone areas at other sites.

Page 415: Implementing cisco mpls

5-100 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-11

OSPF Superbackbone:Implementation

• Extended BGP communities are used to propagate OSPF route type across BGP backbone.

• OSPF cost is copied into MED attribute.

The OSPF superbackbone is implemented with the help of several BGP attributes.

A new BGP extended community was defined to carry OSPF route type and OSPF area across the BGP backbone. The format of this community is defined in this table.

BGP Extended Community Format

Field Number of Bytes Comments

Community type 2 The community type is 0x8000.

OSPF area 4 This field carries the OSPF area from which the route was redistributed into MP-BGP.

LSA type 1 This field carries the OSPF LSA type from which the route was redistributed into MP-BGP.

Option 1 This field is used for external metric type. The low-order bit is set for external 2 routes.

Note The option field in the OSPF route type extended community is not equivalent to the option

field in the OSPF LSA.

As in the standard OSPF-BGP redistribution, the OSPF cost is carried in the multi-exit discriminator (MED) attribute.

Page 416: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-101

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-12

OSPF Superbackbone:Implementation (Cont.)

• OSPF route type is copied into extended BGP community on redistribution into BGP.

• Egress PE router performs interarea transformation.

This figure illustrates the propagation of internal OSPF routes across the MPLS VPN superbackbone.

Example: OSPF Superbackbone Implementation

The sending PE router redistributes the OSPF route into MP-BGP, copies the OSPF cost into the MED attribute, and sets the BGP extended community to indicate the LSA type from which the route was derived.

The receiving PE router redistributes the MP-BGP route back into OSPF and uses the original LSA type and the MED attribute to generate an interarea summary LSA.

An interarea summary LSA or type 3 LSA is always generated because the receiving PE router acts as an ABR between the superbackbone and the OSPF area (or areas).

Note If the OSPF superbackbone connects two or more instances of the same area, the

redistributed route will appear as an interarea summary LSA.

Page 417: Implementing cisco mpls

5-102 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-13

• External OSPF routes are propagated in the same way as internal OSPF routes across the superbackbone.

• External metric and route type are preserved.

OSPF Superbackbone:External Routes

The external OSPF routes are redistributed into MP-BGP in exactly the same way as the internal OSPF routes. Here is how the process changes slightly on the receiving PE router:

For external routes (type 5 LSA), the LSA is reoriginated, with the receiving PE router being the ASBR. The external metric type is copied from the BGP extended community, and the external cost is copied from the MED.

For NSSA external routes (type 7 LSA), the route is announced to the other OSPF sites as a type 5 LSA external route, because the route has already crossed the area boundary.

Page 418: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-103

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-14

• Routes from the MP-BGP backbone that did not originate in OSPF are still subject to standard redistribution behavior when inserted into OSPF.

OSPF Superbackbone:Mixing Routing Protocols

The MPLS VPN superbackbone still retains the traditional OSPF-BGP route redistribution behavior for routes that did not originate in OSPF at other sites (and therefore do not carry the OSPF extended BGP community). These routes are inserted into the OSPF topology database as type 5 external routes (or type 7 external routes for NSSA areas), with the default OSPF metric (not the value of MED).

Page 419: Implementing cisco mpls

5-104 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Configuring OSPF PE-CE Routing This topic describes how to configure a PE-CE OSPF routing session.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-15

Configuring PE-CE OSPF Routing

Follow these steps to configure OSPF as the PE-CE routing protocol:

• Configure per-VRF copy of OSPF.

• Configure redistribution of MP-BGP into OSPF.

• Configure redistribution of OSPF into MP-BGP.

To configure OSPF as a PE-CE routing protocol, you need to start a separate OSPF process for each virtual routing and forwarding instance (VRF) in which you want to run OSPF. The per-VRF OSPF process is configured in the same way as a standard OSPF process. You can use all of the OSPF features that are available in Cisco IOS software.

You need to redistribute OSPF routes into BGP and redistribute BGP routes into OSPF if necessary. Alternatively, you can originate a default route into a per-VRF OSPF process by using the default-information originate always command in router configuration mode.

MP-BGP propagates more than just OSPF cost across the MPLS VPN backbone. The propagation of additional OSPF attributes into MP-BGP is automatic and requires no extra configuration.

Page 420: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-105

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-16

®±«¬»® ±­°ş °®±˝»­­ó·Ľ Ş®ş Ş®şó˛żł»

ňňň ͬż˛Ľż®Ľ ŃÍĐÚ °ż®żł»¬»®­ ňňň

®±«¬»®ř˝±˛ş·ą÷ý

• This command starts the per-VRF OSPF routing process.

• The total number of routing processes per router is limited to 32.

®»Ľ·­¬®·ľ«¬» ľą° ż­ó˛«łľ»® ­«ľ˛»¬­

®±«¬»®ř˝±˛ş·ąó®±«¬»®÷ý

• This command redistributes MP-BGP routes into OSPF. The subnets keyword is mandatory for proper operation.

Configuring PE-CE OSPF Routing (Cont.)

OSPF is the only PE-CE routing protocol that is not fully VPN-aware. A separate OSPF process is run for every VRF.

Note Prior to Cisco IOS Release 12.3(4)T, Cisco IOS software implementation limits the overall

number of routing protocols in a router to 32. Two routing methods are predefined (static

and connected), and two routing protocols are needed for proper MPLS VPN backbone

operation—BGP and backbone IGP. The number of PE-CE routing processes was therefore

limited to 28.

This restriction was removed for MPLS in Cisco IOS Release 12.3(4)T.

Page 421: Implementing cisco mpls

5-106 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

router ospf To configure an OSPF routing process within a VRF, use the router ospf command in global configuration mode. To terminate an OSPF routing process, use the no form of this command.

router ospf process-id vrf vrf-name

no router ospf process-id vrf vrf-name

This table describes the parameters for the router ospf command.

Syntax Description

Parameter Description

°®±˝»­­ó·Ľ Internally used identification parameter for an OSPF routing process

This parameter is locally assigned and can be any positive integer. A unique value is assigned for each OSPF routing process.

Ş®şó˛żł» Name of the VRF where the OSPF process will reside

Defaults No OSPF routing process is defined.

Page 422: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-107

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-17

®±«¬»® ľą° ż­ó˛«łľ»®

żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ş®şó˛żł»

®»Ľ·­¬®·ľ«¬» ±­°ş °®±˝»­­ó·Ľ Ĺłż¬˝¸ Ĺ·˛¬»®˛ż´Ă

Ĺ»¨¬»®˛ż´óďĂ Ĺ»¨¬»®˛ż´óîĂĂ

®±«¬»®ř˝±˛ş·ą÷ý

• OSPF-BGP route redistribution is configured with the redistribute command under the proper address-family command.

• Without the OSPF match keyword specified, only internal OSPF routes are redistributed into OSPF.

Configuring PE-CE OSPF Routing (Cont.)

Use the standard BGP redistribution commands.

Page 423: Implementing cisco mpls

5-108 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Using the OSPF Down Bit This topic describes how the OSPF down bit is used to address the route loop issue.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-18

OSPF Down Bit: Routing Loops between MP-BGP and OSPF

Example: OSPF Down Bit OSPF developers took many precautions to avoid routing loops between OSPF areas—for example, intra-area routes are always preferred over interarea routes. These rules do not work when the superbackbone is introduced. Consider, for example, the network in the figure, where the receiving OSPF area has two PE routers attached to it.

This table indicates the process steps that could produce a routing loop.

Process Steps in a Routing Loop

Step Action

1 The sending PE router receives an intra-area OSPF route.

2 The intra-area OSPF route is redistributed into MP-BGP. An OSPF community is attached to the route to indicate that it was an OSPF route before being redistributed.

3 The receiving PE router redistributes the MP-BGP route into OSPF as an internal interarea summary route.

4 The summary route is propagated across the OSPF area and received by the other PE router attached to the same area.

5 The administrative distance of the OSPF route is better than the administrative distance of the MP-BGP route; therefore, the PE router selects the OSPF route and redistributes the route back into the MP-BGP process, potentially resulting in a routing loop.

Page 424: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-109

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-19

OSPF Down Bit:Loop Prevention

• An additional bit (down bit) has been introduced in the options field of the OSPF LSA header.

• PE routers set the down bit when redistributing routes from MP-BGP into OSPF.

• PE routers never redistribute OSPF routes with the down bit set into MP-BGP.

These two mechanisms were introduced to prevent route redistribution loops between OSPF (running between PE and CE routers) and MP-BGP running between PE routers:

One of these mechanisms is the BGP Site of Origin (SOO), which is discussed in the “Introducing the MPLS VPN Routing Model” lesson of the “MPLS VPN Technology” module and detailed further in the “Configuring BGP as the Routing Protocol Between PE and CE Routers” lesson of the “MPLS VPN Implementation” module.

The other mechanism is the down bit in the options field of the OSPF LSA header.

Page 425: Implementing cisco mpls

5-110 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-20

OSPF Down Bit:Loop Prevention (Cont.)

The down bit is used between the PE routers to indicate which routes were inserted into the OSPF topology database from the MPLS VPN superbackbone and thus shall not be redistributed back in the MPLS VPN superbackbone. The PE router that redistributes the MP-BGP route as an OSPF route into the OSPF topology database sets the down bit. The other PE routers use the down bit to prevent this route from being redistributed back into MP-BGP.

Example: OSPF Down Bit

The typical usage of the down bit is shown in the figure. The steps that show how the down bit prevents routing loops are detailed in this table.

Process to Prevent Routing Loops

Step Action

1 The PE router receives an OSPF route.

2 The PE router redistributes the OSPF route into MP-BGP. The MP-BGP route is propagated to the other PE routers.

3 The MP-BGP route is inserted as an interarea route into an OSPF area by the receiving PE router. The receiving PE router sets the down bit in the summary (type 3) LSA.

4 When the other PE routers receive the summary LSA with the down bit set, they do not redistribute the route back into MP-BGP.

Page 426: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-111

Optimizing Packet Forwarding Across the MPLS VPN Backbone

This topic describes how packet forwarding is optimized across the MPLS VPN backbone.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-21

Optimizing of Packet Forwarding Across the MPLS VPN Backbone

The OSPF superbackbone implementation with MP-BGP has other implications beyond the potential for routing loops between OSPF and BGP.

Example: Optimizing of Packet Forwarding

Consider, for example, the network in the figure. This table indicates a typical flow for routing updates.

Process Steps for Routing Update Flow

Step Action

1 The PE router redistributes the OSPF route into MP-BGP. The route is propagated to other PE routers as an MP-BGP route. The route is also redistributed into other OSPF areas.

2 The redistributed OSPF route is propagated across the OSPF area with the down bit set.

3 The ingress PE router receives an MP-IBGP route with an administrative distance of 200 and an OSPF route with an administrative distance of 110. The OSPF route is preferred over the Multiprotocol Internal Border Gateway Protocol (MP-IBGP) route, and the data packets flow across customer sites, not directly over the MPLS VPN backbone.

Page 427: Implementing cisco mpls

5-112 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-22

• The PE routers ignore OSPF routes with the down bit set for routing purposes:

– These routes originated at other sites; therefore, the traffic toward them should go via the MP-BGP backbone.

• The routing bit is not set on OSPF routes with the down bit set:

– These routes do not enter the IP routing table, even when they are selected as the best routes using the SPF algorithm.

Optimizing of Packet Forwarding Across the MPLS VPN Backbone (Cont.)

To prevent the customer sites from acting as transit parts of the MPLS VPN network, the OSPF route selection rules in PE routers need to be changed. The PE routers have to ignore all OSPF routes with the down bit set, because these routes originated in the MP-BGP backbone and the MP-BGP route should be used as the optimum route toward the destination.

This rule is implemented with the routing bit in the OSPF LSA. For routes with the down bitset, the routing bit is cleared and these routes never enter the IP routing table—even if they are selected as the best routes by the shortest path first (SPF) algorithm.

Note The routing bit is the Cisco extension to OSPF and is used only internally in the router. The

routing bit is never propagated between routers in LSA updates.

Page 428: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-113

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-23

Optimizing of Packet Forwarding Across the MPLS VPN Backbone (Cont.)

With the new route OSPF selection rules in place, the packet forwarding in the network shown in the figure follows the desired path. The process steps are described in this table.

Process Steps for Optimizing Packet Forwarding

Step Action

1 The OSPF route is redistributed into MP-BGP by a PE router and propagated to other PE routers.

2 The receiving PE routers redistribute the MP-BGP route into OSPF.

Other PE routers might receive the MP-BGP and OSPF routes but will ignore the OSPF route for routing purposes because it has the down bit set. The data packets will flow across the MPLS VPN backbone, following only the MP-BGP routes, not the OSPF routes derived from the MP-BGP routes.

Page 429: Implementing cisco mpls

5-114 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Using the OSPF Tag Field This topic describes how the OSPF tag field is used to address the root loop issue.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-24

OSPF Tag Field: Routing Loops Across OSPF Domains

The down bit stops the routing loops between MP-BGP and OSPF. The down bit cannot, however, stop the routing loops when redistribution between multiple OSPF domains is involved.

Example: Routing Loops Across OSPF Domains

The figure illustrates this example. The routing loop in this network occurs as part of the steps outlined in this table.

Process Steps for Routing Loops Across OSPF Domains

Step Action

1 The PE router redistributes a non-OSPF route into an OSPF domain as an external route.

2 The down bit is set because the route should not be redistributed back into MP-BGP.

3 A CE router redistributes the OSPF route into another OSPF domain. The down bit is lost if the CE router does not understand this OSPF extension.

4 The OSPF route is propagated through the other OSPF domain with the down bit cleared.

5 A PE router receives the OSPF route; the down bit is not set, so the route is redistributed back into the MP-BGP backbone, resulting in a routing loop.

Page 430: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-115

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-25

OSPF Tag Field:Operation

• The tag field in external OSPF routes is used to detect cross-domain routing loops.

• PE routers set the tag field to the BGP AS number when redistributing non-OSPF routes from MP-BGP into OSPF.

• The tag field is propagated between OSPF domains when the external OSPF routes are redistributed between OSPF domains.

• PE routers filter external OSPF routes to MP-BGP with OSPF tag field AS numbers matching BGP AS numbers.

The routing loops introduced by route redistribution between OSPF domains can be solved with the help of the tag field, using standard OSPF-BGP redistribution rules.

In standard OSPF-BGP or OSPF-OSPF redistribution, these rules apply:

Whenever a router redistributes a BGP route into OSPF, the tag field in the type 5 (or type 7) LSA is set to the autonomous system (AS) number of the redistributing router.

The tag field from an external OSPF route is propagated across OSPF domains when the external OSPF route is redistributed into another OSPF domain.

In addition to these standard mechanisms, PE routers filter external OSPF routes based on their tag field and do not redistribute, into MP-BGP, routes with a tag field equal to the BGP AS number.

Page 431: Implementing cisco mpls

5-116 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-26

OSPF Tag Field:Usage Guidelines

• Internal OSPF routes have no tag field.

• This technique does not detect cross-domain routing information loops for routes inserted as internal OSPF routes by the PE routers.

• The tag field can be set manually on the router, redistributing routes between OSPF domains with the redistribute ospf source-process-id tag valuecommand.

• Alternatively, only the internal OSPF routes can be redistributed into MP-BGP on the PE routers.

The OSPF tag field is present only in the external OSPF routes (type 5 LSA or type 7 LSA). This technique, therefore, cannot detect cross-domain loops involving internal OSPF routes. Here are the two manual methods that you can use to overcome this OSPF limitation:

You can set the tag field manually on the router, redistributing routes between OSPF domains using the redistribute ospf source-process-id tag value command.

The PE router can be configured to redistribute only internal OSPF routes into MP-BGP.

Page 432: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-117

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-27

OSPF Tag Field:Routing Loop Prevention

The OSPF tag field can be used to prevent routing loops when the redistribution is done between OSPF domains.

Example: OSPF Tag Field—Routing Loop Prevention

The figure illustrates this example. This table lists the steps in this process.

Process Steps to Prevent Routing Loops

Step Action

1 A non-OSPF route is redistributed as an external OSPF route by a PE router.

2 The tag field is set to the BGP AS number, and the down bit is set. The redistributed route is propagated across the OSPF domain.

3 When the route is redistributed into another OSPF domain, the tag field is propagated, but the down bit is cleared.

4 The route is propagated across the OSPF domain with the tag set to the BGP AS number.

5 Another PE router receives the external OSPF route and filters the route based on the tag field. The route is not redistributed into MP-BGP.

Page 433: Implementing cisco mpls

5-118 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Is a Sham Link? This topic describes the features of a sham link.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-28

Sham Link

• OSPF prefers intra-area paths to interarea paths.

• The path over a backdoor link will always be selected.

Although OSPF PE-CE connections assume that the only path between two client sites is across the MPLS VPN backbone, backdoor paths between VPN sites may exist.

Example: Sham Link The figure illustrates the backdoor paths between VPN sites. If these sites belong to the same OSPF area, the path over a backdoor link will always be selected because OSPF prefers intra-area paths to interarea paths. (PE routers advertise OSPF routes learned over the VPN backbone as interarea paths.) For this reason, OSPF backdoor links between VPN sites must be taken into account so that routing is performed based on policy.

Because each site runs OSPF within the same Area 1 configuration, all routing between the sites follows the intra-area path across the backdoor links, rather than over the MPLS VPN backbone.

Page 434: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-119

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-29

Sham Link (Cont.)

• A logical intra-area link.

• Carried by the superbackbone.

• A sham link is required only between two VPN sites that belong to the same area and have a backdoor link for backup purposes.

• OSPF adjacency is established across the sham link.

• LSA flooding occurs across the sham link.

If the backdoor links between sites are used only for backup purposes and do not participate in the VPN service, the default route selection shown in the preceding figure is not acceptable. To reestablish the desired path selection over the MPLS VPN backbone, you must create an additional OSPF intra-area (logical) link between ingress and egress VRFs on the relevant PE routers. This link is called a sham link.

A sham link is required between any two VPN sites that belong to the same OSPF area andshare an OSPF backdoor link. If no backdoor link exists between the sites, no sham link is required.

Page 435: Implementing cisco mpls

5-120 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-30

Sham Link (Cont.)

When a sham-link route is preferred by OSPF:

• The OSPF route is not redistributed to MP-BGP.

• Instead, the router on the other end of the sham link performs the redistribution.

• The forwarding information from the MP-BGP route is used.

A cost is configured with each sham link. This cost is used to decide whether traffic will be sent over the backdoor path or the sham-link path. When a sham link is configured between PE routers, the PE routers can populate the VRF routing table with the OSPF routes learned over the sham link.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-31

Sham Link (Cont.)

Because the sham link is seen as an intra-area link between PE routers, an OSPF adjacency is created and a database exchange (for the particular OSPF process) occurs across the link. The PE router can then flood LS100

Page 436: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-121

As between sites from across the MPLS VPN backbone. As a result, the desired intra-area connectivity is created.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-32

Sham Link (Cont.)

Because the OSPF cost of the sham link has been configured as preferred over the backdoor link, the PE routers will prefer routes learned via the high-bandwidth backbone. The implementation results in optimum packet flow.

Page 437: Implementing cisco mpls

5-122 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Configuring a Sham Link This topic describes how to configure a sham link.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-33

Configuring a Sham Link

• A separate /32 address space is required in each PE router for each sham link.

• This /32 address space:

– Is required so that OSPF packets can be sent over the VPN backbone to the remote end of the sham link

– Must belong to the VRF

– Must not be advertised by OSPF

– Must be advertised by BGP

When you are configuring a sham link, a separate /32 address space is required in each PE router.

The criteria listed here apply to this /32 address space:

Required so that OSPF packets can be sent over the VPN backbone to the remote end of the sham link

Must belong to the VRF

Must not be advertised by OSPF

Must be advertised by BGP

Page 438: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-123

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-34

ż®»ż ż®»żó·Ľ ­¸żłó´·˛µ ­±«®˝»óżĽĽ®»­­ Ľ»­¬·˛ż¬·±˛óżĽĽ®»­­ ˝±­¬ ˛«łľ»®

®±«¬»®ř˝±˛ş·ąó®±«¬»®÷ý

• This command was introduced in Cisco IOS Release 12.2(8)T.

• The sham link belongs to the specified area.

• Sham-link packets sent across the MPLS VPN backbone will have the specified source and destination addresses.

• When the SPF algorithm is executed, the sham link will have the specified cost.

Configuring a Sham Link (Cont.)

To configure a sham-link interface on a PE router in an MPLS VPN backbone, use the areasham-link cost command in global configuration mode. To remove the sham link, use the noform of this command.

area area-id sham-link source-address destination-address cost number

no area area-id sham-link source-address destination-address cost number

This table describes the parameters for the area sham-link cost command.

Syntax Description

Parameter Description

ż®»żó·Ľ ID number of the OSPF area assigned to the sham link; valid values: numeric value or valid IP address

There is no default.

­±«®˝»óżĽĽ®»­­ IP address of the source PE router in the format: ip-address[mask]

Ľ»­¬·˛ż¬·±˛óżĽĽ®»­­ IP address of the destination PE router in the format: ip-address[mask]

˛«łľ»® OSPF cost to send IP packets over the sham-link interface

Valid values are from 1 to 65535.

DefaultsThere is no default behavior or values.

Page 439: Implementing cisco mpls

5-124 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Command ModesUse this command in global configuration mode.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-35

Sample Sham-Link Configuration

A sham link is used only to affect the OSPF intra-area path selection of the PE and CE routers.

Example: Sample Sham-Link Configuration

The figure illustrates this example. The PE router also uses the information received from MP-BGP to set the outgoing label stack of incoming packets and to decide to which egress PE router to label-switch the packets.

The figure shows a sample MPLS VPN topology in which a sham-link configuration is necessary. A VPN client has two sites connected by a backdoor link. A sham link has been configured between the two PE routers.

Page 440: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-125

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-36

• OSPF areas connect to a common backbone area in a two-tier hierarchical model.

• Basic OSPF across an MPLS VPN includes a BGP backbone. OSPF is run at each site, while MP-BGP is used to propagate routes between each site.

• A better option implements the MP-BGP backbone as a new transparent OSPF superbackbone above existing areas.

• OSPF PE-CE routing is implemented as a separate routing process. (One routing process per VRF.)

Summary

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-37

• The OSPF down bit prevents routing loops.

• The OSPF tag field is also used to prevent routing loops.

• Packet forwarding is optimized across the MPLS VPN using the OSPF routing bit

• A sham link is required between any two VPN sites that belong to the same OSPF area and share an OSPF backdoor link.

• The area sham-link cost command is used to configure a sham link across a MPLS VPN backbone.

Summary (Cont.)

Page 441: Implementing cisco mpls

5-126 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 442: Implementing cisco mpls

Lesson 7

Configuring BGP as the Routing Protocol Between PE and CE Routers

OverviewThis lesson explains the provider edge-customer edge (PE-CE) routing protocol configuration steps required when you are using Border Gateway Protocol (BGP) as the routing protocol between provider edge (PE) and customer edge (CE) routers.

It is important to understand not only what you can configure between PE and CE routers when you are setting up Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPNs), but also how to accomplish the configuration successfully. This lesson looks at the configuration parameters that you need to configure an MPLS VPN PE-CE routing exchange.

ObjectivesUpon completing this lesson, you will be able to describe how to configure BGP as the routing protocol between CE and PE routers. This ability includes being able to meet these objectives:

Configure a per-VRF BGP routing context

Explain the reason for limiting the number of routes in a VRF

Describe how to limit the number of prefixes received from a BGP neighbor

Describe how to limit the total number of VRF routes

Identify the issues encountered when a customer wants to reuse the same AS number on several sites

Identify the issues encountered when a customer site links two VPNs

Implement SOO for loop prevention

Page 443: Implementing cisco mpls

5-128 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Configuring a Per-VRF BGP Routing Context This topic describes how to configure a per-virtual routing and forwarding (VRF) BGP routing context.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-3

®±«¬»® ľą° ż­ó˛«łľ»®żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ş®şó˛żł»ňňň Đ»®óĘÎÚ ŢŮĐ Ľ»ş·˛·¬·±˛­ ňňň

᫬»®ř˝±˛ş·ą÷ý

• Select per-VRF BGP context with thecommand.

• Configure CE EBGP neighbors in the VRF context, not in the global BGP configuration.

• CE neighbors have to be activated with the command.

Configuring per-VRF BGP Routing Context

Select the VRF routing context with the address-family ipv4 vrf vrf-name command in the BGP routing processes. All per-VRF routing protocol parameters (network numbers, passive interfaces, neighbors, filters, and so on) are configured under this address family.

When you configure BGP as the PE-CE routing protocol, you must start with the per-VRF BGP configuration. Use the address-family ipv4 vrf vrf-name command in router configuration mode. Enter the address family configuration mode, and then define and activate the BGP neighbors. You also have to configure redistribution from all other per-VRF routing protocols into BGP.

Note You always have to configure a BGP address family for each VRF and configure route

redistribution into BGP for each VRF, even if you do not use BGP as the PE-CE routing

protocol.

Several BGP options have different default values when you configure the per-VRF BGP routing context, as follows:

BGP synchronization is disabled (default = enabled).

Autosummarization (automatic generation of classful networks out of subnetworks redistributed into BGP) is disabled (default = enabled). This is because the MPLS VPN backbone has to propagate customer subnetworks unchanged to facilitate transparent end-to-end routing between customer sites. Redistribution of internal BGP routes into Interior Gateway Protocol (IGP) is enabled (default = disabled).

Page 444: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-129

Note The common parameters defined in router configuration mode are inherited by all address

families defined for this routing process and can be overridden for each individual address

family.

address-family ipv4 To enter address family configuration mode for configuring routing sessions (such as BGP) that use standard IP version 4 (IPv4) address prefixes, use the address-family ipv4 command in router configuration mode. To disable address family configuration mode, use the no form of this command.

address-family ipv4 [multicast | unicast | vrf vrf-name]

no address-family ipv4 [multicast | unicast | vrf vrf-name]

This table describes the parameters for the address-family ipv4 command.

Syntax Description

Parameter Description

ł«´¬·˝ż­¬ (Optional) Specifies IPv4 multicast address prefixes

«˛·˝ż­¬ (Optional) Specifies IPv4 unicast address prefixes

Ş®ş Ş®şó˛żł» (Optional) Specifies the name of the VRF instance to associate with subsequent IPv4 address family configuration mode commands

Defaults

IPv4 address prefixes are not enabled. Unicast address prefixes are the default when IPv4 address prefixes are configured.

Command Modes Use this command in router configuration mode.

Page 445: Implementing cisco mpls

5-130 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-4

Configuring per-VRF BGP Routing Context (Cont.)

The PE router can be defined as a BGP neighbor.

Example: Configuring per-VRF BGP Routing Context

The figure shows that BGP is activated on the CE router and that the PE router is defined as a BGP neighbor. In addition, on the PE router the CE router is defined as a BGP neighbor and activated under the address-family ipv4 vrf Site_A command.

Page 446: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-131

What Are the Reasons for Limiting the Number of Routes in a VRF?

This topic explains the reasons for limiting the number of routes in a VRF.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-5

Limiting the Number of Routes in a VRF

• SPs offering MPLS VPN services are at risk of denial-of-service attacks similar to those aimed at SPs offering BGP connectivity:

– Any customer can generate any number of routes, using resources in the PE routers.

• Therefore, resources used by a single customer have to be limited.

• Cisco IOS software offers two solutions:

– It can limit the number of routes received from a BGP neighbor.

– It can limit the total number of routes in a VRF.

MPLS VPN architecture achieves a tight coupling between the customer and the service provider network, resulting in a number of advantages. The tight coupling might also result in a few disadvantages, because the service provider (SP) network is exposed to design and configuration errors in customer networks, and a number of new denial-of-service attacks based on routing protocol behavior.

To limit the effect of configuration errors and malicious user behavior, Cisco IOS software offers these two features that limit the number of routes and resource consumption that a VPN user can take advantage of at a PE router:

The BGP maximum-prefix feature limits the number of routes that an individual BGP peer can send.

The VRF route limit restricts the total number of routes in a VRF regardless of whether those routes are received from CE routers or from other PE routers via Multiprotocol Internal Border Gateway Protocol (MP-IBGP).

Page 447: Implementing cisco mpls

5-132 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Limiting the Number of Prefixes Received from a BGP Neighbor

This topic describes how to limit the number of prefixes received from a BGP neighbor.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-6

˛»·ą¸ľ±® ·°óżĽĽ®»­­ łż¨·ł«łó°®»ş·¨ łż¨·ł«ł Ŭ¸®»­¸±´ĽĂ Ĺ©ż®˛·˛ąó±˛´§Ă

᫬»®ř˝±˛ş·ąó®±«¬»®óżş÷ý

• Controls how many prefixes can be received from a neighbor

• Optional threshold parameter specifies the percentage where a warning message is logged (default is 75 percent)

• Optional warning-only keyword specifies the action on exceeding the maximum number (default is to drop peering)

Limiting the Number of Prefixes Received from a BGP Neighbor

neighbor maximum-prefix To control how many prefixes can be received from a neighbor, use the neighbor maximum-prefix command in router configuration mode. To disable this function, use the no form of this command.

neighbor {ip-address | peer-group-name} maximum-prefix maximum [threshold][warning-only]

no neighbor {ip-address | peer-group-name} maximum-prefix maximum [threshold][warning-only]

Page 448: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-133

This table describes the parameters for the neighbor maximum-prefix command.

Syntax Description

Parameter Description

·°óżĽĽ®»­­ IP address of the neighbor

°»»®óą®±«°ó˛żł» Name of a BGP peer group

łż¨·ł«ł Maximum number of prefixes allowed from this neighbor

¬¸®»­¸±´Ľ (Optional) Integer identifying at what percentage of the maximum the router starts to generate a warning message

The range is 1 to 100; the default is 75 (percent).

©ż®˛·˛ąó±˛´§ (Optional) Allows the router to generate a log message when the maximum is exceeded instead of terminating the peering.

Defaults Default is disabled; there is no limit on the number of prefixes.

Page 449: Implementing cisco mpls

5-134 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Limiting the Total Number of VRF Routes This topic describes how to limit VRF routes.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-7

Limiting the Total Number of VRF Routes

• The VRF maximum routes limit command limits the number of routes that are imported into a VRF:

– Routes coming from CE routers

– Routes coming from other PE routers (imported routes)

• The route limit is configured for each VRF.

• If the number of routes exceeds the route limit:

– A syslog message is generated.

– The Cisco IOS software can be configured to reject routes (optional).

The VRF route limit, contrary to the BGP maximum-prefix limit, limits the overall number of routes in a VRF regardless of their origin. Similar to the BGP maximum-prefix feature, the network operator might be warned via a syslog message when the number of routes exceeds a certain threshold. Additionally, you can configure Cisco IOS software to ignore new VRF routes when the total number of routes exceeds the maximum configured limit.

The route limit is configured for each individual VRF, providing maximum design and configuration flexibility.

Note The per-VRF limit could be used to implement add-on MPLS VPN services. A user desiring

a higher level of service might be willing to pay to be able to insert more VPN routes into the

network.

Page 450: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-135

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-8

łż¨·ł«ł ®±«¬»­ ´·ł·¬ Ą©ż®˛ó¬¸®»­¸±´Ľ ¤ ©ż®˛ó±˛´§Ł

᫬»®ř˝±˛ş·ąóŞ®ş÷ý

• This command configures the maximum number of routes accepted into a VRF:– The limit parameter is the route limit for the VRF.

– The warn-threshold parameter is the percentage value over which a warning message is sent to syslog.

– The warn-only option creates a syslog error message when the maximum number of routes exceeds the threshold.

• Syslog messages generated by this command are rate-limited.

Limiting the Total Number of VRF Routes (Cont.)

maximum routes To limit the maximum number of routes in a VRF to prevent a PE router from importing too many routes, use the maximum routes command in VRF configuration submode. To remove the limit on the maximum number of routes allowed, use the no form of this command.

maximum routes limit {warn-threshold | warn-only}

no maximum routes

This table describes the parameters for the maximum routes command.

Syntax Description

Parameter Description

´·ł·¬ This parameter specifies the maximum number of routes allowed in a VRF. You may select from 1 to 4,294,967,295 routes to be allowed in a VRF.

©ż®˛ó¬¸®»­¸±´Ľ This parameter rejects routes when the threshold limit is reached. The threshold limit is a percentage of the limit specified, from 1 to 100.

©ż®˛ó±˛´§ This parameter issues a syslog error message when the maximum number of routes allowed for a VRF exceeds the threshold. However, additional routes are still allowed.

Defaults This command has no default behavior or values.

Page 451: Implementing cisco mpls

5-136 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-9

Limiting the Total Number of VRF Routes (Cont.)

The network designer can decide to limit the number of routes in a VRF.

Example: Limiting the Total Number of VRF Routes

In this figure, the network designer has decided to limit the number of routes in a VRF to 4, with the warning threshold being set at 75 percent (or 3 routes).

When the first two routes are received and inserted into the VRF, the router accepts them. When the third route is received, a warning message is generated, and the message is repeated with the insertion of the fourth route.

Note The syslog messages are rate-limited to prevent indirect denial-of-service attacks on the

network management station.

When the PE router receives the fifth route, the maximum route limit is exceeded and the route is ignored. The network operator is notified through another syslog message.

Page 452: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-137

Identifying AS-Override Issues This topic identifies the issues encountered when a customer wants to reuse the same autonomous system (AS) number on several sites.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-10

The customer wants to reuse the same AS number on several sites:

• CE-BGP-A1 announces network 10.1.0.0/16 to PE-Site-X.

• The prefix announced by CE-BGP-A1 is propagated to PE-Site-Y as an internal route through MP-BGP.

• PE-Site-Y prepends AS 65115 to the AS path and propagates the prefix to CE-BGP-A2.

• CE-BGP-A2 drops the update because AS 65213 is already in the AS path.

AS-Override:The Issue

Here are the two ways that an MPLS VPN customer can deploy BGP as the routing protocol between PE and CE routers:

If the customer has used any other routing protocol in the traditional overlay VPN network before, there are no limitations on the numbering of the customer autonomous systems. Every site can be a separate AS.

If the customer has used BGP as the routing protocol before, there is a good chance that all the sites (or a subset of the sites) are using the same AS number.

BGP loop prevention rules disallow discontiguous autonomous systems. Two customer sites with the identical AS number cannot be linked by another AS. If such a setup happens (as in this example), the routing updates from one site are dropped when the other site receives them. There is no connectivity between the sites.

Page 453: Implementing cisco mpls

5-138 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-11

AS-Override:Implementation

• New AS path update procedures have been implemented to reuse the same AS number on all VPN sites.

• The procedures allow the use of private and public AS numbers.

• The same AS number may be used for all sites.

When you are migrating customers from traditional overlay VPNs to MPLS VPNs, it is not uncommon to encounter a customer topology that requires the same customer AS number to be used at more than one site. This requirement can cause issues with the loop prevention rules of BGP. However, the AS path update procedure in BGP has been modified to address this issue. The new AS path update procedure supports the use of one AS number at many sites (even between several overlapping VPNs) and does not rely on a distinction between private and public AS numbers.

Page 454: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-139

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-12

AS-Override:Implementation (Cont.)

• With AS-override configured, the AS path update procedure on the PE router is as follows:

– If the first AS number in the AS path is equal to the neighboring AS, it is replaced with the provider AS number.

– If the first AS number has multiple occurrences (because of AS path prepend), all occurrences are replaced with the provider AS number.

– After this operation, the provider AS number is prepended to the AS path.

The modified AS path update procedure is called AS-override, which is described here:

The procedure is used only if the first AS number in the AS path is equal to the AS number of the receiving BGP router.

In this case, all leading occurrences of the AS number of the receiving BGP router are replaced with the AS number of the sending BGP router. Occurrences farther down the AS path of the AS number of the receiving router are not replaced because they indicate a real routing information loop.

An extra copy of the sending router AS number is prepended to the AS path. The standard AS number prepending procedure occurs on every External Border Gateway Protocol (EBGP) update.

Page 455: Implementing cisco mpls

5-140 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-13

˛»·ą¸ľ±® ·°óżĽĽ®»­­ ż­ó±Ş»®®·Ľ»

᫬»®ř˝±˛ş·ąó®±«¬»®óżş÷ý

• This command configures the AS-override AS path update procedure for the specified neighbor.

• AS-override is configured for CE EBGP neighbors in the VRF address family of the BGP process.

AS-Override:Command

neighbor as-override To configure a PE router to override a site AS number with a provider AS number, use the neighbor as-override command in router configuration mode. To remove VPN version 4 (VPNv4) prefixes from a specified router, use the no form of this command.

neighbor ip-address as-override

no neighbor ip-address as-override

This table describes the parameters for the neighbor as-override command.

Syntax Description

Parameter Description

·°óżĽĽ®»­­ Specifies the router IP address to override with the AS number provided

Defaults This command has no default behavior or values.

Page 456: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-141

Example: AS-Override

In this figure, customer sites A and B use BGP to communicate with the MPLS VPN backbone. Both sites use AS 213. Site B would drop the update sent by site A without the AS-override mechanism.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-14

AS-Override:Example

PE-Site-Y replaces AS 65213 with AS 65115 in the AS path, prepends another copy of AS 65115 to the AS path, and propagates the prefix.

The AS-override mechanism, configured on the PE-Site-Y router, replaces the customer AS number (65213) with the provider AS number (65115) before sending the update to the customer site. An extra copy of the provider AS number is prepended to the AS path during the standard EBGP update process.

Page 457: Implementing cisco mpls

5-142 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: AS-Path Prepending

In this figure, the customer is using AS prepending to influence BGP path selection within the MPLS VPN backbone.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-15

PE-Site-Y replaces all occurrences of AS 65213 with AS 65115 in the AS path, prepends another copy of AS 65115 to the AS path, and propagates the prefix.

AS-Override:AS-Path Prepending

The PE router has to send a route with an AS path containing multiple copies of the customer AS number to the CE router. In this case, all the leading copies of the customer AS number are replaced with the provider AS number (resulting in two occurrences of the provider AS number in the example), and the third occurrence of the provider AS number is prepended to the BGP update before it is sent to the CE router.

Page 458: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-143

Identifying Allowas-in Issues This topic identifies the issues encountered when a customer site links two VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-16

Allowas-in: The Issue

• Customer site links two VPNs

• Not a usual setup (traffic between VPNs should not flow over the customer site)

• Sometimes used for enhanced security

In some security-conscious implementations, customer VPNs are linked by a customer router that performs security functions, such as access filtering or access logging.

Note This setup is not usual because it deviates from the basic goal of MPLS VPN—replacing the

hub-and-spoke routing of a traditional overlay VPN with optimum any-to-any routing.

Page 459: Implementing cisco mpls

5-144 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-17

Allowas-in:The Issue (Cont.)

• VPN perspective: VPN-A is connected to VPN-B via CE-AB.

• Physical topology: The CE-AB router is dual-connected to the PE routers.

• MPLS VPN perspective: The CE-AB router has two links into the P-network.

• BGP perspective shows issue: The CE-AB router has two connections to AS 65115.

The setup in which a customer router links two VPNs in an MPLS VPN backbone can be viewed from several different perspectives, as follows:

From the VPN perspective, a CE router links two VPNs.

From the physical perspective, the CE router is connected through two separate links (physical or logical interface) to one or two PE routers.

In MPLS VPN terms, the CE router has two links into the provider network (P-network).

There is no problem with the proposed customer setup if the setup is analyzed through these perspectives. All of the potential setups represent valid connectivity or routing options.

The issue appears when the setup is analyzed through the BGP perspective:

The CE (CE-AB) router has to propagate routes between two PE routers, which are both in the same AS.

Page 460: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-145

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-18

Allowas-in:The Issue (Cont.)

• PE-1 announces network 10.1.0.0/16 to CE-AB.

• CE-AB prepends its AS number to the AS path and propagatesthe prefix to PE-2.

• PE-2 drops the update because its AS number is already in the AS path.

• AS-override is needed on CE-AB, which may require a Cisco IOS software upgrade on the CE router.

The BGP loop prevention rules prevent a PE router from accepting the routing update sent by the CE router if that routing update already contains the AS number of the MPLS VPN backbone (which it will if the CE router is propagating routes between two VPNs).

One solution to this BGP routing problem is that AS-override has to be used on the CE router. This solution requires a recent version of Cisco IOS software (Cisco IOS Release 12.0T or later) on the CE router. The solution is not enforceable in every customer situation.

Page 461: Implementing cisco mpls

5-146 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: Using Allowas-in to Support Customer Site Linking Two VPNs

This example discusses using the allowas-in command on the PE router to support a customer site linking two VPNs. This example is similar to the situation in which two customer sites use the same AS number.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-19

Allowas-in:Implementation

The allowas-in BGP option disables the AS path check on the PE router:

• The number of occurrences of the PE router AS number is limited to suppress real routing loops.

• The limit has to be configured.

• The PE router will reject the update only if its AS number appears in the AS path more often than the configured limit.

Networks may need to support topologies in which a CE router with no AS-override support links two VPNs. A specific need exists to modify the BGP loop prevention mechanism on the PE routers. The allowas-in feature supports situations in which the PE router receives routes with its own AS number already in the AS path.

With this feature configured on a BGP neighbor of the PE router, the PE router would not drop incoming BGP updates with its AS number in the AS path if the updates are received from that neighbor. To prevent real BGP routing information loops, the number of occurrences of the MPLS VPN backbone AS number can be limited so that incoming updates that exceed the limit can be dropped.

Page 462: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-147

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-20

˛»·ą¸ľ±® ż´´±©ż­ó·˛ ˛«łľ»®

᫬»®ř˝±˛ş·ąó®±«¬»®÷ý

• This command disables the traditional BGP ASpath check.

• An incoming update is rejected only if the AS number of the PE router appears in the AS pathmore often than the configured limit.

Allowas-in:Command

neighbor allowas-in To configure PE routers to allow readvertisement of all prefixes containing duplicate AS numbers, use the neighbor allowas-in command in router configuration mode. To disable readvertisement of the AS number of a PE router, use the no form of this command.

neighbor allowas-in number

no neighbor allowas-in number

This table describes the parameters for the neighbor allowas-in command.

Syntax Description

Parameter Description

˛«łľ»® This parameter specifies the number of times to allow advertisement of the AS number of a PE router. Valid values are from 1 to 10 times.

Defaults This command has no default behavior or values.

Page 463: Implementing cisco mpls

5-148 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Implementing SOO for Loop Prevention This topic describes how to implement Site of Origin (SOO) for loop prevention.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-21

AS path-based BGP loop prevention is bypassed with theAS-override and allowas-in features.

Implementing SOO for Loop Prevention

Most aspects of BGP loop prevention are bypassed when either the AS-override feature or the allowas-in feature is used. Routing information loops can still be detected by manually counting occurrences of an AS number in the AS path in an end-to-end BGP routing scenario then ensuring that the number field in the neighbor allowas-in command is set low enough to prevent loops.

The ability to still detect loops can present a particular problem when BGP is mixed with other PE-CE routing protocols. The SOO extended BGP community can be used as an additional loop prevention mechanism in these scenarios.

Note SOO and any other loop prevention mechanisms are needed only for customer networks

with multihomed sites. Loops can never occur in customer networks that have only stub

sites.

Page 464: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-149

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-22

• The SOO attribute (extended BGP community) can be used to prevent loops in these scenarios.

• The SOO attribute is needed only for multihomed sites.

• When EBGP is run between PE and CE routers, the SOO attribute is configured through a route-mapcommand.

• For other routing protocols, the SOO attribute can be applied to routes learned through a particular VRF interface during the redistribution into BGP.

Implementing SOO for Loop Prevention (Cont.)

Here are the two ways to set the SOO attribute on a BGP route:

For routes received from BGP-speaking CE routers, the SOO attribute is configured by the incoming route map on the PE router.

For all other routes, a route map setting the SOO attribute is applied to the incoming interface. The SOO attribute, as set by the route map, is attached to the BGP route when an IGP route received through that interface is redistributed into BGP.

Outgoing filters based on the SOO attribute also depend on the routing protocol used, as described here:

Where EBGP is used as the PE-CE routing protocol, outbound route maps can be used on the PE router to deny routes matching particular SOO values.

For all other routing protocols, filtering is performed on the basis of the SOO route map configured on the outgoing interface before the update is sent across that interface to the CE router.

Page 465: Implementing cisco mpls

5-150 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-23

®±«¬»ółż° ˛żł» °»®ł·¬ ­»Żłż¬˝¸ ˝±˛Ľ·¬·±˛­­»¬ »¨¬˝±łł«˛·¬§ ­±± »¨¬»˛Ľ»Ľó˝±łł«˛·¬§óŞż´«»

᫬»®ř˝±˛ş·ą÷ý

• Creates a route map that sets the SOO attribute

˛»·ą¸ľ±® ·°óżĽĽ®»­­ ®±«¬»ółż° ˛żł» ·˛

᫬»®ř˝±˛ş·ąó®±«¬»®óżş÷ý

• Applies an inbound route map to the CE EBGP neighbor

Inbound EBGP Update

Implementing SOO for Loop Prevention (Cont.)

set extcommunity To set the extended communities attribute, use the set extcommunity command in route map configuration mode. To delete the entry, use the no form of this command.

set extcommunity {rt extended-community-value [additive] | soo extended-community-value}

no set extcommunity

set extcommunity extcommunity-type community-number [additive]

no set extcommunity extcommunity-type community-number [additive]

Page 466: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-151

This table describes the parameters for the set extcommunity command.

Syntax Description

Parameter Description

®¬ Specifies the route target (RT) extended community attribute

­±± Specifies the SOO extended community attribute

»¨¬»˛Ľ»Ľó˝±łł«˛·¬§óŞż´«»

Specifies the value to be set

The value can be one of these combinations:

autonomous-system-number:network-number

ip-address:network-number

The colon is used to separate the AS number from the network number or the IP address from the network number.

żĽĽ·¬·Ş» (Optional) Adds space after the closing parenthesis; adds the extended community to the already existing extended communities

Defaults

No BGP extended community attributes are set by the route map.

neighbor route-map To apply a route map to incoming or outgoing routes, use the neighbor route-map command in address family or router configuration mode. To remove a route map, use the no form of this command.

neighbor {ip-address | peer-group-name} route-map map-name {in | out}

no neighbor {ip-address | peer-group-name} route-map map-name {in | out}

This table describes the parameters for the neighbor route-map command.

Syntax Description

Parameter Description

·°óżĽĽ®»­­ IP address of the neighbor

°»»®óą®±«°ó˛żł» Name of a BGP or Multiprotocol Border Gateway Protocol (MP-BGP) peer group

łż°ó˛żł» Name of a route map

·˛ Applies route map to incoming routes

±«¬ Applies route map to outgoing routes

Page 467: Implementing cisco mpls

5-152 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-24

·° Ş®ş ­·¬»łż° ®±«¬»ółż°ó˛żł»

᫬»®ř˝±˛ş·ąó·ş÷ý

• Applies a route map that sets the SOO extended community attribute to inbound routing updates received from this interface

Other Inbound Routing Updates

Implementing SOO for Loop Prevention (Cont.)

ip vrf sitemap To set the SOO extended community attribute, use the ip vrf sitemap command in interface configuration mode. To delete the entry, use the no form of this command.

ip vrf sitemap route-map-name

no ip vrf sitemap route-map-name

This table describes the parameters for the ip vrf sitemap command.

Syntax Description

Parameter Description

®±«¬»ółż°ó˛żł» Sets the name of the route map to be used

Defaults

No route map is used to set the SOO extended community attribute.

Note An example configuring SOO for EIGRP PE-CE loop prevention was discussed in the

“Configuring EIGRP PE-CE Routing” topic of the “Configuring Small-Scale Routing Protocols

Between PE and CE Routers” lesson.

Page 468: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-153

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-25

·° »¨¬˝±łł«˛·¬§ó´·­¬ ˛«łľ»® °»®ł·¬ ­±± Şż´«»˙®±«¬»ółż° ˛żł» Ľ»˛§ ­»Żłż¬˝¸ »¨¬˝±łł«˛·¬§ ˛«łľ»®

˙®±«¬»ółż° ˛żł» °»®ł·¬ çççç

᫬»®ř˝±˛ş·ą÷ý

• Defines a route map that discards routes with the desired SOO value

˛»·ą¸ľ±® ·°óżĽĽ®»­­ ®±«¬»ółż° ˛żł» ±«¬

᫬»®ř˝±˛ş·ąó®±«¬»®óżş÷ý

• Applies the route map to outbound updates sent to the EBGP CE neighbor

Implementing SOO for Loop Prevention (Cont.)

In this example, a route map matching a specific SOO value was defined using the ipextcommunity-list command to establish a SOO filter. The route-map command was used to define the route map based on the filter.

The newly defined route map is then applied to a BGP neighbor (CE router) on the PE router.

Page 469: Implementing cisco mpls

5-154 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-26

Summary

• Use the address-family ipv4 vrf vrf-name command in the BGP routing process to configure a per-VRF BGP routing context.

• SPs offering MPLS VPN services are at risk of denial-of-service attacks. Limiting VRF tables is one method to prevent such attacks.

• Use the neighbor maximum-prefix command to limit the number of prefixes received from a BGP neighbor.

• Use the maximum routes command to limit the total number of VRF routes.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-27

• BGP loop detection prevents customers from reusing their AS number. The neighbor ip-addressas-overide command prevents this issue by replacing the customer AS number with the ISP AS number.

• By default, a customer site cannot link two VPN sites of the same AS number because of BGP loop detection. The neighbor allowas-in number commanddisables the BGP path check and permits routing updates.

• The SOO extended BGP community is used as a loop prevention mechanism for multihomed customer sites.

Summary (Cont.)

Page 470: Implementing cisco mpls

Lesson 8

Troubleshooting MPLS VPNs

OverviewThis lesson explains the preliminary steps for troubleshooting a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN). The lesson also looks at routing information flow troubleshooting and VPN data flow troubleshooting.

It is important to be able to determine what steps you should take when trying to solve a problem with your MPLS VPN network. This lesson looks at how to go about correcting MPLS VPN network problems.

ObjectivesUpon completing this lesson, you will be able to describe how to troubleshoot MPLS VPN operations. This ability includes being able to meet these objectives:

Identify the preliminary steps in MPLS VPN troubleshooting

Identify the issues that you should consider when verifying the routing information flow in an MPLS VPN

Describe the process used to validate CE-to-PE routing information flow

Describe the process used to validate PE-to-PE routing information flow

Describe the process used to validate PE-to-CE routing information flow

Identify the issues that you should consider when verifying the data flow in an MPLS VPN

Describe how to validate CEF status

Describe how to validate the end-to-end LSP

Describe how to validate the LFIB status

Page 471: Implementing cisco mpls

5-156 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Identifying Preliminary Steps in MPLS VPN Troubleshooting

This topic identifies the preliminary steps in MPLS VPN troubleshooting.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-3

Preliminary Steps in MPLS VPN Troubleshooting

Perform basic MPLS troubleshooting:

• Is CEF enabled?

• Are labels for IGP routes generated and propagated?

• Are large labeled packets propagated across the MPLS backbone (maximum transmission unit issues)?

Before you start in-depth MPLS VPN troubleshooting, you should ask the following standard MPLS troubleshooting questions:

Is Cisco Express Forwarding (CEF) enabled on all routers in the transit path between the provider edge (PE) routers?

Are labels for Border Gateway Protocol (BGP) next hops generated and propagated?

Are there any maximum transmission unit (MTU) issues in the transit path (for example, LAN switches not supporting a jumbo Ethernet frame)?

MPLS VPN troubleshooting consists of these two major steps:

Verifying the routing information flow using the checks outlined in the figure

Verifying the data flow, or packet forwarding

Page 472: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-157

Verifying the Routing Information Flow This topic identifies the issues that you should consider when verifying the routing information flow in an MPLS VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-4

Verifying the Routing Information Flow

Verify the routing information flow:

• Are CE routes received by a PE router?

• Are routes redistributed into MP-BGP with proper extended communities?

• Are VPNv4 routes propagated to other PE routers?

• Is the BGP route selection process working correctly?

• Are VPNv4 routes inserted into VRFs on other PE routers?

• Are VPNv4 routes redistributed from BGP into the PE-CE routing protocol?

• Are IPv4 routes propagated to other CE routers?

Verification of the routing information flow should be done systematically, starting at the ingress customer edge (CE) router and moving to the egress CE router.

Page 473: Implementing cisco mpls

5-158 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Validating CE-to-PE Routing Information Flow This topic describes the process that is used to validate CE-to-PE routing information flow.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-5

Are CE routes received by the PE router?

• Verify with the show ip route vrf vrf-name command on PE-1.

• Perform traditional routing protocol troubleshooting if needed.

Validating CE-to-PE Routing Information Flow

Troubleshooting routing information flow requires the verification of end-to-end routing information propagation between CE routers. The first step is to check the routing information exchange from CE routers to PE routers. Use the show ip route vrf vrf-name command to verify that the PE router receives customer routes from the CE router. Use traditional routing protocol troubleshooting if needed. BGP-specific troubleshooting is described in the individual modules of the Configuring BGP on Cisco Routers (BGP) course.

Page 474: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-159

Validating PE-to-PE Routing Information Flow This topic describes the process that is used to validate PE-to-PE routing information flow.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-6

Are routes redistributed into MP-BGP with proper extended communities?

• Verify with the show ip bgp vpnv4 vrf vrf-name ip-prefix commandon PE-1.

• Troubleshoot with debug ip bgp commands.

Validating PE-to-PE Routing Information Flow

The CE routes received by the PE router need to be redistributed into Multiprotocol BGP (MP-BGP); otherwise, the routes will not get propagated to other PE routers. Common configuration mistakes in this step include the following:

Failing to configure redistribution between the PE-CE routing protocol and the per-virtual routing and forwarding (VRF) routing context of the BGP

Using a route map on redistribution that filters CE routes

Proper redistribution of CE routes into a per-VRF instance of BGP can be verified with the show ip bgp vpnv4 vrf vrf-name command. The route distinguisher (RD) prepended to the IPv4 prefix and the route targets (RTs) attached to the CE route can be verified with the showip bgp vpnv4 vrf vrf-name ip-prefix command.

Page 475: Implementing cisco mpls

5-160 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-7

Are VPNv4 routes propagated to other PE routers?

• Verify with the show ip bgp vpnv4 all ip-prefix/length command.

• Troubleshoot PE-to-PE connectivity with traditional BGP troubleshooting tools.

Validating PE-to-PE Routing Information Flow (Cont.)

The CE routes redistributed into MP-BGP need to be propagated to other PE routers. Verify proper route propagation with the show ip bgp vpnv4 all ip-prefix command on the remote PE router.

Note Routes sent by the originating PE router might not be received by a remote PE router

because of automatic RT-based filters installed on the remote PE router.

Automatic route filters are based on RTs. Verify that the RTs attached to the CE route in the originating PE router match at least one of the RTs configured as import RTs in the VRF on the receiving PE router.

Page 476: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-161

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-8

Is the BGP route selection process working correctly on PE-2?

• Verify with the vrf-name ip-prefix command.

• Change local preference or weight settings if needed.

• Do not change MED if you are using IGP-BGP redistribution on PE-2.

Validating PE-to-PE Routing Information Flow (Cont.)

In complex environments with multihomed customer sites, the BGP route selection process might affect proper MPLS VPN operation. Use standard BGP route selection tools (weights or local preference) to influence BGP route selection. The multi-exit discriminator (MED) attribute should not be changed inside the MPLS VPN backbone if you plan to use two-way route redistribution between the PE-CE routing protocol and BGP.

Refer to the BGP course for more information on BGP weights, local preference, and the MED attribute.

Page 477: Implementing cisco mpls

5-162 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-9

Are VPNv4 routes inserted into VRFs on PE-2?

• Verify with the show ip route vrf command.

• Troubleshoot with the show ip bgp ip-prefix and show ip vrf detailcommand.

• Perform additional BGP troubleshooting if needed.

Validating PE-to-PE Routing Information Flow (Cont.)

The VPN version 4 (VPNv4) routes received by the PE router have to be inserted into the proper VRF. This insertion can be verified with the show ip route vrf command. Common configuration mistakes in this step include the following:

The wrong import RTs are configured in the VRF.

The route map configured as the import route map is rejecting the VPNv4 routes. Refer to the “Using Advanced VRF Import and Export Features” lesson in the “Complex MPLS VPNs” module for more information on import route maps.

The validity of the import RTs can be verified with the show ip bgp vpnv4 all ip-prefixcommand, which displays the RTs attached to a VPNv4 route. You can also verify the validity of the import RTs with the show ip vrf detail command, which lists the import RTs for a VRF. At least one RT attached to the VPNv4 route needs to match at least one RT in the VRF.

Note Be patient when troubleshooting this step. The import of VPNv4 routes into VRFs is not

immediate and can take more than a minute in the worst circumstances.

Page 478: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-163

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-10

Are VPNv4 routes redistributed from BGP into the PE-CE routing protocol?

• Verify redistribution configuration—is the IGP metric specified?

• Perform traditional routing protocol troubleshooting.

Validating PE-to-PE Routing Information Flow (Cont.)

Finally, the BGP routes received via MP-BGP and inserted into the VRF need to be redistributed into the PE-CE routing protocol. A number of common redistribution mistakes can occur here, starting with missing redistribution metrics.

Refer to the Building Scalable Cisco Internetworks (BSCI) course for more information on route redistribution troubleshooting.

Page 479: Implementing cisco mpls

5-164 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Validating PE-to-CE Routing Information Flow This topic describes the process used to validate PE-to-CE routing information flow.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-11

Are VPNv4 routes propagated to other CE routers?

• Verify with the show ip route command on CE-Spoke.

• Alternatively, do CE-Spokes have a default route toward PE-2?

• Perform traditional routing protocol troubleshooting if needed.

Validating PE-to-CE Routing Information Flow

Last but not least, the routes redistributed into the PE-CE routing protocol have to be propagated to CE routers. You may also configure the CE routers with a default route toward the PE routers. Use standard routing protocol troubleshooting techniques in this step.

Note When using a default route on the CE routers, verify that the CE routers use classless

routing configured with the ip classless command.

Page 480: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-165

Identifying the Issues When Verifying the Data Flow

This topic identifies the issues that you should consider when verifying the data flow in an MPLS VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-12

Verifying the Data Flow

Verify proper data flow:

• Is CEF enabled on the ingress PE router interface?

• Is the CEF entry correct on the ingress PE router?

• Is there an end-to-end label switched path tunnel (LSP tunnel) between PE routers?

• Is the LFIB entry on the egress PE router correct?

After you have verified proper route exchange, start MPLS VPN data flow troubleshooting using the checks listed in the next figures.

Page 481: Implementing cisco mpls

5-166 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Validating CEF Status This topic describes how to validate CEF status.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-13

Is CEF enabled on the ingress PE router interface?

• Verify with the show cef interface command.

• MPLS VPN needs CEF enabled on the ingress PE router interface for proper operation.

• CEF might become disabled because of additional features deployed on the interface.

Validating CEF Status

One of the most common configuration mistakes related to data flow is the failure to enable CEF on the ingress PE router interface. The presence of CEF can be verified with the show cef interface command. CEF is the only switching method that can perform per-VRF lookup and thus support MPLS VPN architecture.

Assuming that CEF is enabled on the router, here are the three common CEF configuration mistakes:

CEF is manually disabled on an interface.

The interface is using an encapsulation method that is not supported by CEF, such as X.25 or Multilink PPP (MLP) with interleaving.

Another feature has been configured on the interface that disables CEF (for example, IP precedence accounting).

Page 482: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-167

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-14

᫬»®ý­¸±© ˝»ş ·˛¬»®şż˝» ­»®·ż´ ďńđňîđ

Í»®·ż´ďńđňîđ ·­ «° ř·şÁ˛«łľ»® ďč÷

ײ¬»®˛»¬ żĽĽ®»­­ ·­ ďëđňďňíďňíéńíđ

×ÝÓĐ ®»Ľ·®»˝¬­ ż®» ż´©ż§­ ­»˛¬

Đ»® °ż˝µ»¬ ´±żĽľż´ż˛˝·˛ą ·­ Ľ·­żľ´»Ľ

×Đ «˛·˝ż­¬ ÎĐÚ ˝¸»˝µ ·­ Ľ·­żľ´»Ľ

ײľ±«˛Ľ ż˝˝»­­ ´·­¬ ·­ ˛±¬ ­»¬

Ń«¬ľ±«˛Ľ ż˝˝»­­ ´·­¬ ·­ ˛±¬ ­»¬

×Đ °±´·˝§ ®±«¬·˛ą ·­ Ľ·­żľ´»Ľ

ײ¬»®şż˝» ·­ łż®µ»Ľ ż­ °±·˛¬ ¬± °±·˛¬ ·˛¬»®şż˝»

Řż®Ľ©ż®» ·Ľľ ·­ Í»®·ż´ďńđ

Úż­¬ ­©·¬˝¸·˛ą ¬§°» ëô ·˛¬»®şż˝» ¬§°» ęě

×Đ ÝŰÚ ­©·¬˝¸·˛ą »˛żľ´»Ľ

×Đ ÝŰÚ ĘĐŇ Úż­¬ ­©·¬˝¸·˛ą ¬«®ľ± Ş»˝¬±®

ĘĐŇ Ú±®©ż®Ľ·˛ą ¬żľ´» ţÍ·¬»ßîţ

ײ°«¬ şż­¬ ş´żą­ đ¨ďđđđô Ń«¬°«¬ şż­¬ ş´żą­ đ¨đ

·ş·˛Ľ»¨ íří÷

Í´±¬ ď Í´±¬ «˛·¬ đ ĘÝ óď

Ě®ż˛­ł·¬ ´·ł·¬ ż˝˝«ł«´ż¬±® đ¨đ řđ¨đ÷

×Đ ÓĚË ďëđđ

Validating CEF Status:show cef interface

show cef interface To display detailed CEF information for all interfaces, use the show cef interface command in EXEC mode.

show cef interface type number [statistics][detail].

This table describes the parameters for the show cef interface command.

Syntax Description

Parameter Description

¬§°» ˛«łľ»® Displays interface type and number for CEF information

­¬ż¬·­¬·˝­ (Optional) Displays switching statistics for the line card

Ľ»¬ż·´ (Optional) Displays detailed CEF information for the specified interface type and number

Usage Guidelines This command is available on routers that have route processor (RP) cards and line cards.

The detail keyword displays more CEF information for the specified interface. You can use this command to show the CEF state on an individual interface.

Page 483: Implementing cisco mpls

5-168 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

This table describes the fields shown in the output.

Syntax Description

Parameter Description

·˛¬»®şż˝» ¬§°» ˛«łľ»® ·­ Ą«° ¤ Ľ±©˛Ł

Indicates status of the interface

ײ¬»®˛»¬ żĽĽ®»­­ Internet address of the interface

×ÝÓĐ ®»Ľ·®»˝¬­ ż®» Ąż´©ż§­ ­»˛¬ ¤ ˛»Ş»® ­»˛¬Ł

Indicates how packet forwarding is configured

Đ»®ó°ż˝µ»¬ ´±żĽ ľż´ż˛˝·˛ą Status of load balancing in use on the interface (enabled or disabled)

×Đ «˛·˝ż­¬ ÎĐÚ ˝¸»˝µ Indicates status of IP unicast Reverse Path Forwarding (RPF) check on the interface

ײľ±«˛Ľ ż˝˝»­­ ´·­¬ Ąý ¤ ұ¬ ­»¬Ł

Number of inbound access lists defined for the interface

Ń«¬ľ±«˛Ľ ż˝˝»­­ ´·­¬ Number of outbound access lists defined for the interface

×Đ °±´·˝§ ®±«¬·˛ą Indicates the status of IP policy routing on the interface

Řż®Ľ©ż®» ·Ľľ ·­ ¬§°» ˛«łľ»® Interface type and number configured

Úż­¬ ­©·¬˝¸·˛ą ¬§°» Indicates switching mode in use; used for troubleshooting

×Đ ÝŰÚ ­©·¬˝¸·˛ą Ą»˛żľ´»Ľ ¤ Ľ·­żľ´»ĽŁ

Indicates the switching path used

Í´±¬ ˛ Í´±¬ «˛·¬ ˛ Slot number

Řż®Ľ©ż®» ¬®ż˛­ł·¬ Ż«»«» Indicates the number of packets in the transmit queue

Ě®ż˛­ł·¬ ´·ł·¬ ż˝˝«ł«´ż¬±® Indicates the maximum number of packets allowed in the transmit queue

×Đ ÓĚË Value of the MTU size set on the interface

Page 484: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-169

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-15

Is the CEF entry correct on the ingress PE router?

• Display the CEF entry with the show ip cef vrf vrf-name ip-prefix/length detail command.

• Verify the label stack in the CEF entry.

Validating CEF Status

If CEF switching is enabled on the ingress interface, you can verify the validity of the CEF entry and the associated label stack with the show ip cef vrf vrf-name ip-prefix detailcommand. The top label in the stack should correspond to the BGP next-hop label as displayed by the show mpls forwarding-table command on the ingress router. The second label in the stack should correspond to the label allocated by the egress router. You can verify this by using the show mpls forwarding-table command on the egress router.

Page 485: Implementing cisco mpls

5-170 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Validating the End-to-End LSP This topic describes how to validate the end-to-end label-switched path (LSP).

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-16

Is there an end-to-end LSP tunnel between PE routers?• Check summarization issues—BGP next hop should be reachable as

host route.

• Quick check—if TTL propagation is disabled, the trace from PE-2 to PE-1 should contain only one hop.

• If needed, check LFIB values hop by hop.

• Check for MTU issues on the path—MPLS VPN requires a larger label header than pure MPLS.

Validating the End-to-End Label Switched Path

If CEF is enabled on the ingress interface and the CEF entry contains proper labels, the data flow problem might lie inside the MPLS core. Two common mistakes include summarization of BGP next hops inside the core Interior Gateway Protocol (IGP) and maximum transmission unit (MTU) issues.

The quickest way to diagnose summarization problems is to disable IP time-to-live (TTL) propagation into the MPLS label header using the no mpls ip ttl-propagate configuration command on the P and PE routers. The traceroute command from the ingress PE router toward the BGP next hop should display no intermediate hops when TTL propagation is disabled. If intermediate hops are displayed, the LSP tunnel between PE routers is broken at those hops and the VPN traffic cannot flow.

Page 486: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-171

Validating the LFIB Status This topic describes how to validate the label forwarding information base (LFIB) status.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-17

Is the LFIB entry on the egress PE router correct?

• Find out the second label in the label stack on PE-2 with the show ip cef vrf vrf-name ip-prefix detail command.

• Verify correctness of LFIB entry on PE-1 with the show mpls forwarding vrf vrf-name value detail command.

Validating the LFIB Status

As a last troubleshooting measure (usually not needed), you can verify the contents of the LFIB on the egress PE router and compare them with the second label in the label stack on the ingress PE router. A mismatch indicates an internal Cisco IOS software error that you will need to report to the Cisco Technical Assistance Center (TAC).

Page 487: Implementing cisco mpls

5-172 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-18

Summary

• Divide MPLS troubleshooting into two main steps:

– Verify routing information flow.

– Verify proper data flow.

• Validate CE-to-PE routing information flow by checking the routing information exchange from CE routers to PE routers.

• Use the show ip bgp vpnv4 vrf vrf-name ip-prefixcommand to validate PE-to-PE routing information flow.

• Verify that routes are redistributed back into the CE routing protocol on the PE route and propagated toward CE routers to validate PE-to-CE routing information flow.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-19

Summary (Cont.)

• Verify data flow systematically, starting at the ingress CE router and moving to the egress CE router.

• Verify that CEF and LSP switching are operational.

• Use the show cef interface command to verify the CEF status.

• When validating the end-to-end LSP, verify that there is an end-to-end LSP tunnel between PE routers.

• To validate the LFIB status, review the contents of the LFIB on the egress PE router in comparison to the second label in the label stack on the ingress PE router.

Page 488: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-173

Module Summary This topic summarizes the key points that were discussed in this module.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-1

Module Summary

• The VRF table is a virtual routing and forwarding instance separating sites with the same connectivity requirements.

• Configuring VRF tables requires defining the VRF name, RD, and import and export RTs.

• MP-BGP configuration must define the neighbors, define the address family, for VPNv4 routing, and finally activate the neighbors.

• RIPv2 and EIGRP routing for PE to CE requires use of the address-family ipv4 command to define the routing context. Redistribution is also required between IGP and BGP.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5-2

Module Summary (Cont.)

• Monitoring MPLS VPN operations includes monitoring MP-BGP neighbor status, VRF routing process, and CEF and LFIB status.

• The MPLS VPN routing model implements MP-BGP as the superbackbone for OSPF. PE-to-CE OSPF routing is defined as a new routing process via the VRF name.

• The MPLS VPN routing model implements BGP routing between PE and CE as BGP instances using the command address-family ipv4.

• MPLS VPN troubleshooting uses a systematic process starting at the ingress PE router and moving to the egress PE router using a variety of show commands.

Page 489: Implementing cisco mpls

5-174 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

An MPLS VPN implementation involves virtual routing and forwarding (VRF) tables, the interaction between customer-to-provider routing protocols, and Multiprotocol Border Gateway Protocol (MP-BGP) in the service provider backbone.

ReferencesFor additional information, refer to these resources:

Access Cisco.com for additional information about VPNs.

Cisco Systems, Inc. The “BGP Filtering and Route Selection” module in the Configuring BGP on Cisco Routers (BGP) course.

Cisco Systems, Inc. The “Advanced BGP Configuration” module in the BGP course.

Cisco Systems, Inc. Building Scalable Cisco Internetworks (BSCI) course.

Page 490: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-175

Module Self-Check Use the questions here to review what you learned in this module. The correct answers and solutions are found in the Module Self-Check Answer Key.

Q1) In an MPLS VPN implementation, what is a VRF? (Source: Using MPLS VPN

Mechanisms of Cisco IOS Platforms)

A) the routing and forwarding instance for all sites belonging to a single customer B) the routing and forwarding instance for all sites belonging to a single customer

locationC) the routing and forwarding instance for all sites using a common routing

protocolD) the routing and forwarding instance for a set of sites with identical connectivity

requirements

Q2) Why are VRFs used to establish separate routing protocol contexts? (Source: Using

MPLS VPN Mechanisms of Cisco IOS Platforms)

______________________________________________________________________

Q3) Which two protocols are VPN-aware? (Choose two.) (Source: Using MPLS VPN

Mechanisms of Cisco IOS Platforms)

A) RIPv2B) IS-ISC) ODRD) EIGRP

Q4) VRFs are assigned to an interface. (Source: Using MPLS VPN Mechanisms of Cisco

IOS Platforms)

A) trueB) false

Q5) A PE router is supporting site A for a VPN on one interface using RIP as the routing

protocol. Site B belongs to the same VPN and is being supported on a second interface

using EBGP as the routing protocol. Why is it necessary to redistribute the RIP-learned

route into the per-VRF instance of the BGP process? (Source: Using MPLS VPN

Mechanisms of Cisco IOS Platforms)

A) to allow site A and B to communicate with each other B) to allow the RIP route to be propagated to the VRF routing tables C) to allow the RIP routes to be propagated to the local EBGP session D) to allow the RIP routes to be propagated through the backbone MP-BGP

process to other PE routers

Page 491: Implementing cisco mpls

5-176 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q6) How are VPNv4 routers propagated to a RIP-speaking CE router? (Source: Using

MPLS VPN Mechanisms of Cisco IOS Platforms)

______________________________________________________________________

______________________________________________________________________

Q7) Which command do you use to create a VRF named VPNA? (Source: Configuring

VRF Tables)

A) ip vrf VPNA B) ip rt vrf VPNA C) ip rd vrf VPNS D) ip vrf forwarding VPNA

Q8) Which two VRF parameters specify the extended community attribute used in VPNv4

BGP? (Choose two.) (Source: Configuring VRF Tables)

A) rd route-distinguisher B) route-target export RT C) route-target import RT D) ip vrf forwarding vrf-name

Q9) Which command do you use to associate interface e0/0 with a VRF named VPNA?

(Source: Configuring VRF Tables)

A) ip vrf VPNA B) ip vrf VPNA int e0/0 C) ip vrf forwarding VPNA D) ip vrf VPNA forwarding e0/0

Q10) What happens to the existing IP address of an interface when you associate the

interface with a VRF? (Source: Configuring VRF Tables)

A) It will remain unchanged. B) It will be removed from the interface. C) It will be changed to the loopback 0 address. D) It will be moved under the VRF configuration.

Q11) You have created a configuration that defines three import route targets (65001:01,

65002:02, and 65003:03) for a VRF. A route update has three RTs (65003:03,

65004:04, and 65005:05) attached to it. How will this update be processed and why?

(Source: Configuring VRF Tables)

A) The update will be accepted by the VRF because it matches the import RD of 03.

B) The update will be discarded by the VRF because it does not match all of the RTs in the import list.

C) The update will be accepted by the VRF because it matches at least one of the RTs in the import list.

D) The update will be discarded by the VRF because it does not match all of the RDs in the import list.

Page 492: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-177

Q12) In which two ways does the MPLS VPN architecture use the BGP routing protocol?

(Source: Configuring an MP-BGP Session Between PE Routers)

______________________________________________________________________

______________________________________________________________________

Q13) What is a BGP address family? (Source: Configuring an MP-BGP Session Between PE

Routers)

______________________________________________________________________

______________________________________________________________________

Q14) What are the two types of BGP address families that can be configured on a PE router?

(Source: Configuring an MP-BGP Session Between PE Routers)

______________________________________________________________________

______________________________________________________________________

Q15) Which mandatory parameters do you have to configure on an MP-BGP neighbor?

(Source: Configuring an MP-BGP Session Between PE Routers)

______________________________________________________________________

______________________________________________________________________

Q16) Why is it necessary to enable extended BGP communities when you are supporting

MPLS VPNs? (Source: Configuring an MP-BGP Session Between PE Routers)

______________________________________________________________________

Q17) Why would you want to disable propagation of IPv4 routing updates between MP-BGP

neighbors? (Source: Configuring an MP-BGP Session Between PE Routers)

______________________________________________________________________

Page 493: Implementing cisco mpls

5-178 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q18) How do you configure the routing context in RIP? (Source: Configuring Small-Scale

Routing Protocols Between PE and CE Routers)

______________________________________________________________________

Q19) How do you propagate static VRF routes between PE routers? (Source: Configuring

Small-Scale Routing Protocols Between PE and CE Routers)

______________________________________________________________________

Q20) How would you configure redistribution to propagate customer RIP routing updates

across the MPLS VPN backbone? (Source: Configuring Small-Scale Routing Protocols

Between PE and CE Routers)

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

Q21) Which three commands do you use to display all configured VRFs on the router?

(Source: Monitoring MPLS VPN Operations)

______________________________________________________________________

______________________________________________________________________

Q22) How do you verify the contents of a VRF routing table? (Source: Monitoring MPLS

VPN Operations)

______________________________________________________________________

______________________________________________________________________

Q23) Why is the BGP protocol always running in every VRF, and how would you display

the BGP parameter related to a VRF? (Source: Monitoring MPLS VPN Operations)

______________________________________________________________________

Page 494: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-179

Q24) How do you verify that a session has been established between two VPNv4 neighbors?

(Source: Monitoring MPLS VPN Operations)

______________________________________________________________________

______________________________________________________________________

Q25) How do you verify the contents of a BGP VPNv4 routing table? (Source: Monitoring

MPLS VPN Operations)

______________________________________________________________________

Q26) Which three commands can be used to display per-VRF FIB and LFIB information?

(Source: Monitoring MPLS VPN Operations)

______________________________________________________________________

______________________________________________________________________

Q27) Which command can be used to display labels assigned to local or remote VRF routes

by the local or remote PE router? (Source: Monitoring MPLS VPN Operations)

Q28) Which command do you use to perform each of the following traceroutes? (Source:

Monitoring MPLS VPN Operations)

ingress CE to egress PE:

ingress CE to egress CE:

ingress PE to egress PE:

ingress PE to egress CE:

Q29) Why is the OSPF superbackbone needed in MPLS VPN environments? (Source:

Configuring OSPF as the Routing Protocol Between PE and CE Routers)

______________________________________________________________________

Page 495: Implementing cisco mpls

5-180 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q30) What is the interaction between Area 0 and a superbackbone? (Source: Configuring

OSPF as the Routing Protocol Between PE and CE Routers)

______________________________________________________________________

Q31) What is the interaction between a superbackbone and other areas? (Source: Configuring

OSPF as the Routing Protocol Between PE and CE Routers)

______________________________________________________________________

Q32) How are OSPF route attributes propagated across an MPLS VPN backbone? (Source:

Configuring OSPF as the Routing Protocol Between PE and CE Routers)

______________________________________________________________________

Q33) What is the purpose of the down bit in an LSA header? (Source: Configuring OSPF as

the Routing Protocol Between PE and CE Routers)

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

Q34) Why do you need a VRF route limit? (Source: Configuring BGP as the Routing

Protocol Between PE and CE Routers)

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

Q35) When would you need the AS-override feature? (Source: Configuring BGP as the

Routing Protocol Between PE and CE Routers)

______________________________________________________________________

______________________________________________________________________

Page 496: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-181

Q36) How does the AS-override feature work? (Source: Configuring BGP as the Routing

Protocol Between PE and CE Routers)

______________________________________________________________________

______________________________________________________________________

Q37) When would you need the allowas-in feature? (Source: Configuring BGP as the

Routing Protocol Between PE and CE Routers)

______________________________________________________________________

______________________________________________________________________

Q38) When is it necessary to use the AS-override feature instead of the allowas-in feature?

(Source: Configuring BGP as the Routing Protocol Between PE and CE Routers)

______________________________________________________________________

______________________________________________________________________

Q39) How do you prevent BGP loops when using AS-override? (Source: Configuring BGP

as the Routing Protocol Between PE and CE Routers)

______________________________________________________________________

______________________________________________________________________

Q40) How do you prevent BGP loops when using allowas-in? (Source: Configuring BGP as

the Routing Protocol Between PE and CE Routers)

______________________________________________________________________

Q41) What is the SOO? (Source: Configuring BGP as the Routing Protocol Between PE and

CE Routers)

______________________________________________________________________

Page 497: Implementing cisco mpls

5-182 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q42) When would you have to use the SOO? (Source: Configuring BGP as the Routing

Protocol Between PE and CE Routers)

______________________________________________________________________

Q43) Where can you set the SOO? (Source: Configuring BGP as the Routing Protocol

Between PE and CE Routers)

______________________________________________________________________

______________________________________________________________________

Q44) What are the preliminary MPLS VPN troubleshooting steps? (Source: Troubleshooting

MPLS VPNs)

______________________________________________________________________

______________________________________________________________________

Q45) Which command do you use to verify that the PE router is receiving customer routes

from the CE router? (Source: Troubleshooting MPLS VPNs)

______________________________________________________________________

______________________________________________________________________

Q46) How do you verify the routing information exchange between PE routers? (Source:

Troubleshooting MPLS VPNs)

______________________________________________________________________

______________________________________________________________________

Q47) How do you verify redistribution of VPNv4 routes into the PE-CE routing protocol?

(Source: Troubleshooting MPLS VPNs)

______________________________________________________________________

______________________________________________________________________

Page 498: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-183

Q48) How do you test end-to-end data flow between PE routers? (Source: Troubleshooting

MPLS VPNs)

______________________________________________________________________

Q49) How do you verify that the PE router ingress interface supports CEF switching?

(Source: Troubleshooting MPLS VPNs)

______________________________________________________________________

Q50) How do you verify that there is an end-to-end LSP? (Source: Troubleshooting MPLS

VPNs)

______________________________________________________________________

Q51) How do you verify that the LFIB entry on the egress PE router is correct? (Source:

Troubleshooting MPLS VPNs)

______________________________________________________________________

Page 499: Implementing cisco mpls

5-184 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Module Self-Check Answer Key Q1) D

Q2) With routing protocols such as RIP and BGP, only a single copy of the protocol may be running in the

router.

Q3) A, D

Q4) False. Interfaces are assigned to a VRF.

Q5) D

Q6) VPNv4 routers are redistributed from the global BGP table to the per-instance BGP table and then to the

per-instance RIP, which is propagated to the CE router.

Q7) A

Q8) B, C

Q9) C

Q10) B

Q11) C

Q12) EBGP is used to carry routing updates between the PE router and the CE router.

IBGP (VNPv4) is used to carry VPN route updates between PE routers.

Note IBGP (IPv4) is used to carry non-VPN route updates between PE routers.

Q13) A BGP address family is a routing protocol context that is used to configure global BGP routing, VPN

routing, and CE-to-PE routing into the same BGP process.

Q14) VPNv4 and IPv4

Q15) neighbor ip-address remote-as as-number

neighbor ip-address update-source interface-type interface number

address-family vpnv4

neighbor ip-address activate

neighbor ip-address next-hop-self

Q16) Extended BGP communities attached to VPNv4 prefixes have to be exchanged between MP-BGP

neighbors because they contain the RT information.

Q17) when you are supporting only VPN routes

Q18) On the CE, enable RIP. On the PE, enable RIP and use the address-family ipv4 vrf vrf-name command

under the router RIP section.

Q19) Enable the static route using the ip route vrf name static route parameters command.

Q20) Use the redistribute rip command under the BGP address family on the ingress PE router to redistribute

the RIP updates into MP-BGP. MP-BGP uses VPNv4 updates to propagate the updates to the egress PE

router. The redistribute bgp metric transparent command under the RIP address family is used on the

egress PE to redistribute the updates back into RIP.

Q21) show ip vrf

show ip vrf detail

show ip vrf interfaces

Q22) Use the show ip route vrf command.

Page 500: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS VPN Implementation 5-185

Q23) The BGP protocol is needed to carry the VPNv4 routes. Use the show ip bgp vpnv4 vrf command.

Q24) Use the show ip bgp neighbors command and verify that the VPNv4 status is “advertised and received.”

Q25) Use the show ip bgp vpnv4 vrf vrf-name command.

Q26) show ip cef vrf

show ip cef vrf detail

show mpls forwarding-table vrf

Q27) show ip bgp vpnv4 all labels

Q28) ingress CE to egress PE: trace

ingress CE to egress CE: trace

ingress PE to egress PE: trace

ingress PE to egress CE: trace vrf vrf-name

Q29) Because MPLS VPNs use BGP to propagate routes between sites; internal OSPF routers in one area will

appear as external routes in another area unless the superbackbone makes the MPLS VPN backbone

transparent to OSPF.

Q30) The superbackbone is transparent to Area 0.

Q31) The superbackbone appears as Area 0 to non-Area 0 areas.

Q32) The OSPF routes are propagated into BGP.

The OSPF metrics and LSA information are carried in the BGP community attribute.

Q33) The down bit is used to prevent routing loops.

Q34) You need a VRF route limit because of tight coupling of the customer and the service provider network in

the MPLS VPN architecture. This tight coupling might also result in the service provider network being

exposed to design and configuration errors in customer networks and to a number of new denial-of-service

attacks based on routing protocol behavior.

Q35) when you need to connect two or more sites that use the same AS number via a VPN

Q36) All leading occurrences of the AS number of the receiving BGP router are replaced with the AS number of

the sending BGP router. Other occurrences (farther down the AS path) of the AS number of the receiving

router are not replaced because they indicate a real routing information loop.

Q37) In some security-conscious implementations, customer VPNs are linked by a customer router that performs

security functions, such as access filtering or access logging.

Q38) in solutions where customer VPNs are linked by a customer router that do not support the AS-override

feature

Q39) Only the leading occurrences of the AS number of the receiving BGP router are replaced with the AS

number of the sending BGP router. Any other occurrences (farther down the AS path) of the AS number of

the receiving router are not replaced because they indicate a real routing information loop.

Q40) Allowas-in specifies the number of times to allow advertisement of an AS number of a PE router. Valid

values are from 1 to 10, using the number parameter of the allowas-in command.

Q41) The SOO is an extended BGP community that is used to indicate the site that has originated the routing

update.

Q42) The SOO is used as an additional loop-prevention mechanism in scenarios when the allowas-in feature is

enabled.

Page 501: Implementing cisco mpls

5-186 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q43) For routes received from BGP-speaking CE routers, the SOO is configured by the incoming route map on

the PE router. For all other routes, a route map setting the SOO is applied to the incoming interface and the

SOO is attached to the BGP route when an IGP route received through that interface is redistributed into

BGP.

Q44) Is CEF enabled?

Are labels for IGP routes generated and propagated?

Are large labeled packets propagated across the MPLS backbone (MTU issues)?

Q45) show ip route vrf vrf-name

Q46) Use the show ip bgp vpnv4 all ip-prefix/length command to verify proper route propagation.

Q47) Use the show ip bgp vpnv4 vrf vrf-name ip-prefix command on the egress PE router or use the show ip

route command on the egress CE router.

Q48) From the ingress PE router, use the ping vrf vrf-name command to ping the interface that supports the CE

router.

Q49) Use the show cef interface command.

Q50) Check LFIB values hop by hop or use the trace vrf vrf-name command from the ingress PE router.

Q51) Determine the second label in the label stack on the ingress PE with the show ip cef vrf vrf-name ip-prefix

detail command. Verify the correctness of the LFIB entry on the egress PE with the show mpls

forwarding vrf vrf-name value detail command.

Page 502: Implementing cisco mpls

Module 6

Complex MPLS VPNs

OverviewThis module discusses some advanced configuration features that can help increase the stability of the Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) backbone. The module also discusses various MPLS VPN features that a service provider might use to help meet service requirements, and looks at various types of VPN solutions and topologies.

Module Objectives Upon completing this module, you will be able to describe how the MPLS VPN model can be used to implement managed services and Internet access. This ability includes being able to meet these objectives:

Configure advanced VRF import and export features

Identify the characteristics of overlapping VPNs

Identify the characteristics of the central services VPN solutions

Identify the characteristics of the managed CE router service

Page 503: Implementing cisco mpls

6-2 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 504: Implementing cisco mpls

Lesson 1

Using Advanced VRF Import and Export Features

OverviewSome virtual routing and forwarding (VRF) features allow you to be more selective with routes, by specifying which routes will or will not be added. You may also limit the number of routes that a customer can insert into the VRF instance. This lesson presents the command syntax that is used to limit each type of route and shows configuration examples of these commands.

It is important to understand how to fine-tune the Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) parameters that will enhance operation of the network. Customer service level agreements (SLAs) should be adhered to so that they provide the best possible solutions for each specific customer. This lesson looks at some key areas regarding the use of VRF import and export features.

ObjectivesUpon completing this lesson, you will be able to describe how to configure advanced VRF import and export features. This ability includes being able to meet these objectives:

Identify advanced VRF features

Configure selective VRF imports

Configure selective VRF exports

Page 505: Implementing cisco mpls

6-4 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are Advanced VRF Features? This topic identifies the advanced VRF features.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-3

Advanced VRF Features

Selective import

• This features allows you to specify additional criteria for importing routes into the VRF.

Selective export

• This features allows you to specify additional RTsattached to exported routes.

VRF route limit

• This features allows you to specify the maximum number of routes in a VRF to prevent memory exhaustion on PE routers or denial-of-service attacks.

These advanced VRF features allow you to deploy advanced MPLS VPN topologies or increase the stability of the MPLS VPN backbone:

The selective import feature allows you to select routes to be imported into a VRF based on criteria other than the route target (RT) of the VRF.

The selective export feature allows you to attach specific RTs to a subset of routes exported from a VRF. By default, the same RTs get attached to all exported routes.

The VRF route limit feature allows you to limit the number of routes that the customer—or other provider edge (PE) routers—can insert in the VRF. This feature prevents undesirable consequences such as configuration errors or denial-of-service attacks.

Page 506: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-5

Configuring Selective VRF Import This topic describes how to configure selective VRF import.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-4

• VRF import criteria might be more specific than just the match on the RT—for example:

– Import only routes with specific BGP attributes (community, and so on).

– Import routes with specific prefixes or subnet masks (only loopback addresses).

• A route map can be configured in a VRF to make the route import more specific.

Configuring Selective VRF Import

Selective route import into a VRF allows you to narrow the route import criteria. Selective route import uses a route map that can filter the routes selected by the RT import filter. The routes imported into a VRF are Border Gateway Protocol (BGP) routes, so you can use match conditions in a route map to match any BGP attribute of a route. These attributes include communities, local preference, multi-exit discriminator (MED), autonomous system (AS) path, and so on.

The import route map filter is combined with the RT import filter. A route has to pass the RT import filter first and then the import route map. The necessary conditions for a route to be imported into a VRF are as follows:

At least one of the RTs attached to the route matches one of the import RTs configured in the VRF.

The route is permitted by the import route map.

Page 507: Implementing cisco mpls

6-6 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-5

·ł°±®¬ łż° ®±«¬»ółż°

᫬»®ř˝±˛ş·ąóŞ®ş÷ý

• This command attaches a route map to the VRF import process.

• A route is imported into the VRF only if at least one RT attached to the route matches one RT configured in the VRF and the route is accepted by the route map.

Configuring Selective VRF Import (Cont.)

import map To configure an import route map for a VRF, use the import map command in VRF configuration submode: import map route-map.

This table describes the parameters for the import map command.

Syntax Description

Parameter Description

®±«¬»ółż° Specifies the route map to be used as an import route map for the VRF

Defaults There is no default. A VRF has no import route map unless one is configured using the importmap command.

Page 508: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-7

Example: Configuring Selective VRF Import The figure shows an example in which an import route map is used to match the IP version 4 (IPv4) portion of incoming VPN version 4 (VPNv4) routes and to import into the VRF only routes matching a certain prefix.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-6

Configuring Selective VRF Import (Cont.)

A configuration similar to this one could be used to accomplish the following:

Deploy advanced MPLS VPN topologies (for example, a managed router services topology)

Increase the security of an extranet VPN by allowing only predefined subnetworks to be inserted into a VRF, thus preventing an extranet site from inserting unapproved subnetworks into the extranet

Note A similar function is usually not needed in an intranet scenario because all customer routers

in an intranet are usually under common administration.

Page 509: Implementing cisco mpls

6-8 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Configuring Selective VRF Export This topic describes how to configure selective VRF export.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-7

Configuring Selective VRF Export

Routes from a VRF might have to be exported with different RTs.

• An example would be export management routes with particular RTs.

An export route map can be configured on a VRF:

• This route map can set extended community RTs.

• No other set operations can be performed by this route map.

Some advanced MPLS VPN topologies are easiest to implement if you can attach a variety of RTs to routes exported from the same VRF. This capability allows only a subset of the routes exported from a VRF to be imported into another VRF. Most services in which customer routers need to connect to a common server (for example, network management stations, voice gateways, and application servers) fall into this category.

The export route map function provides exactly this functionality. A route map can be specified for each VRF to attach additional RTs to routes exported from that VRF. The export route map performs only the attachment of RTs. It does not perform any filtering function.

Attributes attached to a route with an export route map are combined with the export RT attributes. If you specify export RTs in a VRF and set RTs with an export route map, all specified RTs will be attached to the exported route.

Note The export route map provides functionality almost identical to that of the import route map,

but applied to a different VRF. Any requirement that can be implemented with an export

route map can also be implemented with an import route map. However, the implementation

of export maps can be more complicated and harder to manage.

Page 510: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-9

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-8

®±«¬»ółż° ˛żł» °»®ł·¬ ­»Ż

łż¬˝¸ ˝±˛Ľ·¬·±˛

­»¬ »¨¬˝±łł«˛·¬§ ®¬ »¨¬»˛Ľ»Ľó˝±łł«˛·¬§óŞż´«» ĹżĽĽ·¬·Ş»Ă

᫬»®ř˝±˛ş·ą÷ý

• This command creates a route map that matches routes based on any route map conditions and sets RTs.

Configuring Selective VRF Export (Cont.)

set extcommunity To set the BGP extended communities attribute, use the set extcommunity command in route-map configuration mode. To delete the entry, use the no form of this command.

set extcommunity {rt extended-community-value [additive] | soo extended-community-value}

no set extcommunity {rt extended-community-value [additive] | soo extended-community-value}

This table describes the parameters for the set extcommunity command.

Syntax Description

Parameter Description

®¬ Specifies the RT extended community attribute.

­±± Specifies the SOO extended community attribute.

»¨¬»˛Ľ»Ľó˝±łł«˛·¬§óŞż´«»

Specifies the value to be set. The value can be one of the following combinations:

autonomous-system-number: network-number

ip-address: network-number

The colon is used to separate the AS number from the network number or the IP address from the network number.

żĽĽ·¬·Ş» (Optional) Adds an RT to the existing RT list without replacing any RTs.

Page 511: Implementing cisco mpls

6-10 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Defaults No BGP extended community attributes are set by the route map.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-9

»¨°±®¬ łż° ˛żł»

®±«¬»®ř˝±˛ş·ąóŞ®ş÷ý

• This command attaches a route map to the VRF export process.

• All exported routes always get RTs configured with the route-target export command in the VRF.

• A route that is matched by the export route map will have additional RTs attached.

Configuring Selective VRF Export (Cont.)

export map To apply a route map to filter and modify exported routes, use the export map command in VRF configuration mode. To remove the route map from the VRF, use the no form of this command.

export map route-map

no export map route-map

This table describes the parameters for the export map command.

Syntax Description

Parameter Description

®±«¬»ółż° Specifies the name of the route map to be used

Defaults No route map is used.

Page 512: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-11

Example: Configuring Selective VRF Export

In the figure, the configuration is implemented with an export route map.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-10

Configuring Selective VRF Export (Cont.)

Note Depending on when you configure the export map command, you may need to use the

clear ip bgp command to force the existing BGP session to propagate the extended

communities.

In the earlier example, selective import of routes into a VRF was achieved with an import route map in the receiving VRF that allowed only routes from a certain address block to be inserted into the VRF. In this example, routes from a certain address block are marked with an additional RT in the originating VRF and are automatically inserted into the receiving VRF on the basis of their RT.

The main difference between import and export route maps is therefore the deployment point:

The import route map is deployed in the receiving VRF.

The export route map is deployed in the originating VRF.

Based on the network design, the functionality of one or the other might be preferred.

Note Import and export route maps can increase the number of routes processed by a router. The

BGP maximum-prefix function can be used to ensure that the number of routes does not

exceed the network design. (See the “Configuring BGP as the Routing Protocol Between PE

and CE Routers” lesson in the “MPLS VPN Implementation” module for further details.)

Page 513: Implementing cisco mpls

6-12 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-11

Summary

• Two advanced VRF features were discussed:

– Selective import

– Selective export

• Use the import map command to configure an import route map for VRF.

• Use the export map command to attach a route map to the VRF export process.

Page 514: Implementing cisco mpls

Lesson 2

Introducing Overlapping VPNs

OverviewOverlapping Virtual Private Networks (VPNs) are usually used to connect parts of two separate VPNs. A third VPN is created within the Multiprotocol Label Switching (MPLS) VPN network that contains sites from both VPNs. A new route target (RT) extended community is used for networks originating in the sites that are also in the new VPN. This action may require a new virtual routing and forwarding (VRF) instance, resulting in a new route distinguisher (RD). Networks originating in these sites are exported with two RT extended communities: one for the original VPN and one for the overlapping VPN. This lesson looks at the requirements, usage, and solutions associated with overlapping VPNs.

It is important to understand customer needs and how to best fit those needs. This lesson looks at an area that helps to clarify some solutions regarding multiple separate VPNs.

ObjectivesUpon completing this lesson, you will be able to identify the characteristics of overlapping VPNs. This ability includes being able to meet these objectives:

Identify the participants in overlapping VPNs

Identify typical overlapping VPN usages

Describe the routing update flow in an overlapping VPN

Describe the data flow in an overlapping VPN

Configure overlapping VPNs

Page 515: Implementing cisco mpls

6-14 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Who Are the Participants in Overlapping VPNs? This topic identifies the participants in overlapping VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-3

• CE routers participate in simple VPNs.

• Some CE routers participate in more than one simple VPN:

– Here, A-Central talks to B-Central.

Overlapping VPNs

When two VPN customers want to share some information, they may decide to interconnect their central sites. To achieve this interconnection, two simple VPNs are created, each containing a customer central site and its remote sites. Then a third VPN, which partially overlaps with the customer VPNs but connects only their central sites, is created. The central sites can talk to each other. Each central site can also talk to the remote sites in its simple VPN, but not to the remote sites belonging to the other customer simple VPN. The addresses used in the central sites, however, have to be unique in both VPNs.

Another option is to use dual Network Address Translation (NAT) with a registered address to be imported and exported between the two central sites.

Page 516: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-15

What Are Typical Overlapping VPN Usages? This topic identifies typical overlapping VPN usages.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-4

Typical Overlapping VPN Usages

• Companies where central sites participate in a corporate network and in an extranet

• A company with several security-conscious departments that exchange data between their servers

These are two typical uses for overlapping VPNs:

Companies that use MPLS VPNs to implement both intranet and extranet services might use overlapping VPNs. In this scenario, each company participating in the extranet VPN would probably deploy a security mechanism on its customer edge (CE) routers to prevent other companies participating in the VPN from gaining access to other sites in its VPN.

A security-conscious company might decide to limit visibility between different departments in the organization. Overlapping VPNs might be used as a solution.

Note Security issues might force an enterprise network to be migrated to an MPLS VPN even if it

is not using MPLS VPN services from a service provider.

Page 517: Implementing cisco mpls

6-16 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Overlapping VPN Routing This topic describes the routing update flow in an overlapping VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-5

Overlapping VPN Routing

Some key points regarding the routing update flow in overlapping VPNs are as follows:

Each VPN has its own RT (123:750, 123:760) that the sites participating in the VPN import and export.

Sites that participate in more than one VPN import routes with RTs from any VPN in which they participate and export routes with RTs for all VPNs in which they participate.

Example: Overlapping VPN Routing

The figure shows how to implement overlapping VPNs.

For site A-1 and site A-2 (participating only in VPN-A), do the following:

Export all networks with RT 123:750.

Import all networks that carry RT 123:750 (VPN-A).

For site B-1 and site B-2 (participating only in VPN-B), do the following:

Export all networks with RT 123:760.

Import all networks that carry RT 123:760 (VPN-B).

Page 518: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-17

For site A-Central (participating in VPN-A and the overlapping VPN), do the following:

Export all networks with RTs 123:750 and 123:1001.

Import all networks that carry RT 123:750 (VPN-A) or 123:1001 (overlapping VPN).

For site B-Central (participating in VPN-B and the overlapping VPN), do the following:

Export all networks with RTs 123:760 and 123:1001.

Import all networks that carry RT 123:760 (VPN-B) or 123:1001 (overlapping VPN).

Page 519: Implementing cisco mpls

6-18 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Overlapping VPN Data Flow This topic describes the data flow in an overlapping VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-6

Overlapping VPN Data Flow

Because sites belonging to different VPNs do not share routing information, they cannot talk to each other. The figure shows overlapping VPN data flow:

The simple VPN for customer A contains routes that originate from the following:

— A-Central site

— A remote sites

The simple VPN for customer B contains routes that originate from the following:

— B-Central site

— B remote sites

The overlapping VPN contains routes that originate from the following:

— A-Central site

— B-Central site

All of the customer A sites can communicate with each other.

All of the customer B sites can communicate with each other.

A-Central and B-Central can communicate with each other.

The customer A remote site cannot communicate with the customer B remote sites.

Note If a site participating in more than one VPN is propagating a default route to other sites, it

can attract traffic from those sites and start acting as a transit site between VPNs, enabling

sites that were not supposed to communicate to establish two-way communication.

Page 520: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-19

Configuring Overlapping VPNs This topic describes how to configure overlapping VPNs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-7

• Configure one VRF per set of sites with the same VPN membership per PE router.

• For every set of sites with the same VPN membership, use the same RD.

• Configure RTs based on the VPN membership of sites in each VRF.

Overlapping VPNs—Configuration Tasks

You can have a network with four types of sites with different VPN memberships.

Example: Overlapping VPNs—Configuration Tasks

The figure illustrates this example. This situation requires at least the following four VRFs:

A-Spoke-1 and A-Spoke-2 are members of VPN-A only. (They need two VRFs because they are not connected to the same PE router; they can, however, use the same RD and RTs.)

B-Spoke-1 and B-Spoke-2 are members of VPN-B only. (They need two VRFs because they are not connected to the same PE router; they can, however, use the same RD and RTs.)

A-Central is a member of VPN-A and overlapping VPN-AB. (It cannot use the same RD as A-Spoke-1 and A-Spoke-2 because it has different routing requirements. It needs a unique RD and RTs for VPN-A as well as Central.)

B-Central is a member of VPN-B and overlapping VPN-AB. (It needs a unique RD as well as RTs for VPN-B as well as Central.)

Page 521: Implementing cisco mpls

6-20 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

This table shows an RT and RD numbering scheme for PE-1.

PE-1 RT and RD Numbering Scheme

VRF RD Import RT Export RT

VPN-A 123:750 123:750 123:750

VPN-B 123:760 123:760 123:760

VPN-A-Central 123:751 123:750

123:1001

123:750

123:1001

This table shows an RT and RD numbering scheme for PE-2.

PE-2 RT and RD Numbering Scheme

VRF RD Import RT Export RT

VPN-A 123:750 123:750 123:750

VPN-B 123:760 123:760 123:760

VPN-B-Central 123:761 123:760

123:1001

123:760

123:1001

Page 522: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-21

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-8

Configuring Overlapping VPN VRFs

The Cisco IOS software configuration for PE-1 and PE-2 reflects the RT and RD numbering scheme from the two tables.

Example: Configuring Overlapping VPN VRFs

The figure shows only VRF configuration and does not show VPN routing or Multiprotocol Border Gateway Protocol (MP-BGP) routing between the PE routers.

Page 523: Implementing cisco mpls

6-22 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-9

Summary

• Overlapping VPNs are used to provide connectivity between segments of two VPNs.

• There are two uses for overlapping VPNs:

– Companies that use MPLS VPNs to implement both intranet and extranet services

– Companies that might decide to limit visibility between departments

• Sites that participate in more than one (overlapping) VPN importand export routes with RTs from any VPN in which they participate.

• Sites cannot talk to each other if they belong to different VPNs.

• Overlapping VPN sites are configured with the required RTsbased on the VPN membership.

Page 524: Implementing cisco mpls

Lesson 3

Introducing Central Services VPNs

OverviewA central services Virtual Private Network (VPN) is used when multiple VPNs need to share a common set of servers. These servers reside in the central services VPN, and all other VPNs have access to this VPN. The other VPNs, however, are not able to see one another. The central services VPN is implemented using two route target (RT) extended communities, where one imports networks into the VPN and the other exports networks. The client sites do the opposite. Two RT extended communities are needed to prevent client sites from exchanging routing information. This lesson looks at central services VPN solution topologies and how routing updates within that topology would flow. The lesson also discusses the implications of combining a central services VPN with a simple customer VPN. It is important to understand fully the topologies that make the most sense for the customer and to be able to configure or recommend other options.

ObjectivesUpon completing this lesson, you will be able to identify the characteristics of the central services VPN. This ability includes being able to meet these objectives:

Describe the access characteristics of a central services VPN

Describe the routing characteristics of a central services VPN

Describe the data flow within a central services VPN

Configure a central services VPN

Identify the connectivity requirements when you are integrating a central services VPN with a simple VPN

Identify the RD requirements when you are integrating a central services VPN with a simple VPN

Identify the RT requirements when you are integrating a central services VPN with a simple VPN

Page 525: Implementing cisco mpls

6-24 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are the Access Characteristics of a Central Services VPN?

This topic describes the access characteristics of a central services VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-3

• Clients need access to central servers.

• Servers can communicate with each other.

• Clients can communicate with all servers but not with each other.

Central Services VPN

A central services VPN is a topology with these characteristics:

Some sites (“server sites”) can communicate with all other sites.

All the other sites (“client sites”) can communicate only with the server sites.

This topology can be used in these situations:

The service provider offers services to all customers by allowing them access to a common VPN.

Two (or more) companies want to exchange information by sharing a common set of servers.

A security-conscious company separates its departments and allows them access only to common servers.

Page 526: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-25

What Are the Routing Characteristics of a Central Services VPN?

This topic describes the routing characteristics of a central services VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-4

• Client routes need to be exported to the server site.

• Server routes need to be exported to client and server sites.

• No routes areexchanged between client sites.

Central Services VPN Routing

There is a specific routing model used to implement a central services VPN.

Example: Central Services VPN Routing

The figure illustrates the MPLS VPN routing model that is used to implement a central services VPN:

Client 1 and client 2 have their own RTs (123:101, 123:102) that they import and export; they also export networks with RT 123:193 and import networks with RT 123:192.

Note Client-specific RTs were introduced to comply with the implementation requirements of

Cisco IOS Software Release 12.0 T, in which each virtual routing and forwarding (VRF)

instance has to have at least one of its export RTs configured as its import RT.

The central site imports and exports networks with the RT of its VPN, but it also imports networks with RT 123:193 and exports networks with RT 123:192.

Client 1 does the following:

Exports all networks with RTs 123:101 or 123:193

Imports all networks that carry RT 123:101 or 123:192

Page 527: Implementing cisco mpls

6-26 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Client 2 does the following:

Exports all networks with RTs 123:102 or 123:193

Imports all networks that carry RT 123:102 or 123:192

The central site does the following:

Exports all networks with RT 123:192 or RT 123:199

Imports all networks that carry RT 123:193 or RT 123:199

Page 528: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-27

Identifying the Central Services VPN Data Flow Model

This topic describes the data flow within a central services VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-5

• Client VRFs contain server routes; clients can talk to servers.

• Server VRFs contain client routes; servers can talk to clients.

• Client VRFs do not contain routes from other clients; clients cannot communicate.

• Make sure that there is no client-to-client leakage across server sites.

Central Services VPN Data Flow Model

In the central services VPN topology, the client VRF contains only routes from the client site and routes from the server sites. This setup precludes the client sites from communicating with other client sites.

A server VRF in this topology contains routes from the site or sites attached to the VRF and also routes from all other client and server sites. Hosts in server sites can therefore communicate with hosts in all other sites.

Note If the central site is propagating a default route to other sites, it can result in client sites

seeing each other through the customer edge (CE) router in the central site.

Page 529: Implementing cisco mpls

6-28 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Configuring a Central Services VPN This topic describes how to configure a central services VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-6

Steps for Configuring a Central Services VPN

Client sites:• Use a separate VRF per client site.

• Use a unique RD on each client site.

• Import and export routes with an RT that is the same value as the RD for each client site (VPN of client).

• Export routes with an RT (clients-to-server) associated with the server site.

• Import routes with the RT (server-to-clients) into client VRFs.

To configure a central services VPN, you need to address these requirements:

You need a separate VRF for each client.

You need one VRF per provider edge (PE) router connecting a server site.

You need a unique route discriminator (RD) on each client site.

You need a unique RD on each set of server sites.

You need an import-export RT with the same value as the RD for each client site.

Page 530: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-29

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-7

Steps for Configuring a Central Services VPN (Cont.)

Server sites:

• Use one VRF for each service type.

• Use a unique RD on each service type.

• Import and export routes with an RT that is the same value as the RD for each server site (VPN of server).

• Export server site routes with an RT (server-to-client).

• Import routes with the RT (clients-to-server) into the server VRFs.

This table shows an RD and RT numbering scheme for PE-1.

PE-1 RD and RT Numbering Scheme

VRF RD Import RT Export RT

Client-1 123:101 123:101

123:192

123:101

123:193

Client-2 123:102 123:102

123:192

123:102

123:193

This table shows an RD and RT numbering scheme for PE-2.

PE-2 RD and RT Numbering Scheme

VRF RD Import RT Export RT

Client-4 123:104 123:104

123:192

123:104

123:193

Client-5 123:105 123:105

123:192

123:105

123:193

Page 531: Implementing cisco mpls

6-30 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

This table shows an RD and RT numbering scheme for PE-CS-1.

PE-CS-1 RD and RT Numbering Scheme

VRF RD Import RT Export RT

Server 123:103 123:103

123:193

123:103

123:192

This table shows an RD and RT numbering scheme for PE-CS-2.

PE-CS-2 RD and RT Numbering Scheme

VRF RD Import RT Export RT

Server 123:103 123:103

123:193

123:103

123:192

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-8

Configuring a Central Services VPN

Use the ip vrf command to configure a central services VPN.

Example: Configuring a Central Services VPN

The figure shows a fraction of the configuration according to the RD and RT numbering scheme presented in the tables.

Page 532: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-31

Integrating a Central Services VPN with a Simple VPN

This topic identifies the connectivity requirements when you are integrating a central services VPN with a simple VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-9

Central Services VPN and Simple VPN Requirements

• Customers run a simple VPN:

- All A-Spoke sites in A-VPN

- All B-Spoke sites in B-VPN

• Only A-Central and B-Central need access to central servers.

• This situation results in a combination of rules from the overlapping VPN and central services VPN.

In this design, some of the customer sites need access to the central server. All other sites just need optimal intra-VPN access. The design is consequently a mixture of simple VPN topology and central services VPN topology.

Page 533: Implementing cisco mpls

6-32 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-10

• For all sites participating in a simple VPN, configure a separate VRF per set of sites participating in the same VPNs per PE router.

• For sites that are only clients of central servers, create a VRF per site.

• Create one VRF for central servers per PE router.

Central Services VPN and Simple VPN Requirements (Cont.)

When integrating a central services VPN with a simple VPN, you need one VRF per VPN for sites that have access to other sites in the customer VPN but no access to the central services VPN. You need one VRF per VPN for sites that have access to the central services VPN. Finally, you need one VRF for the central services VPN; this VPN is on another PE router in the example.

Page 534: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-33

Identifying the RD Requirements When Integrating Central Services and Simple VPNs

This topic identifies the RD requirements when you are integrating a central services VPN with a simple VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-11

Configuring RDs in a Central Services VPN and Simple VPN

• Configure a unique RD for every set of VRFs with unique membership requirements:– A-Spoke-1 and A-Spoke-2 can share the same RD.

– B-Spoke-1 and B-Spoke-2 can share the same RD.

– A-Central needs a unique RD.

– B-Central needs a unique RD.

• Configure one RD for all central server VRFs.

For this design, you need two RDs per VPN:

Configure one RD for simple VPN sites. (The same value should also be used for import and export RTs.)

Configure one RD for the central services VRFs.

Page 535: Implementing cisco mpls

6-34 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Identifying the RT Requirements When Integrating Central Services and Simple VPNs

This topic identifies the RT requirements when you are integrating a central services VPN with a simple VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-12

• Configure the customer VPN import-export route target in all VRFs participating in customer VPN.

• Configure a unique import-export route target in every VRF that is onlya client of central servers.

• Configure the central services import and export route targets in VRFs that participate in central services VPN.

Configuring RTs in a Central Services VPN and Simple VPN

This table shows an RD and RT numbering scheme for PE-1.

PE-1 RD and RT Numbering Scheme

VRF RD Import RT Export RT

VPN-A 123:750 123:750 123:750

VPN-B 123:760 123:760 123:760

VPN-A-Central 123:751 123:750

123:101

123:750

123:100

Page 536: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-35

This table shows an RD and RT numbering scheme for PE-2.

PE-2 RD and RT Numbering Scheme

VRF RD Import RT Export RT

VPN-A 123:750 123:750 123:750

VPN-B 123:760 123:760 123:760

VPN-B-Central 123:761 123:760

123:101

123:760

123:100

This table shows an RD and RT numbering scheme for PE-CS.

PE-CS RD and RT Numbering Scheme

VRF RD Import RT Export RT

Server 123:101 123:101

123:100

123:101

Page 537: Implementing cisco mpls

6-36 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-13

Configuring VRFs in a Central Services VPN and Simple VPN

Use the ip vrf command to configure VRFs in a central services and simple VPN.

Example: Configuring VRFs in a Central Services and Simple VPN

The example shows a fraction of the configuration using the RD and RT numbering scheme presented in the tables.

Page 538: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-37

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-14

Summary

• A central services VPN is used to provide access from centralized servers to one or more customers.

• A central services VPN routing model indicates these requirements:– Client routes need to be exported to the server site.– Service routes need to be exported to client and server sites.

– No routes are exchanged between client sites.

• The data flow in a central services VPN model indicates these requirements:– Client VRFs contain server routes and do not contain routes from other

clients.– Server VRFs contain client routes.

• Some of the requirements to configure a central services VPN arethese:– Use a separate VRF for each client.

– Use a unique RD on each client site.– Use a unique RD in each set of server sites.

– Use import and export RT matching between server and client sites.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-15

Summary (Cont.)

• The hybrid of a simple VPN and a central VPN provides the following:

– Customers have intra-VPN access, including their central site.

– The central sites of each customer can access centralized servers available to multiple customers.

• Intra-VPN customer sites can share the same RD. The central site of a customer and shared centralized servers require a unique RD.

• The import-export RT must match from respective customer intra-VPN sites to a central site. A different import-export RT set must match from the central site of the respective customers to the shared centralized server site.

Page 539: Implementing cisco mpls

6-38 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 540: Implementing cisco mpls

Lesson 4

Introducing the Managed CE Routers Service

OverviewA service provider can use a separate network management Virtual Private Network (VPN) to manage the customer edge (CE) routers of all the VPNs. A pair of route target (RT) extended communities is used to accomplish this goal. One RT exports CE router loopback addresses and is imported into the virtual routing and forwarding (VRF) instance of the network management VPN. The other RT exports the networks from the VRF associated with the network management VPN and imports them into all other VRF instances. This lesson explains some of the requirements and the implementation solution for the managed CE routers service.

It is important to be able to recognize the requirements of the network and to match them with customer requests. This lesson looks at one such requirement and explains how to handle it.

ObjectivesUpon completing this lesson, you will be able to identify the characteristics of the managed CE routers service. This ability includes being able to meet these objectives:

Identify the overall requirements of a managed CE routers VPN

Identify the VRF and RD requirements of a managed CE routers VPN

Configure a managed CE routers VPN

Page 541: Implementing cisco mpls

6-40 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Are the Requirements of Managed CE Routers?

This topic identifies the overall requirements of a managed CE routers VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-3

• Central server NMS needs access to loopback addresses of all CE routers.

• Very similar to central services and simple VPNs:

– All of the CE routers participate in the central services VPN.

– Only the loopback addresses of the CE routers need to be exported into the central services VPN.

Managed CE Routers

If the service provider is managing the customer routers, it is convenient to have a central point that has access to all CE routers but doe not have access to the other destinations at the customer sites. This requirement is usually implemented by deploying a separate VPN for management purposes. This VPN needs to see all the loopback interfaces of all the CE routers. All CE routers have to see the network management VPN. The design is similar to that of the central services VPN; the only difference is that you mark only loopback addresses to be imported into the network management VPN.

Note The topology described in this lesson is sometimes referred to as a “gray” network

management VPN implementation, because all CE routers are accessed through a single

link between the network management system (NMS) CE router and the network core. An

alternative solution (a “rainbow” network management VPN), in which the NMS CE router

has separate connections to each managed CE router, is usually used in combination with

overlay VPNs (for example, Frame Relay networks).

Page 542: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-41

What Are the VRF and RD Requirements? This topic identifies the VRF and route discriminator (RD) requirements of a managed CE routers VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-4

• Create one VRF per customer VPN per PE router.

• Assign the same RD to each customer VRF.

• Create an NMS VRF on the PE-CS router.

• Assign a unique RD to the NMS VRF.

VRF Creation and RD Overview

The VRF and RD design is the same as with central services VPNs. The only difference between this topology and the central services VPN topology combined with a simple VPN topology is the RT marking process during route export.

Page 543: Implementing cisco mpls

6-42 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Configuring Managed CE Routers This topic describes how to configure a managed CE routers VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-5

• Configure the per-customer import-export RT in all customer VRFs.

• Configure the NMS import-export RT in NMS VRF.

• Import routes with the NMS RT into the customer VRF.

• Export loopback addresses from the customer VRF with RT NMS_Client.

• Import routes with RT NMS_Client into NMS VRF.

Configuring Route Targets

This table shows an RD and RT numbering scheme for PE-1.

PE-1 RD and RT Numbering Scheme

VRF RD Import RT Export RT

VPN-A 123:750 123:750

123:101

123:750

123:100 (using NMS route-map)

VPN-B 123:760 123:760

123:101

123:760

123:100 (using NMS route-map)

This table shows an RD and RT numbering scheme for PE-CS.

PE-CS RD and RT Numbering Scheme

VRF RD Import RT Export RT

NMS 123:101 123:101

123:100 (NMS_Client)

123:101

Page 544: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-43

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-6

Configuring VRFs

You can have a configuration for a customer VRF with differentiated RT export for loopback addresses.

Example: Configuring VRFs

The figure illustrates this example. An export route map is used to match one part of the IP address space and attach an additional RT to the routes within this address space (CE router loopback addresses).

Note The routing protocol between provider edge (PE) and CE routers has to be secured (with

distribute lists or prefix lists) to prevent customers from announcing routes in the address

space dedicated to network management; otherwise, customers can gain two-way

connectivity to the network management station.

The CE router loopback addresses are then imported into the server VPN based on the additional RT attached to them during the export process.

Note This design allows client sites to send packets to the network management VPN regardless

of the source address. Special precautions should be taken to protect the network

management VPN from potential threats and denial-of-service attacks coming from

customer sites.

Page 545: Implementing cisco mpls

6-44 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-7

Summary

• The managed CE routers service allows the service provider to access the loopback addresses of the CE router for management purposes.

• Managed VRF and RD design is the same as with the hybrid of a central and a simple VPN.

• Managed RT design is the same as with the hybrid of a central and simple VPN, except for the RT marking process during route export.

Page 546: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-45

Module Summary This topic summarizes the key points that were discussed in this module.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6-1

Module Summary

• Advanced VRF features allow selective import or export of routes.

• Overlapping VPNs are used to provide connectivity between segments of two VPNs.

• Central services VPNs are used to share a common set of servers with VPNs of multiple customers.

• CE routers for all VPNs can be managed by service providers using a separate network management VPN.

• With MPLS managed services, ISPs can provide additional centralized services that are integrated with existing VPN service to customers.

Market forces continually drive service providers to provide more complex centralized services for their customers. These services, such as advanced virtual routing and forwarding (VRF) import and export features, overlapping Virtual Private Networks (VPNs), and central services VPNs, help to meet service requirements and provide VPN solutions and topologies.

ReferencesFor additional information, refer to these resources:

Access Cisco.com for additional information about VPNs.

Cisco Systems, Inc. “NAT Integration with MPLS VPNs.”

Cisco Systems, Inc. “DHCP Relay—MPLS VPN Support.”

Cisco Systems, Inc. Multicast VPN Design Guide

Page 547: Implementing cisco mpls

6-46 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Module Self-Check Use the questions here to review what you learned in this module. The correct answers and solutions are found in the Module Self-Check Answer Key.

Q1) Why do you need a selective VRF import command? (Source: Using Advanced VRF

Import and Export Features)

______________________________________________________________________

Q2) How does the import route map affect the VRF import process? (Source: Using

Advanced VRF Import and Export Features)

______________________________________________________________________

Q3) Why do you need a selective VRF export command? (Source: Using Advanced VRF

Import and Export Features)

______________________________________________________________________

Q4) How does the export route map affect the VRF export process? (Source: Using

Advanced VRF Import and Export Features)

______________________________________________________________________

Q5) Which BGP attributes can be set with an export route map? (Source: Using Advanced

VRF Import and Export Features)

______________________________________________________________________

Q6) Who are the typical users of overlapping VPNs? (Source: Introducing Overlapping

VPNs)

______________________________________________________________________

Page 548: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-47

Q7) What are the connectivity requirements for overlapping VPNs? (Source: Introducing

Overlapping VPNs)

______________________________________________________________________

Q8) What are the typical usages for a central services VPN topology? (Source: Introducing

Central Services VPNs)

______________________________________________________________________

______________________________________________________________________

Q9) What is the connectivity model for a central services VPN topology? (Source:

Introducing Central Services VPNs)

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

Page 549: Implementing cisco mpls

6-48 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q10) What command syntax do you use to implement a central services VPN topology that

supports two clients? (Source: Introducing Central Services VPNs)

client PE router server PE router

client PE router server PE router

Q11) How many RDs do you need for a central services VPN solution with 50 client sites

and 3 server sites? How many RTs? (Source: Introducing Central Services VPNs)

route distinguishers = route targets =

Q12) How do you combine a central services VPN topology with a simple VPN topology?

(Source: Introducing Central Services VPNs)

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

Page 550: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-49

Q13) Why do you need the managed CE routers service? (Source: Introducing Managed CE

Routers Service)

______________________________________________________________________

______________________________________________________________________

Q14) What is the main difference between the managed CE routers service and the typical

central services VPN topology? (Source: Introducing Managed CE Routers Service)

______________________________________________________________________

______________________________________________________________________

Q15) What syntax would you use for an export statement that limits the export to the

loopback address of 192.168.10.1? (Source: Introducing Managed CE Routers Service)

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

______________________________________________________________________

Page 551: Implementing cisco mpls

6-50 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Module Self-Check Answer Key Q1) A selective VRF import command allows you to select routes to be imported into a VRF based on criteria

other than the VRF RT.

Q2) The import route map filter is combined with the RT import filter—a route has to pass the RT import filter

first and then pass the import route map to be imported into the VRF.

Q3) A selective VRF export command allows you to attach specific RTs to a subset of routes exported from a

VRF. (By default, the same RTs get attached to all exported routes.)

Q4) A route map can be specified for each VRF to attach additional RTs to routes exported from a VRF. The

export route map performs only the attachment of RTs; it does not perform any filtering function, and you

cannot change any other route attributes with it.

Q5) extended community RTs

Q6) companies that use MPLS VPNs to implement both intranet and extranet services, or a security-conscious

company that wishes to limit visibility between different departments in the organization

Q7) Selected sites in a VPN can communicate only with sites within their VPN. Other selected sites can

communicate with sites in their VPN and selected sites in a second VPN.

Q8) in solutions where some sites (server sites) can communicate with all other sites, but all the other sites

(client sites) can communicate only with the server sites

Q9) The clients have their own RTs that they import and export; the clients also export networks with an RT

that will be used by the services VRF and import networks with an RT that identifies the routes of the

services site. The services site imports and exports networks with the RT of its VPN, but it also imports

networks with RTs that identify the client sites.

Q10) Client PE router: Server PE router:

ip vrf Client_1 ip vrf Server

rd 123:101 rd 123:103

route-target both 123:101 route-target both 123: 203

route-target export 123:303 route-target import 123:303

®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ďîíćîđí

·° Ş®ş Ý´·»˛¬Áî

®Ľ ďîíćďđî

®±«¬»ó¬ż®ą»¬ ľ±¬¸ ďîíćďđî

®±«¬»ó¬ż®ą»¬ »¨°±®¬ ďîíćíđí

®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ďîíćîđí

Q11) route distinguishers = 51 route targets = 52

You need one RD for each client (50) and one RD (1) shared by both server sites. You need one RT for

each client (50) to export its routes to its VPN, one RT (1) for all of the clients to export their routes to the

server, and one RT (1) that is shared by both server sites to export their routes to the clients.

Q12) Create a simple VPN that provides connectivity for all of the customer sites that do not need access to the

central services.

Next, create a simple VPN that provides access between all of the server sites that are in the service.

Finally, create an overlapping VPN that contains the sites that must have access to both the customer

VPNs and the services VPN.

Q13) If the service provider is managing the customer routers, it is convenient to have a central point that has

access to all CE routers but not to the other destinations at customer sites.

Q14) The VRF and RD design is similar to that of a central services VPN. The managed CE routers service

combines a service VPN and simple VPN topology like the central services VPN. However, the route

Page 552: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Complex MPLS VPNs 6-51

export statement uses an access list to limit the exported addresses to the loopback address of the managed

routers.

Q15) ip vrf VPN_A

export route-map NMS

route-map NMS

match ip access-list 10

set extcommunity rt 123:100 additive

access-list 10 permit 192.160.10.1 0.0.0.0

Page 553: Implementing cisco mpls

6-52 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 554: Implementing cisco mpls

Module 7

Internet Access and MPLS VPNs

OverviewIntegrating Internet access with a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) solution is one of the most common service provider business requirements. This module provides a good understanding of underlying design issues, several potential design scenarios, and some sample configurations. Various topologies and implementation methods are discussed, along with ways to separate Internet access from VPN services.

Module Objectives Upon completing this module, you will be able to describe the various Internet access implementations available. This ability includes being able to meet these objectives:

Describe Internet connectivity scenarios

Describe implementing separate Internet access and MPLS VPN services

Describe implementing Internet access as a separate VPN service on a MPLS VPN backbone

Page 555: Implementing cisco mpls

7-2 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 556: Implementing cisco mpls

Lesson 1

Introducing Internet Access with MPLS VPNs

OverviewThis lesson describes common customer Internet connectivity scenarios and identifies two design models for combining Internet access with Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) services. The lesson lists the benefits and drawbacks of these models, and then gives an overview of the implications of their use.

This lesson is crucial for learners planning to enhance their usage of network resources using MPLS VPNs.

ObjectivesUpon completing this lesson, you will be able to describe VPN Internet access implementation methods. This ability includes being able to meet these objectives:

Describe common customer Internet connectivity scenarios

Identify the two major design models for combining Internet access with MPLS VPN services

Describe the benefits and drawback of Internet access through global routing

Describe the benefits and drawback of Internet access in a separate VPN

Describe the disadvantages of providing Internet access through route leaking

Page 557: Implementing cisco mpls

7-4 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Customer Internet Connectivity Scenarios This topic describes some customer Internet connectivity scenarios.

Classical Internet Access Classical Internet access is implemented through a central firewall that connects the customer network to the Internet in a secure fashion.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-3

Classical Internet Access

• Customer connects to the Internet through a central site firewall.

– Firewall provides NAT or proxy services as needed.

• Since all Internet traffic goes across the central site, flow toInternet is not optimal.

The customer network and the Internet are connected only through the firewall. The addressing requirements for this type of connection are very simple. The customer is assigned a small block of public address space used by the firewall. The customer typically uses private addresses inside the customer network. The firewall performs Network Address Translation (NAT) between the customer’s private addresses and the public addresses assigned to the customer by the Internet service provider. Alternatively, the firewall might perform an application-level proxy function that also isolates private and public IP addresses.

There are a number of benefits associated with this design. It is a well-known setup, and the expertise needed to implement such a setup is thus simple and straightforward. There is only one interconnection point between the secure customer network and the Internet that needs to be managed.

The major drawback of this design is the traffic flow. All traffic from the customer network to the Internet passes through the central firewall. Although this might not be a drawback for smaller customers, it can be a severe limitation for large organizations with many users, especially when they are geographically separated.

Page 558: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-5

Multisite Internet Access Some customers find the traffic flow limitations of the central firewall setup too limiting. To bypass the limitations of Internet access through a central firewall, some customers are using designs in which each customer site has its own independent Internet access.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-4

Multisite Internet Access

• Customers have Internet access directly from every site.

• There is optimum traffic flow to and from Internet sites.

• Each site has to be secured against unauthorized Internet access.

This design solves traffic flow issues, but the associated drawback is higher exposure. Each site has to be individually secured against unauthorized Internet access, which leads to the increased complexity of managing a firewall at every customer site.

To achieve Internet access from every customer site, each customer edge (CE) router must forward VPN traffic toward other customer sites and forward Internet traffic toward Internet destinations. The two traffic types are usually sent over the same physical link but different logical links to minimize costs.

For customers that do not want the complexity of managing their own firewalls, a managed firewall service offered by the service provider can help address the security issues of Internet connectivity.

Page 559: Implementing cisco mpls

7-6 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Wholesale Internet Access A service provider may provide wholesale Internet access to customers from a range of upstream Internet service providers (ISPs) to satisfy the connectivity and reliability requirements of various customers.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-5

Wholesale Internet Access

• Customers chose ISP and get address space from that ISP.

• The wholesale Internet access provider may have to use a different address pool for every upstream service provider.

The selection of upstream ISPs and the corresponding configuration processes should therefore be as easy as possible for the service provider. From an Internet perspective, customers A, B, and C are connected to ISP X or ISP Y. This means that the IP address space used by the customer should be allocated from the block of addresses administered by the selected ISP. The service provider providing wholesale Internet access may have to use a different address for every upstream ISP.

Page 560: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-7

Internet Design Models for Service Providers This topic identifies two major design models for service providers combining Internet access with MPLS VPN services.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-6

Service Provider Shared Backbone

Because Internet access is one of the most popular services that service providers offer their customers, many service providers offer Internet access as well as MPLS VPN service on their shared backbone. Integrating Internet access with an MPLS VPN solution is one of the most common service provider business requirements. A background of common customer Internet connectivity scenarios will help in assessing possible implementations.

Page 561: Implementing cisco mpls

7-8 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Major Design Models Network designers who want to offer Internet access and MPLS VPN services in the same backbone can choose between these two major design models:

Internet access that is implemented through global routing on the provider edge (PE) routers and that is not a VPN service

Internet access that is implemented as a separate VPN in the ISP network

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-7

Major Design Models

Two major design models:

• Internet access separate from VPN services

• Internet access as a separate VPN

In both cases, security should be the most important concern for customers when they connect to public networks. Customers should isolate private VPNs from Internet traffic, either physically on a separate interface or on a subinterface. Appropriate firewall support either in a dedicated device or integrated in the router Cisco IOS software is a necessity. Depending on the network addressing, network address translation (NAT) will be needed for most customers.

Page 562: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-9

Internet Access Through Global Routing This topic describes options for implementing Internet access through global routing.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-8

Internet Access Through Global Routing

• Implementation via separate interfaces that are not placed in any VRF, via either:

– Static default routing on a PE

– BGP between CE and PE

• Benefits:

– Well-known setup; equivalent to classical Internet service

– Easy to implement; offers a wide range of design options

• Drawback:

– Requires separate physical links or WAN encapsulation that supports subinterfaces

Implementing Internet access through global routing is identical to building a traditional IP backbone offering Internet services. Depending on whether or not the customer sites need full Internet routes, static routes or Border Gateway Protocol (BGP) is used for routing to the Internet. For full Internet routes, BGP is deployed between the PE routers and the PE Internet gateway to exchange Internet routes, and the global routing table on the PE routers is used to forward the customer traffic toward Internet destinations. The PE routers may or may not have the full Internet routing table. The PEs and the provider Internet gateway are in the same Internal BGP (IBGP) area.

The PE routers also use Multiprotocol BGP (MP-BGP) to support VPNs for their customers. The customers reach the global routing table by using a separate logical link for Internet access. Internet access through global routing on separate logical links is easy to set up, because it is the equivalent of the classical combination of Internet and VPN services that many customers use today. This setup is also compatible with all the Internet services required by some customers (for example, the requirement to receive full Internet routing from a service provider).

The drawback of this design is the increased complexity, or cost, of the provider edge-customer edge (PE-CE) connectivity. Separation of Internet and VPN connectivity requires either two separate physical links or a single physical link with encapsulation that supports subinterfaces (for example, Frame Relay).

Page 563: Implementing cisco mpls

7-10 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Internet Access as a Separate VPN This topic describes the benefits and drawbacks of having Internet access in a separate VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-9

Internet Access Through a Separate VPN Service

• Implementation through a separate VPN

• Benefit:

– The provider backbone is isolated from the Internet; increased security is realized.

• Drawback:

– All Internet routes are carried as VPN routes; full Internet routing cannot be implemented because of scalability problems.

For a service provider, implementing Internet access through a separate VPN is similar to offering another managed VPN service.

The major benefit of implementing Internet access as a separate VPN is increased isolation between the provider backbone and the Internet—which results in increased security for the provider. The flexibility of MPLS VPN topologies also provides for some innovative design options that allow service providers to offer services that were simply not possible to implement with pure IP routing.

The obvious drawback of running the Internet as a VPN in the MPLS VPN architecture is the scalability of such a solution. An Internet VPN simply cannot carry full Internet routing because of the scalability problems associated with having all the Internet routes inside a single VPN.

Page 564: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-11

Disadvantages of Providing Internet Access Through Route Leaking

A third variant for Internet support with MPLS VPNs is to provision route leaking into the global routing context. Although this not a recommended design, this option is briefly discussed to show an alternate practice that has been used in the industry.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-10

Internet Access Through Route Leaking

• Implementation through corporate VPN

• Benefit:

– Does not use a separate connection for Internet traffic

• Drawback:

– Insecure because Internet traffic is mingled with corporate traffic in the VPN

– Harder to apply security policies on mingled traffic

– Cannot implement full Internet routing because of scalability problems

Some customers may want to obtain Internet access across their corporate VPN by leaking routes between the VRF and global routing tables.

Note For security reasons, this approach is not recommended. It is not a good practice to

bring in Internet traffic using the corporate VPN. This practice negates the isolation of the

corporate VPN.

With route leaking, the customer site uses a static default route in the virtual routing and forwarding (VRF) table pointing to the global next-hop address of an Internet gateway. Any packets that use the default route leave the VPN space and are routed based on the global routing table at the PE that is the next-hop router. This feature allows “leaking” of VPN packets into the global address space.

The next-hop address for the static default route points to the interface where the Internet routes are learned on the Internet gateway. This interface address must be present within the global routing table so that label switching of the packets between the PE and Internet gateway router can occur. This means that the Internet gateway router must advertise its Internet interface address within the Interior Gateway Protocol (IGP) that runs across the service provider backbone.

Page 565: Implementing cisco mpls

7-12 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Because there is no redistribution between IP version 4 (IPv4) and VPN version 4 (VPNv4) routes, a mechanism is needed to allow the PE router to resolve the next-hop address for the Internet gateway from within the VRF. This is achieved through the use of the global keyword within the static default route configuration. The global keyword specifies that the next-hop address of the static route is resolved within the global routing table, not within the VRF.

Each of the customer IP subnets that are used as source addresses for Internet access must be advertised through the global BGP version 4 (BGP-4) process toward the Internet. The easiest solution for placing these routes in the global routing table is to configure further global static routes so that the VPN subnets appear within the global routing table as well as the VRF. This makes them available for advertisement via BGP-4. These static routes must point to an interface, with a next-hop address specified if the outbound interface is multiaccess (such as Ethernet). Then either these routes can be redistributed into BGP or the network command can be used within the BGP process. If redistribution is used, a route map can be utilized to specify which addresses to advertise.

Note This approach is not recommended. It is not discussed further in this course. This

option is briefly discussed only to show an alternate practice that has been used in the

industry.

Page 566: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-13

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-11

Summary

• Classical Internet access connects through a central firewall. You can use a centralized ISP managed firewall service.

• Multisite Internet access connects the firewall of every site. You can use a centralized ISP-managed firewall service.

• Wholesale Internet access service offers connectivity to multiple ISPs.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-12

Summary (Cont.)

• There are two recommended service provider designs for combining Internet access with MPLS VPN services:

– Global routing (Internet access not from a VPN), which uses separate interfaces that are not placed in any VRF

– Internet services as a separate VPN, which allows for service provider separation of backbone and Internet traffic

• Route leaking is insecure and not recommended because of this approach negates isolation of the corporate VPN.

Page 567: Implementing cisco mpls

7-14 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 568: Implementing cisco mpls

Lesson 2

Implementing Separate Internet Access and VPN Services

OverviewThis lesson describes implementing Internet access service totally separate from Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) services. It is important to understand why you may choose to use global routing to separate Internet access from VPN services.

This lesson identifies the provider edge-customer edge (PE-CE) requirements for separating Internet access from VPN services and describes how to implement the solution in an MPLS VPN network. This lesson is crucial for learners planning to enhance their usage of network resources using MPLS VPNs.

ObjectivesUpon completing this lesson, you will be able to describe the methods to separate Internet access from VPN services. This ability includes being able to meet these objectives:

Describe the features of classical Internet access for a VPN customer

Describe how separate subinterfaces are implemented to support Internet access using global routing

Describe how Internet access can be obtained for every customer site

Identify the benefits and limitations of separating Internet access from VPN services

Page 569: Implementing cisco mpls

7-16 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Classical Internet Access for a VPN Customer This topic describes the features of classical Internet access for a VPN customer on a shared service provider backbone.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-3

Classical Internet Access for a VPN Customer

The classical Internet access design for a customer is based on a separate Internet access model. One central customer site has connectivity to the Internet and provides access to the rest of the customer sites. The central site either connects through a firewall or runs the Cisco IOS firewall feature set.

In the shared service provider backbone, the provider edge (PE) routers have full or partial Internet routes to offer the customer. The provider’s Internet gateway (Internet-GW) is in the same Internal Border Gateway Protocol (IBGP) domain as the provider (P) and PE routers.

This design model can easily map to a customer with an MPLS VPN implementation. In this example, the customer network has been interconnected with an MPLS VPN. A central customer edge router (CE-Central) has Internet connectivity and provides Internet access through a firewall for all the sites in the customer network.

This traditional Internet access implementation model provides maximum design flexibility, because the Internet access is completely separated from the MPLS VPN services. However, the limitations of traditional IP routing prevent this implementation method from being used for innovative Internet access solutions, such as wholesale Internet access.

Page 570: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-17

Using Separate Subinterfaces For security reasons, the VPN and Internet routes to a customer should be on separate interfaces. This topic describes how separate subinterfaces can be used for implementing Internet access through global routing.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-4

Using Separate Subinterfaces

• Separate physical links for VPN and Internet traffic are sometimes not acceptable because of high cost.

• Subinterfaces could be used.

– Over WAN links using Frame Relay or ATM encapsulation (including xDSL)

– Over LAN links

• A tunnel interface could be used.

– Over a VRF-aware tunnel, so that VPN traffic does not run over a global tunnel

Instead of separate physical links for VPN and Internet traffic, subinterfaces can be used to create two logical links over a single physical link. Subinterfaces can be configured only on WAN links using Frame Relay or ATM encapsulation (including xDSL) and on LAN links using any VLAN encapsulation—Inter-Switch Link Protocol (ISL) or 802.1q.

For other encapsulation types, a tunnel interface can be used between the CE router and the PE router. Depending on the router platform and Cisco IOS version, virtual routing and forwarding (VRF)-aware tunnels are now supported.

VRF-aware tunnels remove the need for the endpoints of the tunnel to be in a global routing table.

Without a VRF-aware tunnel, MPLS VPN traffic would need to be tunneled across the Internet interface.

Note Further information on VRF-aware tunnels is outside the scope of this course.

Page 571: Implementing cisco mpls

7-18 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-5

Example Configuration: Static Routes

Example: Internet Access Through Static Routes Using static routing on the CE and the PE routers is the simplest and most common implementation for providing Internet access. The figure illustrates a configuration used to implement Internet access through two Frame Relay subinterfaces with static routes. In this simple example, CE-Central does not need to receive full Internet routing; it just needs a default static route to PE3 to reach the Internet. PE3 has a route to the Internet through Internet-GW, as well as a static route for the Customer A subnets pointing to CE-Central. The full Internet routing table needs to be present only on Internet-GW.

The following configuration steps are performed:

The customer VRF instance VPN-A is created.

The VPN subinterface (Serial0.1) is created and associated with data-link connection identifier (DLCI) 101. The subinterface is added to the VPN-A VRF.

The CE router is configured as a BGP neighbor inside the VPN in the VRF VPN-A with the neighbor ip-address remote-as as-number command in address-family ipv4 configuration mode.

A separate Internet subinterface (Serial0.2) is created and associated with DLCI 102.

A static route to the public CE routes is created and placed in the global routing table.

In addition to the PE configuration, the CE router implements a default static route pointing to 171.68.10.1 on PE3.

Note On the CE-Central router, distribution of the default route may be needed so that remote

sites can also access the Internet. Issues of security and private addresses would have to

be resolved.

Page 572: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-19

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-6

Example Configuration: Dynamic Routes

Example: Dynamic Internet Access Through a Separate Subinterface

The figure illustrates the configuration needed to implement Internet access through a dedicated Frame Relay interface. Some additional configuration steps are needed, compared to the previous static example:

The CE router is configured as a BGP neighbor in the global BGP process with the neighbor ip-address remote-as as-number command in router configuration mode.

A static route to the public CE routes is not needed, because the central CE will advertise the company routes to the PE through the BGP process

In this example, PE3 configures CE-Central as a BGP peer in the global BGP process using the non-VPN interface as the neighbor address. CE-Central will also need to establish peering with PE3 and announce the customer routes that it needs to advertise.

Note On the CE routers, static routes or redistribution may need to be implemented so that

appropriate customer sites can access the Internet. Issues of security and private addresses

would have to be resolved.

Page 573: Implementing cisco mpls

7-20 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-7

Internet Access Through a Dedicated Subinterface—Traffic Flow

Example: Internet Access Through a Dedicated Subinterface—Traffic Flow

The Internet traffic flow in this setup is identical to the traditional Internet traffic flow. When a packet is received from the CE router through the Internet subinterface, a lookup is performed in the global Forwarding Information Base (FIB) on the PE router, and the packet is forwarded toward the BGP next hop.

Page 574: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-21

Accessing the Internet from Every Customer Site This topic describes how Internet access is implemented at every customer site.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-8

• Every CE router needs two links (or subinterfaces) to its PE router.

• Using a separate link or links for Internet access will lead to a complex setup for this customer type.

Internet Access at Every Customer Site

Another option is to provide separate Internet access at every customer site. In this case, two physical (or logical) links between every CE router and its PE router would be needed. This design often becomes too complex or too expensive to implement. Issues including customer route propagation to the Internet and securing access at multiple access points would need to be resolved.

Note The allowas-in feature may need to be configured on the PE router if the customer is

propagating individual site routes to the Internet through BGP.

Page 575: Implementing cisco mpls

7-22 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Separate Internet Access Benefits and Limitations

This topic describes the benefits and limitations of separate Internet access.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-9

Benefits:

• Well-known model

• Supports all customer requirements

• Allows all Internet services implementations, including a BGP session with the customer

Drawbacks:

• This design model requires separate physical link or specific WAN encapsulation.

• PE routers must be able to perform Internet routing (and potentially carry full Internet routing).

• Wholesale Internet access or central firewall service cannot be implemented with this model.

Benefits and Limitations of Separate Internet Access for the Service Provider

The benefits of a separate Internet access design model are as follows:

It is a well-known and widely understood model.

It supports all customer requirements, including multihomed customer connectivity with full Internet routing.

This model allows all Internet services implementations, including BGP sessions with customers.

The drawbacks of this model are as follows:

It requires two dedicated physical links between the PE and the CE router or specific WAN or LAN encapsulations that might not be suitable for all customers.

The PE routers must be able to perform hop-by-hop Internet routing and use either the default route to reach the Internet or carry the full Internet routing table.

Advanced Internet access services (central managed firewall service or wholesale Internet access service) cannot be realized with this model at all.

Page 576: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-23

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-10

Summary

• Classical Internet access for a VPN customer is based on a separated Internet access design model

• Separate subinterfaces can be used for implementing Internet access through global routing

• Internet access from every customer site can be supported but is often too complex or too expensive with classic Internet access.

• The main drawback of separate Internet access is that PE routers potentially carry full Internet routing table

Page 577: Implementing cisco mpls

7-24 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 578: Implementing cisco mpls

Lesson 3

Implementing Internet Access as a Separate VPN

OverviewThis lesson describes the characteristics of Internet access solutions in which the Internet access is provided as a separate Virtual Private Network (VPN). The lesson identifies the scaling issues of this design, and discusses how to implement the design in a Multiprotocol Label Switching (MPLS) VPN network.

This lesson is crucial for learners planning to improve their usage of network resources using MPLS VPNs.

ObjectivesUpon completing this lesson, you will be able to describe the characteristics of implementing Internet access solutions in which the Internet access is provided as a separate VPN. This ability includes being able to meet these objectives:

Describe the features of using Internet access as a separate VPN

Describe the features of a redundant Internet access implementation

Configure classical Internet access for a VPN customer

Configure Internet access from every customer site

Describe how to implement wholesale Internet access

Identify the benefits and limitations of running an Internet backbone in a VPN

Page 579: Implementing cisco mpls

7-26 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Internet Access as a Separate VPN This topic describes the features of using a separate MPLS VPN to provide Internet access.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-3

• A provider Internet gateway is connected as a CE router to the MPLS VPN backbone.

• The Internet gateway does not insert full Internet routing into the Internet VPN.

– Only the default route and the local (regional) routes are inserted.

• Every customer site that needs Internet access is assigned to the same Internet VPN as the Internet gateway.

Internet Access as a Separate VPN

The MPLS VPN architecture can provision a separate VPN to provide Internet access for VPN customers. The service provider defines the Internet VPN and can use different MPLS VPN topologies to implement various types of Internet access. Under this design model, the provider Internet gateways appear as customer edge (CE) routers to the MPLS VPN backbone. Customer Internet access is enabled using a dual VPN topology supporting both an Internet VPN and a customer VPN across separate customer interfaces.

In this design, the Internet VPN should not contain the full set of global Internet routes, because that would make the solution completely nonscalable. The provider Internet gateway routers should announce a default route toward the provider edge (PE) routers. To optimize local routing, the local and regional Internet routes should be inserted in the Internet VPN.

Page 580: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-27

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-4

Internet Access as a Separate VPN (Cont.)

• The Internet VPN is isolated from the P routers.

When the service provider implements Internet access as a separate VPN, the Internet backbone is carried on a VPN, which is isolated from the provider backbone. This topology results in increased security for the provider backbone, because Internet hosts can reach only PE routers, not the core provider routers (P routers). The VPN customers are connected to the Internet simply through an additional virtual routing and forwarding (VRF) instance at the PE.

Page 581: Implementing cisco mpls

7-28 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Example: Configuring the Internet Gateway in a Separate VPN This section shows an example configuration implementing the Internet gateway in a separate VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-5

Example: Configuring the Internet Gatewayin a Separate VPN

The figure shows a sample configuration of the Internet-GW router with conditional default route advertisement. Router Internet-GW will advertise the default route to the PE-GW router only if Internet-GW can reach the network 192.168.0.0/16.

The following steps are used to configure this functionality:

Step 1 A static default route is configured toward a next hop in network 192.168.0.0. If the network 192.168.0.0 is not reachable, this static route will not enter the IP routing table.

Step 2 The default route origination is configured in the Border Gateway Protocol (BGP) routing process with the network command. The default route will be originated in BGP only if it is present in the IP routing table (which, based on Step 1, means that the network 192.168.0.0/16 is reachable).

Step 3 Prefix lists are used to filter BGP routing updates—the default route is sent only to the PE routers, not to the other Internet routers.

Step 4 PE-GW configures the Internet VRF and applies it to the appropriate interface.

Page 582: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-29

Implementing Redundant Internet Access This topic describes how to implement redundant Internet access.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-6

• The default route should be advertised by all Internet gateways only if they can reach the upstream ISP core.

Redundant Internet Access

Redundant Internet access is easy to achieve when the Internet service is implemented as a VPN in the MPLS VPN backbone:

Multiple Internet gateways (acting as CE routers) have to be connected to the MPLS VPN backbone to ensure router and link redundancy.

All Internet gateways advertise the default route to the PE routers, resulting in routing redundancy.

The Internet gateways also announce local Internet routes. Because these routes are announced with different BGP attributes (most notably, multi-exit discriminator [MED]), the PE routers select the proper Internet-GW router as the exit point toward those destinations.

The MED attribute can also be used to indicate the preferred default route to the PE routers. In this setup, one Internet-GW router acts as a primary Internet gateway, and the other Internet-GW router acts as a backup.

The redundancy established so far covers the path between customer sites and the Internet-GW routers. A failure in the Internet backbone might break the Internet connectivity for the customers if the Internet-GW routers announce the default route unconditionally. Conditional advertisement of the default route is therefore configured on the Internet-GW routers—the Internet-GW routers announce the default route to the PE routers only if the Internet-GW routers can reach an upstream destination.

Page 583: Implementing cisco mpls

7-30 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Implementing Classical Internet Access for a VPN Customer

This topic describes how to implement classical Internet access for a VPN customer.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-7

Classical Internet Access for a VPN Customer

The classical Internet access model can be easily implemented with the Internet VPN over the MPLS VPN backbone. The link between a PE router and the Internet-GW router is assigned to the Internet VRF as discussed before. Internet-GW announces a default route to the Internet.

One link between the PE router and each central customer router is assigned to the customer VRF, and one is assigned to the Internet VRF.

In this example, PE3 connects CE-Central of customer A to both the VPN-A VRF and the Internet VRF. A prefix list is used on PE3 in the Internet address family configuration to filter BGP advertisements to the CE-Central router.

Page 584: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-31

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-8

Classical Internet Access for a VPN Customer (Cont.)

The CE-Central router has two neighbor relationships with PE3. It announces the summary route for range of networks that have been assigned to customer A. These networks may be at remote locations.

In this example, the remote locations CE-A1 and CE-A2 will need a default route across VPN-A to reach CE-Central and through CE-Central reach the Internet.

If needed, an External BGP (EBGP) multihop session can be configured between the Internet gateway (Internet-GW) and the CE-Central router to give full Internet routes to the customer. These routes would not be injected into the Internet VRF.

Page 585: Implementing cisco mpls

7-32 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Implementing Internet Access from Every Customer Site

This topic describes how to implement Internet access from every customer site.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-9

• Configure Internet VRF for every location.

Internet Access from Every Customer Site

Internet access from every customer site can be implemented by configuring the Internet VRF at every location. This solution adds complexity for the customer, because firewall and NAT support may be needed at every site unless a central managed firewall service is offered by the service provider.

Page 586: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-33

Implementing Wholesale Internet Access This topic describes how to implement the wholesale Internet access model.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-10

• A separate VPN is created for each upstream ISP.

• Each ISP gateway announces the default route to the VPN.

• Customers are assigned into the VRF that corresponds to the VPN of the desired upstream ISP.

• Changing an ISP is as easy as reassigning an interface into a different VRF (and attending to address allocation issues).

Wholesale Internet Access

Wholesale Internet access is implemented by creating a separate VPN for every upstream Internet service provider (ISP). The Internet gateway of the upstream ISP (acting as a CE router toward the MPLS VPN-based Internet access backbone) announces a default route, which is used for routing inside the VPN.

Customers are tied to upstream service providers simply by placing the PE-CE link into the VRF associated with the upstream service provider. Changing an ISP becomes as easy as reassigning the interface into a different VRF and attending to address allocation issues. For customers using access methods supporting dynamic address allocation (for example, dialup or cable), the new customer IP address is assigned automatically from the address space of the new ISP.

Page 587: Implementing cisco mpls

7-34 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Running an Internet Backbone in a VPN This topic identifies the benefits and limitations of running an Internet backbone in a VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-11

Benefits:

• Supports all Internet access service types

• Can support all customer requirements, including a BGP session with the customer, accomplished through advanced BGP setup

Drawbacks:

• Full Internet routing cannot be carried in the VPN;default routes are needed that can lead to suboptimal routing.

• Internet gateway routers act as CE routers on the VPN backbone; implementing overlapping Internet and VPN backbones requires care.

Limitations of Running an Internet Backbone in a VPN

Internet access implemented as a separate VPN has the following benefits:

This design model supports all Internet access services, ranging from traditional Internet access to innovative services such as wholesale Internet access.

This design also supports all customer requirements, including full Internet routing on customer routers through an EBGP multihop session with the Internet gateway (Internet-GW).

Internet access implemented as a separate VPN has the following drawbacks:

Full Internet routing cannot be carried inside a VPN; therefore, default routing toward the Internet gateways has to be used, potentially resulting in suboptimal routing.

The Internet backbone gateway router is positioned as a customer edge route connected to the MPLS VPN backbone. If the service provider runs Internet service and MPLS VPN service on the same set of routers, the interconnection between the two services requires special considerations.

The benefits of the separate VPN design far outweigh the limitations.

Note An MPLS VPN extension is carrier supporting carrier (CSC). The CSC feature enables one

MPLS VPN-based service provider to allow other service providers to use a segment of its

backbone network. Discussion of the CSC feature is not within the scope of this course.

Page 588: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-35

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-12

Summary

• MPLS VPN architecture supports defining the Internet as a VPN.

– Redundant Internet access is easy to achieve.

– The classical Internet access model can be easily implemented using the Internet VPN.

• Internet access from every customer site can be implemented by configuring the Internet VRF on a second interface at every location

• Wholesale Internet access can be implemented by creating a separate VPN for every upstream ISP.

• Internet VPNs supports all customer requirements, including full Internet routing.

Page 589: Implementing cisco mpls

7-36 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Module Summary This topic summarizes the key points that were discussed in this module.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-1

Module Summary

• Separating Internet access from VPN services can be accomplished though use of logical subinterfaces.

• Classical Internet access uses a separate logical IPv4 interface.

• MPLS VPN architecture can implement the Internet as another VPN.

There are several different models that are used to combine Internet access with Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) services. Each model has benefits and drawbacks. It is important to understand the implications of implementing the various models.

ReferencesFor additional information, refer to this resource:

Access Cisco.com for additional information about MPLS Internet access.

MPLS Internet Connectivity Options http://www.cisco.com/en/US/tech/tk436/tk428/technologies_white_paper09186a00801281f1.shtml

Page 590: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-37

Module Self-Check Use the questions here to review what you learned in this module. The correct answers and solutions are found in the Module Self-Check Answer Key.

Q1) What is the major drawback of the classical Internet access model? (Source:

Introducing Internet Access Models with MPLS VPNs)

A) All of the customer Internet traffic passes through the central firewall service. B) None of the customer Internet traffic passes through the central firewall

service.C) Only some of the customer Internet traffic passes through the central firewall

service.D) There is no drawback.

Q2) When the wholesale Internet access solution is implemented, which statement is

correct? (Source: Introducing Internet Access Models with MPLS VPNs)

A) The downstream ISP allocates a portion of its address space to the end users connected to the Internet access backbone.

B) The upstream ISP allocates a portion of its address space to the end users connected to the Internet access backbone.

C) Both the upstream and downstream ISPs must allocate a portion of their address space to the end users connected to the Internet access backbone.

D) None of the above is correct.

Q3) What are the two major design models for implementing Internet access and MPLS

VPNs? (Choose two.) (Source: Introducing Internet Access Models with MPLS VPNs)

A) using a separate VPN for Internet access B) using global route leaking C) using global routing on PE routers D) using default routes

Q4) What are two major benefits of using VPNs to provide Internet access? (Choose two.)

(Source: Introducing Internet Access Models with MPLS VPNs)

A) Only some of the customer Internet traffic needs to pass through a firewall. B) The provider backbone is isolated from the Internet. C) Security is increased. D) The Internet VRF can support full Internet routes.

Q5) What is the recommended implementation option for using global routing to provide

Internet access? (Source: Introducing Internet Access Models with MPLS VPNs)

A) The separate subinterfaces are placed in separate VRFs. B) The Internet subinterface is not placed in a VRF. C) One interface for the Internet and the MPLS VPN is recommended. D) Static routes are always needed for Internet access.

Page 591: Implementing cisco mpls

7-38 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q6) Which is the main benefit of using separate interfaces or subinterfaces to provide

Internet access? (Source: Introducing Internet Access Models with MPLS VPNs)

A) Wholesale Internet access or central firewall service cannot be implemented. B) It is easy to implement internal BGP sessions between the PE router and CE

router.C) They are well-known and are easy to implement. D) The separate subinterfaces are placed in separate VRFs.

Q7) The traditional Internet access implementation model provides _____. (Source:

Implementing Separate Internet Access and VPN Services)

A) minimum design flexibility, because the Internet access is completely separated from the MPLS VPN services

B) maximum design flexibility, because the Internet access is completely separated from the MPLS VPN services

C) the ability to put the separate subinterfaces into separate VRFs D) no ability to use wholesale Internet services

Q8) In situations where cost prohibits separate physical links for VPN and Internet traffic

for classical Internet access, _____. (Source: Implementing Separate Internet Access

and VPN Services)

A) the Internet access should be integrated with the MPLS VPN through route leaking

B) the Internet access should be integrated with the MPLS VPN through route peaking

C) VRFs can be used to create two logical links over a single physical link D) subinterfaces can be used to create two logical links over a single physical link

Q9) Which setup for a VPN customer is based on a separated Internet access design model?

(Source: Implementing Separate Internet Access and VPN Services)

A) classical Internet access B) route peaking C) route leaking D) classical Intranet access

Q10) For customers that need Internet access from every site, two physical (or logical) links

between every CE router and its PE router might be _____. (Source: Implementing

Separate Internet Access and VPN Services)

A) too complex to implement B) too expensive to implement C) too complex and too expensive to implement D) the most secure solution to implement

Q11) The Internet VPN should _____. (Source: Implementing Internet Access as a Separate

VPN)

A) contain the full set of Internet routes because that would supportable optimal routing

B) not contain the full set of Internet routes because that would make the solution completely nonscalable

C) support route leaking because that would make the solution completely scalable

D) not be used for optimal scalability

Page 592: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Internet Access and MPLS VPNs 7-39

Q12) What should multiple provider Internet gateways in the Internet VPN advertise to the

PE routers? (Source: Implementing Internet Access as a Separate VPN)

A) the full set of Internet routes, because that would support optimal routing B) any leaked routes, to support optimal routing C) the full set of Internet routes, because that would provide redundant routing D) the default route, for routing redundancy

Q13) In a classical Internet access using the separate VPN model, the link between a PE

router and the Internet gateway router is assigned to the _____ VRF, and the link

between a PE router and the CE-Central router is assigned to the _____ VRF. (Source:

Implementing Internet Access as a Separate VPN)

A) Internet, customer B) customer, Internet C) Internet, Internet D) customer, customer

Q14) The main disadvantage of having Internet access at every customer site is that _____.

(Source: Implementing Internet Access as a Separate VPN)

A) this option cannot be implemented with a VPN solution B) firewall services would be needed at every site C) any leaked routes support suboptimal routing D) wholesale Internet access cannot be implemented

Q15) A central managed firewall service can be implemented by _____. (Source:

Implementing Internet Access as a Separate VPN)

A) creating a separate Internet VPN for every customer B) assigning customers to their ISPs by default routes in the Internet VRF C) creating a separate customer VPN D) implementing the managed firewall service through the Internet gateway

Q16) Wholesale Internet access can be implemented by _____. (Source: Implementing

Internet Access as a Separate VPN)

A) creating a separate VPN for every upstream ISP B) assigning customers to their ISPs by default routes in the Internet VRF C) creating a separate VPN for every customer D) propagating full Internet routes into the Internet VRF

Q17) Which two are drawbacks of Internet access that is implemented as a separate VPN?

(Choose two.) (Source: Implementing Internet Access as a Separate VPN)

A) Full Internet routing cannot be carried inside a VRF. B) The customer has no ability to receive full Internet routes. C) Default routing toward the Internet gateways has to be used, which can

potentially result in suboptimal routing. D) The customer must use default routes.

Page 593: Implementing cisco mpls

7-40 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Module Self-Check Answer Key Q1) A

Q2) B

Q3) A, C

Q4) B, C

Q5) B

Q6) C

Q7) B

Q8) D

Q9) A

Q10) C

Q11) B

Q12) D

Q13) C

Q14) B

Q15) D

Q16) A

Q17) A, C

Page 594: Implementing cisco mpls

Module 8

MPLS TE Overview

OverviewThis module provides a brief overview of Multiprotocol Label Switching (MPLS) traffic engineering (TE). The module covers the requirement for TE in modern networks and presents the basic concepts and mechanics that support TE, including tunnel path discovery with link-state protocols and tunnel path signaling with Resource Reservation Protocol (RSVP). The module describes the basic MPLS TE commands for the implementation of MPLS traffic tunnels.

Module Objectives Upon completing this module, you will be able to describe the tasks and commands that are necessary to implement MPLS TE. This ability includes being able to meet these objectives:

Identify basic TE and MPLS TE concepts

Identify MPLS TE components

Create and configure MPLS TE

Monitor basic MPLS TE on Cisco IOS platforms

Page 595: Implementing cisco mpls

8-2 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 596: Implementing cisco mpls

Lesson 1

Introducing the TE Concept

OverviewThis lesson describes the concepts that allow service providers and enterprises to map traffic through specific routes to optimize network resources, especially bandwidth. Traffic engineering (TE) enables backbone networks to be engineered to deliver the total subscribed capacity to customers more efficiently.

This lesson is a helpful introduction for learners who are planning to improve the usage of their network resources with Multiprotocol Label Switching (MPLS) TE.

ObjectivesUpon completing this lesson, you will be able to describe the basic TE concepts. This ability includes being able to meet these objectives:

Identify the concepts behind TE

Identify the major business drivers for implementing TE

Identify congestion avoidance and describe how TE can reduce some congestion-avoidance issues

Identify how TE is implemented using a Layer 2 overlay model

Identify how TE is implemented using a Layer 3 model

Identify how TE is implemented using the MPLS TE model

Page 597: Implementing cisco mpls

8-4 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

What Is TE? This topic identifies the underlying concepts of TE.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-3

What Is Traffic Engineering?

• Traffic engineering is manipulating your traffic to fit your network.

• Network engineering is building your network to carry your predicted traffic.

• TE is commonly used in voice telephony networks.

• TE is a process of measures, models, and controls of traffic to achieve various goals.

• TE for data networks provides an integrated approach to managing traffic at Layer 3.

Traffic engineering (TE) can be contrasted to network engineering:

Traffic engineering is manipulating your traffic to fit your network

Network engineering is building your network to carry your predicted traffic

TE has been widely used in voice telephony. TE means that the traffic is measured and analyzed. A statistical model is then applied to the traffic pattern to make a prognosis and estimates.

If the anticipated traffic pattern does not match the network resources well, the network administrator remodels the traffic pattern. Such decisions can be made to achieve a more optimal use of the resources or to reduce costs by selecting a cheaper transit carrier.

In the data communications world, traffic engineering provides an integrated approach to engineering traffic at Layer 3 in the Open Systems Interconnection (OSI) model. The integrated approach means that routers are configured to divert traffic from destination-based forwarding and move the traffic load from congested parts of the network to uncongested parts.

Traditionally, this diversion has been done using overlay networks where routers use carefully engineered ATM permanent virtual circuits (PVCs) or Frame Relay PVCs to distribute the traffic load on Layer 2.

Page 598: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-5

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-4

What Is Traffic Engineering? Traffic Engineering Motivations

• Reduce the overall cost of operations by more efficient use of bandwidth resources

• Prevent a situation where some parts of a network are overutilized (congested), while other parts remain underutilized

• Implement traffic protection against failures

• Enhance SLA in combination with QoS

Cost reduction is the main motivation for TE.

A cost savings, which results from a more efficient use of resources, will help to reduce the overall cost of operations.

Additionally, more efficient use of bandwidth resources means that a service provider or enterprise network manager can avoid a situation where some parts of a network are congested, while other parts are underutilized.

Because TE can be used to control traffic flows, it can also be used to provide protection against link or node failures by providing backup tunnels.

Finally, when combined with quality of service (QoS) functionality, TE can provide enhanced service level agreements (SLAs).

Page 599: Implementing cisco mpls

8-6 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Business Drivers for TE This topic identifies some business drivers that may lead to implementation of TE.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-5

Business Drivers for Traffic Engineering

• Routers forward traffic along the least-cost route discovered by routing protocols.

• Network bandwidth may not be efficiently utilized:

– The least-cost route may not be the only possible route.

– The least-cost route may not have enough resources to carry all the traffic.

– Alternate paths may be underutilized.

In a Layer 3 routing network, packets are forwarded hop by hop. In each hop, the destination address of the packet is used to make a routing table lookup. The routing tables are created by an Interior Gateway Protocol (IGP), which finds the least-cost route, according to its metric, to each destination in the network.

In many networks, this method works well. But in some networks, the destination-based forwarding results in the overutilization of some links, while others are underutilized. This imbalance will be the case when there are several possible routes to reach a certain destination. The IGP selects one of them as the best and uses only that route. In the extreme case, the best path may have to carry so large a volume of traffic that packets are dropped, while the next-best path is almost idle.

One solution to the problem would be to adjust the link bandwidths to more appropriate values. The network administrator could reduce the bandwidth on the underutilized link and increase the bandwidth on the overutilized one. However, making this adjustment is not always possible.

The alternate path is a backup path. In the case of a primary link failure, the backup must be able to forward at least the major part of the traffic volume that is normally forwarded by the primary path. Therefore, it may not be possible to reduce the bandwidth on the backup path. And without a cost savings, the budget may not allow an increase to the primary link bandwidth.

Page 600: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-7

To provide better network performance within the budget, network administrators move a portion of the traffic volume from the overutilized link to the underutilized link. During normal operations, this move results in fewer packet drops and quicker throughput. In the case of a failure to any of the links, all traffic is forwarded over the remaining link, which then, of course, becomes overutilized.

Moving portions of the traffic volume cannot be achieved by traditional hop-by-hop routing using an IGP for path determination.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-6

Business Drivers for Traffic Engineering(Cont.)

• Lack of resources results in congestion in two ways:

– When network resources themselves are insufficient to accommodate offered load

– When traffic streams are inefficiently mapped onto available resources

• Some resources are overutilized while others remain underutilized.

Network congestion, caused by too much traffic and too few network resources, cannot be solved by moving portions of the traffic between different links. Moving the traffic will help only in the case where some resources are overutilized and others are underutilized. The traffic streams in normal Layer 3 routing are inefficiently mapped onto the available resources.

Good mapping of the traffic streams onto the resources constitutes better use of the money invested in the network.

Cost savings that result in a more efficient use of bandwidth resources help to reduce the overall cost of operations. These reductions, in turn, help service providers and organizations gain an advantage over their competitors. This advantage becomes more and more important as the service provider market gets more and more competitive.

A more efficient use of bandwidth resources means that a provider could avoid a situation where some parts of its network are congested while other parts are underutilized.

Page 601: Implementing cisco mpls

8-8 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Congestion Avoidance and TE This topic discusses congestion avoidance and how TE can reduce some congestion issues.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-7

Congestion Avoidance and Traffic Engineering

Network congestion can be addressed by either:

• Expansion of capacity or classical congestion control techniques (queuing, rate limiting, and so on)

• Traffic engineering, if the problems result from inefficient resource allocation

The focus of TE is not on congestion created as a result of a short-term burst, but on congestion problems that are prolonged.

TE does not solve temporary network congestion that is caused by traffic bursts. This type of problem is better handled by an expansion of capacity or by classical techniques such as various queuing algorithms, rate limiting, and intelligent packet dropping. TE does not solve problems when the network resources themselves are insufficient to accommodate the required load.

TE is used when the problems result from inefficient mapping of traffic streams onto the network resources. In such networks, one part of the network suffers from prolonged congestion, possibly continuously, while other parts of the network have spare capacity.

Page 602: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-9

TE with a Layer 2 Overlay Model This topic discusses the use of a Layer 2 overlay model with TE.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-8

Traffic Engineering with a Layer 2 Overlay Model

• The use of the explicit Layer 2 transit layer allows very exact control of how traffic uses the available bandwidth.

• PVCs or SVCs carry traffic across Layer 2.

• Layer 3 at the edge sees a complete mesh.

In the Layer 2 overlay model, the routers (Layer 3 devices) are overlaid on top of the Layer 2 topology. The routers are not aware of the physical structure and the bandwidth that is available on the links. The IGP views the PVCs or switched virtual circuits (SVCs) as point-to-point links and makes its forwarding decisions accordingly.

All engineering is done at Layer 2. PVCs are carefully engineered across the network, normally using an offline management system. SVCs are automatically established using signaling, and their way across the Layer 2 network is controlled by integrated path determination, such as the Private Network-to-Network Interface (PNNI) protocol.

In the Layer 2 overlay model, PVCs or SVCs carry the traffic across the network. With a Frame Relay network, PVC setup is most often made using a management tool that helps the network administrator calculate the optimum path across the Layer 2 network with respect to available bandwidth and other constraints that may be applied on individual links.

ATM may use the same type of tools as Frame Relay for PVC establishment or may use the SVC approach, where routers use a signaling protocol to dynamically establish an SVC.

If the Layer 2 network provides a full mesh between all routers, the Layer 3 IGP sees all the other routers as directly connected and, most likely, uses the direct logical link whenever it forwards a packet to another router. The full mesh gives Layer 2 full control of the traffic load distribution. Manual engineering of PVCs and the configuration of PNNI parameters are the tools that allow very exact control of how the traffic uses the available bandwidth.

Page 603: Implementing cisco mpls

8-10 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-9

Traffic Engineering with a Layer 2 Overlay Model: Example

Traffic engineering in Layer 2, using the overlay model, allows detailed decisions about which link should be used to carry various traffic patterns.

In this example, traffic from R2 to R3 uses the red PVC (solid arrows), which takes the shortest path using the upper transit switch.

However, traffic from R1 to R3 uses the blue PVC (dashed arrows), which does not take the shortest path. TE on Layer 2 has been applied to let the second PVC use links that would otherwise have been underutilized. This approach avoids overutilization of the upper path.

Page 604: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-11

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-10

Traffic Engineering with a Layer 2 Overlay Model (Cont.)

Drawbacks of the Layer 2 overlay solution

• Extra network devices

• More complex network management:

– Two-level network without integrated network management

– Additional training, technical support, field engineering

• IGP routing scalability issue for meshes

• Additional bandwidth overhead (“cell tax”)

• No differential service (class of service)

Using the Layer 2 overlay model has several drawbacks:

The routers are not physically connected to other routers. The Layer 2 network introduces the need for an additional device, the ATM or Frame Relay switch.

Two networks must be managed. The Layer 2 network requires its own management tools, which, among several other tasks, support TE as well. At the same time, the router network (Layer 3), with its IGP and tuning parameters, must be managed. Both these management tasks require trained staff for technical support and in the field.

The Layer 3 network must be highly meshed to take advantage of the benefits that are provided by the Layer 2 network. The highly meshed network may cause scalability problems for the IGP because of the large number of neighbors.

Overlay networks always require an extra layer of encapsulation. A Frame Relay header must be added to the IP packets, or, when ATM is used, the IP packet must be segmented into cells, each of which must have its own header. The extra layer of encapsulation causes bandwidth overhead.

The Layer 2 devices do not have any Layer 3 knowledge. After the router has transmitted the IP packet across the physical link to the first switch, all IP knowledge is lost. When congestion does occur in the Layer 2 network, the switches have no ability to selectively discard IP packets or to requeue them. Thus, no IP differentiated services can be used within the Layer 2 switch network.

Page 605: Implementing cisco mpls

8-12 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

TE with a Layer 3 Model This topic discusses the use of a Layer 3 model with TE.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-11

Layer 3 Model with No Traffic Engineering

If the same network topology is created using routers (Layer 3 devices), TE must be performed differently. In the example here, if no traffic engineering is applied to the network, traffic from both R8 and R1 toward R5 will use the least-cost path (the upper path). This flow may result in the overutilization of the path R2, R3, R4, R5, while the path R2, R6, R7, R4, R5 will be underutilized.

Page 606: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-13

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-12

Traffic Engineering with a Layer 3 Model (Cont.)

The current forwarding paradigm, centered around “destination-based,” is clearly inadequate:

• Path computation based just on IGP metric is not enough.

• Support for “explicit” routing (source routing) is not available.

• Supported workarounds are static routes, policy routing.

• Provide controlled backup and recovery.

The destination-based forwarding paradigm that is currently used in Layer 3 networks cannot resolve the problem of overutilization of one path while an alternate path is underutilized.

The IGP uses its metric to compute a single best way to reach each destination. There are problems with Layer 3 TE:

IP source routing could be used to override the IGP-created routing table in each of the intermediate routers. However, in a service provider network, source routing is most often prohibited. The source routing would also require the host to create the IP packets to request source routing. The conclusion is that source routing is not an available tool for TE.

Static routing, which overrides the IGP, can be used to direct traffic to take a different path than that of other traffic. However, static routing does not discriminate among various traffic flows based on the source. Static routing also restricts how redundancy in the network can be used.

Policy-based routing (PBR) is able to discriminate packet flows based on the source, but it suffers from low scalability and the same static routing restrictions as to how redundancy can be used.

Page 607: Implementing cisco mpls

8-14 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

TE with the MPLS TE Model This topic discusses using TE with the MPLS TE model.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-13

Traffic Engineering with the MPLS TE Model

• Tunnel is assigned labels that represent the path (LSP) through the system.

• Forwarding within the MPLS network is based on labels (no Layer 3 lookup).

In the MPLS TE implementation, routers use MPLS label switching with TE.

The aim is to control the paths along which data flows, rather than relying simply on destination-based routing. MPLS TE uses tunnels to control the data flow path. An MPLS TE tunnel is simply a collection of data flows that share some common attribute. This attribute might be all traffic sharing the same entry point to the network and the same exit point.

A TE tunnel maps onto an MPLS label-switched path (LSP). After the data flows and the TE tunnels are defined, MPLS technology is used to forward traffic across the network. Data is assigned an MPLS TE, which defines the route taken through the network. The packets that are forwarded under MPLS TE have a stack of two labels imposed by the ingress router. The topmost label identifies a specific LSP or TE tunnel to use to reach another router at the other end of the tunnel. The second label indicates what the router at the far end of the tunnel should do with the packet.

Note Additional details on MPLS tunnels are covered in the next lesson.

Page 608: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-15

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-14

Traffic Engineering with the MPLS TE Model (Cont.)

• The MPLS TE LSPs are created by RSVP.

• The actual path can be specified:

– Explicitly defined by the system administrator

– Dynamically defined using the underlying IGP protocol

For MPLS TE, manual assignment and configuration of the labels can be used to create LSPs to tunnel the packets across the network on the desired path. However, to increase scalability, the Resource Reservation Protocol (RSVP) is used to automate the procedure.

By selecting the appropriate LSP, a network administrator can direct traffic via explicitly indicated routers. The explicit path across identified routers provides benefits that are similar to those of the overlay model without introducing a Layer 2 network. This approach also eliminates the risk of running into IGP scalability problems because of the many neighbors that exist in a full mesh of routers.

MPLS TE provides mechanisms equivalent to those described previously in this lesson in connection with the Layer 2 overlay network. For circuit-style forwarding, instead of using ATM or Frame Relay virtual circuits, the MPLS TE tunnel is used. For signaling, RSVP is used with various extensions to set up the MPLS TE tunnels.

For constraint-based routing (CBR) used in MPLS TE, either Intermediate System-to-Intermediate System (IS-IS) or Open Shortest Path First (OSPF) with extensions is used to carry resource information, such as available bandwidth on the link. Both link-state protocols use new attributes to describe the nature of each link with respect to the constraints. A link that does not have the required resource is not included in the MPLS TE tunnel.

To actually direct the traffic onto the MPLS TE tunnels, network administrators need extensions to IS-IS and OSPF. Directing the traffic into tunnels results in the addition of entries in the Forwarding Information Base (FIB). The IP packets are directed into the MPLS TE tunnel by imposing the correct label stack.

Page 609: Implementing cisco mpls

8-16 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-15

Summary

Traffic engineering measures, models, and controls traffic to achieve various goals.

• TE is driven by inefficient bandwidth utilization.

• TE focuses on prolonged congestion problems.

• With the TE Layer 2 overlay model, routers are not aware of the physical structure and bandwidth available on links.

• With the TE Layer 3 model, the destination-based forwarding paradigm cannot handle the problem of overutilization of one path while an alternate path is underutilized.

• TE with the MPLS TE model means that the routers use the MPLS label-switching paradigm.

ReferencesFor additional information, refer to this resource:

RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels

Page 610: Implementing cisco mpls

Lesson 2

Understanding MPLS TE Components

OverviewThis lesson explains the components of Multiprotocol Label Switching (MPLS) traffic engineering (TE), such as traffic tunnels (along with associated characteristics and attributes), tunnel path discovery based on link-state protocols, and tunnel setup signaling with Resource Reservation Protocol (RSVP).

ObjectivesUpon completing this lesson, you will be able to describe the basic components of MPLS TE. This ability includes being able to meet these objectives:

Identify, at a conceptual level, how a traffic tunnel functions

Identify traffic tunnel characteristics

Identify traffic tunnel attributes

Identify the relation between network links and link attributes

Identify the function of constraint-based path computation

Identify TE procedures

Identify the role of RSVP in path setup and admission contol

Identify how using TE modifies the forwarding table mechanisms

Page 611: Implementing cisco mpls

8-18 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Traffic Tunnels: Concepts This topic describes the concept of traffic tunnels.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-3

The concept of MPLS TE traffic tunnels was introduced to overcome the limitations of hop-by-hop IP routing:

• A tunnel is an aggregation of traffic flows that are placed inside a common MPLS label-switched path.

• Flows are then forwarded along a common path within a network.

Traffic Tunnels: Concepts

The aim of TE is to control the paths along which data flows, rather than relying simply on “normal” destination-based routing. To fulfill this aim, the concept of a “traffic tunnel” has been introduced.

A traffic tunnel is simply a collection of data flows that share some common attribute:

Most simply, this attribute might be the sharing of the same entry point to the network and the same exit point. In practice, this point could be an Internet service provider (ISP) network, where there is a definable data flow from the points of presence (POPs), where the customers attach to the ISP network. There are also the Internet exchange points (IXPs), where data typically leaves the ISP network to traverse the Internet.

In a more complex situation, this attribute could be augmented by defining separate tunnels for different classes of service. For example, in an ISP model, leased-line corporate customers could be given a preferential throughput over dial-in home users. This preference might be greater guaranteed bandwidth or lower latency and higher precedence. Even though the traffic enters and leaves the ISP network at the same points, different characteristics could be assigned to these types of users by defining separate traffic tunnels for their data.

Page 612: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-19

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-4

Traffic Tunnels: Concepts (Cont.)

• Unidirectional single class of service model encapsulates all of the traffic between an ingress and an egress router.

• Different classes of service model assigns traffic into separate tunnels with different characteristics.

Defining traffic trunks (tunnels) requires an understanding of the traffic flows in the network. By understanding the ingress and corresponding egress points, a picture of the traffic flows in the network can be produced.

In the example, there are two traffic tunnels (TT1 and TT2) that are defined for data from PE1 to PE3. These tunnels are unidirectional; they identify the traffic flows from PE1.

Note In practice, there are probably similar tunnels operating in the opposite direction, to PE1.

There may also be tunnels that are defined from all the other routers to each other. Defining tunnels from every router in the network to every router might sound like an administrative nightmare. However, this is not usually the case for the following reasons:

The routers that are identified are on the edge of the network. The traffic tunnels link these routers across the core of the network.

In most networks it is relatively easy to identify the traffic flows, and they rarely form a complete “any-to-any” mesh.

For example, in ISP networks, the traffic tunnels generally form a number of star formations, with their centers at the IXPs and the points at the POPs. Traffic in an ISP network generally flows from the customers that are connected at the POPs to the rest of the Internet (reached via the IXPs). A star-like formation can also exist in many networks centering on the data center. This tendency is found in both ISP networks (providing web-hosting services) and enterprise networks.

After the data flows, and therefore the traffic tunnels, are defined, the technology that they use to forward the data across the network is MPLS. Data that enters a traffic tunnel is assigned an MPLS label-switched path (LSP). The LSP defines the route that is taken through the network.

Page 613: Implementing cisco mpls

8-20 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Traffic Tunnels: Characteristics This topic describes the characteristics of traffic tunnels.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-5

Traffic Tunnels – Characteristics

• A traffic tunnel is distinct from the MPLS LSP through which it traverses:

– More than one TE tunnel can be defined between two points:

• Each tunnel may pick the same or different paths through the network

• Each tunnel will use different MPLS labels

– A traffic tunnel can be moved from one path onto another based on resources in the network.

• A traffic tunnel is configured by defining its required attributes and characteristics.

Traffic tunnels are distinct from the MPLS LSPs that they use in two key ways:

There is a one-to-one mapping of traffic tunnels onto MPLS LSPs. Two tunnels may be defined between two points and may happen to pick the same path through the network. However, they will use different MPLS labels.

Traffic tunnels are not necessarily bound to a particular path through the network. As resources change in the core, or perhaps as links fail, the traffic tunnel may reroute, picking up a new MPLS LSP as it does.

Configuring the traffic tunnels includes defining the characteristics and attributes that it requires. In fact, defining the characteristics and attributes of traffic tunnels is probably the most important aspect of TE. Without a specification of the requirements of the data in a traffic tunnel, the data might as well be left to route “normally” based only on destination information over the least-cost path.

Page 614: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-21

Traffic Tunnels Attributes

This topic describes the attributes of traffic tunnels.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-6

Traffic Tunnels – Attributes

• Attributes are explicitly assigned through administrative action.

• A traffic tunnel is characterized by:

– Its ingress (headend) and egress (tailend) label switch routers

– The forwarding equivalence class that is mapped onto it

– A set of attributes that determine its characteristics

A traffic tunnel is a set of data flows sharing some common feature, attribute, or requirement. If there is no characteristic in the data flow in common with some other flow, there is nothing to define that data as part of a flow or group of flows.

Therefore, the traffic tunnel must include attributes that define the commonality between the data flows making up the tunnel. The attributes that characterize a traffic tunnel include the following:

Ingress and egress points: These points are, fundamentally, the routers at the ends of the tunnel. They are the most basic level of commonality of data flows, given that the flows in a tunnel all start in the same place and end in the same place.

Complex characteristics of the data flows: Examples are bandwidth and latency and precedence requirements.

Class of data: This attribute defines what data is part of this tunnel and what is not. This definition includes such characteristics as traffic flow, class of service, and application class.

The network administrator defines the attributes of a traffic tunnel when the tunnel itself is defined. However, some of these attributes are, in part, influenced by the underlying network and protocols.

Note MPLS TE setup is a control plane function.

Page 615: Implementing cisco mpls

8-22 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-7

Traffic Tunnels–Attributes (Cont.)

The administrator enters the relevant information (attributes) at the headend of the traffic tunnel:

• Traffic parameter—Resources required for tunnel (for example, required bandwidth)

• Generic path selection and management—Path can be administratively specified or computed by the IGP

• Resource class affinity—Include or exclude certain links for certain traffic tunnels

• Adaptability—Should the traffic tunnel be reoptimized?

• Priority and preemption—Importance of a traffic tunnel and possibility for a preemption of another tunnel

• Resilience—Desired behavior under fault conditions

The general tunnel characteristics must be configured by the network administrator to create the tunnel. This configuration includes some or all of the following:

Traffic parameters: Traffic parameters are the resources that are required by the tunnel, such as the minimum required bandwidth.

Generic path selection and management: This category refers to the path selection criteria. The actual path that is chosen through the network could be statically configured by the administrator or could be assigned dynamically by the network, based on information from the Interior Gateway Protocol (IGP), which is Intermediate System-Intermediate System (IS-IS) or Open Shortest Path First (OSPF).

Resource class affinity: This category refers to restricting the choice of paths by allowing the dynamic path to choose only certain links in the network.

Note This restriction can also be accomplished by using the IP address exclusion feature.

Adaptability: Adaptability is the ability of the path to reroute on failure or to optimize on recovery or discovery of a better path.

Priority and preemption: Traffic tunnels can be assigned a priority (0 to 7) that signifies their “importance.” When you are setting up a new tunnel or rerouting, a higher-priority tunnel can tear down (preempt) a lower-priority tunnel; in addition, a new tunnel of lower priority may fail to set up because some tunnels of a higher priority already occupy the required bandwidth of the lower-priority tunnel.

Resilience: Resilience refers to how a traffic tunnel responds to a failure in the network. Does it attempt to reroute around failures or not?

Page 616: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-23

Network Links and Link Attributes This topic discusses the relationship between network links and link attributes.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-8

Network Links and Link Attributes

Resource attributes (link availability) are configured locally on the router interfaces:

• Maximum bandwidth

– The amount of bandwidth available

• Link affinity string

– To allow the operator to administratively include or exclude links in path calculations

• Constraint-based specific metric

– TE default metric

For the tunnel to dynamically discover its path through the network, the headend router must be provided with information on which to base this calculation. Specifically, it needs to be provided with the following:

Maximum bandwidth: The maximum bandwidth is the amount of bandwidth that is available on each link in the network. Because there are priority levels for traffic tunnels, the availability information must be sent for each priority level for each link. Including priority levels means that the path decision mechanism is given the opportunity to choose a link with some bandwidth already allocated to a lower-priority tunnel, forcing that lower-priority tunnel to be “bounced” off the link.

Link resource class: For administrative reasons, the network administrator may decide that some tunnels are not permitted to use certain links. To accomplish this goal, for each link, a link resource class must be defined and advertised. The definition of the tunnel may include a reference to particular “affinity bits.” The tunnel affinity bits are matched against the link resource class to determine whether a link may be used as part of the LSP.

Constraint-based specific metric: Each link has a cost or metric for calculating routes in the normal operation of the IGP. It may be that, when calculating the LSP for traffic tunnels, the link should use a different metric. Thus, a constraint-based specific metric may be specified.

Page 617: Implementing cisco mpls

8-24 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Constraint-Based Path Computation This topic introduces constraint-based path computation.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-9

Constraint-Based Path Computation

• Constraint-based routing is demand-driven.

• Resource-reservation-aware routing paradigm:

– Based on criteria including, but not limited to, network topology

– Calculated at the edge of a network:

• Modified Dijkstra’s algorithm at tunnel headend (CSPF [Constraint-based SPF] or PCALC [path calculation]).

• Output is a sequence of IP interface addresses (next-hop routers) between tunnel endpoints.

In traditional networks, the IGP calculates paths through the network based on the network topology alone. Routing is destination-based, and all traffic to a given destination from a given source uses the same path through the network. That path is based simply on what the IGP regards as the “least cost” between the two points (source and destination).

“Constraint-based routing” (CBR) is the term that is used most often for this approach. In some situations it is also referred to as a “constraint-based shortest path first” (CSPF) calculation or a “path calculation” (PCALC).

CBR behaves in these ways:

It augments the use of link cost by also considering other factors, such as bandwidth availability or link attributes, when choosing the path to a destination.

It tends to be carried out at the edge of the network, discovering a path across the core to some destination elsewhere at the other edge of the network. Typically, this discovery uses the CSPF calculation (a version of shortest path first [SPF] that is used by IS-IS and OSPF, but considering other factors besides cost, such as bandwidth availability).

It produces a sequence of IP addresses that correspond to the routers that are used as the path to the destination; these addresses are the next-hop addresses for each stage of the path.

A consequence of CBR is that, from one source to one destination, many different paths can be used through the network, depending on the requirements of those data flows.

Page 618: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-25

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-10

Constraint-Based Path Computation (Cont.)

• Constraint-based routing takes into account:

– Policy constraints associated with the tunnel and physical links

– Physical resource availability

– Network topology state

• Two types of tunnels can be established across those links with matching attributes:

– Dynamic—Using the least-cost path computed by OSPF or IS-IS

– Explicit—Definition of a path by using Cisco IOS configuration commands

When choosing paths through the network, the CBR system takes into account the following factors:

The topology of the network, including information about the state of the links (the same information that is used by normal hop-by-hop routing)

The resources that are available in the network, such as the bandwidth not already allocated on each link and at each of the eight priority levels (priority 0 to 7)

The requirements that are placed on the constraint-based calculation that is defining the policy or the characteristics of this traffic tunnel

Of course, CBR is a dynamic process, which responds to a request to create a path and calculates (or recalculates) the path based on the status of the network at that time. The network administrator can also explicitly define the traffic tunnel.

By using commands such as exclude-address or next-hop loose in the explicit path configuration, the network administrator can mix static and dynamic computation.

Page 619: Implementing cisco mpls

8-26 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-11

Constraint-Based Path Computation (Cont.)

An example network is shown in the figure. Each link specifies a link cost for metric calculation and a bandwidth available for reservation; for example, a metric of 10 and an available bandwidth of 100 Mbps is shown for the link between R1 and R2. Other than these criteria, no links are subject to any policy restriction that would disallow their use for creating traffic tunnels.

The requirement is to create a tunnel from R1 to R6 with a bandwidth of 30 Mbps.

Based simply on the link costs, the least-cost path from R1 to R6 is R1-R4-R6 with a cost of 30. However, the link from R4 to R6 has only 20 Mbps of bandwidth available for reservation and therefore cannot fulfill the requirements of the tunnel.

Similarly, the link R5-R6 has only 20 Mbps available as well, so no paths can be allocatedvia R5.

Page 620: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-27

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-12

Constraint-Based Path Computation (Cont.)

The diagram now shows only those links that can satisfy the requirement for 30 Mbps of available bandwidth.

Over this topology, two tunnel paths are shown:

The red (solid arrow) path shows the result of a dynamic constraint-based path calculation. The calculation has ignored any links that do not satisfy the bandwidth requirement (those shown in the previous figure but not shown here, such as the connections to R5) and then executes a CSPF calculation on what remains. This calculation has yielded the path R1-R2-R5-R6 with a path cost of 40.

The network administrator has statically defined the blue (dashed arrow) path (R1-R4-R5-R6). Had the administrator attempted to define a path that did not have the required free bandwidth, tunnel establishment would have failed. This tunnel does indeed fulfill the minimum bandwidth requirement. However, adding the link costs yields a total of 45, which is not the lowest cost possible.

Page 621: Implementing cisco mpls

8-28 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

TE Processes This topic explains the processes used in traffic engineering (TE).

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-13

Traffic Engineering Processes

• Information distribution

• Path selection and calculation

• Path setup

• Trunk admission control

• Forwarding traffic on to tunnel

• Path maintenance

There are six TE processes to understand:

Information distribution: Because the resource attributes are configured locally for each link, they must be distributed to the headend routers of traffic trunks. These resource attributes are flooded throughout the network using extensions to link-state intradomain routing protocols, either IS-IS and OSPF. The flooding takes places under these conditions:

— Link-state changes occur.

— The resource class of a link changes (this could happen when a network administrator reconfigures resource class of a link).

— The amount of available bandwidth crosses one of the preconfigured thresholds.

The frequency of flooding is bounded by the OSPF and IS-IS timers. There are up thresholds and down thresholds. The up thresholds are used when a new trunk is admitted. The down thresholds are used when an existing trunk goes away.

Note Extensions to IS-IS and OSPF are discussed in a later topic.

Page 622: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-29

Path selection: Path selection for a traffic trunk takes place at the headend routers of traffic trunks. Using extended IS-IS or OSPF, the edge routers have knowledge of both network topology and link resources. For each traffic trunk, the router starts from the destination of the trunk and attempts to find the shortest path toward the source (that is, using the SPF algorithm). The SPF calculation does not consider the links that are explicitly excluded by the resource class affinities of the trunk or the links that have insufficient bandwidth. The output of the path selection process is an explicit route consisting of a sequence of label switching routers. This path is used as the input to the path setup procedure.

Path setup: Path setup is initiated by the headend routers. Resource Reservation Protocol (RSVP) is the protocol that establishes the forwarding state along the path computed in the path selection process. The headend router sends a PATH message for each traffic trunk it originates.

Trunk admission control: Trunk admission control handles the situation when a router along a computed path has insufficient bandwidth to honor the resource requested in the PATH message.

Forwarding of traffic to a tunnel: Traffic can be forwarded to a tunnel by several means, including these:

— Static routing

— Policy routing from the global routing table

— Autoroute

Path maintenance: Path maintenance refers to two operations: path reoptimization and restoration.

Page 623: Implementing cisco mpls

8-30 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Role of RSVP in Path Setup and Trunk Admission Control

This topic explains how RSVP is used in setting up an LSP path and in trunk admission control.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-14

• When the path has been determined, a signaling protocol is needed:

– To establish and maintain label-switched paths (LSPs) for traffic tunnels

– For creating and maintaining resource reservation states across a network (bandwidth allocation)

• The Resource Reservation Protocol (RSVP) was adopted by the MPLS workgroup of the IETF.

Role of RSVP in Path Setup Procedures

The result of the constraint-based calculation is a list of routers that form the path to the destination. The path is a list of IP addresses that identify each next hop along the path.

However, this list of routers is known only to the router at the headend of the tunnel that is attempting to build the tunnel. Somehow, this now-explicit path must be communicated to the intermediate routers. It is not up to the intermediate routers to make their own CSPF calculations; they merely abide by the path that is provided to them by the headend router.

Therefore, some signaling protocol is required to confirm the path, to check and apply the bandwidth reservations, and finally to apply the MPLS labels to form the MPLS LSP through the routers. The MPLS working group of the Internet Engineering Task Force (IETF) has adopted RSVP to confirm and reserve the path and apply the labels that identify the tunnel. Label Distribution Protocol (LDP) is used to apply the labels for the underlying MPLS network.

Note RSVP is needed for both explicit and dynamic path setup.

Page 624: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-31

Path Setup with RSVP RSVP is used for path setup.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-15

Path Setup with RSVP

• When the path has been calculated, it must be signaled across the network.

– Reserve any bandwidth to avoid “double booking” from other TE reservations.

– Priority can be used to preempt low priority existing tunnels.

• RSVP is used to set up TE LSP.

– PATH message (from head to tail) carries LABEL_REQUEST.

– RESV message (from tail to head) carries LABEL.

• When RESV messages reaches headend, tunnel interface is up.

• RSVP messages exist for LSP teardown and error signaling.

To signal the calculated path across the network, a PATH message is sent to the tailend router by the headend router for each traffic tunnel the headend originates.

Note This process occurs in the MPLS control plane.

The PATH message carries the explicit route (the output of the path selection process) computed for this traffic trunk, consisting of a sequence of label switching routers. The PATH message always follows this explicit route. Each intermediate router along the path performs trunk admission control after receiving the PATH message. When the router at the end of the path (tailend router) receives the PATH message, it sends a RESV message in the reverse direction toward the headend of the traffic trunk. As the RESV message flows toward the sender, each intermediate node reserves bandwidth and allocates labels for the trunk. When the RESV message reaches the sender, the LSP is already established.

RSVP messages also support for LSP teardown and error signaling.

Page 625: Implementing cisco mpls

8-32 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Trunk Admission Control with RSVP RSVP is also used in trunk admission control.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-16

RSVP and Trunk Admission Control

• On receipt of PATH message:

– Router checks whether there is bandwidth available to honor the reservation.

– If bandwidth is available, then RSVP is accepted.

• On receipt of a RESV message:

– Router actually reserves the bandwidth for the TE LSP.

– If preemption is required, lower priority LSPs are torn down.

• OSPF or IS-IS updates are triggered.

Trunk admission control is used to confirm that each device along the computed path has sufficient provisioned bandwidth to support the resource requested in the PATH message. When a router receives a PATH message, it checks whether there is enough bandwidth to honor the reservation at the setup priority of the traffic trunk. Priority levels 0 to 7 are supported. If there is enough provisioned bandwidth, the reservation is accepted, otherwise the path setup fails. When the router receives the RESV message, it reserves bandwidth for the LSP. If preemption is required, the router must tear down existing trunks with a lower priority. As part of trunk admission control, the router must do local accounting to keep track of resource utilization and trigger IS-IS or OSPF updates when the available resource crosses the configured thresholds.

Page 626: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-33

Forwarding Traffic to a Tunnel This topic discusses changes that occur in the forwarding table when MPLS TE is implemented.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-17

Forwarding Traffic to a Tunnel

• IP routing is separate from LSP routing and does not see internal details of the LSP.

• The traffic has to be mapped to the tunnel:

– Static routing—The static route in the IP routing table points to an LSP tunnel interface.

– Policy routing—The next-hop interface is an LSP tunnel.

– Autoroute—SPF enhancement:

• The headend sees the tunnel as a directly connected interface (for modified SPF only).

• The default cost of a tunnel is equal to the shortest IGP metricregardless of the used path.

The tunnel normally does not appear in the IP routing table. The IP routing process does not see the tunnel, so the tunnel is normally not included in any SPF calculations. The IP traffic can be mapped onto a tunnel in four ways:

Using static routes that point to the tunnel interfaces.

Using policy-based routing (PBR) and setting the next hop for the destination to the tunnel interface.

Using the autoroute feature, an SPF enhancement that includes the tunnel interface in the route calculation as well. The result of the autoroute feature is that the tunnel is seen at the headend (and only there) as a directly connected interface. The metric (cost) of the tunnel is set to the normal IGP metric from the tunnel headend to the tunnel endpoint (over the least-cost path, regardless of whether the tunnel is actually using the least-cost path).

Note With the autoroute feature, the traffic-engineered tunnel appears in the IP routing table as

well, but this appearance is restricted to the tunnel headend only.

Using forwarding adjacency, which allows the tunnel to be announced via OSPF or IS-IS like any other unidirectional link (UDL). To be used for data forwarding, such a tunnel has to be set up bidirectionally.

The first two options are not very flexible or scalable. The traffic for each destination that needs to use the tunnel must be manually mapped to the tunnel.

Page 627: Implementing cisco mpls

8-34 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

For example, when you are using static routes, the tunnel is used only for the explicit static routes. Any other traffic that is not covered by the explicit static routes, including traffic for the tailend router (even though the tunnel terminates on that router), will not be able to use the tunnel; instead, it will follow the normal IGP path.

Forwarding Traffic to a Tunnel: Autoroute This topic describes how the IP forwarding database is modified when the autoroute feature is implemented.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-18

• Autoroute feature enables the headend to see the LSP as a directly connected interface:– This feature is used only for the SPF route determination,

not for the constraint-based path computation.

– All traffic directed to prefixes topologically behind the tunnel endpoint (tailend) is forwarded onto the tunnel.

• Autoroute affects the headend only; other routers on the LSP path do not see the tunnel.

• Tunnel is treated as a directly connected link to the tailend:– When tunnel tail is seen in PATH list during IGP SPF,

replace outgoing physical interface with tunnel interface.

– Inherit tunnel to all downstream neighbors of tailend.

IP Forwarding Database Modification with Autoroute

To overcome the problems that result from static routing configurations onto MPLS TE tunnels, the autoroute feature of Cisco IOS software was introduced. The autoroute feature enables the headend router to see the MPLS TE tunnel as a directly connected interface. The headend uses the MPLS TE in its modified SPF computations.

Note The MPLS TE tunnel is used only for normal IGP route calculation (at the headend only) and

is not included in any constraint-based path computation.

When the tunnel is built, there is a directly connected link from headend to tailend.

The autoroute feature enables all the prefixes that are topologically behind the MPLS TE tunnel endpoint (tailend) to be reachable via the tunnel itself. This contrasts with static routing, where only statically configured destinations are reachable via the tunnel.

The autoroute feature affects the headend router only and has no effect on intermediate routers. These routers still use normal IGP routing for all the destinations.

Page 628: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-35

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-19

Autoroute Topology (OSPF and ISIS)

Tunnel1: R1 R2 R3 R4 R5Tunnel2: R1 R6 R7 R4

The figure shows an example with two TE tunnels from R1. When the tunnels are up, R4 and R5 appear as directly connected neighbors to R1.

Note The tunnels are seen for routing purposes only by R1, the headend router. Intermediate

routers do not see the tunnel nor do they take it into consideration for route calculations.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-20

Autoroute Topology (OSPF and ISIS)

From R1 Router Perspective:Next hop to R5 is Tunnel1.

Next hop to R4 and R8 is Tunnel2.

All nodes behind tunnel are routed via tunnel.

2020

Page 629: Implementing cisco mpls

8-36 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-21

Summary

• Traffic tunnels are configured with a set of resource requirements, such as bandwidth and priority.

• CSPF augments the link cost by considering other factors such as bandwidth availability or link latency when choosing a path.

• RSVP with TE extensions is used for establishing and maintaining LSPs.

• TE tunnels do not appear in the IP routing table.

ReferencesFor additional information, refer to this resource:

RFC 2746, RSVP Operation over IP Tunnels

Page 630: Implementing cisco mpls

Lesson 3

Configuring MPLS TE on Cisco IOS Platforms

OverviewThis lesson describes the Multiprotocol Label Switching (MPLS) traffic engineering (TE) commands for the implementation of MPLS traffic tunnels. The configuration commands that are needed to support MPLS TE are explained, and sample setups are presented.

ObjectivesUpon completing this lesson, you will be able to describe how to configure MPLS TE on Cisco IOS platforms. This ability includes being able to meet these objectives:

Identify the tasks that are required to implement MPLS TE

Enable device-level MPLS TE support

Enable MPLS TE support in an IS-IS environment

Enable MPLS TE support in an OSPF environment

Enable MPLS TE on an interface

Create and configure a traffic tunnel

Enable traffic tunnels with autoroute

Page 631: Implementing cisco mpls

8-38 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

MPLS TE Configuration Road Map This topic describes the requirements to implement MPLS TE on a Cisco IOS device.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-3

MPLS TE Configuration Road Map

• Use device supporting MPLS.

– Implement ip cef global configuration command.

• Use IGP supporting MPLS TE.

– OSPF

– IS-IS

• Enable MPLS TE tunnels.

– Configure mpls traffic-eng tunnels (global configuration mode).

– Configure mpls traffic-eng tunnels (interface configuration mode).

• Create and configure traffic tunnels.

• Deploy traffic tunnels with autoroute.

MPLS has to be supported to implement MPLS TE, so Cisco Express Forwarding (CEF) is required.

MPLS TE has to be supported in the Interior Gateway Protocol (IGP). Open Shortest Path First (OSPF) and Intermediate System-to-Intermediate System (IS-IS) currently have MPLS TE support available. The configuration process for both IGPs is covered later in this lesson.

MPLS TE needs to be enabled both in global configuration mode and on specific interfaces. After MPLS TE is enabled, you need to create and configure traffic tunnels and then send the appropriate traffic into the tunnels.

Page 632: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-39

Enabling Device-Level MPLS TE Support This topic describes the command syntax that is required to enable device-level MPLS TE support on a Cisco IOS device.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-4

·° ˝»ş

®±«¬»®ř˝±˛ş·ą÷ý

• Enables IP CEF switching

Enabling Device-Level MPLS TE Support

ł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

®±«¬»®ř˝±˛ş·ą÷ý

• Enables the MPLS TE tunnel feature on a device

ip cef To enable CEF on the router, use the ip cef command in global configuration mode. To disable CEF, use the no form of this command.

ip cef [distributed]

no ip cef [distributed]

Syntax Description

Parameter Description

Ľ·­¬®·ľ«¬»Ľ (Optional) Enables distributed CEF (dCEF) operation. Distributes CEF information to line cards. Line cards perform express forwarding.

Usage Guidelines

CEF is an advanced Layer 3 IP switching technology. CEF optimizes network performance and scalability for networks with dynamic, topologically dispersed traffic patterns, such as those associated with web-based applications and interactive sessions.

Note CEF is a prerequisite for MPLS traffic engineering.

Page 633: Implementing cisco mpls

8-40 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

mpls traffic-eng tunnels (global) To enable MPLS TE tunnel signaling on a device, use the mpls traffic-eng tunnels command in global configuration mode. To disable this feature, use the no form of this command.

mpls traffic-eng tunnels

no mpls traffic-eng tunnels

Usage Guidelines

Enables the MPLS TE feature on a device. To use the feature, MPLS TE must also be enabled on the desired interfaces.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-5

Implementing Device-Level MPLS TE Support

·° ˝»ş ĹĽ·­¬®·ľ«¬»ĽĂł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

This figure illustrates the global configuration commands needed to enable device-level MPLS TE support.

Note These basic commands need to be configured on all provider edge (PE) and provider (P)

routers in the MPLS network.

Page 634: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-41

Enabling MPLS TE Support in IS-IS This topic describes the command syntax that is required to enable MPLS TE support in an IS-IS implementation.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-6

Enabling MPLS TE Support in IS-IS

ł°´­ ¬®żşş·˝ó»˛ą Ą´»Ş»´óď ¤ ´»Ş»´óîŁ

®±«¬»®ř˝±˛ş·ąó®±«¬»®÷ý

• Turns on MPLS traffic engineering for IS-IS Level 1 or Level 2

ł°´­ ¬®żşş·˝ó»˛ą ®±«¬»®ó·Ľ Ą·˛¬»®şż˝»Ł

®±«¬»®ř˝±˛ş·ąó®±«¬»®÷ý

• Specifies the interface to be associated with the TE router identifier (also endpoint of a tunnel)

ł»¬®·˝ó­¬§´» ©·Ľ»

®±«¬»®ř˝±˛ş·ąó®±«¬»®÷ý

• Configures a router to generate and accept only new-style TLV objects

mpls traffic-eng To configure a router running IS-IS so that it floods MPLS TE link information into the indicated IS-IS level, use the mpls traffic-eng command in router configuration mode. To disable the flooding of MPLS TE link information into the indicated IS-IS level, use the noform of this command.

mpls traffic-eng {level-1 | level-2}

no mpls traffic-eng {level-1 | level-2}

Syntax Description

Parameter Description

´»Ş»´óď Floods MPLS TE link information into IS-IS Level 1

´»Ş»´óî Floods MPLS TE link information into IS-IS Level 2

Usage Guidelines

This command appears as part of the routing protocol tree and causes link resource information (for instance, the bandwidth available) for appropriately configured links to be flooded in the IS-IS link-state database.

Page 635: Implementing cisco mpls

8-42 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

mpls traffic-eng router-id To specify the TE router identifier that is to be the IP address that is associated with the given interface for the node, use the mpls traffic-eng router-id command in router configuration mode. To disable this feature, use the no form of this command.

mpls traffic-eng router-id interface

no mpls traffic-eng router-id interface

Syntax Description

Parameter Description

·˛¬»®şż˝» The MPLS TE router identifier is taken from the IP address of the supplied interface. This MPLS TE router identifier should be configured as the tunnel destination for tunnels that originate at other routers and terminate at this router. This interface should be a stable interface that will not go up and down, such as a loopback interface.

Usage Guidelines

The router identifier acts as a stable IP address for the TE configuration. This stable IP address is flooded to all nodes. For all TE tunnels that originate at other nodes and end at this node, the tunnel destination must be set to the TE router identifier of the destination node, because that identifier is the address that the TE topology database at the tunnel head uses for its path calculation.

Note The MPLS router ID has to be the same address as the IGP router ID. Typically a loopback

interface is used for the router ID.

It is a best practice to use the same loopback interface for MPLS TE, IGP, Border Gateway

Protocol (BGP), and Label Distribution Protocol (LDP) router identification.

metric-style wide To configure a router running IS-IS so that it generates and accepts only new-style type, length, and value (TLV) objects, use the metric-style wide command in router configuration mode. To disable this function, use the no form of this command.

metric-style wide [transition] [level-1 | level-2 | level-1-2]

no metric-style wide [transition] [level-1 | level-2 | level-1-2]

Page 636: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-43

Syntax Description

Parameter Description

¬®ż˛­·¬·±˛ (Optional) Instructs the router to accept both old- and new-style TLV objects

´»Ş»´óď Enables this command on routing Level 1

´»Ş»´óî Enables this command on routing Level 2

´»Ş»´óďóî Enables this command on routing Levels 1 and 2

Usage Guidelines

If you enter the metric-style wide command, a router generates and accepts only new-style TLV objects. The router uses less memory and other resources than it would if it were generating both old-style and new-style TLV objects.

This style is appropriate for enabling MPLS TE across an entire network.

Note This discussion of metric styles and transition strategies is oriented toward TE deployment.

Other commands and models may be appropriate if the new-style TLV objects are desired

for other reasons. For example, a network may require wider metrics but may not use TE.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-7

Implementing MPLS TE Support in IS-IS

·° ˝»şł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

®±«¬»® ·­·­ł°´­ ¬®żşş·˝ó»˛ą ®±«¬»®ó·Ľ Ô±±°ľż˝µđł°´­ ¬®żşş·˝ó»˛ą ´»Ş»´óîł»¬®·˝ ©·Ľ»

This figure illustrates typical the router mode configuration commands needed to enable MPLS TE support in an IS-IS implementation.

Note These commands need to be configured on all PE and P routers in the MPLS network for an

IS-IS implementation.

Page 637: Implementing cisco mpls

8-44 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Enabling MPLS TE Support in OSPF This topic describes the command syntax that is required to enable MPLS TE support in an OSPF implementation.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-8

Enabling MPLS TE Support in OSPF

ł°´­ ¬®żşş·˝ó»˛ą ż®»ż ż®»żó˛«ł

®±«¬»®ř˝±˛ş·ąó®±«¬»®÷ý

• Turns on OSPF traffic engineering for the area

ł°´­ ¬®żşş·˝ó»˛ą ®±«¬»®ó·Ľ ·˛¬»®şż˝»

®±«¬»®ř˝±˛ş·ąó®±«¬»®÷ý

• Specifies the interface to be associated with the TE router identifier (also endpoint of a tunnel)

mpls traffic-eng area To configure a router running OSPF MPLS so that it floods TE for the indicated OSPF area, use the mpls traffic-eng area command in router configuration mode. To disable flooding of TE for the indicated OSPF area, use the no form of this command.

mpls traffic-eng area area-number

no mpls traffic-eng area area-number

Syntax Description

Parameter Description

ż®»żó˛«łľ»® Indicates the OSPF area on which MPLS TE is enabled

Usage Guidelines

This command affects the operation of MPLS TE only if MPLS TE is enabled for that routing protocol instance. Currently, only a single area may be enabled for TE.

Page 638: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-45

mpls traffic-eng router-id To specify the TE router identifier for the node that is to be the IP address that is associated with the given interface, use the mpls traffic-eng router-id command in router configuration mode.

mpls traffic-eng router-id interface

Syntax Description

Parameter Description

·˛¬»®şż˝» The MPLS TE router identifier is taken from the IP address of the supplied interface. This MPLS TE router identifier should be configured as the tunnel destination for tunnels that originate at other routers and terminate at this router. This interface should be a stable interface that will not go up and down, such as a loopback interface.

Usage Guidelines

This router identifier acts as a stable IP address for the TE configuration. This stable IP address is flooded to all nodes. For all TE tunnels that originate at other nodes and end at this node, the tunnel destination must be set to the TE router identifier of the destination node, because that identifier is the address that the TE topology database at the tunnel head uses for its path calculation.

Note The MPLS router ID has to be the same address as the IGP router ID. Typically a loopback

interface is used for the router ID.

It is a best practice to use the same loopback interface for MPLS TE, IGP, BGP, and LDP

router identification.

Page 639: Implementing cisco mpls

8-46 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-9

Implementing MPLS TE Support in OSPF

·° ˝»şł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

®±«¬»® ±­°ş ďđďł°´­ ¬®żşş·˝ó»˛ą ®±«¬»®ó·Ľ Ô±±°ľż˝µđł°´­ ¬®żşş·˝ó»˛ą ż®»ż đ

This figure illustrates the typical router mode configuration commands needed to enable MPLS TE support in an OSPF implementation.

Note These commands need to be configured on all PE and P routers in the MPLS network for an

OSPF implementation.

Page 640: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-47

Enabling Basic MPLS TE on an Interface This topic describes the command syntax that is required to enable basic MPLS TE on an interface on a Cisco IOS device.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-10

·° ®­Ş° ľż˛Ľ©·Ľ¬¸ Ĺ·˛¬»®şż˝»óµľ°­ Ĺ­·˛ą´»óş´±©óµľ°­ĂĂ

®±«¬»®ř˝±˛ş·ąó·ş÷ý

• Enables RSVP for IP on an interface and specify amount of bandwidth to be reserved

Enabling Basic MPLS TE on an Interface

ł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

®±«¬»®ř˝±˛ş·ąó·ş÷ý

• Enables the MPLS TE tunnel feature on an interface

ł°´­ ·°

®±«¬»®ř˝±˛ş·ąó·ş÷ý

• Enables MPLS on an interface

mpls ip To enable MPLS forwarding of IP version 4 (IPv4) packets along normally routed paths for a particular interface, use the mpls ip command in interface configuration mode. To disable this feature, use the no form of this command.

mpls ip

no mpls ip

mpls traffic-eng tunnels (interface) To enable MPLS TE tunnel signaling on an interface, use the mpls traffic-eng tunnels command in interface configuration mode. To disable this feature, use the no form of this command.

mpls traffic-eng tunnels

no mpls traffic-eng tunnels

Note MPLS TE tunnel signaling must first be enabled at the global level.

Page 641: Implementing cisco mpls

8-48 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Usage Guidelines

This command enables the MPLS TE feature on the interface. To use the feature, MPLS TE must also be enabled on the device globally. An enabled interface has its resource information flooded into the appropriate IGP link-state database and accepts TE tunnel signaling requests.

ip rsvp bandwidth To enable Resource Reservation Protocol (RSVP) for IP on an interface, use the ip rsvp bandwidth interface configuration command. To disable RSVP, use the no form of this command.

ip rsvp bandwidth [interface-kbps [single-flow-kbps]]

no ip rsvp bandwidth [interface-kbps [single-flow-kbps]]

Syntax Description

Parameter Description

·˛¬»®şż˝»óµľ°­ (Optional) Maximum amount of bandwidth, in kilobits per second, that may be allocated by RSVP flows. The range is from 1 to 10,000,000.

­·˛ą´»óş´±©óµľ°­ (Optional) Maximum amount of bandwidth, in kilobits per second, that may be allocated to a single flow. The range is from 1 to 10,000,000.

Usage Guidelines

RSVP is disabled by default. If the ip rsvp bandwidth command is entered but no bandwidth values are supplied (for example, if you enter ip rsvp bandwidth and then press the Enter key), a default bandwidth value is assumed for both the interface-kbps and single-flow-kbpsarguments.

RSVP cannot be configured with Versatile Interface Processor (VIP) dCEF.

Note To make MPLS TE work over a subinterface, you must configure RSVP on the main

interface with the ip rsvp bandwidth command even if the main interface is not used for

MPLS TE.

Page 642: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-49

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-11

Implementing Basic MPLS TE on an Interface

·° ˝»şł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

®±«¬»® ·­·­ł°´­ ¬®żşş·˝ó»˛ą ®±«¬»®ó·Ľ Ô±±°ľż˝µđł°´­ ¬®żşş·˝ó»˛ą ´»Ş»´óďł»¬®·˝ ©·Ľ»

·˛¬»®şż˝» ­»®·ż´ đńđł°´­ ·°ł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­·° ®­Ş° ľż˛Ľ©·Ľ¬¸ ďîč

This figure illustrates the commands to enable basic MPLS TE support on an interface.

Note These commands need to be configured on all interfaces between the PE and P routers in

the MPLS network.

Page 643: Implementing cisco mpls

8-50 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Creating and Configuring a Traffic Tunnel This topic describes the command syntax that is required to create and configure a traffic tunnel on a Cisco IOS device.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-12

·° «˛˛«łľ»®»Ľ ¬§°» ˛«łľ»®

• Enables IP on the interface, and brings it up without a unique IP address

®±«¬»®ř˝±˛ş·ąó·ş÷ý

Creating a Tunnel

·˛¬»®şż˝» ¬«˛˛»´ ˛«łľ»®

®±«¬»®ř˝±˛ş·ą÷ý

• Configures a tunnel interface

¬«˛˛»´ Ľ»­¬·˛ż¬·±˛ ·°óżĽĽ®»­­

• Specifies the destination for the tunnel

• The tunnel source command is not needed.

®±«¬»®ř˝±˛ş·ąó·ş÷ý

interface tunnel The interface tunnel command is used to declare a tunnel interface. The tunnel interface number parameter value is in the range of 0 to 2147483647.

interface tunnel number

ip unnumberedTo enable IP processing on an interface without assigning an explicit IP address to the interface, use the ip unnumbered command in interface configuration mode or subinterface configuration mode. To disable IP processing on the interface, use the no form of this command.

ip unnumbered type number

no ip unnumbered type number

Note Although the tunnel interface could be assigned an IP address with the ip address

command, using an unnumbered interface is considered a best practice.

Page 644: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-51

Syntax Description

Parameter Description

¬§°» Type of another interface on which the router has an assigned IP address. The interface cannot be another unnumbered interface.

˛«łľ»® Number of another interface on which the router has an assigned IP address. The interface cannot be another unnumbered interface.

Usage Guidelines

Whenever the unnumbered interface generates a packet (for example, for a routing update), it uses the address of the specified interface as the source address of the IP packet. It also uses the address of the specified interface in determining which routing processes are sending updates over the unnumbered interface.

For MPLS TE tunnels, it is recommended that you use a loopback interface for addressing the unnumbered interface.

tunnel destination To specify the destination for a tunnel interface, use the tunnel destination interface configuration command.

tunnel destination {hostname | ip-address}

Syntax Description

Parameter Description

¸±­¬˛żł» Name of the host destination

·°óżĽĽ®»­­ IP address of the host destination expressed in decimal in four-part dotted notation

Usage Guidelines

For MPLS TE, it is a good practice to use the router ID of the remote router as the destination address.

Note Two tunnels cannot use the same encapsulation mode with exactly the same source and

destination address.

With MPLS traffic engineering, the source for the tunnel is set automatically.

Note The tunnel source command is not used.

Page 645: Implementing cisco mpls

8-52 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-13

Example: Creating a Tunnel Interface

ňňň·˛¬»®şż˝» ¬«˛˛»´ đ

·° «˛˛«łľ»®»Ľ ´±±°ľż˝µ 𬫲˛»´ Ľ»­¬·˛ż¬·±˛ ďđňďňďňî

This figure illustrates the commands to create a tunnel interface.

Note These commands are configured only on the ingress PE for the MPLS TE tunnel.

Configuring a Traffic Tunnel This topic describes the command syntax that is required to create and configure a traffic tunnel on a Cisco IOS device.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-14

¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą ľż˛Ľ©·Ľ¬¸ ľż˛Ľ©·Ľ¬¸

• Configures the requested bandwidth for the MPLS TE tunnel

¬«˛˛»´ ł±Ľ» ł°´­ ¬®żşş·˝ó»˛ą

• Sets the tunnel encapsulation mode to MPLS TE

Creating and Configuring a Traffic Tunnel

®±«¬»®ř˝±˛ş·ąó·ş÷ý

®±«¬»®ř˝±˛ş·ąó·ş÷ý

®±«¬»®ř˝±˛ş·ąó·ş÷ý

¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą °®·±®·¬§ ­»¬«°ó°®·±®·¬§ Ÿ±´Ľó°®·±®·¬§Ă

• Configures the setup and reservation priority for an MPLS TE tunnel

Page 646: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-53

tunnel mode mpls traffic-eng To set the mode of a tunnel to MPLS for TE, use the tunnel mode mpls traffic-eng command in interface configuration mode.

tunnel mode mpls traffic-eng

Usage Guidelines

This command specifies that the tunnel interface is for an MPLS TE tunnel and enables the various tunnel MPLS configuration options.

tunnel mpls traffic-eng bandwidth To configure the bandwidth that is required for an MPLS TE tunnel, use the tunnel mpls traffic-eng bandwidth command in the interface configuration mode. To disable this feature, use the no form of this command.

tunnel mpls traffic-eng bandwidth [sub-pool | global] bandwidth

no tunnel mpls traffic-eng bandwidth [sub-pool | global] bandwidth

Syntax Description

Parameter Description

ľż˛Ľ©·Ľ¬¸ The bandwidth required for an MPLS TE tunnel. Bandwidth is specified in kilobits per second. Bandwidth, in kilobits per second, is set aside for the MPLS traffic engineering tunnel. The range is between 1 and 4294967295.

sub-pool (Optional) Indicates a subpool tunnel.

global (Optional) Indicates a global pool tunnel. Entering this keyword is not necessary, for all tunnels are global pool in the absence of the sub-pool keyword. But if users of pre-DiffServ-aware TE images enter this keyword, it is accepted.

Usage Guidelines

This command specifies that the tunnel bandwidth for an MPLS TE tunnel.

Default

The default bandwidth is 0.

tunnel mpls traffic-eng priority To configure the setup and reservation priority for an MPLS TE tunnel, use the tunnel mpls traffic-eng priority command in interface configuration mode. To remove the specified setup and reservation priority, use the no form of this command.

tunnel mpls traffic-eng priority setup-priority [hold-priority]

no tunnel mpls traffic-eng priority setup-priority [hold-priority]

Page 647: Implementing cisco mpls

8-54 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Syntax Description

Parameter Description

­»¬«°ó°®·±®·¬§ The priority that is used when signaling a label-switched path (LSP) for this tunnel to determine which existing tunnels are eligible for preemption. The range is from 0 to 7, where a lower numeric value indicates a higher priority.

¸±´Ľó°®·±®·¬§ (Optional) The priority that is associated with an LSP for this tunnel when it has been established to determine whether it should be preempted by other LSPs that are being signaled. The range is from 0 to 7, where a lower numeric value indicates a higher priority.

Usage Guidelines

When an LSP is being signaled and an interface does not currently have enough bandwidth available for that LSP, the call admission software preempts lower-priority LSPs so that the new LSP can be admitted. (LSPs are preempted if doing so allows the new LSP to be admitted.)

In the described determination, the priority of the new LSP is its setup priority, and the priority of the existing LSP is its hold priority. The two priorities make it possible to signal an LSP with a low setup priority (so that the LSP does not preempt other LSPs on setup) but a high hold priority (so that the LSP is not preempted after it is established).

Setup priority and hold priority are typically configured to be equal, and setup priority cannot be better (numerically smaller) than the hold priority.

Defaults

The defaults are as follows:

Setup priority = 7

Hold priority = 7

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-15

Creating and Configuring a Traffic Tunnel (Cont.)

¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą °ż¬¸ó±°¬·±˛ ˛«łľ»® ĄĽ§˛żł·˝ ¤ »¨°´·˝·¬ Ą˛żł» °ż¬¸ó˛żł» ¤ °ż¬¸ó˛«łľ»®ŁŁ Ĺ´±˝µĽ±©˛Ă

®±«¬»®ř˝±˛ş·ąó·ş÷ý

• Configures the tunnel to use a named IP explicit path or a path dynamically calculated from the TE topology database

·° »¨°´·˝·¬ó°ż¬¸ Ą˛żł» ©±®Ľ ¤ ·Ľ»˛¬·ş·»® ˛«łľ»®Ł ĹĄ»˛żľ´» ¤ Ľ·­żľ´» ŁĂ

®±«¬»®ř˝±˛ş·ą÷ý

• Enters the subcommand mode for IP explicit paths and creates or modifies the specified path

˛»¨¬óżĽĽ®»­­ ·°óżĽĽ®»­­

®±«¬»®ř˝şąó·°ó»¨°´ó°ż¬¸÷ý

• Specifies the next IP address in the explicit path

Page 648: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-55

ip explicit-path To enter the subcommand mode for IP explicit paths to create or modify the named path, use the ip explicit-path command in global configuration mode. An IP explicit path is a list of IP addresses, each representing a node or link in the explicit path.

ip explicit-path {name word | identifier number} [{enable | disable}]

Syntax Description

Parameter Description

˛żł» ©±®Ľ Specifies an explicit path by name.

·Ľ»˛¬·ş·»® ˛«łľ»® Specifies an explicit path by number. You can specify a number from 1 to 65535.

»˛żľ´» (Optional) Sets the state of the path to be enabled.

Ľ·­żľ´» (Optional) Prevents the path from being used for routing while it is being configured.

next-addressTo specify the next IP address in the explicit path, use the next-address command in IP explicit path configuration mode. To remove the specified next IP address in the explicit path, use the no form of this command.

next-address ip-address

no next-address ip-address

Default

The next IP address in the explicit path is not specified.

tunnel mpls traffic-eng path-option To configure a path option for an MPLS-TE tunnel, use the tunnel mpls traffic-eng path-option command in interface configuration mode. To disable the specified path option, use the no form of this command.

tunnel mpls traffic-eng path-option number {dynamic | explicit {name path-name |path-number}} [lockdown]

no tunnel mpls traffic-eng path-option number {dynamic | explicit {name path-name | path-number}} [lockdown]

Page 649: Implementing cisco mpls

8-56 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Syntax Description

Parameter Description

˛«łľ»® When multiple path options are configured, lower-numbered options are preferred.

Ľ§˛żł·˝ Path of the LSP is dynamically calculated.

˛żł» °ż¬¸ó˛żł» Path name of the IP explicit path that the tunnel uses with this option.

°ż¬¸ó˛«łľ»® Path number of the IP explicit path that the tunnel uses with this option.

´±˝µĽ±©˛ (Optional) The LSP cannot be reoptimized.

Usage Guidelines

Multiple path setup options may be configured for a single tunnel. For example, you can configure several explicit paths and a dynamic option for one tunnel. Path setup prefers options with lower numbers to options with higher numbers, so option 1 is the most strongly preferred option. The explicit path is configured using the ip explicit-path command.

Page 650: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-57

Mapping Traffic into Tunnels with Autoroute This section identifies the command syntax that is required to deploy traffic tunnels with the autoroute feature on Cisco IOS devices.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-16

¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą ż«¬±®±«¬» ż˛˛±«˛˝»

®±«¬»®ř˝±˛ş·ąó·ş÷ý

• Causes the IGP to use the tunnel in its enhanced SPF

Deploying Traffic Tunnels with Autoroute

tunnel mpls traffic-eng autoroute announce To instruct the IGP to use the tunnel in its shortest path first (SPF) calculation if the tunnel is up, use the tunnel mpls traffic-eng autoroute announce command in interface configuration mode. To disable this feature, use the no form of this command.

tunnel mpls traffic-eng autoroute announce

no tunnel mpls traffic-eng autoroute announce

Default

The tunnel is not used by the IGP in its SPF next-hop calculation unless a mechanism to map traffic to the tunnel is implemented.

Usage Guidelines

The tunnel mpls traffic-eng autoroute announce command is a scalable way to map IP traffic onto a tunnel. Alternate mapping methods include static routes pointing to the tunnel interface and using policy-based routing (PBR) to set the next hop for the destination to the tunnel interface.

For flexibility, the autoroute feature is preferred over these alternatives.

Page 651: Implementing cisco mpls

8-58 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-17

Example: Configuring TE Options on a Tunnel Interface

·° »¨°´·˝·¬ó°ż¬¸ ˛żł» Ş·żÁĐď »˛żľ´»˛»¨¬óżĽĽ®»­­ ďđňďňďňď¨¬óżĽĽ®»­­ ďđňďňďňî

·˛¬»®şż˝» ¬«˛˛»´ đ·° «˛˛«łľ»®»Ľ Ô±±°ľż˝µđ¬«˛˛»´ Ľ»­¬·˛ż¬·±˛ ďđňďňďň˛˛»´ ł±Ľ» ł°´­ ¬®żşş·˝ó»˛ą¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą °®·±®·¬§ í í¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą ľż˛Ľ©·Ľ¬¸ ďî謫˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą °ż¬¸ó±°¬·±˛ ď »¨°´·˝·¬ ˛żł» Ş·żÁĐשׂ˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą ż«¬±®±«¬» ż˛˛±«˛˝»

This figure illustrates commands to configure some TE options on a tunnel interface.

Note These commands are configured only on the ingress PE for the MPLS TE tunnel.

Page 652: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-59

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-18

Summary

• Required tasks to implement TE in a MPLS VPN network include:

– Enabling device-level MPLS TE support on PE and P routers

– Enabling MPLS TE support in an IS-IS environment on PE and P routers

– Enabling MPLS TE support in an OSPF environment on PE and P routers

– Enabling MPLS TE on an interface on PE and P routers

– Creating and configuring a traffic tunnel on ingress PE router

– Enabling traffic tunnels with autoroute in ingress PE router

ReferencesFor additional information, refer to this resource:

MPLS Configuration Examples and TechNotes. http://www.cisco.com/en/US/tech/tk436/tk428/tech_configuration_examples_list.html

Page 653: Implementing cisco mpls

8-60 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 654: Implementing cisco mpls

Lesson 4

Monitoring Basic MPLS TE on Cisco IOS Platforms

OverviewThis lesson presents some of the commands, syntax, and descriptions for monitoring Multiprotocol Label Switching (MPLS) traffic engineering (TE). This lesson explains how to monitor simple TE tunnels in an MPLS network to ensure that traffic engineering is functioning appropriately.

ObjectivesUpon completing this lesson, you will be able to describe how to monitor basic MPLS TE on Cisco IOS platforms. This ability includes being able to meet these objectives:

Monitor MPLS TE tunnels

Monitor MPLS TE, including verifying RSVP information on an interface, verifying that MPLS TE is present in the global routing table, and verifying that IP traffic is forwarded through the MPLS TE tunnels

Page 655: Implementing cisco mpls

8-62 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Monitoring MPLS TE Tunnels This topic describes how to monitor MPLS TE tunnels.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-3

­¸±© ł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­ Ĺ°ż®żł»¬»®­Ă

®±«¬»®ý

• Shows detailed information about a tunnel

Monitoring MPLS TE Tunnels

­¸±© ł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­ ¬«˛˛»´Á·˛¬»®şż˝» Ĺľ®·»şĂ

®±«¬»®ý

• Shows summary information about a tunnel

­¸±© ·° ®­Ş° ·˛¬»®şż˝»

®±«¬»®ý

• Confirms which interfaces have RSVP information configured

show ip rsvp interface To display Resource Reservation Protocol (RSVP)-related information, use the show ip rsvp interface command in EXEC mode.

show ip rsvp interface [interface-type interface-number] [detail]

Syntax Description

Parameter Description

·˛¬»®şż˝»ó¬§°» (Optional) Type of interface

·˛¬»®şż˝»ó˛«łľ»® (Optional) Number of interface

Ľ»¬ż·´ (Optional) Displays additional information about interfaces

Page 656: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-63

The example shows output from the show ip rsvp interface command.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-4

Monitoring MPLS TE Tunnels:show ip rsvp interface

Đéîý­¸±© ·° ®­Ş° ·˛¬»®şż˝»

·˛¬»®şż˝» ż´´±˝ż¬»Ľ ·ńş łż¨ ş´±© łż¨ ­«ľ łż¨

Í»đńđ đ ďîčŐ ďîčŐ đ

Í»đńđňďďď đ ďîčŐ ďîčŐ đ

Í»đńđňďďî đ ďîčŐ ďîčŐ đ

Í»đńđňîéî đ ďîčŐ ďîčŐ đ

show mpls traffic-eng tunnels To show information about MPLS TE tunnels, use the show mpls traffic-eng tunnels command.

show mpls traffic-eng tunnels tunnel-interface [brief]

show mpls traffic-eng tunnels [destination address][source-id {number | ip-address | ip-address number}] [role {all | head | middle | tail | remote}] [up | down] [name string][suboptimal constraints {none | current | max}] [[interface in physical-interface][interface out physical-interface] | [interface physical-interface] [brief]

The table describes the parameters available for the show mpls traffic-eng tunnels command.

Page 657: Implementing cisco mpls

8-64 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Syntax Description

Parameter Description

¬«˛˛»´ó·˛¬»®şż˝» Displays information for the specified tunneling interface.

ľ®·»ş (Optional) Displays the information in brief format.

Ľ»­¬·˛ż¬·±˛ żĽĽ®»­­ (Optional) Restricts the display to tunnels that are destined to the specified IP address.

­±«®˝»ó·Ľ (Optional) Restricts the display to tunnels with a matching source IP address or tunnel number.

˛«łľ»® (Optional) Tunnel number.

·°óżĽĽ®»­­ (Optional) Source IP address.

·°óżĽĽ®»­­ ˛«łľ»® (Optional) Source IP address and tunnel number.

®±´» (Optional) Restricts the display to tunnels with the indicated role (all, head, middle, tail, or remote).

ż´´ (Optional) Displays all tunnels.

¸»żĽ (Optional) Displays tunnels with their heads at this router.

ł·ĽĽ´» (Optional) Displays tunnels with their midpoints at this router.

¬ż·´ (Optional) Displays tunnels with their tails at this router.

®»ł±¬» (Optional) Displays tunnels with their heads at another router; this display is a combination of the middle and tail keyword values.

«° (Optional) Displays tunnels if the tunnel interface is up. Tunnel midpoints and tails are typically up or not present.

Ľ±©˛ (Optional) Displays tunnels that are down.

˛żł» ­¬®·˛ą (Optional) Displays tunnels with the specified name. The tunnel name is derived from the interface description, if specified; otherwise, it is the interface name. The tunnel name is included in the signaling message so that it is available at all hops.

­«ľ±°¬·łż´ ˝±˛­¬®ż·˛¬­ ˛±˛»

(Optional) Displays tunnels whose path metric is greater than the shortest unconstrained path. Selected tunnels have a longer path than the shortest path of the Interior Gateway Protocol (IGP).

­«ľ±°¬·łż´ ˝±˛­¬®ż·˛¬­ ˝«®®»˛¬

(Optional) Displays tunnels whose path metric is greater than the current shortest path, constrained by the configured tunnel options. Selected tunnels would have a shorter path if they were reoptimized immediately.

­«ľ±°¬·łż´ ˝±˛­¬®ż·˛¬­ łż¨

(Optional) Displays tunnels whose path metric is greater than the current shortest path, constrained by the configured tunnel options and considering only the capacity of the network. Selected tunnels would have a shorter path if no other tunnels were consuming network resources.

·˛¬»®şż˝» ·˛ °¸§­·˝ż´ó·˛¬»®şż˝»

(Optional) Displays tunnels that use the specified input interface.

·˛¬»®şż˝» ±«¬ °¸§­·˝ż´ó·˛¬»®şż˝»

(Optional) Displays tunnels that use the specified output interface.

·˛¬»®şż˝» °¸§­·˝ż´ó·˛¬»®şż˝»

(Optional) Displays tunnels that use the specified interface as an input or output interface.

ľ®·»ş (Optional) Specifies one line per tunnel.

Page 658: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-65

The example shows output from the show mpls traffic-eng tunnels brief command.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-5

Monitoring MPLS TE Tunnels:show mpls traffic-eng tunnels brief

ĐŰéďý­¸±© ł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­ ľ®·»ş

Í·ą˛ż´·˛ą Í«łłż®§ć

ÔÍĐ Ě«˛˛»´­ Đ®±˝»­­ć ®«˛˛·˛ą

ÎÍĘĐ Đ®±˝»­­ć ®«˛˛·˛ą

Ú±®©ż®Ľ·˛ąć »˛żľ´»Ľ

Đ»®·±Ľ·˝ ®»±°¬·ł·¦ż¬·±˛ć »Ş»®§ íđ ­»˝±˛Ľ­ô ˛»¨¬ ·˛ ďď ­»˝±˛Ľ­

Đ»®·±Ľ·˝ ż«¬±óľ© ˝±´´»˝¬·±˛ć Ľ·­żľ´»Ľ

ĚËŇŇŰÔ ŇßÓŰ ÜŰÍĚ×ŇßĚ×ŃŇ ËĐ ×Ú ÜŃÉŇ ×Ú ÍĚßĚŰńĐÎŃĚ

ĐŰéďÁ¬đ ďçîňďęčňéňíí ó Í»đńđňďď «°ń«°

ĐŰéîÁ¬đ ďçîňďęčňéňďé Í»đńđňďď ó «°ń«°

Ü·­°´ż§»Ľ ď ř±ş ď÷ ¸»żĽ­ô đ ř±ş đ÷ ł·Ľ°±·˛¬­ô ď ř±ş ď÷ ¬ż·´­

Note Depending on its length, the tunnel name may be truncated.

Page 659: Implementing cisco mpls

8-66 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Monitoring MPLS TE This topic describes how to monitor MPLS TE.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-6

Monitoring MPLS TE

­¸±© ł°´­ ¬®żşş·˝ó»˛ą ż«¬±®±«¬»

®±«¬»®ý

• Shows tunnels that are announced to IGP, including interface, destination, and bandwidth

­¸±© ·° ˝»ş ˛»¬©±®µ Ĺłż­µĂ

®±«¬»®ý

• Shows network entries in the Forwarding Information Base (FIB) to verify that IP traffic is forwarded through tunnel interface

­¸±© ·° ˝»ş Ş®ş Ş®şó˛żł» ˛»¬©±®µ Ĺłż­µĂ

®±«¬»®ý

• Shows VRF network entries in the FIB to verify that MPLS VPN traffic is forwarded through tunnel interface

show mpls traffic-eng autoroute To show tunnels that are announced to IGP, including interface, destination, and bandwidth, use the show mpls traffic-eng autoroute command in privileged EXEC mode.

show mpls traffic-eng autoroute

Usage Guidelines

The enhanced shortest path first (SPF) calculation of the IGP has been modified so that it uses TE tunnels. This command shows which tunnels the IGP is currently using in its SPF, or which tunnels that are up and have autoroute configured.

Page 660: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-67

The example shows output from the show mpls traffic-eng autoroute command.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-7

Monitoring MPLS TE:show mpls traffic-eng autoroute

ĐŰéďý­¸±© ł°´­ ¬®żşş·˝ó»˛ą ż«¬±®±«¬»

ÓĐÔÍ ĚŰ ż«¬±®±«¬·˛ą »˛żľ´»Ľ

Ľ»­¬·˛ż¬·±˛ đđđđňđđđđňđďéîňđ𠸿­ ď ¬«˛˛»´­

Ě«˛˛»´đ ř´±żĽ ľż´ż˛˝·˛ą ł»¬®·˝ îđđđđđđđô ˛»¨¬¸±° ďçîňďęčňéňíí÷

Note The list of tunnels is organized by destination. All tunnels to a destination will carry a share

of the traffic to that destination.

Page 661: Implementing cisco mpls

8-68 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

show ip cef networkTo verify that IP traffic is forwarded through a tunnel interface, use the show ip cef networkcommand in privileged EXEC mode.

show ip cef network [mask]

The example shows output from the show ip cef network command.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-8

Monitoring MPLS TE:show ip cef network

ĐŰéďý­¸±© ·° ˝»ş ďçîňďęčňéňíí

ďçîňďęčňéňííńíîô Ş»®­·±˛ îëô »°±˝¸ đ

đ °ż˝µ»¬­ô 𠾧¬»­

¬żą ·˛ş±®łż¬·±˛ ­»¬ô ­¸ż®»Ľ

´±˝ż´ ¬żąć íđ

şż­¬ ¬żą ®»©®·¬» ©·¬¸ Ě«đô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć ĄííŁ

Ş·ż ďçîňďęčňéňííô Ě«˛˛»´đô ďď Ľ»°»˛Ľ»˛˝·»­

˛»¨¬ ¸±° ďçîňďęčňéňííô Ě«˛˛»´đ

Şż´·Ľ żĽ¶ż˝»˛˝§

¬żą ®»©®·¬» ©·¬¸ Ě«đô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć ĄííŁ

Page 662: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-69

show ip cef vrf vrf-name networkTo verify that Virtual Private Network (VPN) traffic is forwarded through a tunnel interface, use the show ip cef vrf vrf-name network command in privileged EXEC mode.

show ip cef vrf vrf-name network [mask]

The example shows output from the show ip cef vrf vrf-name network command.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-9

Monitoring MPLS TE:show ip cef vrf vrf-name network

ĐŰéďý­¸±© ·° ˝»ş Ş®ş Ý«­¬ß ďđňďňéîňěç

ďđňďňéîňěçńíîô Ş»®­·±˛ îđô »°±˝¸ đ

đ °ż˝µ»¬­ô 𠾧¬»­

¬żą ·˛ş±®łż¬·±˛ ­»¬

´±˝ż´ ¬żąć ĘĐŇ󮱫¬»ó¸»żĽ

şż­¬ ¬żą ®»©®·¬» ©·¬¸ Ě«đô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć Ąíí íěŁ

Ş·ż ďçîňďęčňéňííô đ Ľ»°»˛Ľ»˛˝·»­ô ®»˝«®­·Ş»

˛»¨¬ ¸±° ďçîňďęčňéňííô Ě«˛˛»´đ Ş·ż ďçîňďęčňéňííńíî

Şż´·Ľ żĽ¶ż˝»˛˝§

¬żą ®»©®·¬» ©·¬¸ Ě«đô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć Ąíí íěŁ

Page 663: Implementing cisco mpls

8-70 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

SummaryThis topic summarizes the key points that were discussed in this lesson.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-10

Summary

• Use the following commands to monitor MPLS TE tunnels:

– show ip rsvp interface

– show mpls traffic-eng tunnels

• Use the following commands to monitor MPLS TE:

– show mpls traffic-eng autoroute

– show ip cef network

– show ip cef vrf vrf-name network

ReferencesFor additional information, refer to this resource:

MPLS Configuration Examples and TechNotes. http://www.cisco.com/en/US/tech/tk436/tk428/tech_configuration_examples_list.html

Page 664: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-71

Module Summary This topic summarizes the key points that were discussed in this module.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-1

Module Summary

• Traffic engineering measures, models, and controls traffic

• The MPLS TE uses traffic tunnels, RSVP with TE extensions, and a link state IGP

• MPLS TE implementation includes device, interface, routing protocol, and tunnel configuration

• Commands including show ip cef and show mplscan be used to monitor MPLS TE

This module provides a brief introduction to Multiprotocol Label Switching (MPLS) traffic engineering (TE).

ReferencesFor additional information, refer to this resource:

MPLS Configuration Examples and TechNotes. http://www.cisco.com/en/US/tech/tk436/tk428/tech_configuration_examples_list.html

Page 665: Implementing cisco mpls

8-72 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Module Self-Check Use the questions here to review what you learned in this module. The correct answers and solutions are found in the Module Self-Check Answer Key.

Q1) What is the main motivation for implementing traffic engineering? (Source:

Introducing the TE Concept)

Q2) Which two situations can result in network congestion? (Choose two.) (Source:

Introducing the TE Concept)

A) The least-cost network path is being used to route traffic. B) Traffic streams are efficiently mapped onto available resources. C) Network resources are insufficient to accommodate the offered load. D) Traffic streams are inefficiently mapped onto available resources.

Q3) Short traffic bursts are best handled by which three mechanisms? (Choose three.)

(Source: Introducing the TE Concept)

A) rate limiting B) traffic engineering C) queuing algorithms D) intelligent packet dropping

Q4) When you are using TE with a Layer 2 overlay model, which two of the following

transport traffic across a network? (Choose two.) (Source: Introducing the TE Concept)

A) DVCsB) PVCsC) RVCsD) SVCs

Q5) When you are using a traffic-engineered Layer 3 model, which two of the following are

limitations? (Choose two.) (Source: Introducing the TE Concept)

A) using static routes B) using policy routing C) unavailability of explicit routing D) path computation that is based just on the IGP metric

Q6) When you are using MPLS-TE, a minimum of _____ labels is assigned to a packet at

the ingress router. (Source: Introducing the TE Concept)

A) oneB) twoC) threeD) four

Page 666: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-73

Q7) A set of data flows that share some common feature, attribute, or requirement is called

_____. (Source: Understanding MPLS TE Components)

A) a static route B) a policy route C) a TE tunnel D) TE LSP

Q8) The constraint-based path computation uses which algorithm? (Source: Understanding

MPLS TE Components)

A) DUAL algorithm B) modified Dijkstra algorithm C) modified Bell-Howell algorithm D) none of the above

Q9) Which two can be used to advertise a traffic tunnel so that it will appear in the IP

routing table? (Choose two.) (Source: Understanding MPLS TE Components)

A) autoroute feature B) TE mapping statement C) static routes D) mpls traffic-eng tunnels command

Q10) What is the role of RSVP in an MPLS TE implementation? (Source: Understanding

MPLS TE Components)

A) It identifies the best path for the tunnel. B) It reserves the bandwidth required by the tunnel. C) It performs the CBR calculations for the tunnel setup. D) It assigns the label for the MPLS LSP.

Q11) To enable MPLS TE tunnel signaling on a device, you must use the _____ command.

(Source: Configuring MPLS TE on Cisco IOS Platforms)

A) ip cef B) mpls ip C) mpls-te enable D) mpls traffic-eng tunnels

Q12) The command to allow a router to generate and accept only new-style TLV objects

under IS-IS is the ________________ command. (Source: Configuring MPLS TE on

Cisco IOS Platforms)

A) ip cef B) metric-style wide C) mpls traffic-eng D) mpls traffic-eng area

Q13) Which command enables MPLS TE in an OSPF implementation? (Source: Configuring

MPLS TE on Cisco IOS Platforms)

A) mpls traffic-eng tunnels B) metric-style wide C) mpls traffic-eng area D) mpls traffic-eng

Page 667: Implementing cisco mpls

8-74 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Q14) The _____ command is used to declare a TSP tunnel interface. (Source: Configuring

MPLS TE on Cisco IOS Platforms)

A) interface tunnel numberB) tunnel destination ip-addressC) tunnel mode mpls traffic-eng D) tunnel mpls traffic-eng autoroute announce

Q15) The _____ command is used to instruct the IGP to use the tunnel in its SPF or next-hop

calculation. (Source: Configuring MPLS TE on Cisco IOS Platforms)

A) interface tunnel numberB) tunnel destination ip-addressC) tunnel mode mpls traffic-eng D) tunnel mpls traffic-eng autoroute announce

Q16) The _____ command is used to display Resource Reservation Protocol (RSVP)-related

information. (Source: Monitoring Basic MPLS TE on Cisco IOS Platforms)

A) show mpls traffic-eng tunnels B) show ip rsvp interface C) show ip cef network D) show ip rsvp network

Q17) The _____ command is used to verify that IP traffic is forwarded through a tunnel

interface. (Source: Monitoring Basic MPLS TE on Cisco IOS Platforms)

A) show mpls traffic-eng tunnels B) show ip rsvp interface C) show ip cef networkD) show ip rsvp network

Q18) The _____ command is used to show information about MPLS TE tunnels. (Source:

Monitoring Basic MPLS TE on Cisco IOS Platforms)

A) show mpls traffic-eng tunnels B) show ip rsvp interface C) show ip cef network D) show ip rsvp network

Page 668: Implementing cisco mpls

© 2006 Cisco Systems, Inc. MPLS TE Overview 8-75

Answer Key Q1) Cost reduction

Q2) C, D

Q3) A, C, D

Q4) B, D

Q5) C, D

Q6) B

Q7) C

Q8) B

Q9) A, C

Q10) C

Q11) D

Q12) B

Q13) C

Q14) A

Q15) D

Q16) B

Q17) C

Q18) A

Page 669: Implementing cisco mpls

8-76 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Page 670: Implementing cisco mpls

MPLS

Implementing Cisco MPLSVersion 2.2

Lab Guide

Editorial, Production, and Web Services: 06.29.07

Page 671: Implementing cisco mpls

DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED “AS IS.” CISCO MAKES AND YOU RECEIVE NO WARRANTIES IN

CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY OR IN ANY OTHER PROVISION OF

THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO SPECIFICALLY DISCLAIMS ALL IMPLIED

WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR

PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. This learning product may contain early release

content, and while Cisco believes it to be accurate, it falls subject to the disclaimer above.

Page 672: Implementing cisco mpls

MPLS

Lab Guide

OverviewThis guide presents the instructions and other information concerning the activities for this course. You can find the solutions in the activity Answer Key.

OutlineThis guide includes these activities:

Lab 2-1: Establishing the Service Provider IGP Routing Environment

Lab 3-1: Establishing the Core MPLS Environment

Lab 5-1: Configuring Initial MPLS VPN Setup

Lab 5-2: Running EIGRP Between PE and CE Routers

Lab 5-3: Running OSPF Between PE and CE Routers

Lab 5-4: Running BGP Between PE and CE Routers

Lab 6-1: Establishing Overlapping VPNs

Lab 6-2: Merging Service Providers

Lab 6-3: Establishing a Common Services VPN

Lab 7-1: Establishing Central Site Internet Connectivity with an MPLS VPN

Lab 8-1: Implementing Basic MPLS TE

Answer Key

Page 673: Implementing cisco mpls

2 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 2-1: Establishing the Service Provider IGP Routing Environment

Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will use the tasks and commands necessary to implement the service provider IGP and routing environment. After completing this activity, you will be able to meet these objectives:

Verify the service provider IP addressing scheme, DLCI assignment, and interface status

Enable the service provider IGP and configure appropriate IP addressing

Visual Objective The figure illustrates what you will accomplish in this activity. This activity contains information about your laboratory setup, details of the physical and logical connectivity in the laboratory, and information about the addressing scheme and IGP routing. The class will be divided into service providers, or SPs, (where x represents your assigned SP number). Each SP will contain the router types as defined in the table.

The names of all routers in your SP follow the naming convention detailed in this table.

Router Naming Convention

Router Role Description

P (provider) Px1 and Px2 are core routers in the network of the provider.

PE(provider edge) PEx1 and PEx2 are provider edge routers connecting from the provider to the customer network.

CE(customer edge) CEx1A and CEx2A and CEx1B and CEx2B are customer edge routers for customer A and customer B, respectively.

SP numbering will be provided by your instructor. SP 3, 4, 5, and 6 will be used for this course.

Page 674: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 3

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—1

MPLS Lab Physical Connection Diagram

Physical connectivity has been provided by preconfigured PVCs defined by their respective DLCIs. The first serial interface of each router (P, PE, and CE) is connected to a Frame Relay switch. The DLCI values for all Frame Relay virtual circuits are shown in the DLCI identification table and the logical connection diagram figure. The subinterface number matches the DLCI values for all Frame Relay virtual circuits.

DLCI Identification

Source Router Destination Router DLCI Interface

CEx1A PEx1 101 S0/0.101

CEx1B PEx1 102 S0/0.102

CEx2A PEx2 101 S0/0.101

CEx2B PEx2 102 S0/0.102

PEx1 CEx1A 101 S0/0.101

PEx1 CEx1B 102 S0/0.102

PEx1 Px1 111 S0/0.111

PEx2 CEx2A 101 S0/0.101

PEx2 CEx2B 102 S0/0.102

PEx2 Px2 111 S0/0.111

Px1 PEx1 111 S0/0.111

Px1 Px2 112 S0/0.112

Px2 PEx2 111 S0/0.111

Px2 Px1 112 S0/0.112

Page 675: Implementing cisco mpls

4 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2

MPLS Lab Logical Connection Diagram

This figure represents the logical connection of two service providers. The Frame Relay DLCI information is included from the DLCI identification table. Note that the serial subinterface number matches the DLCI number.

Each SP has two P routers creating the core of the service provider network. Each P router connects to the PE router that supports the POP, which is the interface between the service provider network and the customer network. The PE routers interconnect two different customers (A and B).

Each SP is further divided into two POPs which correspond to student workgroups. Each student workgroup should configure its respective left or right side of the SP. For example, workgroup 31 at POP 31 should configure P31, PE31, CE31A, and CE31B. This leaves workgroup 32 at POP 32 to configure P32, PE32, CE32A, and CE32B.

Your POP will still depend on the other POP in your SP network to complete end-to-end connectivity for customer A and customer B. Each customer has a location on each side of the POPs. An example is customer A with sites CE31A and CE32A. Site CE31A is connected to PE31 within POP 31; site CE32A is connected to the other PE32 router within POP 32.

Page 676: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 5

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3

MPLS Lab IP Addressing Scheme

The IP addressing of routers has been performed using the allocation scheme detailed in the IP host address table. Note that x equals your SP number.

For all exercises, there are three distinct IP address ranges.

The 10.1.0.0 and 10.2.0.0 ranges are used to provide network addressing for the networks of customers A and B respectively. The second octet indicates the customer. The third octet of the address indicates the SP POP.

For example, 10.1.41.16/28 is a customer A subnet on POP 41 for SP 4.

The 150.0.0.0 range is used to provide addressing for the links between the CE routers and the PE routers. The second octet of the address indicates the SP, and the third octet indicates the SP POP.

For example, 150.5.51.16/28 is a link between a CE router (CE51) and POP 51 (or router PE51) for SP 5.

The 192.168.0.0 range is used to provide addressing for the core MPLS network of the SP. The third octet of the address indicates the SP number.

For example, 192.168.6.64/28 is a link between a PE router (PE62) and a core router (P62) for SP 6.

Page 677: Implementing cisco mpls

6 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

IP Host Address

Parameter Value

CEx1A (S0/0.101) 150.x.x1.17/28

CEx1A (loopback0) 10.1.x1.49/32

CEx1A (E0/0) 10.1.x1.17/28

CEx2A (S0/0.101) 150.x.x2.17/28

CEx2A (loopback0) 10.1.x2.49/32

CEx2A (E0/0) 10.1.x2.17/28

CEx1B (S0/0.102) 150.x.x1.33/28

CEx1B (loopback0) 10.2.x1.49/32

CEx1B (E0/0) 10.2.x1.17/28

CEx2B (S0/0.102) 150.x.x2.33/28

CEx2B (loopback0) 10.2.x2.49/32

CEx2B (E0/0) 10.2.x2.17/28

PEx1 (S0/0.101) 150.x.x1.18/28

PEx1 (S0/0.102) 150.x.x1.34/28

PEx1 (loopback0) 192.168.x.17/32

PEx1 (S0/0.111) 192.168.x.49/28

PEx2 (S0/0.101) 150.x.x2.18/28

PEx2 (S0/0.102) 150.x.x2.34/28

PEx2 (loopback0) 192.168.x.33/32

PEx2 (S0/0.111) 192.168.x.65/28

Px1 (S0/0.111) 192.168.x.50/28

Px1 (S0/0.112) 192.168.x.113/28

Px1 (loopback0) 192.168.x.81/32

Px2 (S0/0.111) 192.168.x.66/28

Px2 (S0/0.112) 192.168.x.114/28

Px2 (loopback0) 192.168.x.97/32

Note This addressing scheme has been selected for ease of use in the labs; it does not optimize

the use of the address space.

Page 678: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 7

Required Resources This is the resource that is required to complete this activity:

Cisco IOS documentation

Command List The table describes the commands that are used in this activity.

IP, IGP, and Interface Commands

Command Description

˛»¬©±®µ ˛»¬©±®µó˛«łľ»® Ų»¬©±®µółż­µĂ To specify a list of networks for the EIGRP routing process, use the network router configuration command. To remove an entry, use the no form of this command.

®±«¬»® »·ą®° ż­ó˛«łľ»® To configure the EIGRP routing process, use the router eigrp global configuration command. To shut down a routing process, use the no form of this command.

·˛¬»®şż˝» ­»®·ż´

Ĺ­´±¬ń°±®¬Ăň­«ľ·˛¬»®şż˝» °±·˛¬ó¬±ó°±·˛¬ To define a logical point-to-point subinterface on a physical serial interface.

»˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§ Enables Frame Relay encapsulation..

ş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· Ľ´˝· Specifies the DLCI associated with its point-to-point link.

­¸±© ş®żł»ó®»´ż§ °Ş˝ To display statistics about PVCs for Frame Relay interfaces, use the show frame-relay pvc privileged EXEC command.

­¸±© ·˛¬»®şż˝»­ ­»®·ż´ Ĺ­´±¬ń°±®¬Ă To display information about a serial interface, use the show interfaces serial command in privileged EXEC mode. When using Frame Relay encapsulation, use the show interfaces serial command in EXEC mode to display information about the multicast DLCI, the DLCIs used on the interface, and the DLCI used for the LMI.

­¸±© ·° °®±¬±˝±´­ To display the parameters and current state of the active routing protocol process, use the show ip protocolsEXEC command.

­¸±© ·° ®±«¬» Ĺ·°óżĽĽ®»­­ Ĺłż­µĂ Ĺ´±˛ą»®ó°®»ş·¨»­ĂĂ ¤ Ĺ°®±¬±˝±´ Ĺ°®±˝»­­ó·ĽĂĂ

To display the current state of the routing table, use the show ip route EXEC command.

Page 679: Implementing cisco mpls

8 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Task 1: Configure the Service Provider IP Interfaces Your task is to configure Layer 2 and Layer 3 addressing and ensure that the proper interfaces are enabled.

Note The enable password on all routers is “mpls.”

Activity Procedure

Complete these steps with reference to the preceding MPLS logical connection diagram and IP addressing scheme. Workgroup x1 on POP x1 and workgroup x2 on POP x2 of each SP should configure their respective group of routers.

Step 1 Configure and enable each P router interface, subinterface, and loopback for its appropriate DLCI and IP addressing.

Step 2 Configure and enable each PE router interface, subinterface, and loopback for its appropriate DLCI and IP addressing.

Step 3 Configure and enable each CE router interface, subinterface, and loopback for appropriate DLCI and IP addressing. Configure the Ethernet interfaces to be half-duplex with no keepalives.

Activity Verification

You have completed this task when you attain these results:

You have pinged the remote end of each serial link from each router to verify that each link

is operational.

Task 2: Configure the Service Provider IGP Your next task is to establish the service provider IGP routing environment. This task will involve enabling the EIGRP routing protocol.

Activity Procedure

Complete these steps for POP x1 and x2 of each SP:

Step 1 On each CE router, enable the RIP version 2 (RIPv2) routing process. Advertise the 10.0.0.0 and the 150.x.0.0 networks. Disable the autosummarization feature of this routing protocol.

Step 2 On each P and PE router, enable the EIGRP routing process, using 1 as the AS number, and ensure that the service provider networks are configured and are being advertised by the EIGRP process. Disable the autosummarization feature of this routing protocol.

Step 3 Ensure that the other POP has completed its configuration tasks.

Page 680: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 9

Activity Verification

You have completed this task when you attain these results:

On each P and PE router, you have verified that the EIGRP router process is active.

On each P and PE router, you have verified that the EIGRP router process is enabled on all serial interfaces.

On each P and PE router, you have verified that the loopback interfaces of all P and PE routers are displayed in the IP routing table.

On each P and PE router, you have verified that the 192.168.x.0 subnetworks of all P and PE routers are displayed in the IP routing table.

On each PE router, you have verified that the 150.x.0.0 subnetworks of all P and PE routers are displayed in the IP routing table.

Đۨďý­¸ ·° ®±«¬»

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî

·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»

± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďçîňďęčň¨ňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­

Ü ďçîňďęčň¨ňçéńíî ĹçđńîčđçčëęĂ Ş·ż ďçîňďęčň¨ňëđô đđćđęćîçô Í»®·ż´đńđňďďď

Ü ďçîňďęčň¨ňďďîńîč

ĹçđńîęčďčëęĂ Ş·ż ďçîňďęčň¨ňëđô đđćđęćîçô Í»®·ż´đńđňďďď

Ü ďçîňďęčň¨ňęěńîč ĹçđńíďçíčëęĂ Ş·ż ďçîňďęčň¨ňëđô đđćđęćîçô Í»®·ż´đńđňďďď

Ü ďçîňďęčň¨ňčďńíî ĹçđńîîçéčëęĂ Ş·ż ďçîňďęčň¨ňëđô đđćđęćîçô Í»®·ż´đńđňďďď

Ü ďçîňďęčň¨ňííńíî ĹçđńííîďčëęĂ Ş·ż ďçîňďęčň¨ňëđô đđćđęćîçô Í»®·ż´đńđňďďď

Ý ďçîňďęčň¨ňěčńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďď

Ý ďçîňďęčň¨ňďéńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­

Ý ďëđň¨ň¨ďňíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđî

Ü ďëđň¨ň¨îňíî ĹçđńíéđëčëęĂ Ş·ż ďçîňďęčň¨ňëđô đđćđęćíđô Í»®·ż´đńđňďďď

Ý ďëđň¨ň¨ďňďę ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđď

Ü ďëđň¨ň¨îňďę ĹçđńíéđëčëęĂ Ş·ż ďçîňďęčň¨ňëđô đđćđęćíđô Í»®·ż´đńđňďďď

Đۨďý

Page 681: Implementing cisco mpls

10 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Шîý­¸ ·° ®±«¬»

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî

·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»

± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďçîňďęčň¨ňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­

Ý ďçîňďęčň¨ňçéńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

Ý ďçîňďęčň¨ňďďîńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďî

Ý ďçîňďęčň¨ňęěńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďď

Ü ďçîňďęčň¨ňčďńíî

ĹçđńîîçéčëęĂ Ş·ż ďçîňďęčň¨ňďďíô đđćďđćëëô Í»®·ż´đńđňďďî

Ü ďçîňďęčň¨ňííńíî ĹçđńîîçéčëęĂ Ş·ż ďçîňďęčň¨ňęëô đđćďđćëëô Í»®·ż´đńđňďďď

Ü ďçîňďęčň¨ňěčńîč

ĹçđńîęčďčëęĂ Ş·ż ďçîňďęčň¨ňďďíô đđćđéćëęô Í»®·ż´đńđňďďî

Ü ďçîňďęčň¨ňďéńíî

ĹçđńîčđçčëęĂ Ş·ż ďçîňďęčň¨ňďďíô đđćđéćěéô Í»®·ż´đńđňďďî

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­

Ü ďëđň¨ň¨ďňíî ĹçđńíďçíčëęĂ Ş·ż ďçîňďęčň¨ňďďíô đđćđéćěéô Í»®·ż´đńđňďďî

Ü ďëđň¨ň¨îňíî ĹçđńîęčďčëęĂ Ş·ż ďçîňďęčň¨ňęëô đđćďđćëęô Í»®·ż´đńđňďďď

Ü ďëđň¨ň¨ďňďę ĹçđńíďçíčëęĂ Ş·ż ďçîňďęčň¨ňďďíô đđćđéćîđô Í»®·ż´đńđňďďî

Ü ďëđň¨ň¨îňďę ĹçđńîęčďčëęĂ Ş·ż ďçîňďęčň¨ňęëô đđćďđćëęô Í»®·ż´đńđňďďď

Шîý

Page 682: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 11

Lab 3-1: Establishing the Core MPLS Environment

Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will use the tasks and commands necessary to implement MPLS on frame-mode Cisco IOS platforms. After completing this activity, you will be able to meet these objectives:

Enable LDP on your PE and P routers

Enable and disable MPLS TTL propagation

Configure conditional label distribution

Remove conditional label distribution

Visual Objective The figure illustrates what you will accomplish in this activity.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—4

MPLS Lab Core LDP Scheme

Required Resources This is the resource that is required to complete this activity:

Cisco IOS documentation

Page 683: Implementing cisco mpls

12 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Command List The table describes the commands that are used in this activity.

MPLS Commands

Command Description

ż˝˝»­­ó´·­¬ ż˝˝»­­ó´·­¬ó˛«łľ»® Ą°»®ł·¬ ¤ Ľ»˛§Ł Ą¬§°»ó˝±Ľ» ©·´Ľółż­µ ¤ żĽĽ®»­­ łż­µŁ

To configure the access list mechanism for filtering frames by protocol type or vendor code, use the access-list global configuration command. To remove the single specified entry from the access list, use the no form of this command.

·° ˝»ş To enable CEF, use the ip cef command in global configuration mode. To disable CEF, use the no form of this command.

ł°´­ ·°

To enable MPLS forwarding of IPv4 packets along normally routed paths for the platform, the mpls ip command can be used in global configuration mode (for TE) but must be used at the interface configuration mode for LDP to become active. To disable this feature, use the no form of this command.

ł°´­ ·° °®±°żąż¬»ó¬¬´ Ĺş±®©ż®Ľ»Ľ ¤ ´±˝ż´Ă

To control the generation of the TTL field in the MPLS header when labels are first added to an IP packet, use the mpls ip propagate-ttl global configuration command. To use a fixed TTL value (255) for the first label of the IP packet, use the no form of this command.

ł°´­ ´żľ»´ °®±¬±˝±´

Ą´Ľ° ¤ ¬Ľ° ¤ ľ±¬¸ Ł

To specify the label distribution protocol to be used on a given interface, use the mpls label protocol interface configuration command. Use the no form of the command to disable this feature.

­¸±© ł°´­ ·˛¬»®şż˝»­

Ĺ·˛¬»®şż˝»Ă ĹĽ»¬ż·´Ă To display information about one or more interfaces that have been configured for label switching, use the show mpls interfaces privileged EXEC command.

­¸±© ł°´­ ´Ľ°

Ľ·­˝±Ş»®§ To display the status of the LDP discovery process, use the show mpls ldp discovery privileged EXEC command. This command generates a list of interfaces over which the LDP discovery process is running.

­¸±© ł°´­ ´Ľ° ˛»·ą¸ľ±®

ĹżĽĽ®»­­ ¤ ·˛¬»®şż˝»Ă ĹĽ»¬ż·´Ă

To display the status of LDP sessions, issue the show mpls ldp neighbor privileged EXEC command.

­¸±© ł°´­ ´Ľ° ľ·˛Ľ·˛ą­

Ų»¬©±®µ Ąłż­µ ¤ ´»˛ą¬¸Ł Ĺ´±˛ą»®ó°®»ş·¨»­ĂĂ Ĺ´±˝ż´ó´żľ»´ ´żľ»´ Ĺó ´żľ»´ĂĂ Ĺ®»ł±¬»ó´żľ»´ ´żľ»´ Ĺó ´żľ»´Ăà Ų»·ą¸ľ±® żĽĽ®»­­Ă Ĺ´±˝ż´Ă

To display the contents of the LIB, use the show mpls ldp bindings privileged EXEC command.

ł°´­ ´Ľ° żĽŞ»®¬·­»ó

´żľ»´­ Ĺş±® °®»ş·¨óż˝˝»­­ó´·­¬ Ŭ± °»»®óż˝˝»­­ó´·­¬ĂĂ

To control the distribution of locally assigned (incoming) labels by means of LDP, use the mpls ldp advertise-labels command in global configuration mode. This command is used to control which labels are advertised to which LDP neighbors. To prevent the distribution of locally assigned labels, use the no form of this command.

Page 684: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 13

Task 1: Enable LDP on Your PE and P Routers Your next task is to establish MPLS within the service provider routing environment. This task will involve enabling CEF and MPLS.

Activity Procedure

Complete these steps:

Step 1 On your assigned PE router, do the following:

Enable CEF.

Enable LDP on the subinterface that is connected to your assigned P router.

Step 2 On your assigned P router, do the following:

Enable CEF.

Enable LDP on the subinterface that is connected to your assigned PE router.

Enable LDP on the subinterface that is connected to the P router of the other POP.

Note The mpls label protocol ldp command can be issued at the global configuration level.

Step 3 Verify that the other POP has completed its configuration.

Step 4 On your assigned PE router, determine the default TTL propagation status by using the traceroute command to the loopback address of the PE router of the other POP.

Note The mpls ip command is issued to enable MPLS on an interface, but it will be displayed in

the show running-config command output as the tag-switching ip command.

Activity Verification

You have completed this task when you attain these results:

On each of your routers, you have verified that the interfaces in question have been configured to use LDP.

Шďý­¸±© ł°´­ ·˛¬»®şż˝»

ײ¬»®şż˝» ×Đ Ě«˛˛»´ Ń°»®ż¬·±˛ż´

Í»®·ż´đńđňďďď Ç»­ ř´Ľ°÷ ұ Ç»­

Í»®·ż´đńđňďďî Ç»­ ř´Ľ°÷ ұ Ç»­

Page 685: Implementing cisco mpls

14 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

On each of your routers, you have verified that the interface is up and has established an LDP neighbor relationship.

Шďý­¸±© ł°´­ ´Ľ° Ľ·­˝±Ş»®§

Ô±˝ż´ ÔÜР׼»˛¬·ş·»®ć

ďçîňďęčňďňčďćđ

Ü·­˝±Ş»®§ ͱ«®˝»­ć

ײ¬»®şż˝»­ć

Í»®·ż´đńđňďďď ř´Ľ°÷ć ¨ł·¬ń®»˝Ş

ÔÜР׼ć ďçîňďęčň¨ňďéćđ

Í»®·ż´đńđňďďî ř´Ľ°÷ć ¨ł·¬ń®»˝Ş

ÔÜР׼ć ďçîňďęčň¨ňçéćđ

Шďý­¸±© ł°´­ ´Ľ° ˛»·ą¸ľ±®

Đ»»® ÔÜР׼»˛¬ć ďçîňďęčň¨ňďéćđĺ Ô±˝ż´ ÔÜР׼»˛¬ ďçîňďęčň¨ňčďćđ

ĚÝĐ ˝±˛˛»˝¬·±˛ć ďçîňďęčň¨ňďéňęěę ó ďçîňďęčň¨ňčďňďďđđđ

ͬż¬»ć Ń°»®ĺ Ó­ą­ ­»˛¬ń®˝ŞĽć îđńîíĺ ܱ©˛­¬®»żł

Ë° ¬·ł»ć đđćđčćđí

ÔÜĐ Ľ·­˝±Ş»®§ ­±«®˝»­ć

Í»®·ż´đńđňďďďô Í®˝ ×Đ żĽĽ®ć ďçîňďęčňďňěç

߼Ľ®»­­»­ ľ±«˛Ľ ¬± °»»® ÔÜР׼»˛¬ć

ďçîňďęčň¨ňďé ďçîňďęčň¨ňěç ďëđň¨ň¨ďňďč ďëđň¨ň¨ďňíě

Đ»»® ÔÜР׼»˛¬ć ďçîňďęčňďňçéćđĺ Ô±˝ż´ ÔÜР׼»˛¬ ďçîňďęčň¨ňčďćđ

ĚÝĐ ˝±˛˛»˝¬·±˛ć ďçîňďęčň¨ňçéňďďđđđ ó ďçîňďęčň¨ňčďňęěę

ͬż¬»ć Ń°»®ĺ Ó­ą­ ­»˛¬ń®˝ŞĽć ďčńďčĺ ܱ©˛­¬®»żł

Ë° ¬·ł»ć đđćđęćďë

ÔÜĐ Ľ·­˝±Ş»®§ ­±«®˝»­ć

Í»®·ż´đńđňďďîô Í®˝ ×Đ żĽĽ®ć ďçîňďęčň¨ňďďě

߼Ľ®»­­»­ ľ±«˛Ľ ¬± °»»® ÔÜР׼»˛¬ć

ďçîňďęčň¨ňçé ďçîňďęčň¨ňęę ďçîňďęčň¨ňďďě

Page 686: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 15

On each of your routers, you have verified that LDP has allocated a label for each prefix in its IP routing table.

Đۨďý­¸±© ·° ®±«¬»

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óîô ·ż ó ×Íó×Í ·˛¬»® ż®»ż

ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»ô ± ó ŃÜÎ

Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďçîňďęčň¨ňđńîě ·­ Şż®·»˛żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­

Ü ďçîňďęčň¨ňçéńíî ĹçđńîčđçčëęĂ Ş·ż ďçîňďęčň¨ňëđô đđćěçćëđô Í»®·ż´đńđňďďď

Ü ďçîňďęčň¨ňďďîńîč

ĹçđńîęčďčëęĂ Ş·ż ďçîňďęčň¨ňëđô đđćěçćëđô Í»®·ż´đńđňďďď

Ü ďçîňďęčň¨ňęěńîč ĹçđńíďçíčëęĂ Ş·ż ďçîňďęčň¨ňëđô đđćěçćëđô Í»®·ż´đńđňďďď

Ü ďçîňďęčň¨ňčďńíî ĹçđńęëççęčĂ Ş·ż ďçîňďęčň¨ňëđô đđćěçćëđô Í»®·ż´đńđňďďď

Ü ďçîňďęčň¨ňííńíî ĹçđńííîďčëęĂ Ş·ż ďçîňďęčňďňëđô đđćěéćđđô Í»®·ż´đńđňďďď

Ý ďçîňďęčň¨ňěčńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďď

Ý ďçîňďęčň¨ňďéńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

ďëđň¨ňđňđ ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­

Ü ďëđň¨ň¨îňíî ĹçđńíéđëčëęĂ Ş·ż ďçîňďęčňíňëđô đđćëđćđęô Í»®·ż´đńđňďďď

Ý ďëđň¨ň¨ďňďę ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđď

Ü ďëđň¨ň¨îňďę ĹçđńíéđëčëęĂ Ş·ż ďçîňďęčňíňëđô đđćëđćđęô Í»®·ż´đńđňďďď

Ý ďëđň¨ň¨ďňíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđî

On each of your routers, you have verified the LDP bindings for all prefixes of the other core routers.

Шďý­¸±© ł°´­ ´Ľ° ľ·˛Ľ·˛ą­

¬·ľ »˛¬®§ć ďëđň¨ň¨ďňďęńîčô ®»Ş ďđ

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć ďé

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć îî

¬·ľ »˛¬®§ć ďëđň¨ň¨ďňíîńîčô ®»Ş ďî

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć ďč

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć îí

¬·ľ »˛¬®§ć ďëđň¨ň¨îňďęńîčô ®»Ş îď

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć îî

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć ďé

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć ďé

¬·ľ »˛¬®§ć ďëđň¨ň¨îňíîńîčô ®»Ş îî

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć îí

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć ďę

Page 687: Implementing cisco mpls

16 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć ďč

¬·ľ »˛¬®§ć ďçîňďęčň¨ňďéńíîô ®»Ş č

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć ďę

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć îď

¬·ľ »˛¬®§ć ďçîňďęčň¨ňííńíîô ®»Ş îđ

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć îď

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć îî

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć ďę

¬·ľ »˛¬®§ć ďçîňďęčň¨ňěčńîčô ®»Ş ę

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć ďç

¬·ľ »˛¬®§ć ďçîňďęčň¨ňęěńîčô ®»Ş ďč

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć ďç

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć îđ

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć ·ł°ó˛«´´

¬·ľ »˛¬®§ć ďçîňďęčň¨ňčďńíîô ®»Ş ë

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć îď

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć îđ

¬·ľ »˛¬®§ć ďçîňďęčň¨ňçéńíîô ®»Ş ďç

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć îđ

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć ďč

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć ·ł°ó˛«´´

¬·ľ »˛¬®§ć ďçîňďęčň¨ňďďîńîčô ®»Ş ě

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć ďç

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć ·ł°ó˛«´´

On your PE router, you have determined TTL propagation status by performing a traceroute to the loopback address of the PE router of the other POP.

Đۨîý¬®ż˝»®±«¬» ďçîňďęčň¨ňďé

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďçîňďęčň¨ňďé

ď ďçîňďęčň¨ňěç ěđ ł­»˝ ěđ ł­»˝ ö

Đۨîý

Page 688: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 17

Task 2: Experiment with TTL Propagation In this task, you will enable MPLS TTL propagation and verify the results. Workgroup x1 on POP x1 will configure PEx1 and Px1. Workgroup x2 on POP x2 will configure PEx2 and Px2..

Activity Procedure

Complete these steps:

Step 1 On your assigned PE router, enable MPLS TTL propagation.

Step 2 On your assigned P router, enable MPLS TTL propagation.

Step 3 Verify that the other POP has completed its configuration.

Step 4 Verify that the MPLS TTL propagation is working.

Step 5 On your assigned PE router, disable MPLS TTL propagation.

Step 6 On your assigned P router, disable MPLS TTL propagation.

Activity Verification

You have completed this task when you attain these results while MPLS TTL propagation is enabled:

You have performed a traceroute from your PE router to the loopback address of the PE router of the other POP and verified that the results display the associated labels.

Đۨďý¬®ż˝» ďçîňďęčň¨ňíí

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďçîňďęčň¨ňíí

ď ďçîňďęčň¨ňëđ ĹÓĐÔÍć Ôżľ»´ ďč ۨ° đĂ ďçę ł­»˝ ďçę ł­»˝ îđě ł­»˝

î ďçîňďęčň¨ňďďě ĹÓĐÔÍć Ôżľ»´ ďé ۨ° đĂ ďđđ ł­»˝ ďđě ł­»˝ ďđđ ł­»˝

í ďçîňďęčň¨ňęë ěě ł­»˝ ö ěđ ł­»˝

Đۨîý¬®ż˝»®±«¬» ďçîňďęčň¨ňďé

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďçîňďęčň¨ňďé

ď ďçîňďęčň¨ňęę ĹÓĐÔÍć Ôżľ»´ îď ۨ° đĂ ďčě ł­»˝ îđđ ł­»˝ îđđ ł­»˝

î ďçîňďęčň¨ňďďí ĹÓĐÔÍć Ôżľ»´ ďę ۨ° đĂ ďđđ ł­»˝ ďđđ ł­»˝ ďđě ł­»˝

í ďçîňďęčň¨ňěç ěđ ł­»˝ ěđ ł­»˝ ö

Note When you are troubleshooting, it may become necessary to view the core routes when

doing traces. If so, it will be necessary to enable TTL propagation.

For this course, enabling TTL propagation will affect the results of some of the traces shown

in the lab activity verification because additional hops and labels will be displayed.

Page 689: Implementing cisco mpls

18 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Task 3: Configure Conditional Label Distribution For the label binding displays that you did in Task 1, you can see that a label is assigned to every prefix that is in the IP routing table of a router. This label assignment results in wasting label space and resources to build unused LSPs. In this task, you will use conditional label advertising to restrict the distribution of labels related to the WAN interfaces in the core.

Workgroup x1 on POP x1 will configure PEx1 and Px1. Workgroup x2 on POP x2 will configure PEx2 and Px2.

Activity Procedure

Complete these steps:

Step 1 On your PE router, display the LSPs that are being built.

Đۨďý­¸±© ł°´­ ş±®©ż®Ľ·˛ąó¬żľ´»

Ô±˝ż´ Ń«¬ą±·˛ą Đ®»ş·¨ ާ¬»­ ¬żą Ń«¬ą±·˛ą Ň»¨¬ ر°

¬żą ¬żą ±® ĘÝ ±® Ě«˛˛»´ ׼ ­©·¬˝¸»Ľ ·˛¬»®şż˝»

ďę îí ďëđň¨ň¨îňíîńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

ďé îî ďëđň¨ň¨îňďęńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

ďč îđ ďçîňďęčň¨ňçéńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

ďç б° ¬żą ďçîňďęčň¨ňďďîńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

îđ ďç ďçîňďęčň¨ňęěńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

îď б° ¬żą ďçîňďęčň¨ňčďńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

îî îď ďçîňďęčň¨ňííńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

Step 2 Note that an LSP has been built to the WAN interfaces that connect the PE and P routers. This LSP will never be used because traffic will not normally terminate at this point.

Step 3 On your assigned P and PE routers, configure conditional label distribution to allow only the distribution of labels related to the core loopback addresses and the interfaces that provide direct customer support.

Step 4 Verify that the other POP has completed its configuration tasks.

Activity Verification

You have completed this task when you attain these results:

On your PE router, you have confirmed that LSPs are not being built for the links between the PE and P routers.

Đۨďý­¸±© ł°´­ ş±®©ż®Ľ·˛ąó¬żľ´»

Ô±˝ż´ Ń«¬ą±·˛ą Đ®»ş·¨ ާ¬»­ ¬żą Ń«¬ą±·˛ą Ň»¨¬ ر°

¬żą ¬żą ±® ĘÝ ±® Ě«˛˛»´ ׼ ­©·¬˝¸»Ľ ·˛¬»®şż˝»

ďę îí ďëđň¨ň¨îňíîńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

ďé îî ďëđň¨ň¨îňďęńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

ďč îđ ďçîňďęčň¨ňçéńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

ďç ˲¬żąą»Ľ ďçîňďęčň¨ňďďîńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

îđ ˲¬żąą»Ľ ďçîňďęčň¨ňęěńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

îď б° ¬żą ďçîňďęčň¨ňčďńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

îî îď ďçîňďęčň¨ňííńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

Page 690: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 19

Note An LSP is no longer built to the WAN interface that connects the other PE and P routers.

On your P router, you have verified the LDP bindings.

Шďý­¸±© ł°´­ ´Ľ° ľ·˛Ľ·˛ą­

¬·ľ »˛¬®§ć ďëđň¨ň¨ďňďęńîčô ®»Ş íě

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć ďé

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć îî

¬·ľ »˛¬®§ć ďëđň¨ň¨ďňíîńîčô ®»Ş íë

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć ďč

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć îí

¬·ľ »˛¬®§ć ďëđň¨ň¨îňďęńîčô ®»Ş íę

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć îî

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć ďé

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć ďé

¬·ľ »˛¬®§ć ďëđň¨ň¨îňíîńîčô ®»Ş íé

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć îí

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć ďę

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć ďč

¬·ľ »˛¬®§ć ďçîňďęčň¨ňďéńíîô ®»Ş íč

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć ďę

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć îď

¬·ľ »˛¬®§ć ďçîňďęčň¨ňííńíîô ®»Ş íç

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć îď

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć îî

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć ďę

¬·ľ »˛¬®§ć ďçîňďęčň¨ňěčńîčô ®»Ş îç

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć ·ł°ó˛«´´

¬·ľ »˛¬®§ć ďçîňďęčň¨ňęěńîčô ®»Ş íđ

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć ďç

¬·ľ »˛¬®§ć ďçîňďęčň¨ňčďńíîô ®»Ş ěđ

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć ·ł°ó˛«´´

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć îď

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć îđ

¬·ľ »˛¬®§ć ďçîňďęčň¨ňçéńíîô ®»Ş ěď

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć îđ

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňďéćđô ¬żąć ďč

®»ł±¬» ľ·˛Ľ·˛ąć ¬­®ć ďçîňďęčň¨ňçéćđô ¬żąć ·ł°ó˛«´´

¬·ľ »˛¬®§ć ďçîňďęčň¨ňďďîńîčô ®»Ş íí

´±˝ż´ ľ·˛Ľ·˛ąć ¬żąć ·ł°ó˛«´´

Шďý

Page 691: Implementing cisco mpls

20 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Note The prefixes assigned to the WAN interfaces connecting the other P and PE routers no

longer have a remote label assigned. Further, none of the core WAN interfaces have remote

labels assigned. This lessening of assignments results in a reduced label space, which

saves memory resources.

Task 4: Remove Conditional Label Distribution For the conditional label distribution displays that you did in Task 3, you can see that a label is not assigned to every prefix that is in the IP routing table of a router. In this task, you will remove conditional label advertising so that there are no restrictions on the distribution of labels related to the WAN interfaces in the core.

Note For this simple lab environment, there are no memory constraints that would lead you to

implement conditional label distribution.

Workgroup x1 on POP x1 will configure PEx1 and Px1. Workgroup x2 on POP x2 will configure PEx2 and Px2

Activity Procedure

Complete these steps:

Step 1 Remove conditional label distribution and the access list that supported it.

Step 2 Verify that the other POP has completed its configuration task.

Activity Verification

You have completed this task when you attain these results:

On your PE router, you have confirmed that all the LSPs that are being built.

Đۨďý­¸±© ł°´­ ş±®©ż®Ľ·˛ąó¬żľ´»

Ô±˝ż´ Ń«¬ą±·˛ą Đ®»ş·¨ ާ¬»­ ¬żą Ń«¬ą±·˛ą Ň»¨¬ ر°

¬żą ¬żą ±® ĘÝ ±® Ě«˛˛»´ ׼ ­©·¬˝¸»Ľ ·˛¬»®şż˝»

ďę ďę ďçîňďęčň¨ňçéńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

ďé б° ¬żą ďçîňďęčň¨ňďďîńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

ďč ďé ďçîňďęčň¨ňęěńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

ďç б° ¬żą ďçîňďęčň¨ňčďńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

îđ ďč ďçîňďęčň¨ňííńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

îď îď ďëđň¨ň¨îňíîńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

îî îí ďëđň¨ň¨îňďęńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

Page 692: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 21

Đۨîý­¸±© ł°´­ ş±®©ż®Ľ·˛ąó¬żľ´»

Ô±˝ż´ Ń«¬ą±·˛ą Đ®»ş·¨ ާ¬»­ ¬żą Ń«¬ą±·˛ą Ň»¨¬ ر°

¬żą ¬żą ±® ĘÝ ±® Ě«˛˛»´ ׼ ­©·¬˝¸»Ľ ·˛¬»®şż˝»

ďę б° ¬żą ďçîňďęčňëňçéńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

ďé б° ¬żą ďçîňďęčňëňďďîńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

ďč ďę ďçîňďęčňëňčďńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

ďç ďč ďçîňďęčňëňěčńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

îđ ďç ďçîňďęčňëňďéńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

îď îđ ďëđňëň¨ďňíîńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

îî îî ďëđňëň¨ďňďęńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

Page 693: Implementing cisco mpls

22 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 5-1: Configuring Initial MPLS VPN Setup Complete this lab activity to practice what you learned in the related module.

Activity Objective The company that you work for is a small service provider. Your SP has been given the task of creating two simple VPNs to support two new customers (customer A and customer B) that have just signed with you.

In this activity, you will create a simple VPN for your customer. After completing this activity, you will be able to meet these objectives:

Configure MP-BGP to establish routing between the PE routers of your POP

Configure the VRF tables necessary to support your customer and establish your customer RIP routing using a simple VPN

Visual Objective The figure illustrates what you will accomplish in this activity.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—5

Two Simple VPNs with a BGP Core

These activities rely on Lab 3-1, “Establishing the Core MPLS Environment”, in which you established MPLS connectivity in your backbone.

Please verify that MPLS has been enabled on all core interfaces in your backbone and that it has not been enabled on interfaces toward the customer POP routers or other SPs.

Page 694: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 23

For your reference, the figure shows the addresses in use in the network.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—6

MPLS Lab IP Addressing Scheme

This activity contains tasks that enable you to configure your core MPLS VPN infrastructure and to establish a simple any-to-any VPN service for a customer.

You will also test various PE-CE routing options, ranging from RIP and OSPF to running BGP between the PE and the CE routers.

Required Resources This is the resource that is required to complete this activity:

Cisco IOS documentation

Command List The table describes the commands that are used in this activity.

VPN-Related Commands

Command Description

żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ş®şó˛żł»

Selects a per-VRF instance of a routing protocol.

żĽĽ®»­­óşżł·´§ Ş°˛Şě Selects VPNv4 address family configuration.

·° Ş®ş ş±®©ż®Ľ·˛ą Ş®şó˛żł»

Assigns an interface to a VRF.

·° Ş®ş Ş®şó˛żł» Creates a VRF table.

Page 695: Implementing cisco mpls

24 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Command Description

˛»·ą¸ľ±® ·°óżĽĽ®»­­ ż˝¬·Şż¬»

Activates an exchange of routes from address family under the configuration for the specified neighbor.

˛»·ą¸ľ±® ·°óżĽĽ®»­­ ®±«¬»ó®»ş´»˝¬±®ó˝´·»˛¬

Configures a route reflector client on a route reflector.

˛»·ą¸ľ±® ˛»¨¬ó¸±°ó­»´ş To configure the router as the next hop for a BGP-speaking neighbor or peer group, use the neighbor next-hop-self router configuration command. To disable this feature, use the no form of this command.

˛»·ą¸ľ±® ®»ł±¬»óż­ To add an entry to the BGP or MP-BGP neighbor table, use the neighbor remote-as router configuration command. To remove an entry from the table, use the no form of this command.

˛»·ą¸ľ±® ­»˛Ľó˝±łł«˛·¬§ To specify that a community attribute should be sent to a BGP neighbor, use the neighbor send-communitycommand in address family or router configuration mode. To remove the entry, use the no form of this command.

˛»·ą¸ľ±® «°Ľż¬»ó­±«®˝» To have Cisco IOS software allow IBGP sessions to use any operational interface for TCP connections, use the neighbor update-source router configuration command. To restore the interface assignment to the closest interface, which is called the “best local address,” use the no form of this command.

°·˛ą Ş®ş Ş®şó˛żł» ¸±­¬ Pings a host reachable through the specified VRF.

®Ľ Şż´«» Assigns an RD to a VRF.

®»Ľ·­¬®·ľ«¬» ľą° ż­ó˛«łľ»® ł»¬®·˝ ¬®ż˛­°ż®»˛¬

Redistributes BGP routes into RIP with propagation of the MED into the RIP hop count.

®±«¬»® ľą° ż­ó˛«łľ»® Selects BGP configuration.

®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ¤ »¨°±®¬ Şż´«»

Assigns an RT to a VRF.

­¸±© ·° ľą° ˛»·ą¸ľ±® Displays information on global BGP neighbors.

­¸±© ·° ľą° Ş°˛Şě Ş®ş Ş®şó˛żł»

Displays VPNv4 routes associated with the specified VRF.

­¸±© ·° ®±«¬» Ş®ş Ş®şó˛żł»

Displays an IP routing table of the specified VRF.

­¸±© ·° Ş®ş Ľ»¬ż·´ Displays detailed VRF information.

­¸±© ł°´­ ş±®©ż®Ľ·˛ą Ş®ş Ş®şó˛żł»

Displays the MPLS forwarding table for a specific VRF

Task 1: Configure MP-BGP In this task, you will configure MP-BGP between the PE routers in your POP.

Workgroup x1 on POP x1 will configure MP-BGP on PEx1, and workgroup x2 on POP x2 will perform the same task on PEx2.

Page 696: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 25

Activity Procedure

Complete these steps:

Step 1 Activate the BGP process on your assigned router using AS 65001 as the AS number. Disable the autosummarization feature.

Step 2 Activate VPNv4 BGP sessions between your assigned PE router and the PE router being configured by the other POP. Disable the autosummarization feature.

Step 3 Verify that the other POP has completed its configuration tasks.

Activity Verification

You have completed this task when you attain these results:

You have displayed the BGP neighbor information and ensured that BGP sessions have been established between the two PE routers.

Đۨîý­¸±© ·° ľą° ­«łłż®§

ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďçîňďęčň¨ňííô ´±˝ż´ ßÍ ˛«łľ»® ęëđđď

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ď

Ň»·ą¸ľ±® Ę ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ Ěľ´Ę»® ×˛Ď Ń«¬Ď Ë°ńܱ©˛ ͬż¬»ńĐş¨Î˝Ľ

ďçîňďęčň¨ňďé ě ęëđđď ç ç ď đ đ đđćđëćîě đ

Đۨďý­¸±© ·° ľą° ­«łłż®§

ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďçîňďęčň¨ňďéô ´±˝ż´ ßÍ ˛«łľ»® ęëđđď

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ď

Ň»·ą¸ľ±® Ę ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ Ěľ´Ę»® ×˛Ď Ń«¬Ď Ë°ńܱ©˛ ͬż¬»ńĐş¨Î˝Ľ

ďçîňďęčň¨ňíí ě ęëđđď ę ę ď đ đ đđćđîćîí đ

Đۨďý­¸±© ľą° ˛»·ą¸ľ±®­

ŢŮĐ ˛»·ą¸ľ±® ·­ ďçîňďęčň¨ňííô ®»ł±¬» ßÍ ęëđđďô ·˛¬»®˛ż´ ´·˛µ

ŢŮĐ Ş»®­·±˛ ěô ®»ł±¬» ®±«¬»® ×Ü ďçîňďęčň¨ňíí

ŢŮĐ ­¬ż¬» ă Ű­¬żľ´·­¸»Ľô «° ş±® đđćđíćíç

Ôż­¬ ®»żĽ đđćđđćíçô ¸±´Ľ ¬·ł» ·­ ďčđô µ»»°ż´·Ş» ·˛¬»®Şż´ ·­ ęđ ­»˝±˛Ľ­

Ň»·ą¸ľ±® ˝ż°żľ·´·¬·»­ć

᫬» ®»ş®»­¸ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľř±´Ľ ú ˛»©÷

߼Ľ®»­­ şżł·´§ ×ĐŞě ˲·˝ż­¬ć żĽŞ»®¬·­»Ľ ż˛Ľ ®»˝»·Ş»Ľ

×ĐŞě ÓĐÔÍ Ôżľ»´ ˝ż°żľ·´·¬§ć

λ˝»·Ş»Ľ é ł»­­żą»­ô 𠲱¬·ş·˝ż¬·±˛­ô đ ·˛ Ż«»«»

Í»˛¬ é ł»­­żą»­ô 𠲱¬·ş·˝ż¬·±˛­ô đ ·˛ Ż«»«»

Ü»şż«´¬ ł·˛·ł«ł ¬·ł» ľ»¬©»»˛ żĽŞ»®¬·­»ł»˛¬ ®«˛­ ·­ ë ­»˝±˛Ľ­

Ú±® żĽĽ®»­­ şżł·´§ć ×ĐŞě ˲·˝ż­¬

ŢŮĐ ¬żľ´» Ş»®­·±˛ ďô ˛»·ą¸ľ±® Ş»®­·±˛ ď

ײĽ»¨ ďô Ńşş­»¬ đô Óż­µ đ¨î

᫬» ®»ş®»­¸ ®»Ż«»­¬ć ®»˝»·Ş»Ľ đô ­»˛¬ đ

đ ż˝˝»°¬»Ľ °®»ş·¨»­ ˝±˛­«ł» 𠾧¬»­

Đ®»ş·¨ żĽŞ»®¬·­»Ľ đô ­«°°®»­­»Ľ đô ©·¬¸Ľ®ż©˛ đ

Page 697: Implementing cisco mpls

26 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

ݱ˛˛»˝¬·±˛­ »­¬żľ´·­¸»Ľ ďĺ Ľ®±°°»Ľ đ

Ôż­¬ ®»­»¬ ˛»Ş»®

ݱ˛˛»˝¬·±˛ ­¬ż¬» ·­ ŰÍĚßŢô ×ńŃ ­¬ż¬«­ć ďô «˛®»żĽ ·˛°«¬ ľ§¬»­ć đ

Ô±˝ż´ ¸±­¬ć ďçîňďęčň¨ňďéô Ô±˝ż´ °±®¬ć ďďđîî

Ú±®»·ą˛ ¸±­¬ć ďçîňďęčň¨ňííô Ú±®»·ą˛ °±®¬ć ďéç

۲Ż«»«»Ľ °ż˝µ»¬­ ş±® ®»¬®ż˛­ł·¬ć đô ·˛°«¬ć đ ł·­ó±®Ľ»®»Ľć đ ř𠾧¬»­÷

ŰŞ»˛¬ Ě·ł»®­ ř˝«®®»˛¬ ¬·ł» ·­ đ¨ßďîŰéčě÷ć

Ě·ł»® ͬż®¬­ Éżµ»«°­ Ň»¨¬

묮ż˛­ č đ đ¨đ

Ě·ł»Éż·¬ đ đ đ¨đ

ß˝µŘ±´Ľ é ë đ¨đ

Í»˛ĽÉ˛Ľ đ đ đ¨đ

Ő»»°ß´·Ş» đ đ đ¨đ

Ů·Ş»Ë° đ đ đ¨đ

Đł¬«ßą»® đ đ đ¨đ

Ü»żĽÉż·¬ đ đ đ¨đ

·­­ć ďëçęďđęđîë ­˛Ľ«˛żć ďëçęďđęďčë ­˛Ľ˛¨¬ć ďëçęďđęďčë ­˛Ľ©˛Ľć ďęîîë

·®­ć îďíěěëíďéî ®˝Ş˛¨¬ć îďíěěëíííî ®˝Ş©˛Ľć ďęîîë Ľ»´®˝Ş©˛Ľć ďëç

ÍÎĚĚć ďçé ł­ô ÎĚĚŃć çčě ł­ô ÎĚĘć éčé ł­ô ŐÎĚĚć đ ł­

ł·˛ÎĚĚć ěě ł­ô łż¨ÎĚĚć íđđ ł­ô ßÝŐ ¸±´Ľć îđđ ł­

Ú´żą­ć ¸·ą¸»® °®»˝»Ľ»˛˝»ô ˛żą´»

Üż¬żą®żł­ řłż¨ Ľż¬ż ­»ął»˛¬ ·­ ëíę ľ§¬»­÷ć

Î˝ŞĽć č ř±«¬ ±ş ±®Ľ»®ć đ÷ô ©·¬¸ Ľż¬żć éô ¬±¬ż´ Ľż¬ż ľ§¬»­ć ďëç

Í»˛¬ć ďě ř®»¬®ż˛­ł·¬ć đô şż­¬®»¬®ż˛­ł·¬ć đ÷ô ©·¬¸ Ľż¬żć éô ¬±¬ż´ Ľż¬ż ľ§¬»­ć ďëç

Task 2: Configure VRF Tables In this task and the following task, you will establish simple VPNs for customer A and customer B. Workgroup x1 will establish a VPN between CEx1A and CEx2A, and workgroup x2 will establish a VPN between CEx1B and CEx2B. Each POP is responsible for all PE router configurations related to its customer. This division of work between POPs applies to all future exercises.

Activity Procedure

Complete these steps:

Step 1 Design your VPN networks—decide on the RD and the RT numbering. Coordinate your number with the other POP.

Note The easiest numbering plan would be to use the same values for the RD and the RT. Use

simple values—for example, x:10 for customer A and x:20 for customer B.

Page 698: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 27

Step 2 Create VRFs on the PE routers and associate the PE-CE interfaces into the proper VRFs; use simple yet descriptive VRF names (for example, CustA and CustB).

Step 3 Your customer is using RIP as its IGP, so enable RIP for the VRF that you have created.

Step 4 Configure redistribution of RIP into BGP from the address-family ipv4 vrfvrf-name command mode.

Step 5 Configure redistribution of BGP into RIP from the address-family ipv4 vrfvrf-name command mode.

Step 6 Configure RIP metric propagation through MP-BGP by using the redistribute bgp as-number metric transparent command in the RIP process.

Step 7 Ensure that RIP is enabled on all of the CE routers. Make sure that all of the networks (including loopbacks) are active in the RIP process.

Activity Verification

You have completed this task when you attain these results:

On a CE router, using the show ip route command, you have verified that the router is receiving all VPN routes. Also, you have verified that no routes from the other customer or the MPLS core are being received. On CEx1A, the printout should be similar to this example:

Ýۨďßý­¸±© ·° ®±«¬»

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô × ó ×ŮÎĐô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» îô Ű ó ŰŮĐ

· ó ×Íó×Íô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óîô ·ż ó ×Íó×Í ·˛¬»® ż®»ż

ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»ô ± ó ŃÜÎ

Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­

Î ďđňďň¨îňěçńíî ĹďîđńîĂ Ş·ż ďëđň¨ň¨ďňďčô đđćđđćďěô Í»®·ż´đńđňďđď

Ý ďđňďň¨ďňěçńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

Î ďđňďň¨îňďęńîč ĹďîđńîĂ Ş·ż ďëđň¨ň¨ďňďčô đđćđđćďěô Í»®·ż´đńđňďđď

Ý ďđňďň¨ďňďęńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô ۬¸»®˛»¬đńđ

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­

Î ďëđň¨ň¨îňďę ĹďîđńďĂ Ş·ż ďëđň¨ň¨ďňďčô đđćđđćďěô Í»®·ż´đńđňďđď

Ý ďëđň¨ň¨ďňďę ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđď

Page 699: Implementing cisco mpls

28 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

You have used ping and trace on the CE routers to verify connectivity across the VPN.

Ýۨďßý¬®ż˝»®±«¬» ďëđň¨ň¨îňďé

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďëđň¨ň¨îňďé

ď ďëđň¨ň¨ďňďč ďî ł­»˝ ďî ł­»˝ ďî ł­»˝

î ďëđň¨ň¨îňďč ęđ ł­»˝ ęđ ł­»˝ ęđ ł­»˝

í ďëđň¨ň¨îňďé éé ł­»˝ éî ł­»˝ ö

Ýۨďßý°·˛ą ďëđň¨ň¨îňďé

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďëđň¨ň¨îňďéô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďěčńďěčńďěç ł­

You have verified that you have the proper configuration of your VRF tables with the showip vrf detail command. Your printout should be similar to this example:

Đۨďý­¸±© ·° Ş®ş Ľ»¬ż·´

ĘÎÚ Ý«­¬ßĺ Ľ»şż«´¬ ÎÜ ¨ćďđĺ Ľ»şż«´¬ ĘĐŇ×Ü ä˛±¬ ­»¬â

ײ¬»®şż˝»­ć

Í»đńđňďđď

ݱ˛˛»˝¬»Ľ żĽĽ®»­­»­ ż®» ˛±¬ ·˛ ą´±ľż´ ®±«¬·˛ą ¬żľ´»

ۨ°±®¬ ĘĐŇ ®±«¬»ó¬ż®ą»¬ ˝±łł«˛·¬·»­

ÎĚć¨ćďđ

׳°±®¬ ĘĐŇ ®±«¬»ó¬ż®ą»¬ ˝±łł«˛·¬·»­

ÎĚć¨ćďđ

ұ ·ł°±®¬ ®±«¬»ółż°

ұ »¨°±®¬ ®±«¬»ółż°

ĘÎÚ Ý«­¬Ţĺ Ľ»şż«´¬ ÎÜ ¨ćîđĺ Ľ»şż«´¬ ĘĐŇ×Ü ä˛±¬ ­»¬â

ײ¬»®şż˝»­ć

Í»đńđňďđî

ݱ˛˛»˝¬»Ľ żĽĽ®»­­»­ ż®» ˛±¬ ·˛ ą´±ľż´ ®±«¬·˛ą ¬żľ´»

ۨ°±®¬ ĘĐŇ ®±«¬»ó¬ż®ą»¬ ˝±łł«˛·¬·»­

ÎĚć¨ćîđ

׳°±®¬ ĘĐŇ ®±«¬»ó¬ż®ą»¬ ˝±łł«˛·¬·»­

ÎĚć¨ćîđ

ұ ·ł°±®¬ ®±«¬»ółż°

ұ »¨°±®¬ ®±«¬»ółż°

Page 700: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 29

Đۨîý­¸ ·° Ş®ş Ľ»¬

ĘÎÚ Ý«­¬ßĺ Ľ»şż«´¬ ÎÜ ëćďđĺ Ľ»şż«´¬ ĘĐŇ×Ü ä˛±¬ ­»¬â

ײ¬»®şż˝»­ć

Í»đńđňďđď

ݱ˛˛»˝¬»Ľ żĽĽ®»­­»­ ż®» ˛±¬ ·˛ ą´±ľż´ ®±«¬·˛ą ¬żľ´»

ۨ°±®¬ ĘĐŇ ®±«¬»ó¬ż®ą»¬ ˝±łł«˛·¬·»­

ÎĚć¨ćďđ

׳°±®¬ ĘĐŇ ®±«¬»ó¬ż®ą»¬ ˝±łł«˛·¬·»­

ÎĚć¨ďđ

ұ ·ł°±®¬ ®±«¬»ółż°

ұ »¨°±®¬ ®±«¬»ółż°

ĘÎÚ ´żľ»´ Ľ·­¬®·ľ«¬·±˛ °®±¬±˝±´ć ˛±¬ ˝±˛ş·ą«®»Ľ

ĘÎÚ Ý«­¬Ţĺ Ľ»şż«´¬ ÎÜ ¨ćîđĺ Ľ»şż«´¬ ĘĐŇ×Ü ä˛±¬ ­»¬â

ײ¬»®şż˝»­ć

Í»đńđňďđî

ݱ˛˛»˝¬»Ľ żĽĽ®»­­»­ ż®» ˛±¬ ·˛ ą´±ľż´ ®±«¬·˛ą ¬żľ´»

ۨ°±®¬ ĘĐŇ ®±«¬»ó¬ż®ą»¬ ˝±łł«˛·¬·»­

ÎĚć¨ćîđ

׳°±®¬ ĘĐŇ ®±«¬»ó¬ż®ą»¬ ˝±łł«˛·¬·»­

ÎĚć¨ćîđ

ұ ·ł°±®¬ ®±«¬»ółż°

ұ »¨°±®¬ ®±«¬»ółż°

ĘÎÚ ´żľ»´ Ľ·­¬®·ľ«¬·±˛ °®±¬±˝±´ć ˛±¬ ˝±˛ş·ą«®»Ľ

You have checked the routing protocols running in your VRF with the show ip protocols vrf command. When executed on PEx1, your printout should be similar to this example:

Đۨďý­¸±© ·° °®±¬±˝±´­ Ş®ş Ý«­¬ß

᫬·˛ą Đ®±¬±˝±´ ·­ ţľą° ęëđđďţ

Ń«¬ą±·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬

ײ˝±ł·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬

×ŮĐ ­§˛˝¸®±˛·¦ż¬·±˛ ·­ Ľ·­żľ´»Ľ

ß«¬±łż¬·˝ ®±«¬» ­«łłż®·¦ż¬·±˛ ·­ Ľ·­żľ´»Ľ

λĽ·­¬®·ľ«¬·˛ąć ®·°

Óż¨·ł«ł °ż¬¸ć ď

᫬·˛ą ײş±®łż¬·±˛ ͱ«®˝»­ć

Ůż¬»©ż§ Ü·­¬ż˛˝» Ôż­¬ Ë°Ľż¬»

ďçîňďęčň¨ňíí îđđ ďëćđëćđę

Ü·­¬ż˛˝»ć »¨¬»®˛ż´ îđ ·˛¬»®˛ż´ îđđ ´±˝ż´ îđđ

᫬·˛ą Đ®±¬±˝±´ ·­ ţ®·°ţ

Í»˛Ľ·˛ą «°Ľż¬»­ »Ş»®§ íđ ­»˝±˛Ľ­ô ˛»¨¬ Ľ«» ·˛ îę ­»˝±˛Ľ­

×˛Şż´·Ľ żş¬»® ďčđ ­»˝±˛Ľ­ô ¸±´Ľ Ľ±©˛ ďčđô ş´«­¸»Ľ żş¬»® îěđ

Ń«¬ą±·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬

ײ˝±ł·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬

λĽ·­¬®·ľ«¬·˛ąć ľą° ęëđđďô ®·°

Ü»şż«´¬ Ş»®­·±˛ ˝±˛¬®±´ć ­»˛Ľ Ş»®­·±˛ îô ®»˝»·Ş» Ş»®­·±˛ î

Page 701: Implementing cisco mpls

30 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

ײ¬»®şż˝» Í»˛Ľ λ˝Ş Ě®·ąą»®»Ľ Î×Đ Ő»§ó˝¸ż·˛

Í»®·ż´đńđňďđď î î

Óż¨·ł«ł °ż¬¸ć ě

᫬·˛ą ş±® Ň»¬©±®µ­ć

ײ¬»®şż˝» Í»˛Ľ λ˝Ş Ě®·ąą»®»Ľ Î×Đ Ő»§ó˝¸ż·˛

ďëđň¨ňđňđ

᫬·˛ą ײş±®łż¬·±˛ ͱ«®˝»­ć

Ůż¬»©ż§ Ü·­¬ż˛˝» Ôż­¬ Ë°Ľż¬»

ďëđň¨ň¨ďňďé ďîđ đđćđđćîé

Ü·­¬ż˛˝»ć řĽ»şż«´¬ ·­ ďîđ÷

Đۨďý­¸±© ·° °®±¬±˝±´­ Ş®ş Ý«­¬Ţ

᫬·˛ą Đ®±¬±˝±´ ·­ ţľą° ęëđđďţ

Ń«¬ą±·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬

ײ˝±ł·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬

×ŮĐ ­§˛˝¸®±˛·¦ż¬·±˛ ·­ Ľ·­żľ´»Ľ

ß«¬±łż¬·˝ ®±«¬» ­«łłż®·¦ż¬·±˛ ·­ Ľ·­żľ´»Ľ

λĽ·­¬®·ľ«¬·˛ąć ®·°

Óż¨·ł«ł °ż¬¸ć ď

᫬·˛ą ײş±®łż¬·±˛ ͱ«®˝»­ć

Ůż¬»©ż§ Ü·­¬ż˛˝» Ôż­¬ Ë°Ľż¬»

ďçîňďęčň¨ňíí îđđ ďëćđěćîé

Ü·­¬ż˛˝»ć »¨¬»®˛ż´ îđ ·˛¬»®˛ż´ îđđ ´±˝ż´ îđđ

᫬·˛ą Đ®±¬±˝±´ ·­ ţ®·°ţ

Í»˛Ľ·˛ą «°Ľż¬»­ »Ş»®§ íđ ­»˝±˛Ľ­ô ˛»¨¬ Ľ«» ·˛ îđ ­»˝±˛Ľ­

×˛Şż´·Ľ żş¬»® ďčđ ­»˝±˛Ľ­ô ¸±´Ľ Ľ±©˛ ďčđô ş´«­¸»Ľ żş¬»® îěđ

Ń«¬ą±·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬

ײ˝±ł·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬

λĽ·­¬®·ľ«¬·˛ąć ľą° ęëđđďô ®·°

Ü»şż«´¬ Ş»®­·±˛ ˝±˛¬®±´ć ­»˛Ľ Ş»®­·±˛ îô ®»˝»·Ş» Ş»®­·±˛ î

ײ¬»®şż˝» Í»˛Ľ λ˝Ş Ě®·ąą»®»Ľ Î×Đ Ő»§ó˝¸ż·˛

Í»®·ż´đńđňďđî î î

Óż¨·ł«ł °ż¬¸ć ě

᫬·˛ą ş±® Ň»¬©±®µ­ć

ײ¬»®şż˝» Í»˛Ľ λ˝Ş Ě®·ąą»®»Ľ Î×Đ Ő»§ó˝¸ż·˛

ďëđň¨ňđňđ

᫬·˛ą ײş±®łż¬·±˛ ͱ«®˝»­ć

Ůż¬»©ż§ Ü·­¬ż˛˝» Ôż­¬ Ë°Ľż¬»

ďëđň¨ň¨ďňíí ďîđ đđćđđćđé

Ü·­¬ż˛˝»ć řĽ»şż«´¬ ·­ ďîđ÷

Page 702: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 31

You have verified the per-VRF routing table on the PE router with the show ip route vrf command. Your printout should be similar to this example:

Đۨďý­¸±© ·° ®±«¬» Ş®ş Ý«­¬ß

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óîô ·ż ó ×Íó×Í ·˛¬»® ż®»ż

ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»ô ± ó ŃÜÎ

Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­

Ţ ďđňďň¨îňěçńíî ĹîđđńďĂ Ş·ż ďçîňďęčň¨ňííô ďëćďđćđě

Î ďđňďň¨ďňěçńíî ĹďîđńďĂ Ş·ż ďëđň¨ň¨ďňďéô đđćđđćîěô Í»®·ż´đńđňďđď

Ţ ďđňďň¨îňďęńîč ĹîđđńďĂ Ş·ż ďçîňďęčň¨ňííô ďëćďđćđě

Î ďđňďň¨ďňďęńîč ĹďîđńďĂ Ş·ż ďëđň¨ň¨ďňďéô đđćđđćîěô Í»®·ż´đńđňďđď

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­

Ţ ďëđň¨ň¨îňďę ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô ďëćěęćđě

Ý ďëđň¨ň¨ďňďę ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđď

Đۨďý­¸±© ·° ®±«¬» Ş®ş Ý«­¬Ţ

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óîô ·ż ó ×Íó×Í ·˛¬»® ż®»ż

ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»ô ± ó ŃÜÎ

Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­

Î ďđňîň¨ďňěçńíî ĹďîđńďĂ Ş·ż ďëđň¨ň¨ďňííô đđćđđćđďô Í»®·ż´đńđňďđî

Ţ ďđňîň¨îňěçńíî ĹîđđńďĂ Ş·ż ďçîňďęčň¨ňííô ďëćđçćîę

Î ďđňîň¨ďňďęńîč ĹďîđńďĂ Ş·ż ďëđň¨ň¨ďňííô đđćđđćđďô Í»®·ż´đńđňďđî

Ţ ďđňîň¨îňďęńîč ĹîđđńďĂ Ş·ż ďçîňďęčň¨ňííô ďëćđçćîę

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­

Ţ ďëđň¨ň¨îňíî ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô ďëćěęćďď

Ý ďëđň¨ň¨ďňíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđî

Page 703: Implementing cisco mpls

32 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

You have used the show ip bgp vpnv4 vrf command to display the BGP routing table associated with a VRF. The printout from the PEx1 router is shown here:

Đۨďý­¸±© ·° ľą° Ş°˛Şě Ş®ş Ý«­¬ß

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ěéô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčň¨ňďé

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · 󷲬»®˛ż´ô

® Î×Ţóşż·´«®»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćďđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬ß÷

öâ ďđňďň¨ďňďęńîč ďëđň¨ň¨ďňďé ď íîéęč á

öâ ďđňďň¨ďňěçńíî ďëđň¨ň¨ďňďé ď íîéęč á

öâ·ďđňďň¨îňďęńîč ďçîňďęčň¨ňíí ď ďđđ đ á

öâ·ďđňďň¨îňěçńíî ďçîňďęčň¨ňíí ď ďđđ đ á

öâ ďëđň¨ň¨ďňďęńîč đňđňđňđ đ íîéęč á

öâ·ďëđň¨ň¨îňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ á

Đۨďý­¸±© ·° ľą° Ş°˛Şě Ş®ş Ý«­¬Ţ

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ěéô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčň¨ňďé

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćîđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬Ţ÷

öâ ďđňîň¨ďňďęńîč ďëđň¨ň¨ďňíí ď íîéęč á

öâ ďđňîň¨ďňěçńíî ďëđň¨ň¨ďňíí ď íîéęč á

öâ·ďđňîň¨îňďęńîč ďçîňďęčň¨ňíí ď ďđđ đ á

öâ·ďđňîň¨îňěçńíî ďçîňďęčň¨ňíí ď ďđđ đ á

öâ ďëđň¨ň¨ďňíîńîč đňđňđňđ đ íîéęč á

öâ·ďëđň¨ň¨îňíîńîč ďçîňďęčň¨ňíí đ ďđđ đ á

Page 704: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 33

You have used the show mpls forwarding vrf vrf-name command on the PE routers to verify the forwarding table for each VRF.

Đۨďý­¸±© ł°´­ ş±®©ż®Ľ·˛ąó¬żľ´» Ş®ş Ý«­¬ß

Ô±˝ż´ Ń«¬ą±·˛ą Đ®»ş·¨ ާ¬»­ ¬żą Ń«¬ą±·˛ą Ň»¨¬ ر°

¬żą ¬żą ±® ĘÝ ±® Ě«˛˛»´ ׼ ­©·¬˝¸»Ľ ·˛¬»®şż˝»

îí ˲¬żąą»Ľ ďđňďň¨ďňďęńîčĹĘĂ đ Í»đńđňďđď °±·˛¬î°±·˛¬

îě ˲¬żąą»Ľ ďđňďň¨ďňěçńíîĹĘĂ ëîđ Í»đńđňďđď °±·˛¬î°±·˛¬

îë ßąą®»ąż¬» ďëđň¨ň¨ďňďęńîčĹĘĂ đ

Đۨďý­¸±© ł°´­ ş±®©ż®Ľ·˛ąó¬żľ´» Ş®ş Ý«­¬Ţ

Ô±˝ż´ Ń«¬ą±·˛ą Đ®»ş·¨ ާ¬»­ ¬żą Ń«¬ą±·˛ą Ň»¨¬ ر°

¬żą ¬żą ±® ĘÝ ±® Ě«˛˛»´ ׼ ­©·¬˝¸»Ľ ·˛¬»®şż˝»

îé ˲¬żąą»Ľ ďđňîň¨ďňďęńîčĹĘĂ đ Í»đńđňďđî °±·˛¬î°±·˛¬

îč ˲¬żąą»Ľ ďđňîň¨ďňěçńíîĹĘĂ đ Í»đńđňďđî °±·˛¬î°±·˛¬

îç ßąą®»ąż¬» ďëđň¨ň¨ďňíîńîčĹĘĂ đ

Đۨďý

You have used the show ip route command on the PE routers to verify that the customer routes are not in the global IP routing table.

Đۨďý­¸±© ·° ®±«¬»

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óîô ·ż ó ×Íó×Í ·˛¬»® ż®»ż

ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»ô ± ó ŃÜÎ

Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďçîňďęčň¨ňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­

Ü ďçîňďęčň¨ňçéńíî ĹçđńîčđçčëęĂ Ş·ż ďçîňďęčň¨ňëđô ďçćďěćëěô Í»®·ż´đńđňďďď

Ü ďçîňďęčň¨ňďďîńîč ĹçđńîęčďčëęĂ Ş·ż ďçîňďęčň¨ňëđô ďçćďěćëěô Í»®·ż´đńđňďďď

Ü ďçîňďęčň¨ňęěńîč ĹçđńíďçíčëęĂ Ş·ż ďçîňďęčň¨ňëđô ďçćďěćëěô Í»®·ż´đńđňďďď

Ü ďçîňďęčň¨ňčďńíî ĹçđńîîçéčëęĂ Ş·ż ďçîňďęčň¨ňëđô ďçćďěćëěô Í»®·ż´đńđňďďď

Ü ďçîňďęčň¨ňííńíî ĹçđńííîďčëęĂ Ş·ż ďçîňďęčň¨ňëđô ďçćďěćëěô Í»®·ż´đńđňďďď

Ý ďçîňďęčň¨ňěčńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďď

Ý ďçîňďęčň¨ňďéńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

Page 705: Implementing cisco mpls

34 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

You have used the ping and trace commands on the PE routers to verify that you cannotreach your customer networks from global address space.

Đۨďý°·˛ą ďëđň¨ň¨ďňďé

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďëđň¨ň¨ďňďéô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

ňňňňň

Í«˝˝»­­ ®ż¬» ·­ đ °»®˝»˛¬ řđńë÷

Đۨďý°·˛ą ďëđň¨ň¨ďňíí

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďëđň¨ň¨ďňííô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

ňňňňň

You have used the ping vrf command on the PE routers to verify that you can reach your customer networks from global address space.

Đۨďý°·˛ą Ş®ş Ý«­¬ß ďëđň¨ň¨ďňďé

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďëđň¨ň¨ďňďéô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă îčńíďńíę ł­

Đۨďý°·˛ą Ş®ş Ý«­¬Ţ ďëđň¨ň¨ďňíí

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďëđň¨ň¨ďňííô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă îčńîčńíî ł­

Page 706: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 35

Lab 5-2: Running EIGRP Between PE and CE Routers

Complete this lab activity to practice what you learned in the related module.

Activity Objective Some customers use EIGRP as the routing protocol in their VPN; sometimes, EIGRP is even combined with RIP or BGP at other sites. In this activity, the customers of the service provider have decided to migrate some of their sites to EIGRP.

In this activity, you will deploy EIGRP as the PE-CE routing protocol in the VPN of your customer. After completing this activity, you will be able to meet this objective:

Convert one of each of the customer sites to EIGRP (from RIP) and establish VPN routing using EIGRP. The other site will continue running RIP as the IGP.

Visual Objective The figure illustrates what you will accomplish in this activity.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8

MPLS Lab Customer EIGRP Scheme

Page 707: Implementing cisco mpls

36 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

For your reference, the figure shows the addresses in use in the network.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7

MPLS Lab IP Addressing Scheme

Required Resources This is the resource that is required to complete this activity:

Cisco IOS documentation

Page 708: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 37

Command List The table describes the commands that are used in this activity.

OSPF Commands

Command Description

żĽĽ®»­­óşżł·´§ ·°Şě Ĺł«´¬·˝ż­¬ ¤ «˛·˝ż­¬ ¤ Ş®ş Ş®şó˛żł»Ă

Enters address family configuration mode and specifies the name of the VRF to associate with submode commands.

˛»¬©±®µ ·°óżĽĽ®»­­ ˛»¬©±®µółż­µ

Specifies the network for the VRF. The network statement is used to identify which interfaces to include in EIGRP. The VRF must be configured with addresses that fall within the subnetwork range of the configured network statement.

®»Ľ·­¬®·ľ«¬» °®±¬±˝±´ Ĺ°®±˝»­­ó·ĽĂ Ą´»Ş»´óď ¤ ´»Ş»´óďóî ¤ ´»Ş»´óîŁ Ĺż­ó˛«łľ»®Ă Ĺł»¬®·˝ ł»¬®·˝óŞż´«»Ă Ĺł»¬®·˝ó¬§°» ¬§°»óŞż´«»Ă Ĺ®±«¬»ółż° łż°ó˛żł»ĂĹłż¬˝¸ Ą·˛¬»®˛ż´ ¤ »¨¬»®˛ż´ ď ¤ »¨¬»®˛ż´ îŁĂ Ŭżą ¬żąóŞż´«»Ă Ĺ®±«¬»ółż° łż°ó¬żąĂ Ĺ­«ľ˛»¬­Ă

Redistributes BGP into the EIGRP. The AS number and metric of the BGP network are configured in this step. BGP must be redistributed into EIGRP for the CE site to accept the BGP routes that carry the EIGRP information. A metric must also be specified for the BGP network and is configured in this step.

®±«¬»® »·ą®° ż­ó˛«łľ»® Enters router configuration mode and creates an EIGRP routing process.

­¸±© ·° »·ą®° Ş®ş Ş®şó˛żł» ·˛¬»®şż˝»­

Displays EIGRP interfaces that are defined under the specified VRF. If an interface is specified, only that interface is displayed. Otherwise, all interfaces on which EIGRP is running as part of the specified VRF are displayed.

­¸±© ·° »·ą®° Ş®ş Ş®şó˛żł» ˛»·ą¸ľ±®­

Displays when VRF neighbors become active and inactive. This command can be used to help debug transport problems.

­¸±© ·° »·ą®° Ş®ş Ş®şó˛żł» ¬±°±´±ą§

Displays VRF entries in the EIGRP topology table. This command can be used to determine Diffusing Update Algorithm (DUAL) states and to debug possible DUAL problems.

­¸±© ·° Ş®ş Displays the set of defined VRFs and associated interfaces. This command is used to verify that the correct RDs are configured for the VRF.

Task 1: Enable an EIGRP VPN In this task, your customer has decided to convert only one of its two locations from RIP to EIGRP. Workgroup x1 will convert the customer A site, CEx1A, from RIP to EIGRP and establish a simple VPN.

Workgroup x2 will convert the customer B site, CEx2B, from RIP to EIGRP and establish a simple VPN.

Each POP is responsible for all PE router configurations related to its customer.

Page 709: Implementing cisco mpls

38 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Activity Procedure

Complete these steps:

Step 1 Disable RIP and configure EIGRP on one of the two routers of your customer. Workgroup x1 on POP x1 will configure CEx1A, and Workgroup x2 on POP x2 will configure CEx2B. Use x, your SP number, as the AS number for EIGRP. Because both customers are connected via the same 150.x.0.0 network, be specific on the EIGRP statement to match the appropriate interface.

Step 2 Remove the appropriate address family from the RIP routing process on your PE router.

Step 3 Configure EIGRP on your PE router.

Step 4 On your assigned PE router, configure redistribution of EIGRP into BGP with the address-family ipv4 vrf vrf-name command. Because the source EIGRP metric is incompatible with the destination RIP metric, set the default metric to 1.

Step 5 On your assigned PE router, configure redistribution of BGP into EIRGP with the address-family ipv4 vrf vrf-name command. Disable the autosummarization feature of EIGRP.

Activity Verification

You have completed this task when you attain these results:

You have verified that EIGRP has been activated on the proper interfaces.

Đۨďý­¸±© ·° »·ą®° ·˛¬»®şż˝»­

×ĐóŰ×ŮÎĐ ·˛¬»®şż˝»­ ş±® °®±˝»­­ ď

Čł·¬ Ď«»«» Ó»ż˛ Đż˝·˛ą Ě·ł» Ó«´¬·˝ż­¬ Đ»˛Ľ·˛ą

ײ¬»®şż˝» Đ»»®­ ˲ńλ´·żľ´» ÍÎĚĚ Ë˛ńλ´·żľ´» Ú´±© Ě·ł»® ᫬»­

Í»đńđňďďď ď đńđ ęđđ đńďë îççď đ

Ô±đ đ đńđ đ đńďđ đ đ

You have verified that EIGRP adjacencies have been established between the CE and PE routers.

Đۨďý­¸±© ·° »·ą®° Ş®ş Ý«­¬ß ˛»·ą¸ľ±®­

×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ě

Ř ßĽĽ®»­­ ײ¬»®şż˝» ر´Ľ Ë°¬·ł» ÍÎĚĚ ÎĚŃ Ď Í»Ż ̧°»

ř­»˝÷ řł­÷ ݲ¬ Ň«ł

đ ďëđň¨ň¨ďňďé Í»đńđňďđď ďě đđćđîćëď íěđ îđěđ đ ě

Đۨîý­¸±© ·° »·ą®° Ş®ş Ý«­¬Ţ ˛»·ą¸ľ±®­

×ĐóŰ×ŮÎĐ ˛»·ą¸ľ±®­ ş±® °®±˝»­­ ě

Ř ßĽĽ®»­­ ײ¬»®şż˝» ر´Ľ Ë°¬·ł» ÍÎĚĚ ÎĚŃ Ď Í»Ż ̧°»

ř­»˝÷ řł­÷ ݲ¬ Ň«ł

đ ďëđň¨ň¨îňíí Í»đńđňďđî ďě đđćđîćîç ďđëđ ëđđđ đ î

Page 710: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 39

You have checked the EIGRP topology database on the CE routers.

Đۨďý­¸±© ·° »·ą®° Ş®ş Ý«­¬ß ¬±°±´±ą§

×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřě÷ń×Üřďëđň¨ň¨ďňďč÷ ᫬·˛ą Ěżľ´»ć Ý«­¬ß

ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô

® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­

Đ ďđňďň¨îňěçńíîô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđđ

Ş·ż λĽ·­¬®·ľ«¬»Ľ řîčďęđđńđ÷

Đ ďđňďň¨ďňěçńíîô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę

Ş·ż ďëđň¨ň¨ďňďé řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđňďđď

Đ ďđňďň¨îňďęńîčô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđđ

Ş·ż λĽ·­¬®·ľ«¬»Ľ řîčďęđđńđ÷

Đ ďđňďň¨ďňďęńîčô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďçëěëę

Ş·ż ďëđň¨ň¨ďňďé řîďçëěëęńîčďęđđ÷ô Í»®·ż´đńđňďđď

Đ ďëđň¨ň¨îňďęńîčô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđđ

Ş·ż λĽ·­¬®·ľ«¬»Ľ řîčďęđđńđ÷

Đ ďëđň¨ň¨ďňďęńîčô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę

Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđňďđď

Đۨîý­¸±© ·° »·ą®° Ş®ş Ý«­¬Ţ ¬±°±´±ą§

×ĐóŰ×ŮÎР̱°±´±ą§ Ěżľ´» ş±® ßÍřě÷ń×Üřďëđň¨ň¨îňíě÷ ᫬·˛ą Ěżľ´»ć Ý«­¬Ţ

ݱĽ»­ć Đ ó Đż­­·Ş»ô ß ó ß˝¬·Ş»ô Ë ó Ë°Ľż¬»ô Ď ó Ď«»®§ô Î ó λ°´§ô

® ó ®»°´§ ͬż¬«­ô ­ ó ­·ż ͬż¬«­

Đ ďđňîň¨ďňěçńíîô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđđ

Ş·ż λĽ·­¬®·ľ«¬»Ľ řîčďęđđńđ÷

Đ ďđňîň¨ďňěçńíîô ď ­«˝˝»­­±®­ô ÚÜ ·­ îîçéčëę

Ş·ż ďëđň¨ň¨îňíí řîîçéčëęńďîčîëę÷ô Í»®·ż´đńđňďđî

Đ ďđňîň¨ďňďęńîčô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđđ

Ş·ż λĽ·­¬®·ľ«¬»Ľ řîčďęđđńđ÷

Đ ďđňîň¨îňďęńîčô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďçëěëę

Ş·ż ďëđň¨ň¨îňíí řîďçëěëęńîčďęđđ÷ô Í»®·ż´đńđňďđî

Đ ďëđň¨ň¨îňíîńîčô ď ­«˝˝»­­±®­ô ÚÜ ·­ îďęçčëę

Ş·ż ݱ˛˛»˝¬»Ľô Í»®·ż´đńđňďđî

Đ ďëđň¨ň¨ďňíîńîčô ď ­«˝˝»­­±®­ô ÚÜ ·­ îčďęđđ

Ş·ż λĽ·­¬®·ľ«¬»Ľ řîčďęđđńđ÷

Page 711: Implementing cisco mpls

40 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

You have verified connectivity across the VPN by using ping and trace commands on the CE routers and ping vrf and trace vrf commands on the PE routers.

ÝۨďŢý°·˛ą ďđňîň¨îňďé

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňîň¨ďňďéô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďěěńďěęńďěç ł­

Ýۨďßý°·˛ą ďđňďň¨îňďé

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďëđň¨ň¨îňďéô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďěěńďěéńďëî ł­

ÝۨďŢý¬®ż˝» ďđňîň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďëđň¨ň¨îňěç

ď ďëđň¨ň¨ďňíě ďę ł­»˝ ďî ł­»˝ ďî ł­»˝

î ďëđň¨ň¨îňíě ĹÓĐÔÍć Ôżľ»´ îç ۨ° đĂ ęě ł­»˝ ęđ ł­»˝ ęđ ł­»˝

í ďëđň¨ň¨îňíí éé ł­»˝ éę ł­»˝ ö

Ýۨďßý¬®ż˝» ďđňďň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďëđň¨ň¨îňďé

ď ďëđň¨ň¨ďňďč ďî ł­»˝ ďî ł­»˝ ďî ł­»˝

î ďëđň¨ň¨îňďč ĹÓĐÔÍć Ôżľ»´ îë ۨ° đĂ ęě ł­»˝ ęđ ł­»˝ ęě ł­»˝

í ďëđň¨ň¨îňďé éę ł­»˝ éę ł­»˝ ö

Đۨďý°·˛ą Ş®ş Ý«­¬ß ďđňďň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňďň¨îňěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďęńďďçńďîđ ł­

Đۨďý¬®ż˝» Ş®ş Ý«­¬Ţ ďđňîň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďđňîň¨îňěç

ď ďëđň¨ň¨îňíě ĹÓĐÔÍć Ôżľ»´ îę ۨ° đĂ çî ł­»˝ čč ł­»˝ čč ł­»˝

î ďëđň¨ň¨îňíí ęđ ł­»˝ ö ęđ ł­»˝

Page 712: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 41

Đۨîý°·˛ą Ş®ş Ý«­¬ß ďđňďň¨ďňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňďň¨ďňěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă îčńîçńíî ł­

Đۨîý¬®ż˝» Ş®ş Ý«­¬ß ďđňďň¨ďňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďđňďň¨ďňěç

ď ďëđň¨ň¨ďňďč ĹÓĐÔÍć Ôżľ»´ îî ۨ° đĂ čč ł­»˝ čč ł­»˝ čč ł­»˝

î ďëđň¨ň¨ďňďé ęđ ł­»˝ ö ęđ ł­»˝

Page 713: Implementing cisco mpls

42 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 5-3: Running OSPF Between PE and CE Routers

Complete this lab activity to practice what you learned in the related module.

Activity Objective Some customers insist on using OSPF as the routing protocol in their VPN, sometimes even combined with RIP or BGP at other sites. In this activity, you will migrate the CE-to-PE routing protocol to OSPF. After completing this activity, you will be able to meet these objectives:

Convert one of each of the customer sites to OSPF (from RIP) and establish VPN routing using OSPF

Visual Objective The figure illustrates what you will accomplish in this activity.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—10

MPLS Lab Customer OSPF Scheme

Page 714: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 43

For your reference, the figure shows the addresses in use in the network.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—9

MPLS Lab IP Addressing Scheme

Required Resources This is the resource that is required to complete this activity:

Cisco IOS documentation

Page 715: Implementing cisco mpls

44 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Command List The table describes the commands that are used in this activity.

OSPF Commands

Command Description

żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ş®şó˛żł»

Selects a per-VRF instance of a routing protocol

Ľ»şż«´¬ó·˛ş±®łż¬·±˛ ±®·ą·˛ż¬» ż´©ż§­

Generates a default route into OSPF

·° Ş®ş ş±®©ż®Ľ·˛ą Ş®şó˛żł»

Assigns an interface to a VRF

·° Ş®ş Ş®şó˛żł» Creates a VRF table

°·˛ą Ş®ş Ş®şó˛żł» ¸±­¬ Pings a host reachable through the specified VRF

®Ľ Şż´«» Assigns an RD to a VRF

®»Ľ·­¬®·ľ«¬» ľą° ż­ó˛«łľ»® ­«ľ˛»¬­

Redistributes BGP routes (including subnetwork routes) into OSPF

®±«¬»® ľą° ż­ó˛«łľ»® Selects BGP configuration

®±«¬»® ±­°ş °®±˝»­­ Ş®ş Ş®şó˛żł»

Starts an OSPF process within the specified VRF

®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ¤ »¨°±®¬ Şż´«»

Assigns an RT to a VRF

­¸±© ·° ľą° Ş°˛Şě Ş®ş Ş®şó˛żł»

Displays VPNv4 routes associated with the specified VRF

­¸±© ·° ±­°ş Ľż¬żľż­» Displays OSPF database information

­¸±© ·° ®±«¬» Ş®ş Ş®şó˛żł»

Displays an IP routing table of the specified VRF

­¸±© ·° Ş®ş Ľ»¬ż·´ Displays detailed VRF information

¬»´˛»¬ ¸±­¬ ńŞ®ş Ş®şó˛żł»

Makes a Telnet connection to a CE router connected to the specified VRF

Task 1: Configure OSPF as the PE-CE Routing Protocol In this task, your customer has decided to have OSPF as the only IGP. This decision means that the customer sites that are running EIGRP or RIP will have to be converted to OSPF. Workgroup x1 will convert customer A (CEx1A and CEx2A), and Workgroup x2 will convert customer B (CEx1B and CEx2B) to establish a simple VPN.

Each POP is responsible for all PE router configurations related to its customer.

Page 716: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 45

Activity Procedure

Complete these steps:

Step 1 Disable EIGRP and RIP and configure OSPF on the CE routers of your customer. Configure OSPF areas (use an OSPF process ID of 1 for CustA and a process ID of 2 for CustB) in the CE router according to the information here.

Area Interface (or Interfaces)

Area 0 WAN interface toward PE router Loopback 0

Area 1 E0/0

Step 2 Configure OSPF (use an OSPF process ID of 1 for CustA and a process ID of 2 for CustB) in the VRFs on the PE routers using the router ospf vrf command. Use OSPF Area 0 on the PE-CE link.

Step 3 Configure redistribution from OSPF to MP-BGP using the redistribute ospf command inside the VRF address family configuration.

Step 4 Configure redistribution from MP-BGP to OSPF using the redistribute bgp subnets command in the OSPF router configuration.

Activity Verification

You have completed this task when you attain these results:

You have verified the OSPF adjacency on PEx1 and PEx2 routers using the show ip ospf neighbor command.

Đۨďý­¸±© ·° ±­°ş ˛»·ą¸ľ±®

Ň»·ą¸ľ±® ×Ü Đ®· ͬż¬» Ü»żĽ Ě·ł» ߼Ľ®»­­ ײ¬»®şż˝»

ďđňďň¨ďňěç đ ÚËÔÔń ó đđćđđćíę ďëđň¨ň¨ďňďé Í»®·ż´đńđňďđď

ďđňîň¨ďňěç đ ÚËÔÔń ó đđćđđćíé ďëđň¨ň¨ďňíí Í»®·ż´đńđňďđî

Đۨîý­¸±© ·° ±­°ş ˛»·ą¸ľ±®

Ň»·ą¸ľ±® ×Ü Đ®· ͬż¬» Ü»żĽ Ě·ł» ߼Ľ®»­­ ײ¬»®şż˝»

ďđňîň¨îňěç đ ÚËÔÔń ó đđćđđćíđ ďëđň¨ň¨îňíí Í»®·ż´đńđňďđî

ďđňďň¨îňěç đ ÚËÔÔń ó đđćđđćíç ďëđň¨ň¨îňďé Í»®·ż´đńđňďđď

Page 717: Implementing cisco mpls

46 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

You have checked the OSPF topology database on CEx1A and CEx2B. You should see router link states (resulting from OSPF connectivity between the PE and the CE routers) and type 5 external link states. A sample printout from CEx1A is shown here:

Ýۨďßý­¸±© ·° ±­°ş Ľż¬żľż­»

ŃÍĐÚ Î±«¬»® ©·¬¸ ×Ü řďđňďňďďňěç÷ řĐ®±˝»­­ ×Ü ď÷

᫬»® Ô·˛µ ͬż¬»­ řß®»ż đ÷

Ô·˛µ ×Ü ßÜĘ Î±«¬»® ßą» Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬

ďđňďň¨ďňěç ďđňďň¨ďňěç ďéěě đ¨îđđđđđđë đ¨đđéÝíđ í

ďëđň¨ň¨ďňďč ďëđň¨ň¨ďňďč îďę đ¨îđđđđđđě đ¨đđđŰčé î

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż đ÷

Ô·˛µ ×Ü ßÜĘ Î±«¬»® ßą» Í»Żý ݸ»˝µ­«ł

ďđňďň¨ďňďę ďđňďň¨ďňěç ďéěě đ¨îđđđđđđî đ¨đđďîÝď

ďđňďň¨îňďę ďëđň¨ň¨ďňďč ďďčę đ¨îđđđđđđď đ¨đđÝÜÜé

ďđňďň¨îňěç ďëđň¨ň¨ďňďč ďďčę đ¨îđđđđđđď đ¨đđčîÚŢ

ďëđň¨ň¨îňďę ďëđň¨ň¨ďňďč ďďčę đ¨îđđđđđđď đ¨đđÝÜçě

᫬»® Ô·˛µ ͬż¬»­ řß®»ż ď÷

Ô·˛µ ×Ü ßÜĘ Î±«¬»® ßą» Í»Żý ݸ»˝µ­«ł Ô·˛µ ˝±«˛¬

ďđňďň¨ďňěç ďđňďň¨ďňěç ďéěě đ¨îđđđđđđî đ¨đđëíîŰ ď

Í«łłż®§ Ň»¬ Ô·˛µ ͬż¬»­ řß®»ż ď÷

Ô·˛µ ×Ü ßÜĘ Î±«¬»® ßą» Í»Żý ݸ»˝µ­«ł

ďđňďň¨ďňěç ďđňďň¨ďňěç ďéěě đ¨îđđđđđđî đ¨đđÝęŰë

ďđňďň¨îňďę ďđňďň¨ďňěç ďîçě đ¨îđđđđđđď đ¨đđđŰěë

ďđňďň¨îňěç ďđňďň¨ďňěç ďîçě đ¨îđđđđđđď đ¨đđÝîęç

ďëđň¨ň¨ďňďę ďđňďň¨ďňěç ďčëí đ¨îđđđđđđî đ¨đđđÜđě

ďëđň¨ň¨îňďę ďđňďň¨ďňěç ďîçě đ¨îđđđđđđď đ¨đđđŰđî

Í«łłż®§ ßÍŢ Ô·˛µ ͬż¬»­ řß®»ż ď÷

Ô·˛µ ×Ü ßÜĘ Î±«¬»® ßą» Í»Żý ݸ»˝µ­«ł

ďëđň¨ň¨ďňďč ďđňďň¨ďňěç ííî đ¨îđđđđđđî đ¨đđěëŢç

Page 718: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 47

You have checked the IP routing table on CEx1A and noted the OSPF interarea (IA) routes in the routing table.

Ýۨďßý­¸±© ·° ®±«¬»

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô × ó ×ŮÎĐô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» îô Ű ó ŰŮĐ

· ó ×Íó×Íô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óîô ·ż ó ×Íó×Í ·˛¬»® ż®»ż

ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»ô ± ó ŃÜÎ

Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­

Ý ďđňďň¨ďňďęńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô ۬¸»®˛»¬đńđ

Ń ×ß ďđňďň¨îňďęńîč ĹďďđńďíčĂ Ş·ż ďëđň¨ň¨ďňďčô đđćíîćěďô Í»®·ż´îńđňďđď

Ý ďđňďň¨ďňěçńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

Ń ×ß ďđňďň¨îňěçńíî ĹďďđńďîçĂ Ş·ż ďëđň¨ň¨ďňďčô đđćíîćěďô Í»®·ż´îńđňďđď

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­

Ń ×ß ďëđň¨ň¨îňďę ĹďďđńęëĂ Ş·ż ďëđň¨ň¨ďňďčô đđćíîćěďô Í»®·ż´îńđňďđď

Ý ďëđň¨ň¨ďňďę ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´îńđňďđď

You have verified connectivity across the VPN by using ping and trace commands on the CE routers and ping vrf and trace vrf commands on the PE routers. These are just a few examples.

Ýۨďßý°·˛ą ďđňďň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňďň¨îňěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďěčńďěčńďěç ł­

Đۨďý°·˛ą Ş®ş Ý«­¬ß ďđňďň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňďň¨îňěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďčńďîîńďîč ł­

Đۨďý°·˛ą Ş®ş Ý«­¬Ţ ďđňîň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňîň¨îňěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďďęńďîďńďíî ł­

Page 719: Implementing cisco mpls

48 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Đۨďý¬®ż˝» Ş®ş Ý«­¬ß ďđňďň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďđňďň¨îňěç

ď ďëđň¨ň¨îňďč ĹÓĐÔÍć Ôżľ»´ ďę ۨ° đĂ čč ł­»˝ çî ł­»˝ čč ł­»˝

î ďëđň¨ň¨îňďé ęđ ł­»˝ ö ęđ ł­»˝

Đۨďý¬®ż˝» Ş®ş Ý«­¬Ţ ďđňîň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďđňîň¨îňěç

ď ďëđň¨ň¨îňíě ĹÓĐÔÍć Ôżľ»´ îě ۨ° đĂ čč ł­»˝ čč ł­»˝ čč ł­»˝

î ďëđň¨ň¨îňíí ęđ ł­»˝ ö ęđ ł­»˝

Page 720: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 49

Lab 5-4: Running BGP Between PE and CE Routers

Complete this lab activity to practice what you learned in the related module.

Activity Objective Your customer has indicated that it wants to have a backup link for a selected site for redundancy. This addition will produce a multihomed environment. As a result, it is necessary to use BGP as the CE-to-PE routing protocol. The provider has decided to implement this conversion in phases. The existing links will be converted to BGP, and then the backup links will be added and activated.

In this activity, you will convert the CE-to-PE routing protocol of your customer to BGP. After completing this activity, you will be able to meet these objectives:

Enable EBGP as the CE-to-PE link routing protocol

Enable a backup link

Configure BGP to control the selection of primary and backup links

Visual Objective The figure illustrates what you will accomplish in this activity.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—12

MPLS Lab Customer BGP Scheme

Page 721: Implementing cisco mpls

50 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

For your reference, the figure shows the addresses in use in the network.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—11

MPLS Lab IP Addressing Scheme

Required Resources This is the resource that is required to complete this activity:

Cisco IOS documentation

Page 722: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 51

Command List The table describes the commands that are used in this activity.

BGP Commands

Command Description

żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ş®şó˛żł»

Selects a per-VRF instance of a routing protocol.

·° Ş®ş ş±®©ż®Ľ·˛ą Ş®şó˛żł»

Assigns an interface to a VRF.

·° Ş®ş Ş®şó˛żł» Creates a VRF table.

˛»·ą¸ľ±® ·°óżĽĽ®»­­ ż­ó±Ş»®®·Ľ»

To configure a PE router to override the AS number of a site with the AS number of a provider, use the neighbor as-overridecommand in router configuration mode. To remove VPNv4 prefixes from a specified router, use the no form of this command.

˛»·ą¸ľ±® ·°óżĽĽ®»­­ ®±«¬»ółż° ˛żł» ·˛ ¤ ±«¬

Applies a route map to BGP updates received from or sent to the specified neighbor.

˛± ˛»·ą¸ľ±® ·°óżĽĽ®»­­ ­¸«¬Ľ±©˛

Enables a BGP neighbor previously disabled with the neighbor shutdown command.

°·˛ą Ş®ş Ş®şó˛żł» ¸±­¬ Pings a host reachable through the specified VRF.

®Ľ Şż´«» Assigns an RD to a VRF.

®±«¬»ółż° ˛żł» °»®ł·¬ ­»Ż

Creates an entry in a route map.

®±«¬»® ľą° ż­ó˛«łľ»® Selects BGP configuration.

®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ¤ »¨°±®¬ Şż´«»

Assigns an RT to a VRF.

­»¬ ł»¬®·˝ Şż´«» Sets the BGP MED attribute in a route map.

­¸±© ·° ľą° Ş°˛Şě Ş®ş Ş®şó˛żł»

Displays VPNv4 routes associated with the specified VRF.

­¸±© ·° ®±«¬» Ş®ş Ş®şó˛żł»

Displays an IP routing table of the specified VRF.

¬»´˛»¬ ¸±­¬ ńŞ®ş Ş®şó˛żł»

Makes a Telnet connection to a CE router connected to the specified VRF.

Task 1: Configure BGP as the PE-CE Routing Protocol In this task, you will make BGP the routing protocol between the PE router and your customer routers. OSPF will remain the customer IGP. You will need to redistribute from BGP to OSPF and from OSPF to BGP on the routers of your customer. You will establish simple VPNs for customer A and customer B. Workgroup x1 will convert customer A (CEx1A and CEx2A), and workgroup x2 will convert customer B (CEx1B and CEx2B) to establish a simple VPN. Each POP is responsible for all PE router configurations related to its customer.

Page 723: Implementing cisco mpls

52 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Activity Procedure

Complete these steps:

Step 1 Activate the BGP routing process on the CE routers of your customer using AS650x1 for customer A and AS 650x2 for customer B. Disable the autosummarization BGP feature.

Step 2 Remove OSPF on the associated PE router and activate the BGP neighbor relationship between each CE router and its associated PE router.

Step 3 Because both customers use the same AS number at all their sites, you will need to enable the AS-override feature on the PE routers.

Activity Verification

You have completed this task when you attain these results:

You have checked BGP connectivity with the show ip bgp summary command on the CE routers.

Ýۨďßý­¸±© ·° ľą° ­«łłż®§

ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďđňďň¨ďňěçô ´±˝ż´ ßÍ ˛«łľ»® ęëđ¨ď

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďđô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ďđ

ę ˛»¬©±®µ »˛¬®·»­ «­·˛ą ëčî ľ§¬»­ ±ş ł»ł±®§

ę °ż¬¸ »˛¬®·»­ «­·˛ą îďę ľ§¬»­ ±ş ł»ł±®§

ď ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą îě ľ§¬»­ ±ş ł»ł±®§

đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§

đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§

ŢŮĐ «­·˛ą çěî ¬±¬ż´ ľ§¬»­ ±ş ł»ł±®§

ŢŮĐ ż˝¬·Ş·¬§ ęńđ °®»ş·¨»­ô çńí °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ęđ ­»˝­

Ň»·ą¸ľ±® Ę ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ Ěľ´Ę»® ×˛Ď Ń«¬Ď Ë°ńܱ©˛ ͬż¬»ńĐş¨Î˝Ľ

ďëđň¨ň¨ďňďč ě ęëđđď ęďé ęďč ďđ đ đ đçćëđćíë í

Ýۨďßý­¸±© ·° ľą°

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ éô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňďň¨ďňěç

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

öâ ďđňďň¨ďňďęńîč đňđňđňđ đ íîéęč á

öâ ďđňďň¨ďňěçńíî đňđňđňđ đ íîéęč á

öâ ďđňďň¨îňďęńîč ďëđň¨ň¨ďňďč đ ęëđđď ęëđđď á

öâ ďđňďň¨îňěçńíî ďëđň¨ň¨ďňďč đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨ďňďęńîč đňđňđňđ đ íîéęč á

öâ ďëđň¨ň¨îňďęńîč ďëđň¨ň¨ďňďč đ ęëđđď ęëđđď á

Page 724: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 53

Đۨďý­¸±© ·° ľą° Ş°˛ ż´´

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ęíô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčň¨ňďé

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćďđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬ß÷

öâ ďđňďň¨ďňďęńîč ďëđň¨ň¨ďňďé đ đ ęëđ¨ď á

öâ ďđňďň¨ďňěçńíî ďëđň¨ň¨ďňďé đ đ ęëđ¨ď á

öâ·ďđňďň¨îňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨ď á

öâ·ďđňďň¨îňěçńíî ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨ď á

®â ďëđň¨ň¨ďňďęńîč ďëđň¨ň¨ďňďé đ đ ęëđ¨ď á

öâ·ďëđň¨ň¨îňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨ď á

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćîđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬Ţ÷

öâ ďđňîň¨ďňďęńîč ďëđň¨ň¨ďňíí đ đ ęëđ¨î á

öâ ďđňîň¨ďňěçńíî ďëđň¨ň¨ďňíí đ đ ęëđ¨î á

öâ·ďđňîň¨îňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨î á

öâ·ďđňîň¨îňěçńíî ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨î á

®â ďëđň¨ň¨ďňíîńîč ďëđň¨ň¨ďňíí đ đ ęëđ¨î á

öâ·ďëđň¨ň¨îňíîńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨î á

Task 2: Configure the Backup PE-CE Link In this task, you will enable the backup links on the PE routers. Workgroup x1 on POP x1 will establish the link between its PEx1 router and the CEx2A router, and workgroup x2 on POP x2will establish the link between its PEx2 router and the CEx1B router. Ensure that the interface is added to the proper VRF and that BGP is activated.

Activity Procedure

Complete these steps:

Step 1 Configure an additional subinterface on the existing serial interfaces on your PE and CE routers. Use the DLCI number as the subinterface number.

Step 2 Add the backup link to the appropriate VRF.

Which VRF is interface Se0/0.113 from CEx1B added to?

Which VRF is interface Se0/0.113 from CEx2A added to?

Page 725: Implementing cisco mpls

54 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Step 3 Configure IP addresses and DLCIs on this interface using the parameters in the table.

Backup Link Configuration Parameters

Source

Router

IP Address DLCI Destination Router IP Address DLCI

CEx2A 150.x.x1.49/28 113 PEx1 150.x.x1.50/28 113

CEx1B 150.x.x2.49/28 113 PEx2 150x.x2.50/28 113

Step 4 Activate the BGP neighbor relationship between your CE router and the appropriate PE router.

Activity Verification

You have completed this task when you attain these results:

You have verified point-to-point connectivity over the new subinterface.

ÝۨďŢý°·˛ą ďëđň¨ň¨îňëđ

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďëđň¨ň¨îňëđô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă îčńîčńíî ł­

Đۨîý°·˛ą Ş®ş Ý«­¬Ţ ďëđň¨ň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďëđň¨ň¨îňěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ëęńëęńęđ ł­

Ýۨîßý°·˛ą ďëđň¨ň¨ďňëđ

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďëđň¨ň¨ďňëđô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă îčńîçńíî ł­

Đۨďý°·˛ą Ş®ş Ý«­¬ß ďëđň¨ň¨ďňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďëđň¨ň¨ďňěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Page 726: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 55

You have checked BGP connectivity with the show ip bgp summary command on the CE routers.

Ýۨîßý­¸±© ·° ľą° ­«łłż®§

ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďđňďň¨îňěçô ´±˝ż´ ßÍ ˛«łľ»® ęëđ¨î

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďđô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ďđ

é ˛»¬©±®µ »˛¬®·»­ ż˛Ľ ç °ż¬¸­ «­·˛ą ďďçé ľ§¬»­ ±ş ł»ł±®§

ďđ °ż¬¸ »˛¬®·»­ «­·˛ą íę𠾧¬»­ ±ş ł»ł±®§

ď ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą îě ľ§¬»­ ±ş ł»ł±®§

đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§

đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§

ŢŮĐ «­·˛ą ďďčí ¬±¬ż´ ľ§¬»­ ±ş ł»ł±®§

ŢŮĐ ż˝¬·Ş·¬§ éńđ °®»ş·¨»­ô ďęńę °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ęđ ­»˝­

Ň»·ą¸ľ±® Ę ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ Ěľ´Ę»® ×˛Ď Ń«¬Ď Ë°ńܱ©˛ ͬż¬»ńĐş¨Î˝Ľ

ďëđň¨ň¨ďňëđ ě ęëđđď ęđę ęđé ďđ đ đ đđćđďćîç î

ďëđň¨ň¨îňďč ě ęëđđď ęďé ęďč ďđ đ đ đçćëđćíë í

Ýۨîßý­¸±© ·° ľą°

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďéô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňďň¨îňěç

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

ö ďđňďň¨ďňďęńîč ďëđň¨ň¨îňďč đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨ďňëđ đ ęëđđď ęëđđď á

ö ďđňďň¨ďňěçńíî ďëđň¨ň¨îňďč đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨ďňëđ đ ęëđđď ęëđđď á

öâ ďđňďň¨îňďęńîč đňđňđňđ đ íîéęč á

öâ ďđňďň¨îňěçńíî đňđňđňđ đ íîéęč á

ö ďëđň¨ň¨ďňďęńîč ďëđň¨ň¨îňďč đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨ďňëđ đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨ďňěčńîč đňđňđňđ đ íîéęč á

öâ ďëđň¨ň¨îňďęńîč đňđňđňđ đ íîéęč á

Page 727: Implementing cisco mpls

56 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Đۨďý­¸±© ·° ľą° Ş°˛ ż´´

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ íęô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčň¨ňďé

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćďđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬ß÷

öâ ďđňďň¨ďňďęńîč ďëđň¨ň¨ďňďé đ đ ęëđ¨ď á

öâ ďđňďň¨ďňěçńíî ďëđň¨ň¨ďňďé đ đ ęëđ¨ď á

öâ ďđňďň¨îňďęńîč ďëđň¨ň¨ďňěç đ đ ęëđ¨ď á

ö · ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨ď á

öâ ďđňďň¨îňěçńíî ďëđň¨ň¨ďňěç đ đ ęëđ¨ď á

ö · ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨ď á

®â ďëđň¨ň¨ďňďęńîč ďëđň¨ň¨ďňďé đ đ ęëđ¨ď á

®â ďëđň¨ň¨ďňěčńîč ďëđň¨ň¨ďňěç đ đ ęëđ¨ď á

® · ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨ď á

öâ ďëđň¨ň¨îňďęńîč ďëđň¨ň¨ďňěç đ đ ęëđ¨ď á

ö · ďçîňďęčňďňíí đ ďđđ đ ęëđ¨ď á

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćîđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬Ţ÷

ö ·ďđňîň¨ďňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨î á

öâ ďëđň¨ň¨ďňíí đ đ ęëđ¨î á

ö ·ďđňîň¨ďňěçńíî ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨î á

öâ ďëđň¨ň¨ďňíí đ đ ęëđ¨î á

öâ·ďđňîň¨îňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨î á

öâ·ďđňîň¨îňěçńíî ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨î á

® ·ďëđň¨ň¨ďňíîńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨î á

®â ďëđň¨ň¨ďňíí đ đ ęëđ¨î á

öâ·ďëđň¨ň¨îňíîńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨î á

ö ·ďëđň¨ň¨îňěčńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨î á

öâ ďëđň¨ň¨ďňíí đ đ ęëđ¨î á

Page 728: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 57

Đۨîý­¸±© ·° ľą° Ş°˛ ż´´

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďíđô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčň¨ňíí

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćďđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬ß÷

öâ·ďđňďň¨ďňďęńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨ď á

öâ·ďđňďň¨ďňěçńíî ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨ď á

ö ·ďđňďň¨îňďęńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨ď á

öâ ďëđň¨ň¨îňďé đ đ ęëđ¨ď á

ö ·ďđňďň¨îňěçńíî ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨ď á

öâ ďëđň¨ň¨îňďé đ đ ęëđ¨ď á

öâ·ďëđň¨ň¨ďňďęńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨ď á

ö ·ďëđň¨ň¨ďňěčńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨ď á

öâ ďëđň¨ň¨îňďé đ đ ęëđ¨ď á

® ·ďëđň¨ň¨îňďęńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨ď á

®â ďëđň¨ň¨îňďé đ đ ęëđ¨ď á

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćîđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬Ţ÷

öâ ďđňîň¨ďňďęńîč ďëđň¨ň¨îňěç đ đ ęëđ¨î á

ö · ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

öâ ďđňîň¨ďňěçńíî ďëđň¨ň¨îňěç đ đ ęëđ¨î á

ö · ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

öâ ďđňîň¨îňďęńîč ďëđň¨ň¨îňíí đ đ ęëđ¨î á

öâ ďđňîň¨îňěçńíî ďëđň¨ň¨îňíí đ đ ęëđ¨î á

öâ ďëđň¨ň¨ďňíîńîč ďëđň¨ň¨îňěç đ đ ęëđ¨î á

ö · ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

®â ďëđň¨ň¨îňíîńîč ďëđň¨ň¨îňíí đ đ ęëđ¨î á

®â ďëđň¨ň¨îňěčńîč ďëđň¨ň¨îňěç đ đ ęëđ¨î á

® · ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

Task 3: Select the Primary and Backup Link with BGP It may be necessary to control the BGP selection of the link to establish a primary backup relationship. In this task, you will use the local preference and MED attributes to control link selection. In this implementation, the new link bypasses the MPLS core. However, because it is a high-cost link, it should be considered only as the backup link; the link through the MPLS core is to be used as the primary link.

Page 729: Implementing cisco mpls

58 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Activity Procedure

Complete these steps:

Step 1 Use the BGP local preference on the CE router to select the link to its local PE router (through the MPLS core) as the primary link and the link to the remote PE router (bypass link) as the backup link. Use a lower local preference on the preferred path.

Step 2 Set the MED in outgoing routing updates from your CE router to make sure that the PE routers prefer the link through the MPLS core before using the backup link.

Activity Verification

You have completed this task when you attain these results:

You may have had to issue a clear ip route or clear ip bgp * command on the CE router to propagate routes with the new parameters.

You have verified that the primary link (the link to your local PE router) is being used. Use the show ip bgp command to verify this. Make sure that the routes received from the primary link are always selected as the best routes.

ÝۨďŢý­¸±© ·° ľą°

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ čô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňîň¨ďňěç

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

ö ďđňîň¨ďňďęńîč ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ đňđňđňđ đ íîéęč á

öâ ďđňîň¨ďňěçńíî đňđňđňđ đ íîéęč á

ö ďđňîň¨îňďęńîč ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨ďňíě đ ęëđđď ęëđđď á

ö ďđňîň¨îňěçńíî ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨ďňíě đ ęëđđď ęëđđď á

ö ďëđň¨ň¨ďňíîńîč ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ đňđňđňđ đ íîéęč á

ö ďëđň¨ň¨îňíîńîč ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨ďňíě đ ęëđđď ęëđđď á

ö ďëđň¨ň¨îňěčńîč ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ đňđňđňđ đ íîéęč á

Page 730: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 59

You have verified the proper setting of the MED by using the show ip bgp vpnv4 vrf command on the PE routers. Make sure that the PE routers select routes coming from the primary link as the best routes.

Đۨîý­¸±© ·° ľą° Ş°˛Şě ż´´

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ íđô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčň¨ňíí

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćďđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬ß÷

öâ·ďđňďň¨ďňďęńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨ď á

öâ·ďđňďň¨ďňěçńíî ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨ď á

öâ ďđňďň¨îňďęńîč ďëđň¨ň¨îňďé đ đ ęëđ¨ď á

öâ ďđňďň¨îňěçńíî ďëđň¨ň¨îňďé đ đ ęëđ¨ď á öâ·ďëđň¨ň¨ďňďęńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨ď á

öâ ďëđň¨ň¨ďňěčńîč ďëđň¨ň¨îňďé đ đ ęëđ¨ď á

®â ďëđň¨ň¨îňďęńîč ďëđň¨ň¨îňďé đ đ ęëđ¨ď á

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćîđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬Ţ÷

öâ·ďđňîň¨ďňďęńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

ö ďëđň¨ň¨îňěç îđđ đ ęëđ¨î á

ö ďđňîň¨ďňěçńîč ďëđň¨ň¨îňěç îđđ đ ęëđ¨î á

öâ· ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

öâ ďđňîň¨îňďęńîč ďëđň¨ň¨îňíí đ đ ęëđ¨î á

öâ ďđňîň¨îňěçńíî ďëđň¨ň¨îňíí đ đ ęëđ¨î á

öâ·ďëđň¨ň¨ďňíîńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

ö ďëđň¨ň¨îňěç îđđ đ ęëđ¨î á

®â ďëđň¨ň¨îňíîńîč ďëđň¨ň¨îňíí đ đ ęëđ¨î á

®â·ďëđň¨ň¨îňěčńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

® ďëđň¨ň¨îňěç îđđ đ ęëđ¨î á

You have shut down the link from the local PE router to the dual-connected CE router. (This is interface Se0/0.102 on PEx1, and Se0/0.101 on PEx2.)

Page 731: Implementing cisco mpls

60 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

You have verified that the backup link (the link to your remote PE router) is being used. Use the show ip bgp command to verify this after BGP converges.

ÝۨďŢý­¸±© ·° ľą°

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ éô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňîň¨ďňěç

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

öâ ďđňîň¨ďňďęńîč đňđňđňđ đ íîéęč á

öâ ďđňîň¨ďňěçńíî đňđňđňđ đ íîéęč á

öâ ďđňîň¨îňďęńîč ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ ďđňîň¨îňěçńíî ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨îňíîńîč ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨îňěčńîč đňđňđňđ đ íîéęč á

Ýۨîßý­¸ ·° ľą°

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ çô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňďň¨îňěç

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

öâ ďđňďň¨ďňďęńîč ďëđň¨ň¨ďňëđ ëđ đ ęëđđď ęëđđď á

öâ ďđňďň¨ďňěçńíî ďëđň¨ň¨ďňëđ ëđ đ ęëđđď ęëđđď á

öâ ďđňďň¨îňďęńîč đňđňđňđ đ íîéęč á

öâ ďđňďň¨îňěçńíî đňđňđňđ đ íîéęč á

öâ ďëđň¨ň¨ďňďęńîč ďëđň¨ň¨ďňëđ ëđ đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨ďňěčńîč đňđňđňđ đ íîéęč á

You have re-enabled the subinterface.

Page 732: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 61

After the BGP session is established with the local PE router, you have verified that the local link is shown as the preferred link for traffic. Use the show ip bgp command to verify this.

ÝۨďŢý­¸±© ·° ľą°

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ čô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňîň¨ďňěç

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

ö ďđňîň¨ďňďęńîč ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ đňđňđňđ đ íîéęč á

ö ďđňîň¨ďňěçńíî đňđňđňđ đ íîéęč á

ö ďđňîň¨îňďęńîč ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨ďňíě đ ęëđđď ęëđđď á

ö ďđňîň¨îňěçńíî ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨ďňíě đ ęëđđď ęëđđď á

ö ďëđň¨ň¨ďňíîńîč ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ đňđňđňđ đ íîéęč á

ö ďëđň¨ň¨îňíîńîč ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨ďňíě đ ęëđđď ęëđđď á

ö ďëđň¨ň¨îňěčńîč ďëđň¨ň¨îňëđ ëđ đ ęëđđď ęëđđď á

öâ đňđňđňđ đ íîéęč á

Page 733: Implementing cisco mpls

62 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 6-1: Establishing Overlapping VPNs Complete this lab activity to practice what you learned in the related module.

Activity Objective Your VPN customers want to exchange data between their central sites. You have decided to implement this request with an overlapping VPN topology.

In this activity, you will establish overlapping VPNs to support the needs of your customers. After completing this activity, you will be able to meet these objectives:

Design a VPN solution

Remove CEx1A and CEx2B from existing VRFs

Configure new VRFs for CEx1A and CEx2B

Visual Objective The figure illustrates what you will accomplish in this activity.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—13

MPLS Lab: Overlapping VPNs

Page 734: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 63

In this lab activity, you will establish overlapping VPNs with the following connectivity goals:

Simple VPN communication

— CEx1A and CEx2A can communicate.

— CEx1B and CEx2B can communicate.

— CEx1A and CEx1B cannot communicate.

— CEx2A and CEx2B cannot communicate.

— CEx1B and CEx2A cannot communicate.

Overlapping VPN communication (CustAB)

— CEx1A and CEx2B can communicate.

Required Resources This is the resource that is required to complete this activity:

Cisco IOS documentation

Command List The commands that are used in this activity have been described in previous activities.

Task 1: Design Your VPN Solution Site CEx1A cannot belong to the same VRF as the other xA sites. Similarly, site CEx2B cannot belong to the same VRF as the xB sites. Also, CEx1A and CEx2B cannot share the same VRF.

Activity Procedure

Complete these steps:

Step 1 On paper, allocate new RDs for VRFs to which CEx1A and CEx2B will be connected.

Step 2 A new RT is needed for the CustAB VPN. Coordinate the value of this RT with the other POP within your SP.

Note You could use x:11 as the RD for VRFs connected to CEx1A, and you could use x:21 as the

RD for VRFs connected to CEx2B. You could use x:1001 as the RT for the CustAB VPN.

Activity Verification

You have completed this task when you attain this result:

You have designed RDs and RTs for the new VRFs.

Page 735: Implementing cisco mpls

64 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Task 2: Remove CEx1A and CEx2B from Existing VRFs CEx1A and CEx2B must be migrated to new routing contexts. It is tempting to do this by merely changing the RDs and RTs of their existing VRF. However, this approach is not possible because the other VPN site, connected to the same PE router, is sharing those VRFs.

Note When you enabled the backup link, you connected both CEx1A and CEx2A to PEx1.

Therefore, if you change the routing context of customer A on PEx1, you will affect both

CEx1A and CEx2A. This situation also holds true for CEx1B, CEx1B, and PEx2.

Sites CEx1A and CEx2B have to be migrated to new VRFs. All of the references to these sites must be removed from the existing routing protocol contexts.

In this task, you will remove the references to CEx1A and CEx2B.

Activity Procedure

Complete these steps:

Step 1 Remove the address family BGP neighbor relationship between CEx1A and CEx2Bon their respective PE routers.

Step 2 Check any other references to CEx1A and CEx2B in their PE router configurations and, if required, remove them.

Activity Verification

You have completed this task when you attain these results:

On the PE router, you have verified that the interface toward the CE router is no longer in the original VRF by using the show ip vrf interfaces command. This action should result in a printout similar to the one here:

Đۨďý­¸±© ·° Ş®ş ·˛¬»®şż˝»­

ײ¬»®şż˝» ×Đó߼Ľ®»­­ ĘÎÚ Đ®±¬±˝±´

Í»®·ż´đńđňďďí ďëđň¨ň¨ďňëđ Ý«­¬ß «°

Í»®·ż´đńđňďđî ďëđň¨ň¨ďňíě Ý«­¬Ţ «°

Đۨîý­¸±© ·° Ş®ş ·˛¬»®şż˝»­

ײ¬»®şż˝» ×Đó߼Ľ®»­­ ĘÎÚ Đ®±¬±˝±´

Í»®·ż´đńđňďđď ďëđň¨ň¨îňďč Ý«­¬ß «°

Í»®·ż´đńđňďďí ďëđň¨ň¨îňëđ Ý«­¬Ţ «°

Page 736: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 65

You have verified that the BGP neighbor relationship has been removed on the PE router with the show ip bgp vpnv4 vrf summary command. This action should give you a printout similar to the one here. Check the status of CEx1A and CEx2B in the printout.

Đۨďý­¸±© ·° ľą° Ş°˛Şě Ş®ş Ý«­¬ß ­«łłż®§

ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďçîňďęčň¨ňďéô ´±˝ż´ ßÍ ˛«łľ»® ęëđđď

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ íěô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ íě

ě ˛»¬©±®µ »˛¬®·»­ «­·˛ą čěé ľ§¬»­ ±ş ł»ł±®§

ďď °ż¬¸ »˛¬®·»­ «­·˛ą éđě ľ§¬»­ ±ş ł»ł±®§

é ŢŮĐ °ż¬¸ ż¬¬®·ľ«¬» »˛¬®·»­ «­·˛ą ďëđ𠾧¬»­ ±ş ł»ł±®§

ď ŢŮĐ ®®·˛ş± »˛¬®·»­ «­·˛ą îě ľ§¬»­ ±ş ł»ł±®§

î ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą ěč ľ§¬»­ ±ş ł»ł±®§

ě ŢŮĐ »¨¬»˛Ľ»Ľ ˝±łł«˛·¬§ »˛¬®·»­ «­·˛ą çę ľ§¬»­ ±ş ł»ł±®§

đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§

đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§

ŢŮĐ «­·˛ą îďíç ¬±¬ż´ ľ§¬»­ ±ş ł»ł±®§

ŢŮĐ ż˝¬·Ş·¬§ ëďńîç °®»ş·¨»­ô ęçńěí °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ďë ­»˝­

Ň»·ą¸ľ±® Ę ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ Ěľ´Ę»® ×˛Ď Ń«¬Ď Ë°ńܱ©˛ ͬż¬»ńĐş¨Î˝Ľ

ďëđň¨ň¨ďňěç ě ęëđ¨ď çéę çéç íě đ đ đđćîçćďî ě

Đۨîý­¸±© ·° ľą° Ş°˛Şě Ş®ş Ý«­¬Ţ ­«łłż®§

ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďçîňďęčň¨ňííô ´±˝ż´ ßÍ ˛«łľ»® ęëđđď

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ííô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ íí

ě ˛»¬©±®µ »˛¬®·»­ «­·˛ą ęđë ľ§¬»­ ±ş ł»ł±®§

é °ż¬¸ »˛¬®·»­ «­·˛ą ěěč ľ§¬»­ ±ş ł»ł±®§

é ŢŮĐ °ż¬¸ ż¬¬®·ľ«¬» »˛¬®·»­ «­·˛ą ďëđ𠾧¬»­ ±ş ł»ł±®§

ď ŢŮĐ ®®·˛ş± »˛¬®·»­ «­·˛ą îě ľ§¬»­ ±ş ł»ł±®§

î ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą ěč ľ§¬»­ ±ş ł»ł±®§

ě ŢŮĐ »¨¬»˛Ľ»Ľ ˝±łł«˛·¬§ »˛¬®·»­ «­·˛ą çę ľ§¬»­ ±ş ł»ł±®§

đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§

đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§

ŢŮĐ «­·˛ą ďęěî ¬±¬ż´ ľ§¬»­ ±ş ł»ł±®§

ŢŮĐ ż˝¬·Ş·¬§ ďîîńďđî °®»ş·¨»­ô ďęđńďíč °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ďë ­»˝­

Ň»·ą¸ľ±® Ę ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ Ěľ´Ę»® ×˛Ď Ń«¬Ď Ë°ńܱ©˛ ͬż¬»ńĐş¨Î˝Ľ

ďëđň¨ň¨îňěç ě ęëđ¨î ďěéé ďěéç íí đ đ đđćíđćîę î

Page 737: Implementing cisco mpls

66 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Task 3: Configure New VRFs for CEx1A and CEx2BIn this task, you will create the new VRFs for CEx1A and CEx2B.

Activity Procedure

Complete these steps:

Step 1 Create the new VRFs for CEx1A and CEx2B on their PE router with the ip vrf command.

Step 2 Assign new RDs to the newly created VRFs with the rd command.

Step 3 Assign proper import and export RTs to the newly created VRFs with the route-target command.

Step 4 Reestablish BGP routing between the PE routers and the CE routers. Please refer to Lab 5-4, “Running BGP Between PE and CE Routers,” if you need more details.

Activity Verification

You have completed this task when you attain these results:

On the PE router, you have verified that the interface toward the CE router is in the proper VRF by using the show ip vrf interfaces command. This action should result in a printout similar to the one here:

Đۨďý­¸±© ·° Ş®ş ·˛¬»®şż˝»­

ײ¬»®şż˝» ×Đó߼Ľ®»­­ ĘÎÚ Đ®±¬±˝±´

Í»®·ż´đńđňďďí ďëđň¨ň¨ďňëđ Ý«­¬ß «°

Í»®·ż´đńđňďđď ďëđň¨ň¨ďňďč Ý«­¬ßŢ «°

Í»®·ż´đńđňďđî ďëđň¨ň¨ďňíě Ý«­¬Ţ «°

Đۨîý­¸±© ·° Ş®ş ·˛¬»®şż˝»­

ײ¬»®şż˝» ×Đó߼Ľ®»­­ ĘÎÚ Đ®±¬±˝±´

Í»®·ż´đńđňďđď ďëđň¨ň¨îňďč Ý«­¬ß «°

Í»®·ż´đńđňďđî ďëđň¨ň¨îňíě Ý«­¬ßŢ «°

Í»®·ż´đńđňďďí ďëđň¨ň¨îňëđ Ý«­¬Ţ «°

You have verified the BGP neighbors on the PE router with the show ip bgp vpnv4 vrf summary command. This action should result in a printout similar to the one here. Check the status of CEx1A and CEx2B in the printout.

Đۨďý­¸±© ·° ľą° Ş°˛Şě Ş®ş Ý«­¬ßŢ ­«łłż®§

ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďçîňďęčň¨ňďéô ´±˝ż´ ßÍ ˛«łľ»® ęëđđď

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ěçô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ěç

ď𠲻¬©±®µ »˛¬®·»­ «­·˛ą ďîď𠾧¬»­ ±ş ł»ł±®§

ďđ °ż¬¸ »˛¬®·»­ «­·˛ą ęě𠾧¬»­ ±ş ł»ł±®§

č ŢŮĐ °ż¬¸ ż¬¬®·ľ«¬» »˛¬®·»­ «­·˛ą ěč𠾧¬»­ ±ş ł»ł±®§

î ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą ěč ľ§¬»­ ±ş ł»ł±®§

ě ŢŮĐ »¨¬»˛Ľ»Ľ ˝±łł«˛·¬§ »˛¬®·»­ «­·˛ą çę ľ§¬»­ ±ş ł»ł±®§

đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§

đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§

Page 738: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 67

ŢŮĐ «­·˛ą îěéě ¬±¬ż´ ľ§¬»­ ±ş ł»ł±®§

ŢŮĐ ż˝¬·Ş·¬§ ëéńíë °®»ş·¨»­ô éëńěç °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ďë ­»˝­

Ň»·ą¸ľ±® Ę ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ Ěľ´Ę»® ×˛Ď Ń«¬Ď Ë°ńܱ©˛ ͬż¬»ńĐş¨Î˝Ľ

ďëđň¨ň¨ďňďé ě ęëđ¨ď ëí ëě ěç đ đ đđćěčćěí í

Đۨîý­¸±© ·° ľą° Ş°˛Şě Ş®ş Ý«­¬ßŢ ­«łłż®§

ŢŮĐ ®±«¬»® ·Ľ»˛¬·ş·»® ďçîňďęčň¨ňííô ´±˝ż´ ßÍ ˛«łľ»® ęëđđď

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ëęô łż·˛ ®±«¬·˛ą ¬żľ´» Ş»®­·±˛ ëę

ď𠲻¬©±®µ »˛¬®·»­ «­·˛ą ďîď𠾧¬»­ ±ş ł»ł±®§

ďđ °ż¬¸ »˛¬®·»­ «­·˛ą ęě𠾧¬»­ ±ş ł»ł±®§

č ŢŮĐ °ż¬¸ ż¬¬®·ľ«¬» »˛¬®·»­ «­·˛ą ěč𠾧¬»­ ±ş ł»ł±®§

î ŢŮĐ ßÍóĐßĚŘ »˛¬®·»­ «­·˛ą ěč ľ§¬»­ ±ş ł»ł±®§

ě ŢŮĐ »¨¬»˛Ľ»Ľ ˝±łł«˛·¬§ »˛¬®·»­ «­·˛ą çę ľ§¬»­ ±ş ł»ł±®§

đ ŢŮĐ ®±«¬»ółż° ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§

đ ŢŮĐ ş·´¬»®ó´·­¬ ˝ż˝¸» »˛¬®·»­ «­·˛ą 𠾧¬»­ ±ş ł»ł±®§

ŢŮĐ «­·˛ą îđęč ¬±¬ż´ ľ§¬»­ ±ş ł»ł±®§

ŢŮĐ ż˝¬·Ş·¬§ ďíđńďďđ °®»ş·¨»­ô ďęčńďěę °ż¬¸­ô ­˝ż˛ ·˛¬»®Şż´ ďë ­»˝­

Ň»·ą¸ľ±® Ę ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ Ěľ´Ę»® ×˛Ď Ń«¬Ď Ë°ńܱ©˛ ͬż¬»ńĐş¨Î˝Ľ

ďëđň¨ň¨îňíí ě ęëđ¨î ç ďđ ëę đ đ đđćđěćďé í

You have checked the BGP routing table in the new VRF with the show ip bgp vpnv4 vrf command. You should see routes from CEx1A or CEx2B and routes imported from other VRFs. Use the AS path to work out which routes belong to which CE router. Routes announced by CEx1A should have 650x1 in the AS path, and routes announced by CEx2Bshould have 650x2 in the AS path.

Đۨďý­¸±© ·° ľą° Ş°˛Şě Ş®ş Ý«­¬ßŢ

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ěçô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčň¨ňďé

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćďď řĽ»şż«´¬ ş±® Ş®ş Ý«­¬ßŢ÷

öâ ďđňďň¨ďňďęńîč ďëđň¨ň¨ďňďé đ đ ęëđ¨ď á

öâ ďđňďň¨ďňěçńíî ďëđň¨ň¨ďňďé đ đ ęëđ¨ď á

öâ·ďđňďň¨îňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨ď á

öâ·ďđňďň¨îňěçńíî ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨î á

öâ·ďđňîň¨îňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨î á

öâ·ďđňîň¨îňěçńíî ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨ď á

®â ďëđň¨ň¨ďňďęńîč ďëđň¨ň¨ďňďé đ đ ęëđ¨ď á

öâ·ďëđň¨ň¨ďňěčńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨ď á

öâ·ďëđň¨ň¨îňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨ď á

öâ·ďëđň¨ň¨îňíîńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨î á

Page 739: Implementing cisco mpls

68 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Đۨîý­¸±© ·° ľą° Ş°˛Şě Ş®ş Ý«­¬ßŢ

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ çëô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčň¨ňíí

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćîď řĽ»şż«´¬ ş±® Ş®ş Ý«­¬ßŢ÷

öâ·ďđňďň¨ďňďęńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨ď á

öâ·ďđňďň¨ďňěçńíî ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨ď á

öâ·ďđňîň¨ďňďęńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

öâ·ďđňîň¨ďňěçńíî ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

öâ ďđňîň¨îňďęńîč ďëđň¨ň¨îňíí đ đ ęëđ¨î á

öâ ďđňîň¨îňěçńíî ďëđň¨ň¨îňíí đ đ ęëđ¨î á

öâ·ďëđň¨ň¨ďňďęńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨ď á

öâ·ďëđň¨ň¨ďňíîńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

®â ďëđň¨ň¨îňíîńîč ďëđň¨ň¨îňíí đ đ ęëđ¨î á

öâ·ďëđň¨ň¨îňěčńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

You have connected to CEx1A and performed ping and trace tests to the loopback address of CEx2B (or vice versa). The other router should be reachable. For subgroup B, perform the test in the other direction.

Ýۨďßý°·˛ą ďđňîň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňîň¨îňěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďěčńďěčńďěç ł­

Ýۨďßý¬®ż˝» ďđňîň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďđňîň¨îňěç

ď ďëđň¨ň¨ďňďč ďę ł­»˝ ďę ł­»˝ ďî ł­»˝

î ďëđň¨ň¨îňíě ĹßÍ ęëđ¨îĂ ĹÓĐÔÍć Ôżľ»´ ďé ۨ° đĂ ďďę ł­»˝ ďďę ł­»˝ ďďę ł­»˝

í ďëđň¨ň¨îňíí ĹßÍ ęëđ¨îĂ éî ł­»˝ éé ł­»˝ ö

From CEx1A, perform a ping test to the loopback address of CEx1B (or vice versa). The other router should not be reachable.

Ýۨďßý°·˛ą ďđňîň¨ďňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňîň¨ďňěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

ňňňňň

Í«˝˝»­­ ®ż¬» ·­ đ °»®˝»˛¬ řđńë÷

Page 740: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 69

Connect to CEx2A and try to ping CEx2B or CEx1B. Those routers should not be reachable from CEx2A.

Ýۨîßý°·˛ą ďđňîň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňîň¨îňěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

ňňňňň

Í«˝˝»­­ ®ż¬» ·­ đ °»®˝»˛¬ řđńë÷

Ýۨîßý°·˛ą ďđňîň¨ďňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňîň¨ďňěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

ňňňňň

Í«˝˝»­­ ®ż¬» ·­ đ °»®˝»˛¬ řđńë÷

Page 741: Implementing cisco mpls

70 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 6-2: Merging Service Providers Complete this lab activity to practice what you learned in the related module.

Activity Objective Your small service provider is merging with several other small service providers. To accomplish this consolidation, a new central P router (P1) has been installed and configured. Frame Relay connectivity has been provided from each local Px1 and Px2 router to P1. In addition, the core IGP is being converted from EIGRP to IS-IS.

In this activity, you will merge your small service provider with several other small service providers. After completing this activity, you will be able to meet these objectives:

Establish connectivity with the central P1 router

Convert the core IGP from EIGRP to IS-IS

Enable MPLS LDP connectivity with the central P router

Enable IBGP connectivity between all PE routers

Visual Objective You will configure your PE router, and the directly connected P router. P1 has been preconfigured.

The figure illustrates what you will accomplish in this activity.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—14

MPLS Lab: Merging Service Providers

Page 742: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 71

Required Resources This is the resource that is required to complete this activity:

Cisco IOS documentation

Command List The table describes the commands that are used in this activity.

Commands for Merging Service Providers

Command Description

®±«¬»® ·­·­ ż®»żó¬żą To enable the IS-IS routing protocol and to specify an IS-IS process, use the router isis command in global configuration mode. To disable IS-IS routing, use the no form of this command.

˛»¬ ˛»¬©±®µó»˛¬·¬§ó¬·¬´»

To configure an IS-IS network entity title (NET) for a Connectionless Network Service (CLNS) routing process, use the net command in router configuration mode. To remove a NET, use the no form of this command.

·­·­ ˝·®˝«·¬ó¬§°» Ą´»Ş»´óď ¤ ´»Ş»´óďóî ¤ ´»Ş»´óî󱲴§Ł

To configure the type of adjacency, use the isis circuit-typeinterface configuration command. To reset the circuit type to Level l and Level 2, use the no form of this command.

ł»¬®·˝ó­¬§´» ©·Ľ» Ŭ®ż˛­·¬·±˛Ă Ĺ´»Ş»´óď ¤ ´»Ş»´óî ¤ ´»Ş»´óďóîĂ

To configure a router running IS-IS so that it generates and accepts only new-style type, TLV objects, use the metric-style wide command in router configuration mode. To disable this function, use the no form of this command.

Task 1: Enable Connectivity with the Central P Router In this task, you will enable the Frame Relay link between your P routers and P1, and then enable LDP connectivity between the two routers.

Activity Procedure

Complete these steps:

Step 1 Configure IP addresses and DLCIs on your P router on the interface to P1 using the parameters in the table.

Note The parameters are configured on the P routers of the SP and not the PE routers.

IP Address and DLCI Configuration Parameters

Router Subinterface DLCI IP Address

P31 S0/0.231 231 192.168.100.10/29

P32 S0/0.232 232 192.168.100.18/29

P41 S0/0.241 241 192.168.100.26/29

P42 S0/0.242 242 192.168.100.34/29

Page 743: Implementing cisco mpls

72 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Router Subinterface DLCI IP Address

P51 S0/0.251 251 192.168.100.42/29

P52 S0/0.252 252 192.168.100.50/29

P61 S0/0.261 261 192.168.100.58/29

P62 S0/0.262 262 192.168.100.66/29

Activity Verification

You have completed this task when you attain this result:

On your P router, you have used the show interface command to verify that the new interfaces are operational.

Task 2: Migrate the Core to IS-IS Because a link-state protocol is more scalable than a distance vector protocol, the service provider has decided to migrate the core to IS-IS. The P1 router has already been migrated. Your POP is responsible for the migration of all of your assigned routers. Workgroup x1 will migrate PEx1 and Px1. Workgroup x2 will migrate PEx2 and Px2.

Activity Procedure

Complete these steps:

Step 1 Disable EIGRP as the core IGP on your assigned routers.

Step 2 Enable IS-IS as the core IGP using the parameters detailed in the table.

IS-IS Parameters

Router ID NET Remarks

PEx1 net 49.0001.0000.0000.01x1.00 Where x = the SP number

PEx2 net 49.0001.0000.0000.01x2.00

Px1 net 49.0001.0000.0000.02x1.00

Px2 net 49.0001.0000.0000.02x2.00

Note Ensure that the metric-style command is set to wide, the is-type command is set to level-

2-only, and IS-IS has been enabled on the active serial interfaces that are supporting the

core MPLS.

Page 744: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 73

Activity Verification

You have completed this task when you attain these results:

You have used the show ip protocols command to verify that IS-IS is active and enabled on all appropriate interfaces on the PE routers.

Đۨďý­¸±© ·° °®±¬±˝±´­

᫬·˛ą Đ®±¬±˝±´ ·­ ţľą° ęëđđďţ

Ń«¬ą±·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬

ײ˝±ł·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬

×ŮĐ ­§˛˝¸®±˛·¦ż¬·±˛ ·­ Ľ·­żľ´»Ľ

ß«¬±łż¬·˝ ®±«¬» ­«łłż®·¦ż¬·±˛ ·­ Ľ·­żľ´»Ľ

Ň»·ą¸ľ±®ř­÷ć

߼Ľ®»­­ Ú·´¬×˛ Ú·´¬Ń«¬ Ü·­¬×˛ Ü·­¬Ń«¬ É»·ą¸¬ ᫬»Óż°

ďçîňďęčň¨ňíí

Óż¨·ł«ł °ż¬¸ć ď

᫬·˛ą ײş±®łż¬·±˛ ͱ«®˝»­ć

Ůż¬»©ż§ Ü·­¬ż˛˝» Ôż­¬ Ë°Ľż¬»

Ü·­¬ż˛˝»ć »¨¬»®˛ż´ îđ ·˛¬»®˛ż´ îđđ ´±˝ż´ îđđ

᫬·˛ą Đ®±¬±˝±´ ·­ ţ·­·­ţ

×˛Şż´·Ľ żş¬»® đ ­»˝±˛Ľ­ô ¸±´Ľ Ľ±©˛ đô ş´«­¸»Ľ żş¬»® đ

Ń«¬ą±·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬

ײ˝±ł·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬

λĽ·­¬®·ľ«¬·˛ąć ·­·­

߼Ľ®»­­ Í«łłż®·¦ż¬·±˛ć

ұ˛»

Óż¨·ł«ł °ż¬¸ć ě

᫬·˛ą ş±® Ň»¬©±®µ­ć

Í»®·ż´đńđňďďď

Ô±±°ľż˝µđ

᫬·˛ą ײş±®łż¬·±˛ ͱ«®˝»­ć

Ůż¬»©ż§ Ü·­¬ż˛˝» Ôż­¬ Ë°Ľż¬»

ďçîňďęčň¨ňçé ďďë đđćđčćíî

ďçîňďęčň§ňçé ďďë đđćđčćíî

ďçîňďęčň¨ňčď ďďë đđćđčćîî

ďçîňďęčň§ňčď ďďë đđćđčćíî

ďçîňďęčň¨ňíí ďďë đđćđčćîî

ďçîňďęčň§ňíí ďďë đđćđčćíî

ďçîňďęčň§ňďé ďďë đđćđčćíî

ďçîňďęčňďđđňďîç ďďë đđćđčćíî

Ü·­¬ż˛˝»ć řĽ»şż«´¬ ·­ ďďë÷

Note The IS-IS gateways should show the loopback addresses of the PE and P routers. In these

results, x is your SP number, and y is the number of the other SP.

Depending on how far along the other SP is in configuring its devices, you may not see the y

routes.

Page 745: Implementing cisco mpls

74 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

You have used the show ip route command on the PE routers to verify that all routers are sending and receiving the appropriate prefixes.

Đۨďý­¸±© ·° ®±«¬»

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óîô ·ż ó ×Íó×Í ·˛¬»® ż®»ż

ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»ô ± ó ŃÜÎ

Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďçîňďęčň§ňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­

· Ôî ďçîňďęčň§ňçéńíî ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňďďîńîč ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňęěńîč ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňčďńíî ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňííńíî ĹďďëńëđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňěčńîč ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňďéńíî ĹďďëńëđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

ďçîňďęčňďđđňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ô î łż­µ­

· Ôî ďçîňďęčňďđđňčńîç ĹďďëńîđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčňďđđňîěńîç ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčňďđđňďęńîç ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčňďđđňíîńîç ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčňďđđňďîçńíî ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

ďçîňďęčň¨ňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­

· Ôî ďçîňďęčň¨ňçéńíî ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň¨ňďďîńîč ĹďďëńîđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň¨ňęěńîč ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň¨ňčďńíî ĹďďëńîđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň¨ňííńíî ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

Ý ďçîňďęčň¨ňěčńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďď

Ý ďçîňďęčň¨ňďéńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

Note In these results, x is your SP number, and y is the number of the other SP.

Depending on how far along the other SP is in configuring its devices, you may not see the y

routes.

Page 746: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 75

You have used the show ip protocols command to verify that IS-IS is active and enabled on all appropriate interfaces on the P routers.

Шďý­¸±© ·° °®±¬±˝±´­

᫬·˛ą Đ®±¬±˝±´ ·­ ţ·­·­ţ

×˛Şż´·Ľ żş¬»® đ ­»˝±˛Ľ­ô ¸±´Ľ Ľ±©˛ đô ş´«­¸»Ľ żş¬»® đ

Ń«¬ą±·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬

ײ˝±ł·˛ą «°Ľż¬» ş·´¬»® ´·­¬ ş±® ż´´ ·˛¬»®şż˝»­ ·­ ˛±¬ ­»¬

λĽ·­¬®·ľ«¬·˛ąć ·­·­

߼Ľ®»­­ Í«łłż®·¦ż¬·±˛ć

ұ˛»

Óż¨·ł«ł °ż¬¸ć ě

᫬·˛ą ş±® Ň»¬©±®µ­ć

Í»®·ż´đńđňďďď

Í»®·ż´đńđňďďî

Í»®·ż´đńđňî¨ď

Ô±±°ľż˝µđ

᫬·˛ą ײş±®łż¬·±˛ ͱ«®˝»­ć

Ůż¬»©ż§ Ü·­¬ż˛˝» Ôż­¬ Ë°Ľż¬»

ďçîňďęčň¨ňçé ďďë đđćđđćëç

ďçîňďęčň§ňçé ďďë đđćďîćđé

ďçîňďęčň§ňčď ďďë đđćďěćíę

ďçîňďęčň¨ňíí ďďë đđćďđćđě

ďçîňďęčň§ňíí ďďë đđćďîćđé

ďçîňďęčň¨ňďé ďďë đđćđđćëç

ďçîňďęčň§ňďé ďďë đđćďîćďé

ďçîňďęčňďđđňďîç ďďë đđćđđćëç

Ü·­¬ż˛˝»ć řĽ»şż«´¬ ·­ ďďë÷

Note In these results, x is your SP number, and y is the number of the other SP.

You have used the show ip route command on the P routers to verify that all routers are sending and receiving the appropriate prefixes.

Шďý­¸±© ·° ®±«¬»

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óîô ·ż ó ×Íó×Í ·˛¬»® ż®»ż

ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»ô ± ó ŃÜÎ

Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďçîňďęčň§ňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­

· Ôî ďçîňďęčň§ňçéńíî ĹďďëńíđĂ Ş·ż ďçîňďęčňďđđňçô Í»®·ż´đńđňîíď

· Ôî ďçîňďęčň§ňďďîńîč ĹďďëńíđĂ Ş·ż ďçîňďęčňďđđňçô Í»®·ż´đńđňîíď

Page 747: Implementing cisco mpls

76 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

· Ôî ďçîňďęčň§ňęěńîč ĹďďëńíđĂ Ş·ż ďçîňďęčňďđđňçô Í»®·ż´đńđňîíď

· Ôî ďçîňďęčň§ňčďńíî ĹďďëńíđĂ Ş·ż ďçîňďęčňďđđňçô Í»®·ż´đńđňîíď

· Ôî ďçîňďęčň§ňííńíî ĹďďëńěđĂ Ş·ż ďçîňďęčňďđđňçô Í»®·ż´đńđňîíď

· Ôî ďçîňďęčň§ňěčńîč ĹďďëńíđĂ Ş·ż ďçîňďęčňďđđňçô Í»®·ż´đńđňîíď

· Ôî ďçîňďęčň§ňďéńíî ĹďďëńěđĂ Ş·ż ďçîňďęčňďđđňçô Í»®·ż´đńđňîíď

ďçîňďęčňďđđňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ô î łż­µ­

Ý ďçîňďęčňďđđňčńîç ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňîíď

· Ôî ďçîňďęčňďđđňîěńîç ĹďďëńîđĂ Ş·ż ďçîňďęčňďđđňçô Í»®·ż´đńđňî¨ď

· Ôî ďçîňďęčňďđđňďęńîç ĹďďëńîđĂ Ş·ż ďçîňďęčňďđđňçô Í»®·ż´đńđňî¨ď

ĹďďëńîđĂ Ş·ż ďçîňďęčň¨ňďďěô Í»®·ż´đńđňďďî

· Ôî ďçîňďęčňďđđňíîńîç ĹďďëńîđĂ Ş·ż ďçîňďęčňďđđňçô Í»®·ż´đńđňî¨ď

· Ôî ďçîňďęčňďđđňďîçńíî ĹďďëńîđĂ Ş·ż ďçîňďęčňďđđňçô Í»®·ż´đńđňî¨ď

ďçîňďęčň¨ňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­

· Ôî ďçîňďęčň¨ňçéńíî ĹďďëńîđĂ Ş·ż ďçîňďęčň¨ňďďěô Í»®·ż´đńđňďďî

Ý ďçîňďęčň¨ňďďîńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďî

· Ôî ďçîňďęčň¨ňęěńîč ĹďďëńîđĂ Ş·ż ďçîňďęčň¨ňďďěô Í»®·ż´đńđňďďî

Ý ďçîňďęčň¨ňčďńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

· Ôî ďçîňďęčň¨ňííńíî ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňďďěô Í»®·ż´đńđňďďî

Ý ďçîňďęčň¨ňěčńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň¨ňďéńíî ĹďďëńîđĂ Ş·ż ďçîňďęčň¨ňěçô Í»®·ż´đńđňďďď

Note In these results, x is your SP number, and y is the number of the other SP.

Task 3: Enable MPLS LDP Connectivity with the Central P Router

In this task you will enable LDP connectivity between your routers and P1.

Activity Procedure

Complete this step:

Step 1 Enable LDP on the subinterface that you have created on Px1 or Px2 router.

Activity Verification

You have completed this task when you attain these results:

On your P router, you have verified that an LDP neighbor relationship has been established between your P router and P1.

Шďý­¸±© ł°´­ ´Ľ° ˛»·ą¸ľ±®

Đ»»® ÔÜР׼»˛¬ć ďçîňďęčň¨ňďéćđĺ Ô±˝ż´ ÔÜР׼»˛¬ ďçîňďęčň¨ňčďćđ

ĚÝĐ ˝±˛˛»˝¬·±˛ć ďçîňďęčň¨ňďéňęěę ó ďçîňďęčň¨ňčďňěěčéë

ͬż¬»ć Ń°»®ĺ Ó­ą­ ­»˛¬ń®˝ŞĽć ďíëńďíđĺ ܱ©˛­¬®»żł

Ë° ¬·ł»ć đďćíęćđí

ÔÜĐ Ľ·­˝±Ş»®§ ­±«®˝»­ć

Í»®·ż´đńđňďďďô Í®˝ ×Đ żĽĽ®ć ďçîňďęčň¨ňěç

߼Ľ®»­­»­ ľ±«˛Ľ ¬± °»»® ÔÜР׼»˛¬ć

Page 748: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 77

ďçîňďęčň¨ňďé ďçîňďęčň¨ňěç

Đ»»® ÔÜР׼»˛¬ć ďçîňďęčň¨ňçéćđĺ Ô±˝ż´ ÔÜР׼»˛¬ ďçîňďęčň¨ňčďćđ

ĚÝĐ ˝±˛˛»˝¬·±˛ć ďçîňďęčň¨ňçéňëěěëď ó ďçîňďęčň¨ňčďňęěę

ͬż¬»ć Ń°»®ĺ Ó­ą­ ­»˛¬ń®˝ŞĽć ďíęńďíęĺ ܱ©˛­¬®»żł

Ë° ¬·ł»ć đďćíęćđí

ÔÜĐ Ľ·­˝±Ş»®§ ­±«®˝»­ć

Í»®·ż´đńđňďďîô Í®˝ ×Đ żĽĽ®ć ďçîňďęčň¨ňďďě

߼Ľ®»­­»­ ľ±«˛Ľ ¬± °»»® ÔÜР׼»˛¬ć

ďçîňďęčň¨ňçé ďçîňďęčň¨ňęę ďçîňďęčň¨ňďďě ďçîňďęčňďđđňíě

Đ»»® ÔÜР׼»˛¬ć ďçîňďęčňďđđňďîçćđĺ Ô±˝ż´ ÔÜР׼»˛¬ ďçîňďęčň¨ňčďćđ

ĚÝĐ ˝±˛˛»˝¬·±˛ć ďçîňďęčňďđđňďîçňíęëěé ó ďçîňďęčň¨ňčďňęěę

ͬż¬»ć Ń°»®ĺ Ó­ą­ ­»˛¬ń®˝ŞĽć îěńíđĺ ܱ©˛­¬®»żł

Ë° ¬·ł»ć đđćđîćîë

ÔÜĐ Ľ·­˝±Ş»®§ ­±«®˝»­ć

Í»®·ż´đńđňî¨ďô Í®˝ ×Đ żĽĽ®ć ďçîňďęčňďđđňîë

߼Ľ®»­­»­ ľ±«˛Ľ ¬± °»»® ÔÜР׼»˛¬ć

ďçîňďęčňďđđňďîç îđďňîđîňîđňď îđďňîđîňîďňď îđďňîđîňîîňď

îđďňîđîňîíňď îđďňîđîňîěňď îđďňîđîňîëňď ďçîňďęčňďđđňç

ďçîňďęčňďđđňďé ďçîňďęčňďđđňîë ďçîňďęčňďđđňíí

On your PE router, you have verified that labels are being received from the other POPs.

Đۨďý­¸±© ł°´­ ş±®©ż®Ľ·˛ąó¬żľ´»

Ô±˝ż´ Ń«¬ą±·˛ą Đ®»ş·¨ ާ¬»­ ¬żą Ń«¬ą±·˛ą Ň»¨¬ ر°

¬żą ¬żą ±® ĘÝ ±® Ě«˛˛»´ ׼ ­©·¬˝¸»Ľ ·˛¬»®şż˝»

ďč б° ¬żą ďçîňďęčňďđđňčńîç đ Í»đńđňďďď °±·˛¬î°±·˛¬

ďç б° ¬żą ďçîňďęčň¨ňďďîńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

îđ б° ¬żą ďçîňďęčň¨ňčďńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

îď ďč ďçîňďęčňďđđňďęńîç đ Í»đńđňďďď °±·˛¬î°±·˛¬

îî îđ ďçîňďęčň¨ňçéńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

îë ďç ďçîňďęčň¨ňęěńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

îę ďé ďçîňďęčňďđđňîěńîç đ Í»đńđňďďď °±·˛¬î°±·˛¬

îé îî ďçîňďęčňďđđňíîńîç đ Í»đńđňďďď °±·˛¬î°±·˛¬

îč îí ďçîňďęčňďđđňďîçńíî Ä

đ Í»đńđňďďď °±·˛¬î°±·˛¬

îç ˲¬żąą»Ľ ďđňďň¨ďňďęńîčĹĘĂ đ Í»đńđňďđď °±·˛¬î°±·˛¬

íđ ˲¬żąą»Ľ ďđňďň¨ďňěçńíîĹĘĂ đ Í»đńđňďđď °±·˛¬î°±·˛¬

íď ßąą®»ąż¬» ďëđň¨ň¨ďňďęńîčĹĘĂ ëîđ

íî ˲¬żąą»Ľ ďđňîň¨ďňďęńîčĹĘĂ đ Í»đńđňďđî °±·˛¬î°±·˛¬

íí ďę ďçîňďęčň§ňďďîńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

íě îď ďçîňďęčň§ňčďńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

íë îě ďçîňďęčň§ňěčńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

íę ˲¬żąą»Ľ ďđňîň¨ďňěçńíîĹĘĂ đ Í»đńđňďđî °±·˛¬î°±·˛¬

íé ßąą®»ąż¬» ďëđň¨ň¨ďňíîńîčĹĘĂ đ

íč ˲¬żąą»Ľ ďëđň¨ň¨îňěčńîčĹĘĂ đ Í»đńđňďđî °±·˛¬î°±·˛¬

íç îë ďçîňďęčň§ňçéńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

ěđ îę ďçîňďęčň§ňęěńîč đ Í»đńđňďďď °±·˛¬î°±·˛¬

ěď îé ďçîňďęčň§ňííńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

Page 749: Implementing cisco mpls

78 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

ěî îč ďçîňďęčň§ňďéńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

ěí íđ ďçîňďęčň¨ňííńíî đ Í»đńđňďďď °±·˛¬î°±·˛¬

Note In these results, x is your SP number, and y is the number of the other SP. The “[V]”

indicates a VPN prefix.

Task 4: Enable IBGP Connectivity for All PE Routers At this point, you have established LDP connectivity for all of the PE and P routers in your new service provider environment, but you have not yet established BGP connectivity. You now need to establish IBGP connectivity for your PE routers.

There are two methods that you can implement. The first is to use the bgp neighbor command to add a neighbor relationship between each of the routers, but this approach would entail a substantial configuration effort.

The second method is to implement route reflectors. To this end, P1 has been configured as a BGP route reflector. However, to take advantage of this fact, you will need to remove the neighbor relationship between your two PE routers and make them neighbors of P1.

Note The loopback address for P1 is 192.168.100.129 with AS 65001. Ensure that your update

source is also your loopback interface.

Workgroup x1 will configure PEx1, and Workgroup x2 will configure PEx2.

Activity Procedure

Complete these steps:

Step 1 Remove the neighbor relationship between your PE router and the PE router in your remote POP.

Step 2 Configure your PE router as a neighbor of P1.

What routes do you expect to see in VRF CustA?

What routes do you expect to see in VRF CustB?

What routes do you expect to see in VRF CustAB?

Activity Verification

You have completed this task when you attain these results:

Page 750: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 79

On your PE routers, you have checked BGP connectivity to all POPs with the show ip bgp summary and show ip bgp neighbor commands on CE routers.

Đۨďý­¸±© ·° ľą° ­«łłż®§

Ň»·ą¸ľ±® Ę ßÍ Ó­ąÎ˝ŞĽ Ó­ąÍ»˛¬ Ěľ´Ę»® ×˛Ď Ń«¬Ď Ë°ńܱ©˛ ͬż¬»ńĐş¨Î˝Ľ

ďçîňďęčňďđđňďîç ě ęëđđď ďč ďę ě đ đ đđćđěćîę ď

You have verified the per-VRF BGP table for your customer on your PE routers with the show ip bgp vpnv4 vrf command. You should still see that the BGP routes coming from the CE routers are being selected as the best routes for those destinations.

Đۨďý­¸±© ·° ľą° Ş°˛Şě Ş®ş Ý«­¬ß

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďçčô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčň¨ňďé

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

᫬» Ü·­¬·˛ą«·­¸»®ć ďćďđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬ß÷

öâ ďđňďň¨ďňďęńîč ďëđň¨ň¨ďňďé đ đ ęëđ¨ď á

öâ ďđňďň¨ďňěçńíî ďëđň¨ň¨ďňďé đ đ ęëđ¨ď á

öâ·ďđňďň¨îňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨ď á

ö ďëđň¨ň¨ďňěç îđđ đ ęëđ¨ď á

öâ·ďđňďň¨îňěçńíî ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨ď á

ö ďëđň¨ň¨ďňěç îđđ đ ęëđ¨ď á

öâ ďëđň¨ň¨ďňďęńîč ďëđň¨ň¨ďňďé đ đ ęëđ¨ď á

®â·ďëđň¨ň¨ďňěčńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨ď á

® ďëđň¨ň¨ďňěç îđđ đ ęëđ¨ď á

öâ·ďëđň¨ň¨îňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđ¨ď á

ö ďëđň¨ň¨ďňěç îđđ đ ęëđ¨ď á

Đۨîý­¸ ·° ľą° Ş° Ş®ş Ý«­¬Ţ

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ íčô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčň¨ňíí

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćîđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬Ţ÷

öâ ďđňîň¨îňďęńîč ďëđň¨ň¨îňíí đ đ ęëđ¨î á

öâ ďđňîň¨îňěçńíî ďëđň¨ň¨îňíí đ đ ęëđ¨î á

öâ·ďđňîň¨ďňďęńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

ö ďëđň¨ň¨îňěç îđđ đ ęëđ¨î á

öâ·ďđňîň¨ďňěçńíî ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

ö ďëđň¨ň¨îňěç îđđ đ ęëđ¨î á

Page 751: Implementing cisco mpls

80 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

â ďëđň¨ň¨îňíîńîč ďëđň¨ň¨îňíí đ đ ęëđ¨î á

®â·ďëđň¨ň¨îňěčńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

® ďëđň¨ň¨îňěç îđđ đ ęëđ¨î á

öâ·ďëđň¨ň¨ďňíîńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđ¨î á

ö ďëđň¨ň¨îňěç îđđ đ ęëđ¨î á

ĐŰëîâ

You have verified the per-VRF table for your customer on your PE routers with the showip route vrf command. You should still see only the routes coming from the CE routers being selected.

Đۨďý­¸±© ·° ®±«¬» Ş®ş Ý«­¬ß

᫬·˛ą Ěżľ´»ć Ý«­¬ß

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óîô ·ż ó ×Íó×Í ·˛¬»® ż®»ż

ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»ô ± ó ŃÜÎ

Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­

Ţ ďđňďň¨ďňďęńîč ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňďé řÝ«­¬ßŢ÷ô đěćëďćđď

Ţ ďđňďň¨îňďęńîč ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćîéćěî

Ţ ďđňďň¨ďňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňďé řÝ«­¬ßŢ÷ô đěćëďćđď

Ţ ďđňďň¨îňěçńíî ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćîéćěî

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­

Ţ ďëđň¨ň¨îňďę ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćîéćěî

Ţ ďëđň¨ň¨ďňďę ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňďé řÝ«­¬ßŢ÷ô đěćëďćđď

Ý ďëđň¨ň¨ďňěč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďí

Đۨďý­¸±© ·° ®±«¬» Ş®ş Ý«­¬Ţ

᫬·˛ą Ěżľ´»ć Ý«­¬Ţ

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óîô ·ż ó ×Íó×Í ·˛¬»® ż®»ż

ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»ô ± ó ŃÜÎ

Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­ô î łż­µ­

Page 752: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 81

Ţ ďđňîň¨ďňďęńîč ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňííô đëćëíćíč

Ţ ďđňîň¨îňďęńîč ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćíđćëč

Ţ ďđňîň¨ďňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňííô đëćëíćďď

Ţ ďđňîň¨îňěçńíî ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćíđćëč

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô í ­«ľ˛»¬­

Ţ ďëđň¨ň¨îňěč ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňííô đëćëíćďď

Ţ ďëđň¨ň¨îňíî ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćíđćëč

Ý ďëđň¨ň¨ďňíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđî

Đۨďý­¸±© ·° ®±«¬» Ş®ş Ý«­¬ßŢ

᫬·˛ą Ěżľ´»ć Ý«­¬ßŢ

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî

·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»

± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ę ­«ľ˛»¬­ô î łż­µ­

Ţ ďđňďň¨ďňďęńîč ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňďéô đíćđđćđđ

Ţ ďđňîň¨îňěçńíî ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćďíćěę

Ţ ďđňďň¨îňěçńíî ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćďíćěę

Ţ ďđňďň¨ďňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňďéô đíćđđćđđ

Ţ ďđňîň¨îňďęńîč ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćďíćěę

Ţ ďđňďň¨îňďęńîč ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćďíćěę

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­

Ţ ďëđň¨ň¨îňíî ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćďíćěé

Ý ďëđň¨ň¨ďňďę ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđď

Ţ ďëđň¨ň¨îňďę ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćďíćěé

Ţ ďëđň¨ň¨ďňěč ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćďíćěč

Đۨďý

Page 753: Implementing cisco mpls

82 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 6-3: Establishing a Common Services VPN The new MPLS VPN infrastructure can be used to implement a new approach to managed CE router services, where the central NMS can monitor all CE routers through a dedicated VPN.

The NMS VPN should provide connectivity only between the NMS and a single IP address on the CE router that is used for network management purposes.

In this activity, your SP has established a network management center using a VPN between the loopback interfaces of the CE routers and the NMS router. You will establish connectivity only between the NMS and the CE router loopback interfaces with a /32 subnet mask.

Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will establish a network management VPN between the loopback interfaces of the CE routers and the NMS router. After completing this activity, you will be able to meet these objectives:

Implement a network management VPN between the management VRF and customer VRFs by configuring proper RTs

Visual Objective The figure illustrates what you will accomplish in this activity.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—15

MPLS Lab: Managed Services

• PE NMS can reach all CE Lo0.• Each CE Lo0 can reach

PE NMS.• NMS VRF does not support

CE Lo0 to CE Lo0.

Note The NMS router is simulated by a loopback on the P1 router.

Page 754: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 83

Required Resources This is the resource that is required to complete this activity:

Cisco IOS documentation

Command List The table describes the commands that are used in this activity.

Network Management VPN Commands

Command Description

»¨°±®¬ łż° ˛żł» Specifies a VRF export route map

®±«¬»ółż° ˛żł» °»®ł·¬ ­»Ż

Creates a route map entry

­»¬ »¨¬˝±łł«˛·¬§ ®¬ Şż´«» żĽĽ·¬·Ş»

Appends the specified RT to a route matched with the match command

Task 1: Establish Connectivity Between the NMS VRF and Other VRFs

The network management VPN is a common services VPN. Therefore, two RTs are needed for the VPN: the server RT and the client RT. On the PE router supporting the NMS, a VRF for the network management VPN and associated RD are also needed. Here are the relevant parts of the configuration on the NMS PE router:

Note This configuration resides on the P1 router, which in this exercise is simulating the central

service PE router.

˙ Ý®»ż¬» ¬¸» ŇÓÍ ĘÎÚ

˙

·° Ş®ş ŇÓÍ

®Ľ ďđďćëđđ

®±«¬»ó¬ż®ą»¬ »¨°±®¬ ďđďćëđđ

®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ďđďćëđđ

®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ďđďćëđď

Note You will need to configure the VRF of your customer only on the local PE router to match the

RT used by the NMS VPN.

To establish connectivity between the NMS VRF and the customer VRF, you must attach the client RT to the CE router loopback addresses when the routes are exported from the customer VRF. You also need to import routes from the NMS router into all customer VRFs.

Page 755: Implementing cisco mpls

84 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Activity Procedure

Complete these steps:

Step 1 Create an IP access list that will match the CE router loopback addresses.

Step 2 Create a route map that will match the CE router loopback addresses with the access list and append the client RT to those routes.

Step 3 Apply the route map to routes exported from the customer VRF with the export map command.

Step 4 Import NMS routes into the customer VRF by specifying the proper import RT.

What routes do you expect to see in VRF CustA on your PE?

What routes do you expect to see in VRF NMS on your PE?

What routes do you expect to see in VRF NMS on P1?

Activity Verification

You have completed this task when you attain these results:

You have verified that the proper RTs are appended to the routes toward the CE router loopback addresses by using the show ip bgp vpnv4 vrf name prefix command. This action should result in a printout similar to this example:

Đۨďý­¸±© ·° ľą° Ş°˛Şě Ş®ş Ý«­¬ß ďđňďň¨ďňěç

ŢŮĐ ®±«¬·˛ą ¬żľ´» »˛¬®§ ş±® ďćďđćďđňďň¨ďňěçńíîô Ş»®­·±˛ ěę

Đż¬¸­ć řď żŞż·´żľ´»ô ľ»­¬ ýďô ¬żľ´» Ý«­¬ß÷

ßĽŞ»®¬·­»Ľ ¬± ˛±˛ °»»®óą®±«° °»»®­ć

ďëđň¨ň¨ďňěç

ęëđ¨ďô ·ł°±®¬»Ľ °ż¬¸ ş®±ł ¨ćďďćďđňďň¨ďňěçńíî

ďëđň¨ň¨ďňďé ş®±ł ďëđň¨ň¨ďňďé řďđňďň¨ďňěç÷

Ń®·ą·˛ ·˛˝±ł°´»¬»ô ł»¬®·˝ đô ´±˝ż´°®»ş ďđđô Şż´·Ľô »¨¬»®˛ż´ô ľ»­¬

ۨ¬»˛Ľ»Ľ ݱłł«˛·¬§ć ÎĚć¨ćďđ ÎĚć¨ćďđđď ÎĚćďđďćëđď

Note If after a few minutes you do not see RT:101:501 in the extended community list on the PE

router, you may need to use the clear ip bgp * command to reset the BGP session.

Page 756: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 85

You have verified that the proper routes are in the VRF CustA on your PE router. You should now see the simulated NMS address and the prefixes for your CustA routes.

Đۨďý­¸±© ·° ľą° Ş° Ş®ş Ý«­¬ß

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ éěô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčňíňďé

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

᫬» Ü·­¬·˛ą«·­¸»®ć íćďđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬ß÷

öâ ďđňďň¨ďňďęńîč ďëđň¨ň¨ďňďé đ đ ęëđíď á

öâ ďđňďň¨ďňěçńíî ďëđň¨ň¨ďňďé đ đ ęëđíď á

öâ·ďđňďň¨îňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđíď á

ö ďëđň¨ň¨ďňěç îđđ đ ęëđíď á

öâ·ďđňďň¨îňěçńíî ďçîňďęčň¨ňíí đ ďđđ đ ęëđíď á

ö ďëđň¨ň¨ďňěç îđđ đ ęëđíď á

öâ·ďđňďđňďđňěçńíî ďçîňďęčňďđđňďîç đ ďđđ đ á

öâ ďëđň¨ň¨ďňďęńîč ďëđň¨ň¨ďňďé đ đ ęëđíď á

®â·ďëđň¨ň¨ďňěčńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđíď á

® ďëđň¨ň¨ďňěç îđđ đ ęëđíď á

öâ·ďëđň¨ň¨îňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđíď á

ö ďëđň¨ň¨ďňěç îđđ đ ęëđíď á

Đۨďý

You have verified that no routes are in the VRF NMS on your PE router. You should not see any routes because you do not have interfaces in that VRF, and the VRF is not configured on your router.

Đۨďý­¸±© ·° ľą° Ş° Ş®ş ŇÓÍ

Đۨďý

Đۨďý­¸±© ·° Ş®ş

Ňżł» Ü»şż«´¬ ÎÜ ×˛¬»®şż˝»­

Ý«­¬ß ¨ćďđ Í»đńđňďďí

Ý«­¬ßŢ ¨ćďď Í»đńđňďđď

Ý«­¬Ţ ¨ćîđ Í»đńđňďđî

Using an extended ping command, you have verified that you can ping from the loopback address of the managed CE router to the loopback address of the NMS CE router (10.10.10.49).

Ýۨďßý°·˛ą

Đ®±¬±˝±´ Ĺ·°Ăć

Ěż®ą»¬ ×Đ żĽĽ®»­­ć ďđňďđňďđňěç

λ°»ż¬ ˝±«˛¬ ĹëĂć

Üż¬żą®żł ­·¦» ĹďđđĂć

Ě·ł»±«¬ ·˛ ­»˝±˛Ľ­ ĹîĂć

ۨ¬»˛Ľ»Ľ ˝±łłż˛Ľ­ ŲĂć §

ͱ«®˝» żĽĽ®»­­ ±® ·˛¬»®şż˝»ć ´±±°ľż˝µđ

Page 757: Implementing cisco mpls

86 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

̧°» ±ş ­»®Ş·˝» ĹđĂć

Í»¬ ÜÚ ľ·¬ ·˛ ×Đ ¸»żĽ»®á Ų±Ăć

Ęż´·Ľż¬» ®»°´§ Ľż¬żá Ų±Ăć

Üż¬ż °ż¬¬»®˛ Ĺđ¨ßŢÝÜĂć

Ô±±­»ô ͬ®·˝¬ô λ˝±®Ľô Ě·ł»­¬żł°ô Ę»®ľ±­»Ĺ˛±˛»Ăć

Í©»»° ®ż˛ą» ±ş ­·¦»­ ŲĂć

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňďđňďđňěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

Đż˝µ»¬ ­»˛¬ ©·¬¸ ż ­±«®˝» żĽĽ®»­­ ±ş ďđňďň¨ďňěç

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ččńďďěńîďî ł­

Using an extended ping command, you have verified that you cannot ping from the Ethernet address of the managed CE router to the loopback address of the NMS CE router (10.10.10.49).

You have verified that your CE router is seeing only prefixes within your VPN and that no prefixes are being leaked from other VPNs.

Ýۨďßâ­¸ ·° ľą°

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďîô ´±˝ż´ ®±«¬»® ×Ü ·­ ďđňďň¨ďňěç

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

öâ ďđňďň¨ďňďęńîč đňđňđňđ đ íîéęč á

öâ ďđňďň¨ďňěçńíî đňđňđňđ đ íîéęč á

öâ ďđňďň¨îňďęńîč ďëđň¨ň¨ďňďč đ ęëđđď ęëđđď á

öâ ďđňďň¨îňěçńíî ďëđň¨ň¨ďňďč đ ęëđđď ęëđđď á

öâ ďđňîň¨îňďęńîč ďëđň¨ň¨ďňďč đ ęëđđď ęëđíî á

öâ ďđňîň¨îňěçńíî ďëđň¨ň¨ďňďč đ ęëđđď ęëđíî á

öâ ďđňďđňďđňěçńíî ďëđň¨ň¨ďňďč đ ęëđđď á

öâ ďëđň¨ň¨ďňďęńîč đňđňđňđ đ íîéęč á

öâ ďëđň¨ň¨ďňěčńîč ďëđň¨ň¨ďňďč đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨îňďęńîč ďëđň¨ň¨ďňďč đ ęëđđď ęëđđď á

öâ ďëđň¨ň¨îňíîńîč ďëđň¨ň¨ďňďč đ ęëđđď ęëđíî á

Ýۨďßâ­¸ ·° ®±

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô × ó ×ŮÎĐô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» îô Ű ó ŰŮĐ

· ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî

·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»

± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

Page 758: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 87

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­

Ý ďđňďň¨ďňďęńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô ۬¸»®˛»¬đńđ

Ţ ďđňîň¨îňěçńíî ĹîđńđĂ Ş·ż ďëđň ¨ň¨ďňďčô đđćđëćďé

Ţ ďđňďň¨îňěçńíî ĹîđńđĂ Ş·ż ďëđň ¨ň¨ďňďčô đđćđëćďé

Ý ďđňďň¨ďňěçńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

Ţ ďđňîň¨îňďęńîč ĹîđńđĂ Ş·ż ďëđň ¨ň¨ďňďčô đđćđëćďé

Ţ ďđňďđňďđňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňďčô đđćđëćďé

Ţ ďđňďň¨îňďęńîč ĹîđńđĂ Ş·ż ďëđň ¨ň¨ďňďčô đđćđëćďé

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­

Ţ ďëđň¨ň¨îňíî ĹîđńđĂ Ş·ż ďëđňíňíďňďčô đđćđëćďé

Ý ďëđň¨ň¨ďňďę ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđď

Ţ ďëđň¨ň¨îňďę ĹîđńđĂ Ş·ż ďëđňíňíďňďčô đđćđëćďé

Ţ ďëđň¨ň¨ďňěč ĹîđńđĂ Ş·ż ďëđňíňíďňďčô đđćđëćďé

ÝŰíďßâ

You have verified that the P router has only the management prefixes in the NMS VRF.

Đďâ­¸ ·° ľą° Ş°˛ Ş®ş ŇÓÍ

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ďíëô ´±˝ż´ ®±«¬»® ×Ü ·­ îđďňîđîňîëňď

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

᫬» Ü·­¬·˛ą«·­¸»®ć ďđďćëđđ řĽ»şż«´¬ ş±® Ş®ş ŇÓÍ÷

öâ·ďđňďň¨ďňěçńíî ďçîňďęčň¨ňďé đ ďđđ đ ęëđíď á

öâ·ďđňďň¨îňěçńíî ďçîňďęčň¨ňíí đ ďđđ đ ęëđíď á

öâ·ďđňďň§ďňěçńíî ďçîňďęčň§ňďé đ ďđđ đ ęëđěď á

öâ·ďđňďň§îňěçńíî ďçîňďęčň§ňíí đ ďđđ đ ęëđěď á

öâ·ďđňîň¨ďňěçńíî ďçîňďęčň¨ňďé đ ďđđ đ ęëđíî á

öâ·ďđňîň¨îňěçńíî ďçîňďęčň¨ňíí đ ďđđ đ ęëđíî á

öâ·ďđňîň§ďňěçńíî ďçîňďęčň§ňďé đ ďđđ đ ęëđěî á

öâ·ďđňîň§îňěçńíî ďçîňďęčň§ňíí đ ďđđ đ ęëđěî á

öâ ďđňďđňďđňěçńíî đňđňđňđ đ íîéęč á

Đďâ

Note In these results, x is your SP number, and y is the number of the other SP. You need only

check for the x routes.

Page 759: Implementing cisco mpls

88 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 7-1: Establishing Central Site Internet Connectivity with an MPLS VPN

Internet connectivity in MPLS VPN-based networks can be achieved through a dedicated Internet VPN. The dedicated Internet VPN approach provides better security because it completely isolates the service provider core (P routers) from the Internet. On the other hand, this approach is also less scalable; for example, you cannot export full Internet routing updates into an Internet VPN.

Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will remove the overlapping VPNS between customer A and customer B and then configure a separate VPN for Internet access for each customer. After completing this activity, you will be able to meet these objectives:

Restore a simple customer VPN configuration

Establish CE-PE connectivity for central site Internet access

Establish central site CE-PE connectivity for Internet access across a separate MPLS VPN

Establish remote site Internet connectivity through the central site router

Visual Objective The figure illustrates what you will accomplish in this activity. For clarity, customer A connectivity is shown on the left side of the diagram, and customer B connectivity is shown on the right side of the diagram. Customer A is connected through POP x1, customer B is connected through POP x2.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—16

Internet Connectivity Through Central Site

Page 760: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 89

Note The simulated Internet gateway router with an Internet VRF is preconfigured on P1.

You will first remove the overlapping VPNs between customer A and customer B, and reestablish simple VPN connectivity for each customer. You will then configure additional virtual links between the central site CE routers (CEx1A and CEx2B) and their PE routers. These separate circuits will connect from the central CE routers to their PE router to carry the Internet traffic.

The figure illustrates the new subinterfaces.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—17

Separate Internet Connection for Central Sites

You will next create connectivity on the PE router between the Internet VPN and the customer central site for all Internet traffic in the SP. Each POP will be responsible for performing the configuration tasks on its PE router. The PE router will send only the default route from the Internet gateway to the central CE router.

Because the remote sites (CEx1B and CEx2A) will access the Internet using the MPLS VPN connection to their respective central sites, you will create default routes for each VPN pointing to the central CE router.

Note Internet traffic within the SP will not go to the Internet gateway but will be appropriately

routed by the PE routers.

Page 761: Implementing cisco mpls

90 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Required Resources This is the resource that is required to complete this activity:

Cisco IOS documentation

Command List The table describes some commands that are used in this activity. All other commands used in this lab have been described in previous labs.

Command Description

·° °®»ş·¨ó´·­¬ ˛żł» °»®ł·¬ żĽĽ®»­­ łż­µ

Creates an IP prefix list that matches a specific address and mask

˛»·ą¸ľ±® ·°óżĽĽ®»­­ °®»ş·¨ó´·­¬ °®»ş·¨ó´·­¬ó˛żł» ±«¬

Filters BGP advertisements to a neighbor based on the prefix list

°·˛ą ¸±­¬ ­±«®˝» Ĺ·°óżĽĽ®»­­ ¤ ·˛¬»®şż˝»ó¬§°» ·˛¬»®şż˝»ó˛«łľ»®Ă

Pings a host using a specified source address

Task 1: Restore a Simple Customer VPN Configuration In this task, you will remove the overlapping VRF CustAB. You will restore all customer A sites to VRF CustA and all customer B sites to VRF CustB with the following connectivity goals:

CEx1A and CEx2A can communicate with each other, but not to CEx*B devices.

CEx1B and CEx2B can communicate with each other, but not to CEx*A devices.

Activity Procedure

Complete these steps:

Step 1 Remove the address family BGP neighbor relationship between CEx1A and CEx2Bon their respective PE router.

Step 2 Configure CEx1A with the CustA address family BGP neighbor relationship.

Step 3 Configure CEx2B with the CustB address family BGP neighbor relationship.

Page 762: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 91

Activity Verification

You have completed this task when you attain these results:

You have verified that the appropriate neighbor relationships are in place. Use the show ip bgp command to verify this.

Đۨďý­¸ ·° ľą° Ş°˛ Ş®ş Ý«­¬ß

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ëęô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčňěňďé

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćďđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬ß÷

öâ ďđňďň¨ďňďęńîč ďëđň¨ň¨ďňďé đ đ ęëđěď á

öâ ďđňďň¨ďňěçńíî ďëđň¨ň¨ďňďé đ đ ęëđěď á

öâ·ďđňďň¨îňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđěď á

ö ďëđň¨ň¨ďňěç îđđ đ ęëđěď á

öâ·ďđňďň¨îňěçńíî ďçîňďęčň¨ňíí đ ďđđ đ ęëđěď á

ö ďëđň¨ň¨ďňěç îđđ đ ęëđěď á

öâ·ďđňďđňďđňěçńíî ďçîňďęčňďđđňďîç đ ďđđ đ á

®â ďëđň¨ň¨ďňďęńîč ďëđň¨ň¨ďňďé đ đ ęëđěď á

®â·ďëđň¨ň¨ďňěčńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđěď á

® ďëđň¨ň¨ďňěç îđđ đ ęëđěď á

öâ·ďëđň¨ň¨îňďęńîč ďçîňďęčň¨ňíí đ ďđđ đ ęëđěď á

ö ďëđň¨ň¨ďňěç îđđ đ ęëđěď á

Đۨďý

Đۨîý­¸ ·° ľą° Ş°˛ Ş®ş Ý«­¬Ţ

ŢŮĐ ¬żľ´» Ş»®­·±˛ ·­ ëęô ´±˝ż´ ®±«¬»® ×Ü ·­ ďçîňďęčň¨ňíí

ͬż¬«­ ˝±Ľ»­ć ­ ­«°°®»­­»Ľô Ľ Ľżł°»Ľô ¸ ¸·­¬±®§ô ö Şż´·Ľô â ľ»­¬ô · ó ·˛¬»®˛ż´ô

® Î×Ţóşż·´«®»ô Í Í¬ż´»

Ń®·ą·˛ ˝±Ľ»­ć · ó ×ŮĐô » ó ŰŮĐô á ó ·˛˝±ł°´»¬»

Ň»¬©±®µ Ň»¨¬ ر° Ó»¬®·˝ Ô±˝Đ®ş É»·ą¸¬ Đż¬¸

᫬» Ü·­¬·˛ą«·­¸»®ć ¨ćîđ řĽ»şż«´¬ ş±® Ş®ş Ý«­¬Ţ÷

öâ·ďđňîň¨ďňďęńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđěî á

ö ďëđň¨ň¨îňěç îđđ đ ęëđěî á

öâ·ďđňîň¨ďňěçńíî ďçîňďęčň¨ňďé đ ďđđ đ ęëđěî á

ö ďëđň¨ň¨îňěç îđđ đ ęëđěî á

öâ ďđňîň¨îňďęńîč ďëđň¨ň¨îňíí đ đ ęëđěî á

öâ ďđňîň¨îňěçńíî ďëđň¨ň¨îňíí đ đ ęëđěî á

öâ·ďđňďđňďđňěçńíî ďçîňďęčňďđđňďîç đ ďđđ đ á

öâ·ďëđň¨ň¨ďňíîńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđěî á

ö ďëđň¨ň¨îňěç îđđ đ ęëđěî á

®â ďëđň¨ň¨îňíîńîč ďëđň¨ň¨îňíí đ đ ęëđěî á

Page 763: Implementing cisco mpls

92 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

®â·ďëđň¨ň¨îňěčńîč ďçîňďęčň¨ňďé đ ďđđ đ ęëđěî á

® ďëđň¨ň¨îňěç îđđ đ ęëđěî á

Đۨîý

From your customer router, you have verified that you can ping the loopback interface of the remote customer router.

Ýۨďßý°·˛ą ďđňďň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňďň¨îňěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďěčńďěčńďěç ł­

ÝۨîŢý°·˛ą ďđňîň¨ďňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňîň¨ďňěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ďěčńďěčńďěç ł­

Note You may need to issue a clear ip bgp * command on the CE router to force the propagation

of the new routes.

Page 764: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 93

Task 2: Establish CE-PE Connectivity for Central Site Internet Access

In this task, you will add a new subinterface to support the Internet VPN on the central site router.

Activity Procedure

Complete these steps:

Step 1 Create a separate subinterface (S0/0.114) on the central router of the customer using the address information in the table.

Router ID IP Address DLCI

CEx1A 150.x.x1.66/28 114

CEx2B 150.x.x2.66/28 114

Step 2 Activate the new interface in the IGP routing process and make the interface passive.

Step 3 Create a separate subinterface (S0/0.114) on the PE routers using the address information in this table.

Router ID IP Address DLCI

PEx1 150.x.x1.65/28 114

PEx2 150.x.x2.65/28 114

Step 4 Activate the new interface in the IGP routing process and make the interface passive.

Note Global routing between your PE router and P1 was established in Lab 6-2, “Merging Service

Providers.”

Activity Verification

You have completed this task when you attain these results:

You have used the show ip interface command to verify the status of the new interfaces.

Ýۨďßý­¸±© ·° ·˛¬»®şż˝» ­đńđňďďě

Í»®·ż´đńđňďďě ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «°

ײ¬»®˛»¬ żĽĽ®»­­ ·­ ďëđň¨ň¨ďňęęńîč

Ţ®±żĽ˝ż­¬ żĽĽ®»­­ ·­ îëëňîëëňîëëňîëë

߼Ľ®»­­ Ľ»¬»®ł·˛»Ľ ľ§ ­»¬«° ˝±łłż˛Ľ

ÓĚË ·­ ďëđ𠾧¬»­

öööööööööööööö ±«¬°«¬ ±ł·¬¬»Ľ öööööööööööööööööööööööö

Đۨďý­¸±© ·° ·˛¬»®şż˝» ­đńđňďďě

Í»®·ż´đńđňďďě ·­ «°ô ´·˛» °®±¬±˝±´ ·­ «°

Page 765: Implementing cisco mpls

94 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

ײ¬»®˛»¬ żĽĽ®»­­ ·­ ďëđň¨ň¨ďňęëńîč

Ţ®±żĽ˝ż­¬ żĽĽ®»­­ ·­ îëëňîëëňîëëňîëë

߼Ľ®»­­ Ľ»¬»®ł·˛»Ľ ľ§ ­»¬«° ˝±łłż˛Ľ

ÓĚË ·­ ďëđ𠾧¬»­

öööööööööööööö ±«¬°«¬ ±ł·¬¬»Ľ öööööööööööööööööööööööö

Task 3: Establish Central Site Connectivity for Internet Access Another group in the service provider organization has already created a VPN in the provider core to carry the Internet traffic. You will connect the central customer site CE to the Internet VPN to support all Internet traffic from the customer. Each POP will be responsible for performing the configuration tasks on its PE router.

To control Internet routes forwarded to the customer, the PE router will send only the default route from the Internet gateway to the central CE router.

Activity Procedure

Complete these steps:

Step 1 Create /24 summary routes for both customer sites with default routes to the Null0 interface on the central CE router.

Step 2 Add the appropriate PE router neighbor statement to the BGP process on the CE router.

Step 3 Add the summary networks to the BGP routing process on the central CE router.

Step 4 Create a VRF named “Internet” on the PE router. Use RD 100:600, and import RT 100:600.

Step 5 Create a route-map to export only the default route and the /24 summary routes from the customer.

Step 6 Place the new interface (Se0/0.114) that will support the central site CE router (CEx1A or CEx2B) into the Internet VRF on the PE router.

Step 7 Create a prefix list to permit only the default route.

Step 8 Add the central site router neighbor statements to the IPv4 VRF address family for the Internet VRF on the PE router.

Activity Verification

You have completed this task when you attain these results:

You have verified that the central site CE router is receiving only the default route across the Internet subinterface from its PE neighbor and that /24 summary routes for both customer sites are in the routing table.

Ýۨďßý­¸ ·° ®±«¬»

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô × ó ×ŮÎĐô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» îô Ű ó ŰŮĐ

Page 766: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 95

· ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî

·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»

± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ďëđň¨ň¨ďňęë ¬± ˛»¬©±®µ đňđňđňđ

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô í łż­µ­

Ţ ďđňďň¨îňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňďčô đďćîéćďí

Ý ďđňďň¨ďňěçńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

Í ďđňďň¨îňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ň«´´đ

Í ďđňďň¨ďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ň«´´đ

Ţ ďđňďň¨îňďęńîč ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňďčô đďćîéćďí

Ý ďđňďň¨ďňďęńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô ۬¸»®˛»¬đńđ

Ţ ďđňďđňďđňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňďčô đđćíëćďď

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­

Ţ ďëđň¨ň¨ďňěč ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňďčô đďćîéćďě

Ţ ďëđň¨ň¨îňďę ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňďčô đďćîéćďě

Ý ďëđň¨ň¨ďňďę ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđď

Ý ďëđň¨ň¨ďňęě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďě

Ţö đňđňđňđńđ ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňęëô đđćíěćëí

Ýۨďßý

ÝۨîŢý­¸±© ·° ®±«¬»

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô × ó ×ŮÎĐô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» îô Ű ó ŰŮĐ

· ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî

·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»

± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ďëđň¨ň¨îňęë ¬± ˛»¬©±®µ đňđňđňđ

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô í łż­µ­

Ţ ďđňîň¨ďňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨îňíěô đđćíëćîě

Ý ďđňîň¨îňěçńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

Í ďđňîň¨ďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ň«´´đ

Í ďđňîň¨îňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ň«´´đ

Ţ ďđňîň¨ďňďęńîč ĹîđńđĂ Ş·ż ďëđň¨ň¨îňíěô đđćíëćîě

Ý ďđňîň¨îňďęńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô ۬¸»®˛»¬đńđ

Ţ ďđňďđňďđňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨îňíěô đđćíëćîě

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­

Ţ ďëđň¨ň¨îňěč ĹîđńđĂ Ş·ż ďëđň¨ň¨îňíěô đđćíëćîë

Ý ďëđň¨ň¨îňíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđî

Ţ ďëđň¨ň¨ďňíî ĹîđńđĂ Ş·ż ďëđň¨ň¨îňíěô đđćíëćîë

Page 767: Implementing cisco mpls

96 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Ý ďëđň¨ň¨îňęě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďě

Ţö đňđňđňđńđ ĹîđńđĂ Ş·ż ďëđň¨ň¨îňęëô đđćďëćďé

ÝۨîŢý

You have verified that the PE router is receiving Internet routes from the central CE router as well as the Internet gateway. The /24 summary routes for both customer sites are in the Internet routing table.

Đۨďý­¸±© ·° ®±«¬» Ş®ş ײ¬»®˛»¬

᫬·˛ą Ěżľ´»ć ײ¬»®˛»¬

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî

·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»

± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ďçîňďęčňďđđňďîç ¬± ˛»¬©±®µ đňđňđňđ

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ďđ ­«ľ˛»¬­ô í łż­µ­

Ţ ďđňďň¨ďňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňęęô đđćíđćěę

Ţ ďđňďň§ďňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň§ňďéô đđćîěćíé

Ţ ďđňîň§ďňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň§ňííô đđćîěćíé

Ţ ďđňîň¨ďňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćďęćëď

Ţ ďđňďň¨îňđńîě ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňęęô đđćîđćëč

Ţ ďđňîň¨îňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćďęćëď

Ţ ďđňďň¨ďňđńîě ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňęęô đđćîďćîé

Ţ ďđňîň§îňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň§ňííô đđćîěćíč

Ţ ďđňďň§îňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň§ňďéô đđćîěćíč

Ţ ďđňďň¨ďňďęńîč ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňęęô đđćíđćěé

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­

Ţ ďëđň¨ň¨ďňďę ĹîđńđĂ Ş·ż ďëđňěňěďňęęô đđćíćěč

Ý ďëđň¨ň¨ďňęě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďě

Ţö đňđňđňđńđ ĹîđđńđĂ Ş·ż ďçîňďęčňďđđňďîçô đđćďęćëî

Đۨďý

Note In these results, x is your SP number, and y is the number of the other SP in the merged SP

network. Depending on the status of the other groups, you could see the /24 subnets for

CEx1A, CEx2A, CEx1B, CEx2B, CEy1A, CEy2A, CEy1B, and CEy2B.

Page 768: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 97

Đۨîý­¸±© ·° ®±«¬» Ş®ş ײ¬»®˛»¬

᫬·˛ą Ěżľ´»ć ײ¬»®˛»¬

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî

·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»

± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ďçîňďęčňďđđňďîç ¬± ˛»¬©±®µ đňđňđňđ

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ďđ ­«ľ˛»¬­ô í łż­µ­

Ţ ďđňîň¨îňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨îňęęô đđćëďćíě

Ţ ďđňďňíďňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňďéô đđćëďćîé

Ţ ďđňîňíďňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćëďćîé

Ţ ďđňîň¨ďňđńîě ĹîđńđĂ Ş·ż ďëđň¨ň¨îňęęô đđćëďćíě

Ţ ďđňďň¨îňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňďéô đđćëďćîé

Ţ ďđňîň¨îňđńîě ĹîđńđĂ Ş·ż ďëđň¨ň¨îňęęô đđćëďćíě

Ţ ďđňďň¨ďňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňďéô đđćëďćîé

Ţ ďđňîňíîňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćëďćîč

Ţ ďđňďňíîňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňďéô đđćëďćîč

Ţ ďđňîň¨îňďęńîč ĹîđńđĂ Ş·ż ďëđň¨ň¨îňęęô đđćëďćíë

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô î ­«ľ˛»¬­

Ţ ďëđň¨ň¨îňíî ĹîđńđĂ Ş·ż ďëđň¨ň¨îňęęô đđćëďćíé

Ý ďëđň¨ň¨îňęě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďě

Ţö đňđňđňđńđ ĹîđđńđĂ Ş·ż ďçîňďęčňďđđňďîçô đđćíďćďě

Đۨîý

Note In these results, x is your SP number, and y is the number of the other SP in the merged SP

network. Depending on the status of the other groups, you could see the /24 subnets for

CEx1A, CEx2A, CEx1B, CEx2B, CEy1A, CEy2A, CEy1B, and CEy2B.

Page 769: Implementing cisco mpls

98 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

You have verified that the /24 summary routes for both customer sites are in the Internet routing table on the P1 router.

Đďâ­¸±© ·° ®±«¬» Ş®ş ײ¬»®˛»¬

᫬·˛ą Ěżľ´»ć ײ¬»®˛»¬

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî

·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»

± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ďđňđňđňî ¬± ˛»¬©±®µ đňđňđňđ

ďéîňďęňđňđńîě ·­ ­«ľ˛»¬¬»Ľô ď ­«ľ˛»¬­

Ý ďéîňďęňđňđ ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µďéî

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ďę ­«ľ˛»¬­ô î łż­µ­

Ý ďđňđňđňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µîđđ

Ţ ďđňďň¨ďňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňďéô đđćîčćíě

Ţ ďđňîň¨ďňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćîčćíě

Ţ ďđňîň§ďňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň§ňííô đďćđđćěç

Ţ ďđňďň§îňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň§ňďéô đđćîěćíě

Ţ ďđňîň§îňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň§ňííô đđćđđćëđ

Ţ ďđňďň§ďňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň§ňďéô đđćîëćîđ

Ţ ďđňîň¨îňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćîčćíë

Ţ ďđňďň¨îňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňďéô đđćîčćíé

Ý ďđňîňéîňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µîéî

Ý ďđňďňéďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µîéď

Ý ďđňďňçďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µîçď

Ý ďđňîňçîňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µîçî

Ý ďđňîňčîňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µîčî

Ý ďđňďňčďňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µîčď

Ý ďçîňďęčňđňđńîě ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µďçî

Íö đňđňđňđńđ ĹďńđĂ Ş·ż ďđňđňđňî

Đďâ

Note In these results, x is your SP number, and y is the number of the other SP in the merged SP

network. Depending on the status of the other groups, you could see the /24 subnets for

CEx1A, CEx2A, CEx1B, CEx2B, CEy1A, CEy2A, CEy1B, and CEy2B.

P1 also has loopbacks simulating Internet devices. You should be able to ping 10.0.0.1,

172.176.0.1, and 192.168.0.1 from any prefix in this routing table.

Page 770: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 99

You have verified that the central customer site devices can reach the simulated networks the P1 Internet VRF routing table.

Ýۨďßý°·˛ą ďéîňďęňđňď ­±«®˝» ´±±°ľż˝µđ

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďéîňďęňđňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

Đż˝µ»¬ ­»˛¬ ©·¬¸ ż ­±«®˝» żĽĽ®»­­ ±ş ďđňďň¨ďňěç

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ččńçíńďďî ł­

Ýۨďßý

ÝۨîŢý°·˛ą ďđňđňđňď ­±«®˝» ´±±°ľż˝µđ

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňđňđňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

Đż˝µ»¬ ­»˛¬ ©·¬¸ ż ­±«®˝» żĽĽ®»­­ ±ş ďđňîň¨îňěç

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă ččńďďéńîíé ł­

ÝۨîŢý¬®ż˝»

Đ®±¬±˝±´ Ĺ·°Ăć

Ěż®ą»¬ ×Đ żĽĽ®»­­ć ďđňđňđňď

ͱ«®˝» żĽĽ®»­­ć ďđňîň¨îňďé

Ň«ł»®·˝ Ľ·­°´ż§ ŲĂć

Ě·ł»±«¬ ·˛ ­»˝±˛Ľ­ ĹíĂć

Đ®±ľ» ˝±«˛¬ ĹíĂć

Ó·˛·ł«ł Ě·ł» ¬± Ô·Ş» ĹďĂć

Óż¨·ł«ł Ě·ł» ¬± Ô·Ş» ĹíđĂć

ᮬ Ň«łľ»® ĹííěíěĂć

Ô±±­»ô ͬ®·˝¬ô λ˝±®Ľô Ě·ł»­¬żł°ô Ę»®ľ±­»Ĺ˛±˛»Ăć

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďđňđňđňď

ď ďëđň¨ň¨îňęë ďé ł­»˝ ďę ł­»˝ ďę ł­»˝

î ďđňđňđňď ĹßÍ ęëđđďĂ ěě ł­»˝ ö ěě ł­»˝

ÝۨîŢý

Note The packet from the central CE router should go to its PE router (150.x.x1.65) through the

Internet interface to reach the Internet address.

Page 771: Implementing cisco mpls

100 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Task 4: Establish Remote Site Internet Connectivity Through the Central Site Router

Because the remote sites (CEx1B and CEx2A) will access the Internet using the MPLS VPN connection to their respective central sites, you will create default routes for each VPN pointing to the central CE router.

Activity Procedure

Complete these steps:

Step 1 On your PE router, add a default VRF route pointing to Loopback0 on the central CE router.

Step 2 Add the redistribute static command and the default-information originatecommand to your address family to propagate this route to the CEs.

Activity Verification

You have completed this task when you attain these results:

You have verified that the remote CE router has a default route across the MPLS VPN to its CE neighbor.

ÝۨďŢý­¸±© ·° ®±«¬»

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô × ó ×ŮÎĐô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» îô Ű ó ŰŮĐ

· ó ×Íó×Íô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óîô ·ż ó ×Íó×Í ·˛¬»® ż®»ż

ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»ô ± ó ŃÜÎ

Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ďđňîň¨îňěç ¬± ˛»¬©±®µ đňđňđňđ

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô í łż­µ­

Ý ďđňîň¨ďňěçńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

Ţ ďđňîň¨îňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňíěô đđćđîćîď

Ţ ďđňîň¨ďňđńîě ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňíěô đđćđîćîď

Ţ ďđňîň¨îňđńîě ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňíěô đđćđîćîď

Ý ďđňîň¨ďňďęńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô ۬¸»®˛»¬đńđ

Ţ ďđňîň¨îňďęńîč ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňíěô đđćđîćîď

Ţ ďđňďđňďđňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňíěô đđćîîćđç

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­

Ý ďëđň¨ň¨îňěč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďí

Ţ ďëđň¨ň¨îňíî ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňíěô đđćđîćîî

Ý ďëđň¨ň¨ďňíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđî

Ţ ďëđň¨ň¨îňęě ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňíěô đđćđîćîî

Ţö đňđňđňđńđ ĹďńđĂ Ş·ż ďđňîň¨îňěç

ÝۨďŢý

Page 772: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 101

Ýۨîßý­¸±© ·° ®±«¬»

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô × ó ×ŮÎĐô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» îô Ű ó ŰŮĐ

· ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî

·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»

± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ďđňďň¨ďňěç ¬± ˛»¬©±®µ đňđňđňđ

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô í łż­µ­

Ý ďđňďň¨îňěçńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

Ţ ďđňďň¨ďňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨îňďčô đđćđčćđđ

Ţ ďđňďň¨îňđńîě ĹîđńđĂ Ş·ż ďëđň¨ň¨îňďčô đđćđčćđđ

Ţ ďđňďň¨ďňđńîě ĹîđńđĂ Ş·ż ďëđň¨ň¨îňďčô đđćđčćđđ

Ý ďđňďň¨îňďęńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô ۬¸»®˛»¬đńđ

Ţ ďđňďň¨ďňďęńîč ĹîđńđĂ Ş·ż ďëđň¨ň¨îňďčô đđćđčćđđ

Ţ ďđňďđňďđňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨îňďčô đđćđčćđđ

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­

Ý ďëđň¨ň¨ďňěč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďí

Ý ďëđň¨ň¨îňďę ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđď

Ţ ďëđň¨ň¨ďňďę ĹîđńđĂ Ş·ż ďëđň¨ň¨îňďčô đđćđčćđî

Ţ ďëđň¨ň¨ďňęě ĹîđńđĂ Ş·ż ďëđň¨ň¨îňďčô đđćđčćđî

Íö đňđňđňđńđ ĹďńđĂ Ş·ż ďđňďň¨ďňěç

Ýۨîßý

You have verified that the PE routers have the appropriate default routes across the MPLS VPN to the CE neighbor.

Đۨďý­¸ ·° ®± Ş®ş Ý«­¬Ţ

᫬·˛ą Ěżľ´»ć Ý«­¬Ţ

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî

·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»

± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ďçîňďęčň¨ňíí ¬± ˛»¬©±®µ đňđňđňđ

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô í łż­µ­

Ţ ďđňîň¨ďňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňííô đđćďěćíé

Ţ ďđňîň¨îňěçńíî ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćđçćíë

Ţ ďđňîň¨ďňďęńîč ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňííô đđćďěćíé

Ţ ďđňîň¨îňďęńîč ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćđçćíë

Page 773: Implementing cisco mpls

102 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Ţ ďđňďđňďđňěçńíî ĹîđđńđĂ Ş·ż ďçîňďęčňďđđňďîçô đđćďěćîî

Ţ ďđňîň¨ďňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćďďćđë

Ţ ďđňîň¨îňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćďďććđë

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­

Ý ďëđň¨ň¨ďňíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđî

Ţ ďëđň¨ň¨îňíî ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćđçćíę

Ţ ďëđň¨ň¨îňěč ĹîđńđĂ Ş·ż ďëđň¨ň¨ďňííô đđćďęćďí

Ţ ďëđň¨ň¨îňęě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćđçćěđ

Ţö đňđňđňđńđ ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňííô đđćđçćěđ

Đۨďý

Đۨîý­¸ ·° ®± Ş®ş Ý«­¬ß

᫬·˛ą Ěżľ´»ć Ý«­¬ß

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô ­« ó ×Íó×Í ­«łłż®§ô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óî

·ż ó ×Íó×Í ·˛¬»® ż®»żô ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»

± ó ŃÜÎô Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ďçîňďęčň¨ňďé ¬± ˛»¬©±®µ đňđňđňđ

ďđňđňđňđńč ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô í łż­µ­

Ţ ďđňďň¨ďňěçńíî ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňďéô đđćďčćďë

Ţ ďđňďň¨îňěçńíî ĹîđńđĂ Ş·ż ďëđň¨ň¨îňďéô đđćďëćěę

Ţ ďđňďň¨ďňďęńîč ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňďéô đđćďčćďë

Ţ ďđňďň¨îňďęńîč ĹîđńđĂ Ş·ż ďëđň¨ň¨îňďéô đđćďëćěę

Ţ ďđňďň¨ďňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňďéô đđćďčćďë

Ţ ďđňďđňďđňěçńíî ĹîđđńđĂ Ş·ż ďçîňďęčňďđđňďîçô đđćďčćďë

Ţ ďđňďň¨îňđńîě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňďéô đđćďčćďë

ďëđň¨ňđňđńîč ·­ ­«ľ˛»¬¬»Ľô ě ­«ľ˛»¬­

Ţ ďëđň¨ň¨ďňěč ĹîđńđĂ Ş·ż ďëđň¨ň¨îňďéô đđćďëćěé

Ţ ďëđň¨ň¨ďňďę ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňďéô đđćďčćďę

Ý ďëđň¨ň¨îňďę ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďđď

Ţ ďëđň¨ň¨ďňęě ĹîđđńđĂ Ş·ż ďçîňďęčň¨ňďéô đđćďčćďé

Ţö đňđňđňđńđ ĹďńđĂ Ş·ż ďçîňďęčň¨ňďéô đđćďčćďé

Đۨîý

You have used the ping and trace commands to verify that you can reach remote devices.

Ýۨîßý°·˛ą ďđňđňđňď ­±«®˝» ´±±°ľż˝µđ

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňđňđňďô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

Page 774: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 103

Đż˝µ»¬ ­»˛¬ ©·¬¸ ż ­±«®˝» żĽĽ®»­­ ±ş ďđňďň¨îňěç

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă îíîńîěçńíďé ł­

ÝۨďŢý°·˛ą ďéîňďęňđňď ­±«®˝» ´±±°ľż˝µđ

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Í»˛Ľ·˛ą ëô ďđđ󾧬» ×ÝÓĐ Ű˝¸±­ ¬± ďđňďňéďňďěçô ¬·ł»±«¬ ·­ î ­»˝±˛Ľ­ć

Đż˝µ»¬ ­»˛¬ ©·¬¸ ż ­±«®˝» żĽĽ®»­­ ±ş ďđňďň¨îňěç

˙˙˙˙˙

Í«˝˝»­­ ®ż¬» ·­ ďđđ °»®˝»˛¬ řëńë÷ô ®±«˛Ľó¬®·° ł·˛ńżŞąńłż¨ ă îíîńîěçńíďé ł­

ÝۨďŢý

Ýۨîßý¬®ż˝»

Đ®±¬±˝±´ Ĺ·°Ăć

Ěż®ą»¬ ×Đ żĽĽ®»­­ć ďđňđňđňď

ͱ«®˝» żĽĽ®»­­ć ďđňďň¨îňďé

Ň«ł»®·˝ Ľ·­°´ż§ ŲĂć

Ě·ł»±«¬ ·˛ ­»˝±˛Ľ­ ĹíĂć

Đ®±ľ» ˝±«˛¬ ĹíĂć

Ó·˛·ł«ł Ě·ł» ¬± Ô·Ş» ĹďĂć

Óż¨·ł«ł Ě·ł» ¬± Ô·Ş» ĹíđĂć

ᮬ Ň«łľ»® ĹííěíěĂć

Ô±±­»ô ͬ®·˝¬ô λ˝±®Ľô Ě·ł»­¬żł°ô Ę»®ľ±­»Ĺ˛±˛»Ăć

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďđňđňđňď

ď ďëđň¨ň¨îňďč ďî ł­»˝ ďî ł­»˝ ďé ł­»˝

î ďëđň¨ň¨ďňďč ĹßÍ ęëđđďĂ ĹÓĐÔÍć Ôżľ»´ íç ۨ° đĂ ďîđ ł­»˝ ďďę ł­»˝ ďďę ł­»˝

í ďëđň¨ň¨ďňďé ĹßÍ ęëđđďĂ éę ł­»˝ éę ł­»˝ éę ł­»˝

ě ďëđň¨ň¨ďňęë ĹßÍ ęëđđďĂ čç ł­»˝ ďéę ł­»˝ îęđ ł­»˝

ë ďđňđňđňď ďîď ł­»˝ ö ďďé ł­»˝

Ýۨîßý

Note If you trace the path, the packet from the remote CE router should go to its PE (150.x.x2.18),

then to the central site PE (150.x.x1.18 outbound), then to the central site CE (150.x.x1.17) ,

and then out the central site CE Internet interface to the central site PE (150.x.x1.65) to

reach the Internet address.

Page 775: Implementing cisco mpls

104 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 8-1: Implementing Basic MPLS TE In this exercise, you will establish MPLS traffic tunnels to support a new requirement of the SP management.

Complete this lab activity to practice what you learned in the related module.

Activity Objective In this activity, you will configure MPLS TE to forward all traffic through the P1 router. The links between Px1 and Px2 will be retained for backup purposes. You will use MPLS TE to direct customer traffic across the P1 router. After completing this activity, you will be able to meet these objectives:

Follow traffic flows in a MPLS backbone

Configure basic MPLS TE support on your routers

Configure MPLS TE tunnels

Visual Objective The figure illustrates what you will accomplish in this activity.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—18

MPLS Traffic Engineering Layout

Required Resources This is the resource that is required to complete this activity:

Cisco IOS documentation

Page 776: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 105

Command List The table describes the commands that are used in this activity.

Command Description

·˛¬»®şż˝» ¬«˛˛»´ ˛«łľ»® Creates a tunnel interface

·° »¨°´·˝·˝¬ó°ż¬¸ ˛żł»

˛żł» Enters the subcommand mode for IP explicit paths and creates or modifies the specified path

·° ®­Ş° ľż˛Ľ©·Ľ¬¸ Ĺłż¨ó®»­»®Şżľ´» Ĺ­·˛ą´»ó®»Ż«»­¬ĂĂ

Enables RSVP on an interface

ł»¬®·˝ó­¬§´» ©·Ľ» Specifies the IS-IS metric type

ł°´­ ·° Starts MPLS support and LDP on an interface

ł°´­ ·° °®±°żąż¬»ó¬¬´ Enables MPLS TTL propagation support

ł°´­ ¬®żşş·˝ó»˛ą ´»Ş»´ Configures IS-IS TE support

ł°´­ ¬®żşş·˝ó»˛ą ´±ąą·˛ą Configures MPLS TE logging

ł°´­ ¬®żşş·˝ó»˛ą

®»±°¬·ł·¦» ¬·ł»®­

ş®»Ż«»˛˝§ íđ

Controls the frequency with which tunnels with established LSPs are checked for better LSPs

ł°´­ ¬®żşş·˝ó»˛ą

®±«¬»®ó·Ľ ·˛¬»®şż˝» Defines the IP address that is used as the tunnel destination for this router

ł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­ Enables MPLS TE globally or on an interface

˛»¨¬óżĽĽ®»­­ ·°óżĽĽ®»­­ Specifies the next IP address in the explicit path

®±«¬»® ·­·­ Starts IS-IS configuration

­¸±© ł°´­ ¬®żşş·˝ó»˛ą

ż«¬±®±«¬»

Displays autoroute information

­¸±© ł°´­ ¬®żşş·˝ó»˛ą

¬«˛˛»´­

Displays detailed tunnel information

­¸±© ł°´­ ¬®żşş·˝ó»˛ą

¬«˛˛»´­ ľ®·»ş

Displays the overall status of MPLS TE tunnels

¬«˛˛»´ Ľ»­¬·˛ż¬·±˛ ·°óżĽĽ®»­­

Specifies the tunnel tailend router

¬«˛˛»´ ł±Ľ» ł°´­

¬®żşş·˝ó»˛ą

Specifies tunnel encapsulation mode

¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą

ż«¬±®±«¬» ż˛˛±«˛˝»

Enables autoroute on an MPLS TE tunnel

¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą

ľż˛Ľ©·Ľ¬¸ ľż˛Ľ©·Ľ¬¸ Specifies the bandwidth that is reserved by the MPLS TE tunnel

¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą

°ż¬¸ó±°¬·±˛ ˛«łľ»® »¨°´·˝·¬ ˛żł» °ż¬¸ó˛żł»

Specifies that the MPLS TE path option will use an explicit path

¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą °®·±®·¬§ ­»¬«° ¸±´Ľ

Specifies MPLS TE tunnel setup and hold priority

Page 777: Implementing cisco mpls

106 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Task 1: Log the Existing Traffic Flow In this task, you will log the existing traffic flow pattern to establish the current path through the network.

Exercise Procedure

Complete these steps:

Step 1 Enable MPLS TTL propagation on all PE and P routers.

Step 2 Perform a traceroute between your two assigned CE routers.

Exercise Verification

You have completed this task when you attain these results:

You have used the trace command to verify the route between the devices.

ÝۨďŢý¬®ż˝» ďđňîň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďđňîň¨îňěç

ď ďëđň¨ň¨ďňíě ďî ł­»˝ ďî ł­»˝ ďî ł­»˝

î ďçîňďęčň¨ňëđ ĹÓĐÔÍć Ôżľ»´­ îďńěç ۨ° đĂ íçé ł­»˝ îëę ł­»˝ íđď ł­»˝

í ďçîňďęčň¨ňďďě ĹÓĐÔÍć Ôżľ»´­ ďéńěç ۨ° đĂ îđě ł­»˝ ďçę ł­»˝ ďçé ł­»˝

ě ďëđň¨ň¨îňíě ĹßÍ ęëđđďĂ ĹÓĐÔÍć Ôżľ»´ ěç ۨ° đĂ ďďę ł­»˝ ďďę ł­»˝ ďďę ł­»˝

ë ďëđň¨ň¨îňíí ĹßÍ ęëđđďĂ éę ł­»˝ ö éî ł­»˝

ÝۨďŢý

ÝۨîŢý¬®ż˝» ďđňîň¨ďňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďđňîň¨ďňěç

ď ďëđň¨ň¨îňíě ďę ł­»˝ ďę ł­»˝ ďî ł­»˝

î ďçîňďęčň¨ňęę ĹßÍ ęëđđďĂ ĹÓĐÔÍć Ôżľ»´­ îíńěî ۨ° đĂ îçé ł­»˝ íđđ ł­»˝ îçé ł­»˝

í ďçîňďęčň¨ňďďí ĹßÍ ęëđđďĂ ĹÓĐÔÍć Ôżľ»´­ ďčńěî ۨ° đĂ îěě ł­»˝ ďçí ł­»˝ ďçę ł­»˝

ě ďëđň¨ň¨ďňíě ĹßÍ ęëđđďĂ ĹÓĐÔÍć Ôżľ»´ ěî ۨ° đĂ ďďę ł­»˝ ďďę ł­»˝ ďďé ł­»˝

ë ďëđň¨ň¨ďňíí ĹßÍ ęëđđďĂ éę ł­»˝ ö éî ł­»˝

ÝۨîŢý

Page 778: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 107

Task 2: Configure MPLS TE Support on the PE and P Routers In this task, you will enable global features that will allow TE tunnels to be built.

Exercise Procedure

Complete these steps:

Step 1 Configure global MPLS TE support.

Step 2 Configure IS-IS support to generate and accept only new-style TLV objects. Configure IS-IS to support level 2 TE.

Step 3 Use “loopback0” as the router ID on the Px1, Px2, PEx1, and PEx2 routers.

Step 4 Configure MPLS TE support and reservable bandwidth on all links between the backbone routers. Allow up to 128 kbps of reservable bandwidth on any single subinterface and up to 128 kbps of reservable bandwidth on physical interfaces.

Note To make MPLS TE work over a subinterface, you must configure RSVP on the main

interface with the ip rsvp bandwidth command even though the main interface is not used

for MPLS TE.

Exercise Verification

You have completed this task when you attain these results:

You have used the show ip rsvp interface command to confirm the RVSP information that has been configured. Verify that the proper interface and bandwidths have been enabled.

Đۨďý­¸±© ·° ®­Ş° ·˛¬»®şż˝»

·˛¬»®şż˝» ż´´±˝ż¬»Ľ ·ńş łż¨ ş´±© łż¨ ­«ľ łż¨

Í»đńđ đ ďîčŐ ďîčŐ đ

Í»đńđňďďď đ ďîčŐ ďîčŐ đ

Đۨîý­¸±© ·° ®­Ş° ·˛¬»®şż˝»

·˛¬»®şż˝» ż´´±˝ż¬»Ľ ·ńş łż¨ ş´±© łż¨ ­«ľ łż¨

Í»đńđ đ ďîčŐ ďîčŐ đ

Í»đńđňďďď đ ďîčŐ ďîčŐ đ

Шďý­¸±© ·° ®­Ş° ·˛¬»®şż˝»

·˛¬»®şż˝» ż´´±˝ż¬»Ľ ·ńş łż¨ ş´±© łż¨ ­«ľ łż¨

Í»đńđ đ ďîčŐ ďîčŐ đ

Í»đńđňďďî đ ďîčŐ ďîčŐ đ

Í»đńđňî¨ď đ ďîčŐ ďîčŐ đ

Í»đńđňďďď đ ďîčŐ ďîčŐ đ

Page 779: Implementing cisco mpls

108 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Шîý­¸±© ·° ®­Ş° ·˛¬»®şż˝»

·˛¬»®şż˝» ż´´±˝ż¬»Ľ ·ńş łż¨ ş´±© łż¨ ­«ľ łż¨

Í»đńđ đ ďîčŐ ďîčŐ đ

Í»đńđňďďď đ ďîčŐ ďîčŐ đ

Í»đńđňďďî đ ďîčŐ ďîčŐ đ

Í»đńđňî¨î đ ďîčŐ ďîčŐ đ

Task 3: Configure MPLS TE Tunnels In this task, you will create the traffic tunnels between PE routers.

Exercise Procedure

Complete these steps:

Step 1 On both of your PE routers, configure an MPLS TE tunnel toward the other PE router in your SP passing through the P1 router (for example, PEx1 Px1 P1 Px2 PEx2). Use the tunnel parameters shown in the table.

Parameter Value

IP address Loopback 0

Tunnel bandwidth 100 kbps

Path options Explicit path selection

Tunnel priority Setup = 0, hold = 0

Autoroute Enabled

Step 2 Enable MPLS forwarding on the MPLS TE tunnels to establish end-to-end LSPs to be used for MPLS VPN traffic.

Step 3 Force faster tunnel optimization with the global command mpls traffic-eng reoptimize timers frequency 30.

Page 780: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 109

Exercise Verification

You have completed this task when you attain these results:

You have used the show mpls traffic-engineering tunnels brief command to display tunnels that are going through a particular router and verified the operational state of the tunnels that are originating in the router. You should get a printout similar to this example.

Đۨďý­¸±© ł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­ ľ®·»ş

Í·ą˛ż´·˛ą Í«łłż®§ć

ÔÍĐ Ě«˛˛»´­ Đ®±˝»­­ć ®«˛˛·˛ą

ÎÍĘĐ Đ®±˝»­­ć ®«˛˛·˛ą

Ú±®©ż®Ľ·˛ąć »˛żľ´»Ľ

Đ»®·±Ľ·˝ ®»±°¬·ł·¦ż¬·±˛ć »Ş»®§ íđ ­»˝±˛Ľ­ô ˛»¨¬ ·˛ ďď ­»˝±˛Ľ­

Đ»®·±Ľ·˝ ż«¬±óľ© ˝±´´»˝¬·±˛ć Ľ·­żľ´»Ľ

ĚËŇŇŰÔ ŇßÓŰ ÜŰÍĚ×ŇßĚ×ŃŇ ËĐ ×Ú ÜŃÉŇ ×Ú ÍĚßĚŰńĐÎŃĚ

ĐۨďÁ¬đ ďçîňďęčň¨ňíí ó Í»đńđňďď «°ń«°

ĐۨîÁ¬đ ďçîňďęčň¨ňďé Í»đńđňďď ó «°ń«°

Ü·­°´ż§»Ľ ď ř±ş ď÷ ¸»żĽ­ô đ ř±ş đ÷ ł·Ľ°±·˛¬­ô ď ř±ş ď÷ ¬ż·´­

Đۨîý­¸±© ł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­ ľ®·»ş

Í·ą˛ż´·˛ą Í«łłż®§ć

ÔÍĐ Ě«˛˛»´­ Đ®±˝»­­ć ®«˛˛·˛ą

ÎÍĘĐ Đ®±˝»­­ć ®«˛˛·˛ą

Ú±®©ż®Ľ·˛ąć »˛żľ´»Ľ

Đ»®·±Ľ·˝ ®»±°¬·ł·¦ż¬·±˛ć »Ş»®§ íđ ­»˝±˛Ľ­ô ˛»¨¬ ·˛ î ­»˝±˛Ľ­

Đ»®·±Ľ·˝ ż«¬±óľ© ˝±´´»˝¬·±˛ć Ľ·­żľ´»Ľ

ĚËŇŇŰÔ ŇßÓŰ ÜŰÍĚ×ŇßĚ×ŃŇ ËĐ ×Ú ÜŃÉŇ ×Ú ÍĚßĚŰńĐÎŃĚ

ĐۨîÁ¬đ ďçîňďęčň¨ňďé ó Í»đńđňďď «°ń«°

ĐۨďÁ¬đ ďçîňďęčň¨ňíí Í»đńđňďď ó «°ń«°

Ü·­°´ż§»Ľ ď ř±ş ď÷ ¸»żĽ­ô đ ř±ş đ÷ ł·Ľ°±·˛¬­ô ď ř±ş ď÷ ¬ż·´­

Note If the tunnel does not come up, check these conditions:

a) The required global commands are implemented on the P and PE routers.

b) The required ISIS commands are implemented on the P and PE routers.

c) The required interface commands are implemented on the P and PE routers.

d) The explicit tunnel path is correctly configured.

e) The ingress tunnel interface commands are correctly configured.

Page 781: Implementing cisco mpls

110 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

You have used show ip route to verify that the tunnel is in the global routing table.

Đۨďý­¸±© ·° ®±«¬»

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óîô ·ż ó ×Íó×Í ·˛¬»® ż®»ż

ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»ô ± ó ŃÜÎ

Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďçîňďęčň¨ňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­

· Ôî ďçîňďęčň¨ňçéńíî ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň¨ňďďîńîč ĹďďëńîđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň¨ňęěńîč ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň¨ňčďńíî ĹďďëńîđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň¨ňííńíî ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňííô Ě«˛˛»´đ

Ý ďçîňďęčň¨ňěčńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďď

Ý ďçîňďęčň¨ňďéńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

ďçîňďęčňďđđňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ô î łż­µ­

· Ôî ďçîňďęčňďđđňčńîç ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčňďđđňîěńîç ĹďďëńîđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčňďđđňďęńîç ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčňďđđňíîńîç ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčňďđđňďîçńíî ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

ďçîňďęčň§ňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­

· Ôî ďçîňďęčň§ňçéńíî ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňďďîńîč ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňęěńîč ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňčďńíî ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňííńíî ĹďďëńëđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňěčńîč ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňďéńíî ĹďďëńëđĂ Ş·ż ďçîňďęčň¨ňëđô Í»®·ż´đńđňďďď

Đۨďý

Note In these results, x is your SP, and y is the other SP as viewed from PEx1. Depending on

how far along the other SP is in configuring its devices, you may not see the y routes. You

need be concerned only about the x routes.

Page 782: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 111

Đۨîý­¸±© ·° ®±«¬»

ݱĽ»­ć Ý ó ˝±˛˛»˝¬»Ľô Í ó ­¬ż¬·˝ô Î ó Î×Đô Ó ó ł±ľ·´»ô Ţ ó ŢŮĐ

Ü ó Ű×ŮÎĐô ŰČ ó Ű×ŮÎĐ »¨¬»®˛ż´ô Ń ó ŃÍĐÚô ×ß ó ŃÍĐÚ ·˛¬»® ż®»ż

Ňď ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» ďô Ňî ó ŃÍĐÚ ŇÍÍß »¨¬»®˛ż´ ¬§°» î

Űď ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» ďô Űî ó ŃÍĐÚ »¨¬»®˛ż´ ¬§°» î

· ó ×Íó×Íô Ôď ó ×Íó×Í ´»Ş»´óďô Ôî ó ×Íó×Í ´»Ş»´óîô ·ż ó ×Íó×Í ·˛¬»® ż®»ż

ö ó ˝ż˛Ľ·Ľż¬» Ľ»şż«´¬ô Ë ó °»®ó«­»® ­¬ż¬·˝ ®±«¬»ô ± ó ŃÜÎ

Đ ó °»®·±Ľ·˝ Ľ±©˛´±żĽ»Ľ ­¬ż¬·˝ ®±«¬»

Ůż¬»©ż§ ±ş ´ż­¬ ®»­±®¬ ·­ ˛±¬ ­»¬

ďçîňďęčň¨ňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­

· Ôî ďçîňďęčň¨ňçéńíî ĹďďëńîđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň¨ňďďîńîč ĹďďëńîđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

Ý ďçîňďęčň¨ňęěńîč ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň¨ňčďńíî ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

Ý ďçîňďęčň¨ňííńíî ·­ Ľ·®»˝¬´§ ˝±˛˛»˝¬»Ľô Ô±±°ľż˝µđ

· Ôî ďçîňďęčň¨ňěčńîč ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň¨ňďéńíî ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňďéô Ě«˛˛»´đ

ďçîňďęčňďđđňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô ë ­«ľ˛»¬­ô î łż­µ­

· Ôî ďçîňďęčňďđđňčńîç ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčňďđđňîěńîç ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčňďđđňďęńîç ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčňďđđňíîńîç ĹďďëńîđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčňďđđňďîçńíî ĹďďëńíđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

ďçîňďęčň§ňđńîě ·­ Şż®·żľ´§ ­«ľ˛»¬¬»Ľô é ­«ľ˛»¬­ô î łż­µ­

· Ôî ďçîňďęčň§ňçéńíî ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňďďîńîč ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňęěńîč ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňčďńíî ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňííńíî ĹďďëńëđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňěčńîč ĹďďëńěđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

· Ôî ďçîňďęčň§ňďéńíî ĹďďëńëđĂ Ş·ż ďçîňďęčň¨ňęęô Í»®·ż´đńđňďďď

Đۨîý

Note In these results, x is your SP, and y is the other SP as viewed from PEx2. Depending on

how far along the other SP is in configuring its devices, you may not see the y routes. You

need be concerned only about the “x” routes.

Page 783: Implementing cisco mpls

112 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

You have used the show ip cef network command to verify that the IP traffic toward the tunnel destination gets forwarded through the tunnel interface.

Đۨďý­¸±© ·° ˝»ş ďçîňďęčň¨ňíí

ďçîňďęčň¨ňííńíîô Ş»®­·±˛ îëô »°±˝¸ đ

đ °ż˝µ»¬­ô 𠾧¬»­

¬żą ·˛ş±®łż¬·±˛ ­»¬ô ­¸ż®»Ľ

´±˝ż´ ¬żąć íđ

şż­¬ ¬żą ®»©®·¬» ©·¬¸ Ě«đô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć ĄííŁ

Ş·ż ďçîňďęčň¨ňííô Ě«˛˛»´đô ďď Ľ»°»˛Ľ»˛˝·»­

˛»¨¬ ¸±° ďçîňďęčň¨ňííô Ě«˛˛»´đ

Şż´·Ľ żĽ¶ż˝»˛˝§

¬żą ®»©®·¬» ©·¬¸ Ě«đô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć ĄííŁ

Đۨîý­¸±© ·° ˝»ş ďçîňďęčň¨ňďé

ďçîňďęčň¨ňďéńíîô Ş»®­·±˛ îéô »°±˝¸ đ

đ °ż˝µ»¬­ô 𠾧¬»­

¬żą ·˛ş±®łż¬·±˛ ­»¬

´±˝ż´ ¬żąć íî

şż­¬ ¬żą ®»©®·¬» ©·¬¸ Ě«đô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć ĄíďŁ

Ş·ż ďçîňďęčň¨ňďéô Ě«˛˛»´đô ďď Ľ»°»˛Ľ»˛˝·»­

˛»¨¬ ¸±° ďçîňďęčň¨ňďéô Ě«˛˛»´đ

Şż´·Ľ żĽ¶ż˝»˛˝§

¬żą ®»©®·¬» ©·¬¸ Ě«đô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć ĄíďŁ

You have used the show ip cef vrf name network command to verify that the MPLS VPN traffic gets forwarded through the tunnel interface.

Đۨďý­¸±© ·° ˝»ş Ş®ş Ý«­¬ß ďđňďň¨îňěç

ďđňďň¨îňěçńíîô Ş»®­·±˛ îđô »°±˝¸ đ

đ °ż˝µ»¬­ô 𠾧¬»­

¬żą ·˛ş±®łż¬·±˛ ­»¬

´±˝ż´ ¬żąć ĘĐŇ󮱫¬»ó¸»żĽ

şż­¬ ¬żą ®»©®·¬» ©·¬¸ Ě«đô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć Ąíí íěŁ

Ş·ż ďçîňďęčň¨ňííô đ Ľ»°»˛Ľ»˛˝·»­ô ®»˝«®­·Ş»

˛»¨¬ ¸±° ďçîňďęčň¨ňííô Ě«˛˛»´đ Ş·ż ďçîňďęčň¨ňííńíî

Şż´·Ľ żĽ¶ż˝»˛˝§

¬żą ®»©®·¬» ©·¬¸ Ě«đô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć Ąíí íěŁ

Page 784: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 113

Đۨîý­¸ ·° ˝»ş Ş®ş Ý«­¬ß ďđňďň¨ďňěç

ďđňďňě¨ňěçńíîô Ş»®­·±˛ ďîô »°±˝¸ đ

đ °ż˝µ»¬­ô 𠾧¬»­

¬żą ·˛ş±®łż¬·±˛ ­»¬ô ­¸ż®»Ľ

´±˝ż´ ¬żąć ĘĐŇ󮱫¬»ó¸»żĽ

şż­¬ ¬żą ®»©®·¬» ©·¬¸ Ě«đô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć Ąíď íëŁ

Ş·ż ďçîňďęčň¨ňďéô ď Ľ»°»˛Ľ»˛˝§ô ®»˝«®­·Ş»

˛»¨¬ ¸±° ďçîňďęčň¨ňďéô Ě«˛˛»´đ Ş·ż ďçîňďęčň¨ňďéńíî

Şż´·Ľ żĽ¶ż˝»˛˝§

¬żą ®»©®·¬» ©·¬¸ Ě«đô °±·˛¬î°±·˛¬ô ¬żą­ ·ł°±­»Ľć Ąíď íëŁ

You have repeated the traces that you did in Task 1 to verify that the trace now bypasses the direct Px1-to-Px2 link and passes through the P router links.

Ýۨďß⬮ż˝» ďđňďň¨îňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďđňďň¨îňěç

ď ďëđň¨ň¨ďňďč ďî ł­»˝ ďî ł­»˝ ďî ł­»˝

î ďçîňďęčň¨ňëđ ĹßÍ ęëđđďĂ ĹÓĐÔÍć Ôżľ»´­ ííńíě ۨ° đĂ îéé ł­»˝ íđđ ł­»˝ íđď ł­»˝

í ďçîňďęčňďđđňöö ĹßÍ ęëđđďĂ ĹÓĐÔÍć Ôżľ»´­ íîńíě ۨ° đĂ íęč ł­»˝ íčë ł­»˝ îçî ł­»˝

ě ďçîňďęčňďđđňöö ĹßÍ ęëđđďĂ ĹÓĐÔÍć Ôżľ»´­ ííńíě ۨ° đĂ îďé ł­»˝ íîě ł­»˝ îéí ł­»˝

ë ďëđň¨ň¨îňďč ĹßÍ ęëđđďĂ ĹÓĐÔÍć Ôżľ»´ íě ۨ° đĂ ďěě ł­»˝ ďěč ł­»˝ ďěě ł­»˝

ę ďëđň¨ň¨îňďé ĹßÍ ęëđđďĂ çî ł­»˝ ö ďéé ł­»˝

Note The third and fourth router addresses will vary, based on the SP.

Ýۨîß⬮ż˝» ďđňďň¨ďňěç

̧°» »­˝ż°» ­»Ż«»˛˝» ¬± żľ±®¬ň

Ě®ż˝·˛ą ¬¸» ®±«¬» ¬± ďđňďň¨ďňěç

ď ďëđň¨ň¨îňďč ďî ł­»˝ ďî ł­»˝ ďę ł­»˝

î ďçîňďęčň¨ňęę ĹÓĐÔÍć Ôżľ»´­ íďńíë ۨ° đĂ íěđ ł­»˝ îçé ł­»˝ íčč ł­»˝

í ďçîňďęčňďđđňöö ĹÓĐÔÍć Ôżľ»´­ ííńíë ۨ° đĂ îěç ł­»˝ îçę ł­»˝ íěç ł­»˝

ě ďçîňďęčňďđđňöö ĹÓĐÔÍć Ôżľ»´­ íďńíë ۨ° đĂ îěč ł­»˝ îçé ł­»˝ íđđ ł­»˝

ë ďëđň¨ň¨ďňďč ĹßÍ ęëđđďĂ ĹÓĐÔÍć Ôżľ»´ íë ۨ° đĂ ďěç ł­»˝ ďěě ł­»˝ ďěč ł­»˝

ę ďëđň¨ň¨ďňďé ĹßÍ ęëđđďĂ ďëę ł­»˝ ö čč ł­»˝

Note The third and fourth router addresses will vary, based on the SP.

Page 785: Implementing cisco mpls

114 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Answer Key The correct answers and expected solutions for the activities that are described in this guide appear here.

Lab 2-1 Answer Key: Establishing the Service Provider IGP Routing Environment

When you complete this activity, your router will be similar to the results here, with differences that are specific to your SP. The PE routers need the EIGRP network 150.x.0.0 command only for testing. It can be removed after testing. The CE routers will need network 150.x.0.0 in a later lab, so you could add the network statement in this lab.

Task 1: Configure the Service Provider IP Interfaces Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ý·˛¬»®şż˝» ´±±°ľż˝µđ

Đۨďř˝±˛ş·ąó·ş÷ý·° żĽĽ®»­­ ďçîňďęčň¨ňďé îëëňîëëňîëëňîëë

Đۨďř˝±˛ş·ąó·ş÷ý˛± ­¸«¬Ľ±©˛

Đۨďř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» ­»®·ż´ đńđ

Đۨďř˝±˛ş·ąó·ş÷ý»˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§

Đۨďř˝±˛ş·ąó·ş÷ýş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝±

Đۨďř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» Í»®·ż´đńđňďđď °±·˛¬ó¬±ó°±·˛¬

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨ďňďč îëëňîëëňîëëňîěđ

Đۨďř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďđď

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·˛¬»®şż˝» Í»®·ż´đńđňďđî °±·˛¬ó¬±ó°±·˛¬

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨ďňíě îëëňîëëňîëëňîěđ

Đۨďř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďđď

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·˛¬»®şż˝» Í»®·ż´đńđňďďď °±·˛¬ó¬±ó°±·˛¬

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďçîňďęčň¨ňěç îëëňîëëňîëëňîěđ

Đۨďř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďď

Configuration steps on PEx2:

Đۨîř˝±˛ş·ą÷ý·˛¬»®şż˝» ´±±°ľż˝µđ

Đۨîř˝±˛ş·ąó·ş÷ý·° żĽĽ®»­­ ďçîňďęčň¨ňíí îëëňîëëňîëëňîëë

Đۨîř˝±˛ş·ąó·ş÷ý˛± ­¸«¬Ľ±©˛

Đۨîř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» ­»®·ż´ đńđ

Đۨîř˝±˛ş·ąó·ş÷ý»˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§

Đۨîř˝±˛ş·ąó·ş÷ýş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝±

Đۨîř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» Í»®·ż´đńđňďđď °±·˛¬ó¬±ó°±·˛¬

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨îňďč îëëňîëëňîëëňîěđ

Đۨîř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďđď

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·˛¬»®şż˝» Í»®·ż´đńđňďđî °±·˛¬ó¬±ó°±·˛¬

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨îňíě îëëňîëëňîëëňîěđ

Đۨîř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďđď

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·˛¬»®şż˝» Í»®·ż´đńđňďďď °±·˛¬ó¬±ó°±·˛¬

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďçîňďęčň¨ňęë îëëňîëëňîëëňîěđ

Đۨîř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďď

Page 786: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 115

Configuration steps on Px1:

Шďř˝±˛ş·ą÷ý·˛¬»®şż˝» ´±±°ľż˝µđ

Шďř˝±˛ş·ąó·ş÷ý·° żĽĽ®»­­ ďçîňďęčň¨ňčď îëëňîëëňîëëňîëë

Шďř˝±˛ş·ąó·ş÷ý˛± ­¸«¬Ľ±©˛

Шďř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» ­»®·ż´ đńđ

Шďř˝±˛ş·ąó·ş÷ý»˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§

Шďř˝±˛ş·ąó·ş÷ýş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝±

Шďř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» Í»®·ż´đńđňďďď °±·˛¬ó¬±ó°±·˛¬

Шďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďçîňďęčň¨ňëđ îëëňîëëňîëëňîěđ

Шďř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďď

Шďř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» Í»®·ż´đńđňďďî °±·˛¬ó¬±ó°±·˛¬

Шďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďçîňďęčň¨ňďďí îëëňîëëňîëëňîěđ

Шďř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďî

Configuration steps on Px2:

Шîř˝±˛ş·ą÷ý·˛¬»®şż˝» ´±±°ľż˝µđ

Шîř˝±˛ş·ąó·ş÷ý·° żĽĽ®»­­ ďçîňďęčň¨ňçé îëëňîëëňîëëňîëë

Шîř˝±˛ş·ąó·ş÷ý˛± ­¸«¬Ľ±©˛

Шîř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» ­»®·ż´ đńđ

Шîř˝±˛ş·ąó·ş÷ý»˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§

Шîř˝±˛ş·ąó·ş÷ýş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝±

Шîř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» Í»®·ż´đńđňďďď °±·˛¬ó¬±ó°±·˛¬

Шîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďçîňďęčň¨ňęę îëëňîëëňîëëňîěđ

Шîř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďď

Шîř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» Í»®·ż´đńđňďďî °±·˛¬ó¬±ó°±·˛¬

Шîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďçîňďęčň¨ňďďě îëëňîëëňîëëňîěđ

Шîř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďî

Configuration steps on CEx1A routers:

Ýۨďßř˝±˛ş·ą÷ý·˛¬»®şż˝» ´±±°ľż˝µđ

Ýۨďßř˝±˛ş·ąó·ş÷ý·° żĽĽ®»­­ ďđňďň¨ďňěç îëëňîëëňîëëňîëë

Ýۨďßř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» »¬¸»®˛»¬đńđ

Ýۨďßř˝±˛ş·ąó·ş÷ý·° żĽĽ®»­­ ďđňďň¨ďňďé îëëňîëëňîëëňîěđ

Ýۨďßř˝±˛ş·ąó·ş÷ý˛± ­¸«¬Ľ±©˛

Ýۨďßř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» ­»®·ż´ đńđ

Ýۨďßř˝±˛ş·ąó·ş÷ý»˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§

Ýۨďßř˝±˛ş·ąó·ş÷ýş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝±

Ýۨďßř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» Í»®·ż´đńđňďđď °±·˛¬ó¬±ó°±·˛¬

Ýۨďßř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨ďňďé îëëňîëëňîëëňîěđ

Ýۨďßř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďđď

Page 787: Implementing cisco mpls

116 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Configuration steps on CEx1B routers:

ÝۨďŢř˝±˛ş·ą÷ý·˛¬»®şż˝» ´±±°ľż˝µđ

ÝۨďŢř˝±˛ş·ąó·ş÷ý·° żĽĽ®»­­ ďđňîň¨ďňěç îëëňîëëňîëëňîëë

ÝۨďŢř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» »¬¸»®˛»¬đńđ

ÝۨďŢř˝±˛ş·ąó·ş÷ý·° żĽĽ®»­­ ďđňîň¨ďňďé îëëňîëëňîëëňîěđ

ÝۨďŢř˝±˛ş·ąó·ş÷ý˛± ­¸«¬Ľ±©˛

ÝۨďŢř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» ­»®·ż´ đńđ

ÝۨďŢř˝±˛ş·ąó·ş÷ý»˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§

ÝۨďŢř˝±˛ş·ąó·ş÷ýş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝±

ÝۨďŢř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» Í»®·ż´đńđňďđî °±·˛¬ó¬±ó°±·˛¬

ÝۨďŢř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨ďňíí îëëňîëëňîëëňîěđ

ÝۨďŢř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďđî

Configuration steps on CEx2A routers:

Ýۨîßř˝±˛ş·ą÷ý·˛¬»®şż˝» ´±±°ľż˝µđ

Ýۨîßř˝±˛ş·ąó·ş÷ý·° żĽĽ®»­­ ďđňďň¨îňěç îëëňîëëňîëëňîëë

Ýۨîßř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» »¬¸»®˛»¬đńđ

Ýۨîßř˝±˛ş·ąó·ş÷ý·° żĽĽ®»­­ ďđňďň¨îňďé îëëňîëëňîëëňîěđ

Ýۨîßř˝±˛ş·ąó·ş÷ý˛± ­¸«¬Ľ±©˛

Ýۨîßř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» ­»®·ż´ đńđ

Ýۨîßř˝±˛ş·ąó·ş÷ý»˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§

Ýۨîßř˝±˛ş·ąó·ş÷ýş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝±

Ýۨîßř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» Í»®·ż´đńđňďđď °±·˛¬ó¬±ó°±·˛¬

Ýۨîßř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨îňďé îëëňîëëňîëëňîěđ

Ýۨîßř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďđď

Configuration steps on CEx2B routers:

ÝۨîŢř˝±˛ş·ą÷ý·˛¬»®şż˝» ´±±°ľż˝µđ

ÝۨîŢř˝±˛ş·ąó·ş÷ý·° żĽĽ®»­­ ďđňîň¨îňěç îëëňîëëňîëëňîëë

ÝۨîŢř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» »¬¸»®˛»¬đńđ

ÝۨîŢř˝±˛ş·ąó·ş÷ý·° żĽĽ®»­­ ďđňîň¨îňďé îëëňîëëňîëëňîěđ

ÝۨîŢř˝±˛ş·ąó·ş÷ý˛± ­¸«¬Ľ±©˛

ÝۨîŢř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» ­»®·ż´ đńđ

ÝۨîŢř˝±˛ş·ąó·ş÷ý»˛˝ż°­«´ż¬·±˛ ş®żł»ó®»´ż§

ÝۨîŢř˝±˛ş·ąó·ş÷ýş®żł»ó®»´ż§ ´ł·ó¬§°» ˝·­˝±

ÝۨîŢř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» Í»®·ż´đńđňďđî °±·˛¬ó¬±ó°±·˛¬

ÝۨîŢř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨îňíí îëëňîëëňîëëňîěđ

ÝۨîŢř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďđî

Page 788: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 117

Task 2: Configure the Service Provider IGP Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ý®±«¬»® »·ą®° ď

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ ř±°¬·±˛ż´÷

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďçîňďęčň¨ňđ

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛± ż«¬±ó­«łłż®§

Configuration steps on PEx2:

Đۨîř˝±˛ş·ą÷ý®±«¬»® »·ą®° ď

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ ř±°¬·±˛ż´÷

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďçîňďęčň¨ňđ

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛± ż«¬±ó­«łłż®§

Configuration steps on Px1:

Шďř˝±˛ş·ą÷ý®±«¬»® »·ą®° ď

Шďř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďçîňďęčň¨ňđ

Шďř˝±˛ş·ąó®±«¬»®÷ý˛± ż«¬±ó­«łłż®§

Configuration steps on Px2:

Шîř˝±˛ş·ą÷ý®±«¬»® »·ą®° ď

Шîř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďçîňďęčň¨ňđ

Шîř˝±˛ş·ąó®±«¬»®÷ý˛± ż«¬±ó­«łłż®§

Configuration steps on all CE routers:

Ýۨööř˝±˛ş·ą÷ý®±«¬»® ®·°

Ýۨööř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďđňđňđňđ

Ýۨööř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ ř±°¬·±˛ż´÷

Ýۨööř˝±˛ş·ąó®±«¬»®÷ý˛± ż«¬±ó­«łłż®§

Page 789: Implementing cisco mpls

118 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 3-1 Answer Key: Establishing the Core MPLS Environment

When you complete this activity, your router will be similar to the results here, with differences that are specific to your SP.

Task 1: Enable LDP on Your PE and P Routers Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ý·° ˝»ş

Đۨďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďď

Đۨďř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ´żľ»´ °®±¬±˝±´ ´Ľ°

Đۨďř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ·°

Note The mpls label protocol ldp command can be issued at the global configuration level.

Configuration steps on PEx2:

Đۨîř˝±˛ş·ą÷ý·° ˝»ş

Đۨîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďď

Đۨîř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ´żľ»´ °®±¬±˝±´ ´Ľ°

Đۨîř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ·°

Configuration steps on Px1:

Шďř˝±˛ş·ą÷ý·° ˝»ş

Шďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďď

Шďř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ´żľ»´ °®±¬±˝±´ ´Ľ°

Шďř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ·°

Шďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďî

Шďř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ´żľ»´ °®±¬±˝±´ ´Ľ°

Шďř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ·°

Configuration steps on Px2:

Шîř˝±˛ş·ą÷ý·° ˝»ş

Шîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďď

Шîř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ´żľ»´ °®±¬±˝±´ ´Ľ°

Шîř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ·°

Шîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďî

Шîř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ´żľ»´ °®±¬±˝±´ ´Ľ°

Шîř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ·°

Note The mpls ip command is issued to enable MPLS on an interface but will be displayed in the

show running-config command output as the tag-switching ip command.

Page 790: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 119

Task 2: Experiment with TTL Propagation Configuration steps on PEx1 and PEx2 to enable MPLS TTL propagation:

Đۨöř˝±˛ş·ą÷ýł°´­ ·° °®±°żąż¬»ó¬¬´

Configuration steps on Px1 and Px2 to enable MPLS TTL propagation:

Шöř˝±˛ş·ą÷ýł°´­ ·° °®±°żąż¬»ó¬¬´

Configuration steps on PEx1 and PEx2 to disable MPLS TTL propagation:

Đۨöř˝±˛ş·ą÷ý˛± ł°´­ ·° °®±°żąż¬»ó¬¬´

Configuration steps on Px1 and Px2 to disable MPLS TTL propagation:

Шöř˝±˛ş·ą÷ý˛± ł°´­ ·° °®±°żąż¬»ó¬¬´

Task 3: Configure Conditional Label Distribution

Note There are various ways to construct an access list to accomplish the desired result. This

example shows one way. The key, however, is to meet the task objective.

Configuration steps on PEx1 and PEx2:

Đۨöř˝±˛ş·ą÷ý˛± ł°´­ ´Ľ° żĽŞ»®¬·­»ó´żľ»´­

Đۨöř˝±˛ş·ą÷ýł°´­ ´Ľ° żĽŞ»®¬·­»ó´żľ»´­ ş±® çđ

Đۨöř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ çđ °»®ł·¬ ďëđň¨ňđňđ đňđňîëëňîëë

Đۨöř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ çđ °»®ł·¬ ďçîňďęčň¨ňďę đňđňđňďë

Đۨö˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ çđ °»®ł·¬ ďçîňďęčň¨ňíî đňđňđňďë

Đۨöř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ çđ °»®ł·¬ ďçîňďęčň¨ňčđ đňđňđňďë

Đۨöř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ çđ °»®ł·¬ ďçîňďęčň¨ňçę đňđňđňďë

Configuration steps on Px1 and Px2:

Шöř˝±˛ş·ą÷ý˛± ł°´­ ´Ľ° żĽŞ»®¬·­»ó´żľ»´­

Шöř˝±˛ş·ą÷ýł°´­ ´Ľ° żĽŞ»®¬·­»ó´żľ»´­ ş±® çđ

Шöř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ çđ °»®ł·¬ ďëđň¨ňđňđ đňđňîëëňîëë

Шöř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ çđ °»®ł·¬ ďçîňďęčň¨ňďę đňđňđňďë

Шöř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ çđ °»®ł·¬ ďçîňďęčň¨ňíî đňđňđňďë

Шöř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ çđ °»®ł·¬ ďçîňďęčň¨ňčđ đňđňđňďë

Шöř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ çđ °»®ł·¬ ďçîňďęčň¨ňçę đňđňđňďë

Task 4: Remove Conditional Label Distribution Configuration steps on PEx1 and PEx2:

Đۨöř˝±˛ş·ą÷ý˛± ł°´­ ´Ľ° żĽŞ»®¬·­»ó´żľ»´­ ş±® çđ

Đۨöř˝±˛ş·ą÷ýł°´­ ´Ľ° żĽŞ»®¬·­»ó´żľ»´­

Đۨöř˝±˛ş·ą÷ý˛± ż˝˝»­­ó´·­¬ çđ

Configuration steps on Px1 and Px2:

Шöř˝±˛ş·ą÷ý˛± ł°´­ ´Ľ° żĽŞ»®¬·­»ó´żľ»´­ ş±® çđ

Шöř˝±˛ş·ą÷ýł°´­ ´Ľ° żĽŞ»®¬·­»ó´żľ»´­

Шöř˝±˛ş·ą÷ý˛± ż˝˝»­­ó´·­¬ çđ

Page 791: Implementing cisco mpls

120 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 5-1 Answer Key: Configuring Initial MPLS VPN Setup

When you complete this activity, your router will be similar to the results here, with differences that are specific to your SP.

Task 1: Configure MP-BGP Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďçîňďęčň¨ňíí ®»ł±¬»óż­ ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďçîňďęčň¨ňíí «°Ľż¬»ó­±«®˝» ´±±°ľż˝µ đ

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛± ż«¬±ó­«łłż®§

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ Ş°˛Şě

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďçîňďęčň¨ňíí ż˝¬·Şż¬»

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďçîňďęčň¨ňíí ˛»¨¬ó¸±°ó­»´ş

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďçîňďęčň¨ňíí ­»˛Ľó˝±łł«˛·¬§ ľ±¬¸

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ż«¬±ó­«łłż®§

Configuration steps on PEx2:

Đۨîř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďçîňďęčň¨ňďé ®»ł±¬»óż­ ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďçîňďęčň¨ňďé «°Ľż¬»ó­±«®˝» ´±±°ľż˝µ đ

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛± ż«¬±ó­«łłż®§

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ Ş°˛Şě

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďçîňďęčň¨ňďé ż˝¬·Şż¬»

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďçîňďęčň¨ňďé ˛»¨¬ó¸±°ó­»´ş

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďçîňďęčň¨ňďé ­»˛Ľó˝±łł«˛·¬§ ľ±¬¸

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ż«¬±ó­«łłż®§

Task 2: Configure VRF Tables Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ý·° Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ąóŞ®ş÷ý®Ľ ¨ćďđ

Đۨďř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ľ±¬¸ ¨ćďđ

Đۨďř˝±˛ş·ą÷ý·° Ş®ş Ý«­¬Ţ

Đۨďř˝±˛ş·ąóŞ®ş÷ý®Ľ ¨ćîđ

Đۨďř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ľ±¬¸ ¨ćîđ

Đۨďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďđď

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° Ş®ş ş±®©ż®Ľ·˛ą Ý«­¬ß

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨ďňďč îëëňîëëňîëëňîěđ

Đۨďř˝±˛ş·ą÷ý·˛¬ ­»®·ż´đńđňďđî

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° Ş®ş ş±®©ż®Ľ·˛ą Ý«­¬Ţ

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨ďňíě îëëňîëëňîëëňîěđ

Đۨďř˝±˛ş·ą÷ý®±«¬»® ®·°

Đۨďř˝±˛ş·ąó®±«¬»®÷ýŞ»®­·±˛ î

Page 792: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 121

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»¬©±®µ ďëđň¨ňđňđ

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ż«¬±ó­«łłż®§

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ľą° ęëđđď ł»¬®·˝ ¬®ż˛­°ż®»˛¬

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»¬©±®µ ďëđň¨ňđňđ

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ż«¬±ó­«łłż®§

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ľą° ęëđđď ł»¬®·˝ ¬®ż˛­°ż®»˛¬

Đۨďř˝±˛ş·ąó®±«¬»®÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ż«¬±ó­«łłż®§

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ®·°

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý»¨·¬

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ż«¬±ó­«łłż®§

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ®·°

Configuration steps on PEx2:

Đۨîř˝±˛ş·ą÷ý·° Ş®ş Ý«­¬ß

Đۨîř˝±˛ş·ąóŞ®ş÷ý®Ľ ¨ćďđ

Đۨîř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ľ±¬¸ ¨ćďđ

Đۨîř˝±˛ş·ą÷ý·° Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąóŞ®ş÷ý®Ľ ¨ćîđ

Đۨîř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ľ±¬¸ ¨ćîđ

Đۨîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďđď

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° Ş®ş ş±®©ż®Ľ·˛ą Ý«­¬ß

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨îňďč îëëňîëëňîëëňîěđ

Đۨîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďđî

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° Ş®ş ş±®©ż®Ľ·˛ą Ý«­¬Ţ

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨îňíě îëëňîëëňîëëňîěđ

Đۨîř˝±˛ş·ą÷ý®±«¬»® ®·°

Đۨîř˝±˛ş·ąó®±«¬»®÷ýŞ»®­·±˛ î

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»¬©±®µ ďëđň¨ňđňđ

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ż«¬±ó­«łłż®§

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ľą° ęëđđď ł»¬®·˝ ¬®ż˛­°ż®»˛¬

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»¬©±®µ ďëđň¨ňđňđ

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ż«¬±ó­«łłż®§

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ľą° ęëđđď ł»¬®·˝ ¬®ż˛­°ż®»˛¬

Đۨîř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ż«¬±ó­«łłż®§

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ®·°

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ż«¬±ó­«łłż®§

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ®·°

Page 793: Implementing cisco mpls

122 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 5-2 Answer Key: Running EIGRP Between PE and CE Routers

When you complete this activity, your router will be similar to the results here, with differences that are specific to your SP.

Task 1: Enable an EIGRP VPN Configuration steps on CEx1A:

Ýۨďßř˝±˛ş·ą÷ý˛± ®±«¬»® ®·°

Ýۨďßř˝±˛ş·ą÷ý®±«¬»® »·ą®° ¨

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďđňđňđňđ

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý˛± ż«¬±ó­«łłż®§

Configuration steps on CEx2B:

ÝۨîŢř˝±˛ş·ą÷ý˛± ®±«¬»® ®·°

ÝۨîŢř˝±˛ş·ą÷ý®±«¬»® »·ą®° ¨

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďđňđňđňđ

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý˛± ż«¬±ó­«łłż®§

Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ý®±«¬»® ®·°

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛± żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ą÷ý®±«¬»® »·ą®° ď

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ýż«¬±˛±ł±«­ó­§­¬»ł ¨

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»¬©±®µ ďëđň¨ň¨ďňďę đňđňđňďë

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ż«¬±ó­«łłż®§

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ľą° ęëđđď ł»¬®·˝ ďđđđđ ďđđ îëë ď ďëđđ

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý»¨·¬

Đۨďř˝±˛ş·ąó®±«¬»®÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ®»Ľ·­¬®·ľ«¬» ®·°

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» »·ą®° ¨ ł»¬®·˝ ď

Configuration steps on PEx2:

Đۨîř˝±˛ş·ą÷ý®±«¬»® ®·°

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛± żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąó®±«¬»®÷ý®±«¬»® »·ą®° ď

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ýż«¬±˛±ł±«­ó­§­¬»ł ¨

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»¬©±®µ ďëđň¨ň¨îňíî đňđňđňďë

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ż«¬±ó­«łłż®§

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ľą° ęëđđď ł»¬®·˝ ďđđđđ ďđđ îëë ď ďëđđ

Page 794: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 123

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý»¨·¬

Đۨîř˝±˛ş·ąó®±«¬»®÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ®»Ľ·­¬®·ľ«¬» ®·°

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» »·ą®° ¨ ł»¬®·˝ ď

Page 795: Implementing cisco mpls

124 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 5-3 Answer Key: Running OSPF Between PE and CE Routers

When you complete this activity, your router will be similar to the results here, with differences that are specific to your SP.

Task 1: Configure OSPF as the PE-CE Routing Protocol Configuration steps on CEx1A:

Ýۨďßř˝±˛ş·ą÷ý˛± ®±«¬»® »·ą®° ¨

Ýۨďßř˝±˛ş·ą÷ý®±«¬»® ±­°ş ď

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ đňđňîëëňîëë ż®»ż đ

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďđňďň¨ďňěç đňđňđňđ ż®»ż đ

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďđňďň¨ďňďę đňđňđňďë ż®»ż ď

Configuration steps on CEx1B:

ÝۨďŢř˝±˛ş·ą÷ý˛± ®±«¬»® ®·°

ÝۨďŢř˝±˛ş·ą÷ý®±«¬»® ±­°ş î

ÝۨďŢř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ đňđňîëëňîëë ż®»ż đ

ÝۨďŢř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďđňîň¨ďňěç đňđňđňđ ż®»ż đ

ÝۨďŢř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďđňîň¨ďňďę đňđňđňďë ż®»ż ď

Configuration steps on CEx2A:

Ýۨîßř˝±˛ş·ą÷ý˛± ®±«¬»® ®·°

Ýۨîßř˝±˛ş·ą÷ý®±«¬»® ±­°ş ď

Ýۨîßř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ đňđňîëëňîëë ż®»ż đ

Ýۨîßř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďđňďň¨îňěç đňđňđňđ ż®»ż đ

Ýۨîßř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďđňďň¨îňďę đňđňđňďë ż®»ż ď

Configuration steps on CEx2B:

ÝۨîŢř˝±˛ş·ą÷ý˛± ®±«¬»® »·ą®° ¨

ÝۨîŢř˝±˛ş·ą÷ý®±«¬»® ±­°ş î

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ đňđňîëëňîëë ż®»ż đ

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďđňîň¨îňěç đňđňđňđ ż®»ż đ

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďđňîň¨îňďę đňđňđňďë ż®»ż ď

Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ý˛± ®±«¬»® ®·°

Đۨďř˝±˛ş·ą÷ý®±«¬»® ±­°ş î Ş®ş Ý«­¬Ţ

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ đňđňîëëňîëë ż®»ż đ

Đۨďř˝±˛ş·ąó®±«¬»®÷ý®»Ľ·­¬®·ľ«¬» ľą° ęëđđď ­«ľ˛»¬­

Đۨďř˝±˛ş·ąó®±«¬»®÷ý»¨·¬

Đۨďř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛± ®»Ľ·­¬®·ľ«¬» ®·°

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ±­°ş î

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý»¨·¬

Page 796: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 125

Đۨďř˝±˛ş·ą÷ý®±«¬»® »·ą®° ď

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛± żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ą÷ý®±«¬»® ±­°ş ď Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ đňđňîëëňîëë ż®»ż đ

Đۨďř˝±˛ş·ąó®±«¬»®÷ý®»Ľ·­¬®·ľ«¬» ľą° ęëđđď ­«ľ˛»¬­

Đۨďř˝±˛ş·ąó®±«¬»®÷ý»¨·¬

Đۨďř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ®»Ľ·­¬®·ľ«¬» »·ą®° ¨

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ±­°ş ď

Configuration steps on PEx2:

Đۨîř˝±˛ş·ą÷ý˛± ®±«¬»® ®·°

Đۨîř˝±˛ş·ą÷ý®±«¬»® ±­°ş ď Ş®ş Ý«­¬ß

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ đňđňîëëňîëë ż®»ż đ

Đۨîř˝±˛ş·ąó®±«¬»®÷ý®»Ľ·­¬®·ľ«¬» ľą° ęëđđď ­«ľ˛»¬­

Đۨîř˝±˛ş·ąó®±«¬»®÷ý»¨·¬

Đۨîř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛± ®»Ľ·­¬®·ľ«¬» ®·°

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ±­°ş ď

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý»¨·¬

Đۨîř˝±˛ş·ą÷ý®±«¬»® »·ą®° ď

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛± żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ą÷ý®±«¬»® ±­°ş î Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ đňđňîëëňîëë ż®»ż đ

Đۨîř˝±˛ş·ąó®±«¬»®÷ý®»Ľ·­¬®·ľ«¬» ľą° ęëđđď ­«ľ˛»¬­

Đۨîř˝±˛ş·ąó®±«¬»®÷ý»¨·¬

Đۨîř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ®»Ľ·­¬®·ľ«¬» »·ą®° ¨

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ±­°ş î

Page 797: Implementing cisco mpls

126 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 5-4 Answer Key: Running BGP Between PE and CE Routers

When you complete this activity, your router will be similar to the results here, with differences that are specific to your SP.

Task 1: Configure BGP as the PE-CE Routing Protocol Configuration steps on CEx1A:

Ýۨďßř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđ¨ď

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňďč ®»ł±¬»óż­ ęëđđď

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý˛± ż«¬±ó­«łłż®§

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý®»Ľ·­¬®·ľ«¬» ±­°ş ď

Ýۨďßř˝±˛ş·ą÷ý®±«¬»® ±­°ş ď

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý®»Ľ·­¬®·ľ«¬» ľą° ęëđ¨ď ­«ľ˛»¬­

Configuration steps on CEx1B:

ÝۨďŢř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđ¨î

ÝۨďŢř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňíě ®»ł±¬»óż­ ęëđđď

ÝۨďŢř˝±˛ş·ąó®±«¬»®÷ý˛± ż«¬±ó­«łłż®§

ÝۨďŢř˝±˛ş·ąó®±«¬»®÷ý®»Ľ·­¬®·ľ«¬» ±­°ş î

ÝۨďŢř˝±˛ş·ąó®±«¬»®÷ý®±«¬»® ±­°ş î

ÝۨďŢř˝±˛ş·ąó®±«¬»®÷ý®»Ľ·­¬®·ľ«¬» ľą° ęëđ¨î ­«ľ˛»¬­

Configuration steps on CEx2A:

Ýۨîßř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđ¨ď

Ýۨîßř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňďč ®»ł±¬»óż­ ęëđđď

Ýۨîßř˝±˛ş·ąó®±«¬»®÷ý˛± ż«¬±ó­«łłż®§

Ýۨîßř˝±˛ş·ąó®±«¬»®÷ý®»Ľ·­¬®·ľ«¬» ±­°ş ď

Ýۨîßř˝±˛ş·ąó®±«¬»®÷ý®±«¬»® ±­°ş ď

Ýۨîßř˝±˛ş·ąó®±«¬»®÷ý®»Ľ·­¬®·ľ«¬» ľą° ęëđ¨ď ­«ľ˛»¬­

Configuration steps on CEx2B:

ÝۨîŢř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđ¨î

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňíě ®»ł±¬»óż­ ęëđđď

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý˛± ż«¬±ó­«łłż®§

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý®»Ľ·­¬®·ľ«¬» ±­°ş î

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý®±«¬»® ±­°ş î

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý®»Ľ·­¬®·ľ«¬» ľą° ęëđ¨î ­«ľ˛»¬­

Page 798: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 127

Configuration steps on PEx1:

˙ööööööö ɱ®µą®±«° ¨ď ööööööööööööö

Đۨďř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ®»Ľ·­¬®·ľ«¬» ±­°ş ď

Đۨďř˝±˛ş·ą÷ý˛± ®±«¬»® ±­°ş ď Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňďé ®»ł±¬»óż­ ęëđ¨ď

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňďé ż˝¬·Şż¬»

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňďé ż­ó±Ş»®®·Ľ»

˙ööööööö ɱ®µą®±«° ¨î öööööööööööööö

Đۨďř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ®»Ľ·­¬®·ľ«¬» ±­°ş î

Đۨďř˝±˛ş·ą÷ý˛± ®±«¬»® ±­°ş î Ş®ş Ý«­¬Ţ

Đۨďř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňíí ®»ł±¬»óż­ ęëđ¨î

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňíí ż˝¬·Şż¬»

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňíí ż­ó±Ş»®®·Ľ»

Configuration steps on PEx2:

˙ööööööö ɱ®µą®±«° ¨ď ööööööö

Đۨîř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ®»Ľ·­¬®·ľ«¬» ±­°ş ď

Đۨîř˝±˛ş·ą÷ý˛± ®±«¬»® ±­°ş ď Ş®ş Ý«­¬ß

Đۨîř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňďé ®»ł±¬»óż­ ęëđ¨ď

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňďé ż˝¬·Şż¬»

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňďé ż­ó±Ş»®®·Ľ»

˙ööööööö ɱ®µą®±«° ¨î ööööööö

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ®»Ľ·­¬®·ľ«¬» ±­°ş î

Đۨîř˝±˛ş·ą÷ý˛± ®±«¬»® ±­°ş î Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňíí ®»ł±¬»óż­ ęëđ¨î

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňíí ż˝¬·Şż¬»

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňíí ż­ó±Ş»®®·Ľ»

Page 799: Implementing cisco mpls

128 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Task 2: Configure the Backup PE-CE Link Answer to “Which VRF is interface Se0/0.113 from CEx1B added to?” CustB

Answer to “Which VRF is interface Se0/0.113 from CEx2A added to?” CustA

Configuration steps on CEx1B:

ÝۨďŢř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďí °±·˛¬ó¬±ó°±·˛¬

ÝۨďŢř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨îňěç îëëňîëëňîëëňîěđ

ÝۨďŢř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďí

ÝۨďŢř˝±˛ş·ąóş®óĽ´˝·÷ý˛± ­¸«¬

ÝۨďŢř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđ¨î

ÝۨďŢř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňëđ ®»ł±¬»óßÍ ęëđđď

Configuration steps on PEx2:

Đۨîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďí °±·˛¬ó¬±ó°±·˛¬

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° Ş®ş ş±®©ż®Ľ·˛ą Ý«­¬Ţ

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨îňëđ îëëňîëëňîëëňîěđ

Đۨîř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďí

Đۨîř˝±˛ş·ąóş®óĽ´˝·÷ý˛± ­¸«¬

Đۨîř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňěç ®»ł±¬»óż­ ęëđ¨î

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňěç ż˝¬·Şż¬»

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňěç ż­ó±Ş»®®·Ľ»

Configuration steps on CEx2A:

Ýۨîßř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďí °±·˛¬ó¬±ó°±·˛¬

Ýۨîßř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨ďňěç îëëňîëëňîëëňîěđ

Ýۨîßř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďí

Ýۨîßř˝±˛ş·ąóş®óĽ´˝·÷ý˛± ­¸«¬

Ýۨîßř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđ¨ď

Ýۨîßř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňëđ ®»ł±¬»óż­ ęëđđď

Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďí °±·˛¬ó¬±ó°±·˛¬

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° Ş®ş ş±®©ż®Ľ·˛ą Ý«­¬ß

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨ďňëđ îëëňîëëňîëëňîěđ

Đۨďř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďí

Đۨďř˝±˛ş·ąóş®óĽ´˝·÷ý˛± ­¸«¬

Đۨďř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňěç ®»ł±¬»óż­ ęëđ¨ď

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňěç ż˝¬·Şż¬»

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňěç ż­ó±Ş»®®·Ľ»

Page 800: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 129

Task 3: Select the Primary and Backup Link with BGP Configuration steps on CEx1B:

ÝۨďŢř˝±˛ş·ą÷ý®±«¬»ółż° ­»¬ÔĐ °»®ł·¬ ďđ

ÝۨďŢř˝±˛ş·ąó®±«¬»ółż°÷ý­»¬ ´±˝ż´ó°®»ş»®»˛˝» ëđ

ÝۨďŢř˝±˛ş·ąó®±«¬»ółż°÷ý®±«¬»ółż° ­»¬ÓŰÜ °»®ł·¬ ďđ

ÝۨďŢř˝±˛ş·ąó®±«¬»ółż°÷ý­»¬ ł»¬®·˝ îđđ

ÝۨďŢř˝±˛ş·ąó®±«¬»ółż°÷ý®±«¬»® ľą° ęëđ¨î

ÝۨďŢř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňëđ ®±«¬»ółż° ­»¬ÔĐ ·˛

ÝۨďŢř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňëđ ®±«¬»ółż° ­»¬ÓŰÜ ±«¬

Configuration steps on CEx2A:

Ýۨîßř˝±˛ş·ą÷ý®±«¬»ółż° ­»¬ÔĐ °»®ł·¬ ďđ

Ýۨîßř˝±˛ş·ąó®±«¬»ółż°÷ý­»¬ ´±˝ż´ó°®»ş»®»˛˝» ëđ

Ýۨîßř˝±˛ş·ąó®±«¬»ółż°÷ý®±«¬»ółż° ­»¬ÓŰÜ °»®ł·¬ ďđ

Ýۨîßř˝±˛ş·ąó®±«¬»ółż°÷ý­»¬ ł»¬®·˝ îđđ

Ýۨîßř˝±˛ş·ąó®±«¬»ółż°÷ý®±«¬»® ľą° ęëđ¨ď

Ýۨîßř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňëđ ®±«¬»ółż° ­»¬ÔĐ ·˛

Ýۨîßř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňëđ ®±«¬»ółż° ­»¬ÓŰÜ ±«¬

Page 801: Implementing cisco mpls

130 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 6-1 Answer Key: Establishing Overlapping VPNs

When you complete this activity, your router will be similar to the results here, with differences that are specific to your SP.

Task 1: Design Your VPN Solution No configuration steps are required for this task. On paper, you defined new RDs for VRFs to which CEx1A and CEx2B will be connected. A new RT is needed for the CustAB VPN. The RT value should be the same with the other POP within your SP. It was suggested to use x:11as the RD for VRFs connected to CEx1A, x:21 as the RD for VRFs connected to CEx2B, and x:1001 as the RT for the CustAB VPN.

Task 2: Remove CEx1A and CEx2B from Existing VRFs Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ˛»·ą¸ľ±® ďëđň¨ň¨ďňďé

Đۨďř˝±˛ş·ąóŞ®ş÷ý·˛¬»®şż˝» ­»®·ż´đńđňďđď

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý˛± ·° Ş®ş ş±®©ż®Ľ·˛ą Ý«­¬ß

Note After removing the interface from the VRF, the following message will appear:

“% Interface Serial0/0.101 IP address 150.x.x1.18 removed due to disabling VRF CustA.”

Configuration steps on PEx2:

Đۨîř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛± ˛»·ą¸ľ±® ďëđň¨ň¨îňíí

Đۨîř˝±˛ş·ąóŞ®ş÷ý·˛¬»®şż˝» ­»®·ż´đńđňďđî

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý˛± ·° Ş®ş ş±®©ż®Ľ·˛ą Ý«­¬Ţ

Note After removing the interface from the VRF, the following message will appear:

“% Interface Serial0/0.102 IP address 150.x.x2.34 removed due to disabling VRF CustB.”

Task 3: Configure New VRFs for CEx1A and CEx2B

Note The RDs and RTs listed in these results may not match those that you have used in this

task.

Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ý·° Ş®ş Ý«­¬ßŢ

Đۨďř˝±˛ş·ąóŞ®ş÷ý®Ľ ¨ćďď

Đۨďř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ľ±¬¸ ¨ćďđ

Page 802: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 131

Đۨďř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ľ±¬¸ ¨ćďđđď

Đۨďř˝±˛ş·ąóŞ®ş÷ý·˛¬»®şż˝» ­»®·ż´đńđňďđď

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° Ş®ş ş±®©ż®Ľ·˛ą Ý«­¬ßŢ

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨ďňďč îëëňîëëňîëëňîěđ

Đۨďř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ßŢ

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňďé ®»ł±¬»óż­ ęëđ¨ď

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňďé ż˝¬·Şż¬»

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňďé ż­ó±Ş»®®·Ľ»

Configuration steps on PEx2:

Đۨîř˝±˛ş·ą÷ý·° Ş®ş Ý«­¬ßŢ

Đۨîř˝±˛ş·ąóŞ®ş÷ý®Ľ ¨ćîď

Đۨîř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ľ±¬¸ ¨ćîđ

Đۨîř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ľ±¬¸ ¨ćďđđď

Đۨîř˝±˛ş·ąóŞ®ş÷ý·˛¬»®şż˝» ­»®·ż´đńđňďđî

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° Ş®ş ş±®©ż®Ľ·˛ą Ý«­¬ßŢ

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨îňíě îëëňîëëňîëëňîěđ

Đۨîř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ßŢ

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňíí ®»ł±¬»óż­ ęëđ¨î

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňíí ż˝¬·Şż¬»

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňíí ż­ó±Ş»®®·Ľ»

Page 803: Implementing cisco mpls

132 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Lab 6-2 Answer Key: Merging Service Providers When you complete this activity, your router will be similar to the results here, with differences that are specific to your SP.

Task 1: Enable Connectivity with the Central P Router

Note The subinterface number and DLCI number in these configurations will match with the

central P router and are determined by the instructions for this task.

This task is for the Px1 and Px2 routers of the SP, and not the PE routers.

Configuration steps on the Px1 routers:

Đíďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňîíď °±·˛¬ó¬±ó°±·˛¬

Đíďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďçîňďęčňďđđňďđ îëëňîëëňîëëňîěč

Đíďř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· îíď

Đíďř˝±˛ş·ąóş®óĽ´˝·÷ý˛± ­¸«¬

Đěďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňîěď °±·˛¬ó¬±ó°±·˛¬

Đěďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďçîňďęčňďđđňîę îëëňîëëňîëëňîěč

Đěďř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· îěď

Đěďř˝±˛ş·ąóş®óĽ´˝·÷ý˛± ­¸«¬

Đëďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňîëď °±·˛¬ó¬±ó°±·˛¬

Đëďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďçîňďęčňďđđňěî îëëňîëëňîëëňîěč

Đëďř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· îëď

Đëďř˝±˛ş·ąóş®óĽ´˝·÷ý˛± ­¸«¬

Đęďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňîęď °±·˛¬ó¬±ó°±·˛¬

Đęďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďçîňďęčňďđđňëč îëëňîëëňîëëňîěč

Đęďř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· îęď

Đęďř˝±˛ş·ąóş®óĽ´˝·÷ý˛± ­¸«¬

Configuration steps on the Px2 routers:

Đíîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňîíî °±·˛¬ó¬±ó°±·˛¬

Đíîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďçîňďęčňďđđňďč îëëňîëëňîëëňîěč

Đíîř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· îíî

Đíîř˝±˛ş·ąóş®óĽ´˝·÷ý˛± ­¸«¬

Đěîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňîěî °±·˛¬ó¬±ó°±·˛¬

Đěîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďçîňďęčňďđđňíě îëëňîëëňîëëňîěč

Đěîř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· îěî

Đěîř˝±˛ş·ąóş®óĽ´˝·÷ý˛± ­¸«¬

Page 804: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 133

Đëîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňîëî °±·˛¬ó¬±ó°±·˛¬

Đëîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďçîňďęčňďđđňëđ îëëňîëëňîëëňîěč

Đëîř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· îëî

Đëîř˝±˛ş·ąóş®óĽ´˝·÷ý˛± ­¸«¬

Đęîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňîęî °±·˛¬ó¬±ó°±·˛¬

Đęîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďçîňďęčňďđđňęę îëëňîëëňîëëňîěč

Đęîř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· îęî

Đęîř˝±˛ş·ąóş®óĽ´˝·÷ý˛± ­¸«¬

Task 2: Migrate the Core to IS-IS

Note Take care to apply the configuration steps to the appropriate PE or P router.

Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ý˛± ®±«¬»® »·ą®° ď

Đۨďř˝±˛ş·ą÷ý®±«¬»® ·­·­

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛»¬ ěçňđđđďňđđđđňđđđđňđď¨ďňđđ

Đۨďř˝±˛ş·ąó®±«¬»®÷ý·­ó¬§°» ´»Ş»´óî󱲴§

Đۨďř˝±˛ş·ąó®±«¬»®÷ýł»¬®·˝ó­¬§´» ©·Ľ»

Đۨďř˝±˛ş·ąó®±«¬»®÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďď

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° ®±«¬»® ·­·­

Đۨďř˝±˛ş·ą÷ý·˛¬»®şż˝» ´±±°ľż˝µđ

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° ®±«¬»® ·­·­

Page 805: Implementing cisco mpls

134 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Configuration steps on PEx2:

Шîř˝±˛ş·ą÷ý˛± ®±«¬»® »·ą®° ď

Đۨîř˝±˛ş·ą÷ý®±«¬»® ·­·­

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛»¬ ěçňđđđďňđđđđňđđđđňđď¨îňđđ

Đۨîř˝±˛ş·ąó®±«¬»®÷ý·­ó¬§°» ´»Ş»´óî󱲴§

Đۨîř˝±˛ş·ąó®±«¬»®÷ýł»¬®·˝ó­¬§´» ©·Ľ»

Đۨîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďď

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° ®±«¬»® ·­·­

Đۨîř˝±˛ş·ą÷ý·˛¬»®şż˝» ´±±°ľż˝µđ

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° ®±«¬»® ·­·­

Note The configuration steps shown next apply to the P routers.

Configuration steps on Px1:

Шďř˝±˛ş·ą÷ý˛± ®±«¬»® »·ą®° ď

Шďř˝±˛ş·ą÷ý®±«¬»® ·­·­

Шďř˝±˛ş·ąó®±«¬»®÷ý˛»¬ ěçňđđđďňđđđđňđđđđňđî¨ďňđđ

Шďř˝±˛ş·ąó®±«¬»®÷ý·­ó¬§°» ´»Ş»´óî󱲴§

Шďř˝±˛ş·ąó®±«¬»®÷ýł»¬®·˝ó­¬§´» ©·Ľ»

Шďř˝±˛ş·ąó®±«¬»®÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďď

Шďř˝±˛ş·ąó­«ľ·ş÷ý·° ®±«¬»® ·­·­

Шďř˝±˛ş·ąó®±«¬»®÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďî

Шďř˝±˛ş·ąó­«ľ·ş÷ý·° ®±«¬»® ·­·­

Шďř˝±˛ş·ąó®±«¬»®÷ý·˛¬»®şż˝» ­»®·ż´đńđňî¨ď

Шďř˝±˛ş·ąó­«ľ·ş÷ý·° ®±«¬»® ·­·­

Шďř˝±˛ş·ą÷ý·˛¬»®şż˝» ´±±°ľż˝µđ

Шďř˝±˛ş·ąó­«ľ·ş÷ý·° ®±«¬»® ·­·­

Configuration steps on Px2:

Шîř˝±˛ş·ą÷ý˛± ®±«¬»® »·ą®° ď

Шîř˝±˛ş·ą÷ý®±«¬»® ·­·­

Шîř˝±˛ş·ąó®±«¬»®÷ý˛»¬ ěçňđđđďňđđđđňđđđđňđî¨îňđđ

Шîř˝±˛ş·ąó®±«¬»®÷ý·­ó¬§°» ´»Ş»´óî󱲴§

Шîř˝±˛ş·ąó®±«¬»®÷ýł»¬®·˝ó­¬§´» ©·Ľ»

Шîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďď

Шîř˝±˛ş·ąó­«ľ·ş÷ý·° ®±«¬»® ·­·­

Шîř˝±˛ş·ąó®±«¬»®÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďî

Шîř˝±˛ş·ąó­«ľ·ş÷ý·° ®±«¬»® ·­·­

Шîř˝±˛ş·ąó®±«¬»®÷ý·˛¬»®şż˝» ­»®·ż´đńđňî¨î

Шîř˝±˛ş·ąó­«ľ·ş÷ý·° ®±«¬»® ·­·­

Шîř˝±˛ş·ą÷ý·˛¬»®şż˝» ´±±°ľż˝µđ

Шîř˝±˛ş·ąó­«ľ·ş÷ý·° ®±«¬»® ·­·­

Page 806: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 135

Task 3: Enable MPLS LDP Connectivity with the Central P Router

Note The subinterface number and DLCI number in these configurations match each other and

are determined by the instructions for this task.

Configuration steps on Px1:

Шďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňî¨ď

Шďř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ·°

Шďř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ´żľ»´ °®±¬±˝±´ ´Ľ°

Configuration steps on Px2:

Шîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňî¨î

Шîř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ·°

Шîř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ´żľ»´ °®±¬±˝±´ ´Ľ°

Task 4: Enable IBGP Connectivity for All PE Routers Answer to “What routes do you expect to see in VRF CustA?”

Only routes from your SP: 10.1.x1.16/28, 10.1.x1.49/32, 10.1.x2.16/28, 10.1.x2.49/32, 150.x.x1.16/18, 150.x.x1.48/28, 150.x.x2.16/18

Answer to “What routes do you expect to see in VRF CustB?”

Only routes from your SP: 10.2.x1.16/28, 10.2.x1.49/32, 10.2.x2.16/28, 10.2.x2.49/32, 150.x.x2.32/18, 150.x.x2.48/28, 150.x.x1.32/18

Answer to “What routes do you expect to see in VRF CustAB?”

Only routes from your SP: 10.1.x1.16/28, 10.1.x1.49/32, 10.1.x2.16/28, 10.1.x2.49/32, 10.2.x2.16/28, 10.2.x2.49/32, 150.x.x1.16/18, 150.x.x1.48/28, 150.x.x2.16/18, , 150.x.x2.32/18

Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛± ˛»·ą¸ľ±® ďçîňďęčň¨ňíí ®»ł±¬»óż­ ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďçîňďęčňďđđňďîç ®»ł±¬»óż­ ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďçîňďęčňďđđňďîç «°Ľż¬»ó­±«®˝» ´±±°ľż˝µđ

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ Ş°˛Şě

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďçîňďęčňďđđňďîç ż˝¬·Şż¬»

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďçîňďęčňďđđňďîç ­»˛Ľó˝±łł«˛·¬§ ľ±¬¸

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďçîňďęčňďđđňďîç ˛»¨¬ó¸±°ó­»´ş

Page 807: Implementing cisco mpls

136 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Configuration steps on PEx2:

Đۨîř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛± ˛»·ą¸ľ±® ďçîňďęčň¨ňďé ®»ł±¬»óż­ ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďçîňďęčňďđđňďîç ®»ł±¬»óż­ ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ľ±® ďçîňďęčňďđđňďîç «°Ľż¬»ó­±«®˝» ´±±°ľż˝µđ

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ Ş°˛Şě

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďçîňďęčňďđđňďîç ż˝¬

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďçîňďęčňďđđňďîç ­»˛Ľó˝±łł«˛·¬§ ľ±¬¸

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďçîňďęčňďđđňďîç ˛»¨¬ó¸±°ó­»´ş

Page 808: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 137

Lab 6-3 Answer Key: Establishing a Common Services VPN

When you complete this activity, your router will be similar to the results here, with differences that are specific to your SP.

Task 1: Establish Connectivity Between the NMS VRF and Other VRFs

Answer to “What routes do you expect to see in VRF CustA on your PE?”

All the routes from before, plus the prefix for the new link and 10.10.10.49. These should include: 10.1.x1.16/28, 10.1.x1.49/32, 10.1.x2.16/28, 10.1.x2.49/32, 150.x.x1.16/18, 150.x.x1.48/28, 150.x.x1.64/28, 150.x.x2.16/18, and 10.10.10.10.49/32.

Answer to “What routes do you expect to see in VRF NMS on your PE?”

None, because the PE router has no interfaces in the NMS VRF and does not have the NMS VRF configured.

Answer to “What routes do you expect to see in VRF NMS on P1?”

The loopback addresses of the CE routers in the SP and 10.10.10.49. You need only check for your loopback address: 10.1.x1.49/32, 10.2.x1.49/32, 10.1.x2.49/32, 10.2.x1.49/32, and 10.10.10.49/32.

Configuration steps on PEx1 for customer A:

Đۨďř˝±˛ş·ą÷ý·° Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ąóŞ®ş÷ý»¨°±®¬ łż° ŇÓÍÁÝ«­Áß

Đۨďř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ďđďćëđđ

Đۨďř˝±˛ş·ą÷ý·° Ş®ş Ý«­¬ßŢ

Đۨďř˝±˛ş·ąóŞ®ş÷ý»¨°±®¬ łż° ŇÓÍÁÝ«­Áß

Đۨďř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ďđďćëđđ

Đۨďř˝±˛ş·ą÷ý®±«¬»ółż° ŇÓÍÁÝ«­Áß °»®ł·¬ ďđ

Đۨďř˝±˛ş·ąó®±«¬»ółż°÷ýłż¬˝¸ ·° żĽĽ®»­­ ďđ

Đۨďř˝±˛ş·ąó®±«¬»ółż°÷ý­»¬ »¨¬˝±łł«˛·¬§ ®¬ ďđďćëđď żĽĽ

Đۨďř˝±˛ş·ąó®±«¬»ółż°÷ý»¨·¬

Đۨďř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ ďđ °»®ł·¬ ¸±­¬ ďđňďň¨ďňěç

Đۨďř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ ďđ °»®ł·¬ ¸±­¬ ďđňďň¨îňěç

Configuration steps on PEx2 for customer A:

Đۨîř˝±˛ş·ą÷ý·° Ş®ş Ý«­¬ß

Đۨîř˝±˛ş·ąóŞ®ş÷ý»¨°±®¬ łż° ŇÓÍÁÝ«­Áß

Đۨîř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ďđďćëđđ

Đۨîř˝±˛ş·ą÷ý®±«¬»ółż° ŇÓÍÁÝ«­Áß °»®ł·¬ ďđ

Đۨîř˝±˛ş·ąó®±«¬»ółż°÷ýłż¬˝¸ ·° żĽĽ®»­­ ďđ

Đۨîř˝±˛ş·ąó®±«¬»ółż°÷ý­»¬ »¨¬˝±łł«˛·¬§ ®¬ ďđďćëđď żĽĽ

Đۨîř˝±˛ş·ąó®±«¬»ółż°÷ý»¨·¬

Page 809: Implementing cisco mpls

138 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Đۨîř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ ďđ °»®ł·¬ ¸±­¬ ďđňďň¨ďňěç

Đۨîř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ ďđ °»®ł·¬ ¸±­¬ ďđňďň¨îňěç

Configuration steps on PEx1 for customer B:

Đۨďř˝±˛ş·ą÷ý·° Ş®ş Ý«­¬Ţ

Đۨďř˝±˛ş·ąóŞ®ş÷ý»¨°±®¬ łż° ŇÓÍÁÝ«­ÁŢ

Đۨďř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ďđďćëđđ

Đۨďř˝±˛ş·ą÷ý®±«¬»ółż° ŇÓÍÁÝ«­ÁŢ °»®ł·¬ ďđ

Đۨďř˝±˛ş·ąó®±«¬»ółż°÷ýłż¬˝¸ ·° żĽĽ®»­­ îđ

Đۨďř˝±˛ş·ąó®±«¬»ółż°÷ý­»¬ »¨¬˝±łł«˛·¬§ ®¬ ďđďćëđď żĽĽ

Đۨďř˝±˛ş·ąó®±«¬»ółż°÷ý»¨·¬

Đۨďř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ îđ °»®ł·¬ ¸±­¬ ďđňîň¨ďňěç

Đۨďř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ îđ °»®ł·¬ ¸±­¬ ďđňîň¨îňěç

Configuration steps on PEx2 for customer B:

Đۨîř˝±˛ş·ą÷ý·° Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąóŞ®ş÷ý»¨°±®¬ łż° ŇÓÍÁÝ«­ÁŢ

Đۨîř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ďđďćëđđ

Đۨîř˝±˛ş·ą÷ý·° Ş®ş Ý«­¬ßŢ

Đۨîř˝±˛ş·ąóŞ®ş÷ý»¨°±®¬ łż° ŇÓÍÁÝ«­ÁŢ

Đۨîř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ďđďćëđđ

Đۨîř˝±˛ş·ą÷ý®±«¬»ółż° ŇÓÍÁÝ«­ÁŢ °»®ł·¬ ďđ

Đۨîř˝±˛ş·ąó®±«¬»ółż°÷ýłż¬˝¸ ·° żĽĽ®»­­ îđ

Đۨîř˝±˛ş·ąó®±«¬»ółż°÷ý­»¬ »¨¬˝±łł«˛·¬§ ®¬ ďđďćëđď żĽĽ

Đۨîř˝±˛ş·ąó®±«¬»ółż°÷ý»¨·¬

Đۨîř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ îđ °»®ł·¬ ¸±­¬ ďđňîň¨ďňěç

Đۨîř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ îđ °»®ł·¬ ¸±­¬ ďđňîň¨îňěç

Page 810: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 139

Lab 7-1 Answer Key: Establishing Central Site Internet Connectivity with an MPLS VPN

When you complete this activity, your router will be similar to the results here, with differences that are specific to your SP.

Task 1: Restore a Simple Customer VPN Configuration Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˛± żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ßŢ

Đۨďř˝±˛ş·ąó®±«¬»®÷ý˙

Đۨďř˝±˛ş·ąó®±«¬»®÷ý żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý ˛»·ą¸ľ±® ďëđň¨ň¨ďňďé ®»ł±¬»óż­ ęëđ¨ď

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý ˛»·ą¸ľ±® ďëđň¨ň¨ďňďé ż˝¬·Şż¬»

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý ˛»·ą¸ľ±® ďëđň¨ň¨ďňďé ż­ó±Ş»®®·Ľ»

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý »¨·¬óżĽĽ®»­­óşżł·´§

Đۨďř˝±˛ş·ąó®±«¬»®÷ý »¨·¬

Đۨďř˝±˛ş·ą÷ý˛± ·° Ş®ş Ý«­¬ßŢ

Đۨďř˝±˛ş·ą÷ý·˛¬ ­»® đńđňďđď

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° Ş®ş ş±®©ż®Ľ·˛ą Ý«­¬ß

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ ďëđň¨ň¨ďňďč îëëňîëëňîëëňîěđ

Configuration steps on PEx2:

Đۨîř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ý˛± żĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ßŢ

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý ˛»·ą¸ľ±® ďëđň¨ň¨îňíí ®»ł±¬»óż­ ęëđ¨î

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý ˛»·ą¸ľ±® ďëđň¨ň¨îňíí ż˝¬·Şż¬»

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý ˛»·ą¸ľ±® ďëđň¨ň¨îňíí ż­ó±Ş»®®·Ľ»

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý »¨·¬óżĽĽ®»­­óşżł·´§

Đۨîř˝±˛ş·ąó®±«¬»®÷ý »¨·¬

Đۨîř˝±˛ş·ą÷ý˛± ·° Ş®ş Ý«­¬ßŢ

Đۨîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´ đńđňďđî

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° Ş®ş ş±®©ż®Ľ·˛ą Ý«­¬Ţ

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨îňíě îëëňîëëňîëëňîěđ

Page 811: Implementing cisco mpls

140 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Task 2: Establish CE-PE Connectivity for Central Site Internet Access

Configuration steps on CEx1A:

Ýۨďßř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďě °±·˛¬ó¬±ó°±·˛¬

Ýۨďßř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ ďëđň¨ň¨ďňęę îëëňîëëňîëëňîěđ

Ýۨďßř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďě

Ýۨďßř˝±˛ş·ąó­«ľ·ş÷®±«¬»® ±­°ş ď

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ đňđňîëëňîëë ż®»ż đ

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý°ż­­·Ş»ó·˛¬»®şż˝» ­»®·ż´đńđňďďě

Configuration steps on CEx2B:

ÝۨîŢř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďě °±·˛¬ó¬±ó°±·˛¬

ÝۨîŢř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ ďëđň¨ň¨îňęę îëëňîëëňîëëňîěđ

ÝۨîŢř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďě

ÝۨîŢř˝±˛ş·ąó­«ľ·ş÷®±«¬»® ±­°ş î

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďëđň¨ňđňđ đňđňîëëňîëë ż®»ż đ

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý°ż­­·Ş»ó·˛¬»®şż˝» ­»®·ż´đńđňďďě

Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďě °±·˛¬ó¬±ó°±·˛¬

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ ďëđň¨ň¨ďňęë îëëňîëëňîëëňîěđ

Đۨďř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďě

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° ®±«¬»® ·­·­

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý®±«¬»® ·­·­

Đۨďř˝±˛ş·ąó®±«¬»®÷ý°ż­­·Ş»ó·˛¬»®şż˝» ­»®·ż´đńđňďďě

Configuration steps on PEx2:

Đۨîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďě °±·˛¬ó¬±ó°±·˛¬

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ ďëđň¨ň¨îňęë îëëňîëëňîëëňîěđ

Đۨîř˝±˛ş·ąó­«ľ·ş÷ýş®żł»ó®»´ż§ ·˛¬»®şż˝»óĽ´˝· ďďě

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° ®±«¬»® ·­·­

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý®±«¬»® ·­·­

Đۨîř˝±˛ş·ąó®±«¬»®÷ý°ż­­·Ş»ó·˛¬»®şż˝» ­»®·ż´đńđňďďě

Task 3: Establish Central Site Connectivity for Internet Access Configuration steps on CEx1A:

Ýۨďßř˝±˛ş·ą÷ý·° ®±«¬» ďđňďň¨ďňđ îëëňîëëňîëëň𠲫´´đ

Ýۨďßř˝±˛ş·ą÷ý·° ®±«¬» ďđňďň¨îňđ îëëňîëëňîëëň𠲫´´đ

Ýۨďßř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđ¨ď

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý˛»·ą¸ ďëđň¨ň¨ďňęë ®»ł±¬»óż­ ęëđđď

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďđňďň¨ďňđ łż­µ îëëňîëëňîëëňđ

Ýۨďßř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďđňďň¨îňđ łż­µ îëëňîëëňîëëňđ

Page 812: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 141

Configuration steps on CEx2B:

ÝۨîŢř˝±˛ş·ą÷ý·° ®±«¬» ďđňîň¨ďňđ îëëňîëëňîëëň𠲫´´đ

ÝۨîŢř˝±˛ş·ą÷ý·° ®±«¬» ďđňîň¨îňđ îëëňîëëňîëëň𠲫´´đ

ÝۨîŢř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđ¨î

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý˛»· ďëđň¨ň¨îňęë ®»ł±¬»óż­ ęëđđď

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý˛»¬©±®µ ďđňîň¨ďňđ łż­µ îëëňîëëňîëëňđ

ÝۨîŢř˝±˛ş·ąó®±«¬»®÷ý ˛»¬©±®µ ďđňîň¨îňđ łż­µ îëëňîëëňîëëňđ

Configuration steps on PEx1:

Đۨďř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ ¨đ °»®ł·¬ đňđňđňđ

Đۨďř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ ¨đ °»®ł·¬ ďđňďň¨ďňđ

Đۨďř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ ¨đ °»®ł·¬ ďđňďň¨îňđ

Đۨďř˝±˛ş·ą÷ý®±«¬»ółż° ײ»¬Áß °»®ł·¬ ďđ

Đۨďř˝±˛ş·ąó®±«¬»ółż°÷ýłż¬˝¸ ·° żĽĽ®»­­ ¨đ

Đۨďř˝±˛ş·ąó®±«¬»ółż°÷ý­»¬ »¨¬˝±łł«˛·¬§ ®¬ ďđđćęđđ

Đۨďř˝±˛ş·ąó®±«¬»ółż°÷ý»¨·¬

Đۨďř˝±˛ş·ą÷ý·° Ş®ş ײ¬»®˛»¬

Đۨďř˝±˛ş·ąóŞ®ş÷ý®Ľ ďđđćęđđ

Đۨďř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ďđđćęđđ

Đۨďř˝±˛ş·ąóŞ®ş÷ý»¨°±®¬ łż° ײ»¬Áß

Đۨďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďě

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° Ş®ş ş±®©ż®Ľ·˛ą ײ¬»®˛»¬

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ®»­­ ďëđň¨ň¨ďňęë îëëňîëëňîëëňîěđ

Đۨďř˝±˛ş·ąó­«ľ·ş÷ý»¨·¬

Đۨďř˝±˛ş·ą÷ý·° °®»ş·¨ó´·­¬ Ü»şŃ˛´§ °»®ł·¬ đňđňđňđńđ

Đۨďř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş ײ¬»®˛»¬

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňęę ®»ł±¬» ęëđ¨ď

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňęę ż˝¬·Şż¬»

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨ďňęę °®»ş·¨ó´·­¬ Ü»şŃ˛´§ ±«¬

Configuration steps on PEx2:

Đۨîř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ ¨đ °»®ł·¬ đňđňđňđ

Đۨîř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ ¨đ °»®ł·¬ ďđňîň¨ďňđ

Đۨîř˝±˛ş·ą÷ýż˝˝»­­ó´·­¬ ¨đ °»®ł·¬ ďđňîň¨îňđ

Đۨîř˝±˛ş·ą÷ý®±«¬»ółż° ײ»¬ÁŢ °»®ł·¬ ďđ

Đۨîř˝±˛ş·ąó®±«¬»ółż°÷ýłż¬˝¸ ·° żĽĽ®»­­ ¨đ

Đۨ˛ş·ąó®±«¬»ółż°÷ý­»¬ »¨¬˝±łł«˛·¬§ ®¬ ďđđćęđđ

Đۨîř˝±˛ş·ąó®±«¬»ółż°÷ý»¨·¬

Đۨîř˝±˛ş·ą÷ý·° Ş®ş ײ¬»®˛»¬

Đۨîř˝±˛ş·ąóŞ®ş÷ý®Ľ ďđđćęđđ

Đۨîř˝±˛ş·ąóŞ®ş÷ý®±«¬»ó¬ż®ą»¬ ·ł°±®¬ ďđđćęđđ

Đۨîř˝±˛ş·ąóŞ®ş÷ý»¨°±®¬ łż° ײ»¬ÁŢ

Đۨîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´đńđňďďě

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° Ş®ş ş±®©ż®Ľ·˛ą ײ¬»®˛»¬

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý·° żĽĽ ďëđň¨ň¨îňęë îëëňîëëňîëëňîěđ

Page 813: Implementing cisco mpls

142 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Đۨîř˝±˛ş·ąó­«ľ·ş÷ý»¨·¬

Đۨîř˝±˛ş·ą÷ý·° °®»ş·¨ó´·­¬ Ü»şŃ˛´§ °»®ł·¬ đňđňđňđńđ

Đۨîř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş ײ¬»®˛»¬

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňęę ®»ł±¬» ęëđ¨î

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňęę ż˝¬·Şż¬»

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý˛»·ą¸ľ±® ďëđň¨ň¨îňęę °®»ş·¨ó´·­¬ Ü»şŃ˛´§ ±«¬

Task 4: Establish Remote Site Internet Connectivity Through the Central Site Router

Configuration steps on the PE routers:

Đۨďř˝±˛ş·ą÷ý ·° ®±«¬» Ş®ş Ý«­¬ß đňđňđňđ đňđňđňđ ďđňďň¨ďňěç

Đۨďř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨďř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬ß

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ­¬ż¬·˝

Đۨďř˝±˛ş·ąó®±«¬»®óżş÷ýĽ»şż«´¬ó·˛ş±®łż¬·±˛ ±®·ą·˛ż¬»

Đۨîř˝±˛ş·ą÷ý ·° ®±«¬» Ş®ş Ý«­¬Ţ đňđňđňđ đňđňđňđ ďđňîň¨îňěç

Đۨîř˝±˛ş·ą÷ý®±«¬»® ľą° ęëđđď

Đۨîř˝±˛ş·ąó®±«¬»®÷ýżĽĽ®»­­óşżł·´§ ·°Şě Ş®ş Ý«­¬Ţ

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ý®»Ľ·­¬®·ľ«¬» ­¬ż¬·˝

Đۨîř˝±˛ş·ąó®±«¬»®óżş÷ýĽ»şż«´¬ó·˛ş±®łż¬·±˛ ±®·ą·˛ż¬»

Page 814: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 143

Lab 8-1 Answer Key: Implementing Basic MPLS TE

When you complete this activity, your router will be similar to the results here, with differences that are specific to your SP.

Task 1: Log the Existing Traffic Flow Configuration steps on the PE routers:

Đۨďř˝±˛ş·ą÷ýł°´­ ·° °®±°żąż¬»ó¬¬´

Đۨîř˝±˛ş·ą÷ýł°´­ ·° °®±°żąż¬»ó¬¬´

Configuration steps on the P routers:

Шďř˝±˛ş·ą÷ýł°´­ ·° °®±°żąż¬»ó¬¬´

Шďř˝±˛ş·ą÷ýł°´­ ·° °®±°żąż¬»ó¬¬´

Task 2: Configure MPLS TE Support on the PE and P Routers Configuration steps on the PEx* routers:

Đۨöř˝±˛ş·ą÷ýł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

Đۨöř˝±˛ş·ą÷ý®±«¬»® ·­·­

Đۨöř˝±˛ş·ąó®±«¬»®÷ýł°´­ ¬®żşş·˝ó»˛ą ®±«¬»®ó·Ľ ´±±°ľż˝µđ

Đۨöř˝±˛ş·ąó®±«¬»®÷ýł»¬®·˝ó­¬§´» ©·Ľ»

Đۨöř˝±˛ş·ąó®±«¬»®÷ýł°´­ ¬®żşş·˝ó»˛ą ´»Ş»´óî

Đۨöř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´ đńđ

Đۨöř˝±˛ş·ą÷ý·° ®­Ş° ľż˛Ľ©·Ľ¬¸ ďîč

Đۨöř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´ đńđňďďď

Đۨöř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

Đۨöř˝±˛ş·ąó­«ľ·ş÷ý·° ®­Ş° ľż˛Ľ©·Ľ¬¸ ďîč

Note When steps show “PEx*,” implement them on both the PEx1 and PEx2 routers.

Configuration steps on the Px* routers:

Шöř˝±˛ş·ą÷ýł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

Шöř˝±˛ş·ą÷ý®±«¬»® ·­·­

Шöř˝±˛ş·ąó®±«¬»®÷ýł°´­ ¬®żşş·˝ó»˛ą ®±«¬»®ó·Ľ ´±±°ľż˝µđ

Шöř˝±˛ş·ąó®±«¬»®÷ýł»¬®·˝ó­¬§´» ©·Ľ»

Шöř˝±˛ş·ąó®±«¬»®÷ýł°´­ ¬®żşş·˝ó»˛ą ´»Ş»´óî

Note When steps show “Px*,” implement them on both the Px1 and Px2 routers.

Page 815: Implementing cisco mpls

144 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.

Шďř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´ đńđ

Шďř˝±˛ş·ąó·ş÷ý·° ®­Ş° ľż˛Ľ©·Ľ¬¸ ďîč

Шďř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» ­»®·ż´ đńđňďďď

Шďř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

Шďř˝±˛ş·ąó­«ľ·ş÷ý·° ®­Ş° ľż˛Ľ©·Ľ¬¸ ďîč

Шďř˝±˛ş·ąó­«ľ·ş÷ý·˛¬»®şż˝» ­»®·ż´ đńđňďďî

Шďř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

Шďř˝±˛ş·ąó­«ľ·ş÷ý·° ®­Ş° ľż˛Ľ©·Ľ¬¸ ďîč

Шďř˝±˛ş·ąó­«ľ·ş÷ý·˛¬»®şż˝» ­»®·ż´ đńđňî¨ď

Шďř˝±˛ş·ąó­«ľ·ş÷ý·° ®­Ş° ľż˛Ľ©·Ľ¬¸ ďîč

Шďř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

Шîř˝±˛ş·ą÷ý·˛¬»®şż˝» ­»®·ż´ đńđ

Шîř˝±˛ş·ąó·ş÷ý·° ®­Ş° ľż˛Ľ©·Ľ¬¸ ďîč

Шîř˝±˛ş·ąó·ş÷ý·˛¬»®şż˝» ­»®·ż´ đńđňďďď

Шîř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

Шîř˝±˛ş·ąó­«ľ·ş÷ý·° ®­Ş° ľż˛Ľ©·Ľ¬¸ ďîč

Шîř˝±˛ş·ąó­«ľ·ş÷ý·˛¬»®şż˝» ­»®·ż´ đńđňďďî

Шîř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

Шîř˝±˛ş·ąó­«ľ·ş÷ý·° ®­Ş° ľż˛Ľ©·Ľ¬¸ ďîč

Шîř˝±˛ş·ąó­«ľ·ş÷ý·˛¬»®şż˝» ­»®·ż´ đńđňî¨î

Шîř˝±˛ş·ąó­«ľ·ş÷ý·° ®­Ş° ľż˛Ľ©·Ľ¬¸ ďîč

Шîř˝±˛ş·ąó­«ľ·ş÷ýł°´­ ¬®żşş·˝ó»˛ą ¬«˛˛»´­

Task 3: Configure MPLS TE Tunnels Configuration steps on the PEx1 router:

Đۨďř˝±˛ş·ą÷ý·˛¬»®şż˝» Ě«˛˛»´đ

Đۨďř˝±˛ş·ąó·ş÷ý·° «˛˛«łľ»®»Ľ Ô±±°ľż˝µďđ

Đۨďř˝±˛ş·ąó·ş÷ý¬«˛˛»´ Ľ»­¬·˛ż¬·±˛ ďçîňďęčň¨ňíí

Đۨďř˝±˛ş·ąó·ş÷ý¬«˛˛»´ ł±Ľ» ł°´­ ¬®żşş·˝ó»˛ą

Đۨďř˝±˛ş·ąó·ş÷ý¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą ż«¬±®±«¬» ż˛˛±«˛˝»

Đۨďř˝±˛ş·ąó·ş÷ý¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą °®·±®·¬§ đ đ

Đۨďř˝±˛ş·ąó·ş÷ý¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą ľż˛Ľ©·Ľ¬¸ ďđđ

Đۨďř˝±˛ş·ąó·ş÷ý ¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą °ż¬¸ó±°¬·±˛ ď𠻨°´·˝·¬ ˛żł» ĐۨďÁľ§ÁĐď

Đۨďř˝±˛ş·ąó·ş÷ýł°´­ ·°

Đۨďř˝±˛ş·ąó·ş÷ý»¨·¬

Đۨďř˝±˛ş·ą÷ýł°´­ ¬®żşş·˝ó»˛ą ®»±°¬·ł·¦» ¬·ł»®­ ş®»Ż«»˛˝§ íđ

Đۨďř˝±˛ş·ą÷ý·° »¨°´·˝·¬ó°ż¬¸ ˛żł» ĐۨďÁľ§ÁĐď

Đۨďř˝şąó·°ó»¨°´ó°ż¬¸÷ý˛»¨¬óżĽĽ®»­­ ďçîňďęčň¨ňčď

Đۨďř˝şąó·°ó»¨°´ó°ż¬¸÷ý˛»¨¬óżĽĽ®»­­ ďçîňďęčňďđđňďîç

Đۨďř˝şąó·°ó»¨°´ó°ż¬¸÷ý˛»¨¬óżĽĽ®»­­ ďçîňďęčň¨ňçé

Đۨďř˝şąó·°ó»¨°´ó°ż¬¸÷ý˛»¨¬óżĽĽ®»­­ ďçîňďęčň¨ňíí

Page 816: Implementing cisco mpls

© 2006 Cisco Systems, Inc. Lab Guide 145

Configuration steps on the PEx2 router:

Đۨîř˝±˛ş·ą÷ý·˛¬»®şż˝» Ě«˛˛»´đ

Đۨîř˝±˛ş·ąó·ş÷ý·° «˛˛«łľ»®»Ľ Ô±±°ľż˝µďđ

Đۨîř˝±˛ş·ąó·ş÷ý¬«˛˛»´ Ľ»­¬·˛ż¬·±˛ ďçîňďęčň¨ňďé

Đۨîř˝±˛ş·ąó·ş÷ý¬«˛˛»´ ł±Ľ» ł°´­ ¬®żşş·˝ó»˛ą

Đۨîř˝±˛ş·ąó·ş÷ý¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą ż«¬±®±«¬» ż˛˛±«˛˝»

Đۨîř˝±˛ş·ąó·ş÷ý¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą °®·±®·¬§ đ đ

Đۨîř˝±˛ş·ąó·ş÷ý¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą ľż˛Ľ©·Ľ¬¸ ďđđ

Đۨîř˝±˛ş·ąó·ş÷ý ¬«˛˛»´ ł°´­ ¬®żşş·˝ó»˛ą °ż¬¸ó±°¬·±˛ ď𠻨°´·˝·¬ ˛żł» ĐۨîÁľ§ÁĐď

Đۨîř˝±˛ş·ąó·ş÷ýł°´­ ·°

Đۨîř˝±˛ş·ąó·ş÷ý»¨·¬

Đۨîř˝±˛ş·ą÷ýł°´­ ¬®żşş·˝ó»˛ą ®»±°¬·ł·¦» ¬·ł»®­ ş®»Ż«»˛˝§ íđ

Đۨîř˝±˛ş·ą÷ý·° »¨°´·˝·¬ó°ż¬¸ ˛żł» ĐۨîÁľ§ÁĐď

Đۨîř˝şąó·°ó»¨°´ó°ż¬¸÷ý˛»¨¬óżĽĽ®»­­ ďçîňďęčň¨ňçé

Đۨîř˝şąó·°ó»¨°´ó°ż¬¸÷ý˛»¨¬óżĽĽ®»­­ ďçîňďęčňďđđňďîç

Đۨîř˝şąó·°ó»¨°´ó°ż¬¸÷ý˛»¨¬óżĽĽ®»­­ ďçîňďęčň¨ňčď

Đۨîř˝şąó·°ó»¨°´ó°ż¬¸÷ý˛»¨¬óżĽĽ®»­­ ďçîňďęčň¨ňďé

Page 817: Implementing cisco mpls

146 Implementing Cisco MPLS (MPLS) v2.2 © 2006 Cisco Systems, Inc.