Advanced MPLS VPN Solutions

Transcription

1 AMVS Advanced MPLS VPN Solutions Volume 1 Version 1.0 Student Guide Text Part Number:

2 The products and specifications, configurations, and other technical information regarding the products in this manual are subject to change without notice. All statements, technical information, and recommendations in this manual are believed to be accurate but are presented without warranty of any kind, express or implied. You must take full responsibility for their application of any products specified in this manual. LICENSE PLEASE READ THESE TERMS AND CONDITIONS CAREFULLY BEFORE USING THE MANUAL, DOCUMENTATION, AND/OR SOFTWARE ( MATERIALS ). BY USING THE MATERIALS YOU AGREE TO BE BOUND BY THE TERMS AND CONDITIONS OF THIS LICENSE. IF YOU DO NOT AGREE WITH THE TERMS OF THIS LICENSE, PROMPTLY RETURN THE UNUSED MATERIALS (WITH PROOF OF PAYMENT) TO THE PLACE OF PURCHASE FOR A FULL REFUND. Cisco Systems, Inc. ( Cisco ) and its suppliers grant to you ( You ) a nonexclusive and nontransferable license to use the Cisco Materials solely for Your own personal use. If the Materials include Cisco software ( Software ), Cisco grants to You a nonexclusive and nontransferable license to use the Software in object code form solely on a single central processing unit owned or leased by You or otherwise embedded in equipment provided by Cisco. You may make one (1) archival copy of the Software provided You affix to such copy all copyright, confidentiality, and proprietary notices that appear on the original. EXCEPT AS EXPRESSLY AUTHORIZED ABOVE, YOU SHALL NOT: COPY, IN WHOLE OR IN PART, MATERIALS; MODIFY THE SOFTWARE; REVERSE COMPILE OR REVERSE ASSEMBLE ALL OR ANY PORTION OF THE SOFTWARE; OR RENT, LEASE, DISTRIBUTE, SELL, OR CREATE DERIVATIVE WORKS OF THE MATERIALS. You agree that aspects of the licensed Materials, including the specific design and structure of individual programs, constitute trade secrets and/or copyrighted material of Cisco. You agree not to disclose, provide, or otherwise make available such trade secrets or copyrighted material in any form to any third party without the prior written consent of Cisco. You agree to implement reasonable security measures to protect such trade secrets and copyrighted Material. Title to the Materials shall remain solely with Cisco. This License is effective until terminated. You may terminate this License at any time by destroying all copies of the Materials. This License will terminate immediately without notice from Cisco if You fail to comply with any provision of this License. Upon termination, You must destroy all copies of the Materials. Software, including technical data, is subject to U.S. export control laws, including the U.S. Export Administration Act and its associated regulations, and may be subject to export or import regulations in other countries. You agree to comply strictly with all such regulations and acknowledge that it has the responsibility to obtain licenses to export, re-export, or import Software. This License shall be governed by and construed in accordance with the laws of the State of California, United States of America, as if performed wholly within the state and without giving effect to the principles of conflict of law. If any portion hereof is found to be void or unenforceable, the remaining provisions of this License shall remain in full force and effect. This License constitutes the entire License between the parties with respect to the use of the Materials Restricted Rights - Cisco s software is provided to non-dod agencies with RESTRICTED RIGHTS and its supporting documentation is provided with LIMITED RIGHTS. Use, duplication, or disclosure by the U.S. Government is subject to the restrictions as set forth in subparagraph C of the Commercial Computer Software - Restricted Rights clause at FAR In the event the sale is to a DOD agency, the U.S. Government s rights in software, supporting documentation, and technical data are governed by the restrictions in the Technical Data Commercial Items clause at DFARS and DFARS DISCLAIMER OF WARRANTY. ALL MATERIALS ARE PROVIDED AS IS WITH ALL FAULTS. CISCO AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. In no event shall Cisco s or its suppliers liability to You, whether in contract, tort (including negligence), or otherwise, exceed the price paid by You. The foregoing limitations shall apply even if the above-stated warranty fails of its essential purpose. The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense. The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency energy. If it is not installed in accordance with Cisco s installation instructions, it may cause interference with radio and television reception. This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of

3 the FCC rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no guarantee that interference will not occur in a particular installation. You can determine whether your equipment is causing interference by turning it off. If the interference stops, it was probably caused by the Cisco equipment or one of its peripheral devices. If the equipment causes interference to radio or television reception, try to correct the interference by using one or more of the following measures: Turn the television or radio antenna until the interference stops. Move the equipment to one side or the other of the television or radio. Move the equipment farther away from the television or radio. Plug the equipment into an outlet that is on a different circuit from the television or radio. (That is, make certain the equipment and the television or radio are on circuits controlled by different circuit breakers or fuses.) Modifications to this product not authorized by Cisco Systems, Inc. could void the FCC approval and negate your authority to operate the product. The following third-party software may be included with your product and will be subject to the software license agreement: CiscoWorks software and documentation are based in part on HP OpenView under license from the Hewlett- Packard Company. HP OpenView is a trademark of the Hewlett-Packard Company. Copyright 1992, 1993 Hewlett-Packard Company. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB s public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California. Network Time Protocol (NTP). Copyright 1992, David L. Mills. The University of Delaware makes no representations about the suitability of this software for any purpose. Point-to-Point Protocol. Copyright 1989, Carnegie-Mellon University. All rights reserved. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. The Cisco implementation of TN3270 is an adaptation of the TN3270, curses, and termcap programs developed by the University of California, Berkeley (UCB) as part of UCB s public domain version of the UNIX operating system. All rights reserved. Copyright , Regents of the University of California. Cisco incorporates Fastmac and TrueView software and the RingRunner chip in some Token Ring products. Fastmac software is licensed to Cisco by Madge Networks Limited, and the RingRunner chip is licensed to Cisco by Madge NV. Fastmac, RingRunner, and TrueView are trademarks and in some jurisdictions registered trademarks of Madge Networks Limited. Copyright 1995, Madge Networks Limited. All rights reserved. XRemote is a trademark of Network Computing Devices, Inc. Copyright 1989, Network Computing Devices, Inc., Mountain View, California. NCD makes no representations about the suitability of this software for any purpose. The X Window System is a trademark of the X Consortium, Cambridge, Massachusetts. All rights reserved. Access Registrar, AccessPath, Any to Any, Are You Ready, AtmDirector, Browse with Me, CCDA, CCDE, CCDP, CCIE, CCNA, CCNP, CCSI, CD-PAC, the Cisco logo, Cisco Certified Internetwork Expert logo, CiscoLink, the Cisco Management Connection logo, the Cisco NetWorks logo, the Cisco Powered Network logo, Cisco Systems Capital, the Cisco Systems Capital logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, the Cisco Technologies logo, Fast Step, FireRunner, Follow Me Browsing, FormShare, GigaStack, IGX, Intelligence in the Optical Core, Internet Quotient, IP/VC, IQ Breakthrough, IQ Expertise, IQ FastTrack, IQ Readiness Scorecard, The IQ Logo, Kernel Proxy, MGX, Natural Network Viewer, NetSonar, Network Registrar, the Networkers logo, Packet, PIX, Point and Click Internetworking, Policy Builder, Precept, RateMUX, ReyMaster, ReyView, ScriptShare, Secure Script, Shop with Me, SlideCast, SMARTnet, SVX, The Cell, TrafficDirector, TransPath, VlanDirector, Voice LAN, Wavelength Router, Workgroup Director, and Workgroup Stack are trademarks; Changing the Way We Work, Live, Play, and Learn, Empowering the Internet Generation, The Internet Economy, and The New Internet Economy are service marks; and Aironet, ASIST, BPX, Catalyst, Cisco, Cisco IOS, the Cisco IOS logo, Cisco Systems, the Cisco Systems logo, the Cisco Systems Cisco Press logo, CollisionFree, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastLink, FastPAD, FastSwitch, GeoTel, IOS, IP/TV, IPX, LightStream, LightSwitch, MICA, NetRanger, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. or its affiliates in the U.S. and certain other countries. All other trademarks mentioned in this document are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any of its resellers. (0005R) Advanced MPLS VPN Solutions, Revision 1.0: Student Guide Copyright 2000, Cisco Systems, Inc. All rights reserved. Printed in USA.

4

5 Table of Contents Volume 1 ADVANCED MPLS VPN SOLUTIONS 1-1 Overview 1-1 Course Objectives 1-2 Course Objectives Implementation 1-3 Course Objectives Solutions 1-4 Prerequisites 1-5 Participant Role 1-7 General Administration 1-9 Sources of Information 1-10 MPLS VPN TECHNOLOGY 2-1 Overview 2-1 Objectives 2-1 Introduction to Virtual Private Networks 2-2 Objectives 2-2 Summary 2-8 Review Questions 2-8 Overlay and Peer-to-Peer VPN 2-9 Objectives 2-9 Overlay VPN Implementations 2-13 Summary 2-23 Review Questions 2-24 Major VPN Topologies 2-25 Objectives 2-25 VPN Categorizations 2-25 Summary 2-38 Review Questions 2-38 MPLS VPN Architecture 2-39 Objectives 2-39 Summary 2-60 Review Questions 2-61 MPLS VPN Routing Model 2-62 Objectives 2-62 Summary 2-78 Review Questions 2-78 MPLS VPN Packet Forwarding 2-79 Objectives 2-79 Summary 2-91 Review Questions 2-91 Lesson Summary 2-92 Answers to Review Questions 2-93 Introduction to Virtual Private Networks 2-93 Overlay and Peer-to-Peer VPN 2-93 Copyright 2000, Cisco Systems, Inc. Advanced MPLS VPN Solutions v

6 Major VPN Topologies 2-94 MPLS VPN Architecture 2-94 MPLS VPN Routing Model 2-95 MPLS VPN Packet Forwarding 2-96 MPLS/VPN CONFIGURATION ON IOS PLATFORMS 3-1 Overview 3-1 Objectives 3-1 MPLS/VPN Mechanisms in Cisco IOS 3-2 Objectives 3-2 Summary 3-16 Review Questions 3-16 Configuring Virtual Routing and Forwarding Table 3-17 Objectives 3-17 Summary 3-26 Review Questions 3-26 Configuring a Multi-Protocol BGP Session Between the PE Routers 3-27 Objectives 3-27 Summary 3-43 Review Questions 3-43 Configuring Routing Protocols Between PE and CE Routers 3-44 Objectives 3-44 Summary 3-55 Review Questions 3-55 Monitoring MPLS/VPN Operation 3-56 Objectives 3-56 Summary 3-82 Review Questions 3-82 Troubleshooting MPLS/VPN 3-83 Objectives 3-83 Summary Review Questions Advanced VRF Import/Export Features Objectives Summary Review Questions Advanced PE-CE BGP Configuration Objectives Summary Review Questions USING OSPF IN AN MPLS VPN ENVIRONMENT 4-1 Overview 4-1 Objectives 4-1 Using OSPF as the PE-CE Protocol in an MPLS VPN Environment 4-2 Objectives 4-2 Summary 4-26 Review Questions 4-26 Configuring and Monitoring OSPF in an MPLS VPN Environment 4-27 Objectives 4-27 Summary 4-35 Review Questions 4-35 vi Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

7 Volume 2 Summary 4-36 Answers to Review Questions 4-37 Using OSPF as the PE-CE Protocol in an MPLS VPN Environment 4-37 Configuring and Monitoring OSPF in an MPLS VPN Environment 4-37 MPLS VPN TOPOLOGIES 5-1 Overview 5-1 Objectives 5-1 Simple VPN with Optimal Intra-VPN Routing 5-2 Objectives 5-2 Summary 5-17 Review Questions 5-17 Using BGP as the PE-CE Routing Protocol 5-18 Objectives 5-18 Summary 5-23 Review Questions 5-23 Overlapping Virtual Private Networks 5-24 Objectives 5-24 Summary 5-33 Review Questions 5-33 Central Services VPN Solutions 5-34 Objectives 5-34 Summary 5-47 Review Questions 5-47 Hub-andSpoke VPN Solutions 5-48 Objectives 5-48 Summary 5-54 Review Questions 5-54 Managed CE-Router Service 5-55 Objectives 5-55 Summary 5-60 Review Questions 5-60 Chapter Summary 5-60 INTERNET ACCESS FROM A VPN 6-1 Overview 6-1 Objectives 6-1 Integrating Internet Access with the MPLS VPN Solution 6-2 Objectives 6-2 Summary 6-16 Review Questions 6-16 Design Options for Integrating Internet Access with MPLS VPN 6-17 Objectives 6-17 Summary 6-23 Review Questions 6-23 Leaking Between VPN and Global Backbone Routing 6-24 Objectives 6-24 Usability of Packet Leaking for Various Internet Access Services 6-32 Redundant Internet Access with Packet Leaking 6-36 Summary 6-38 Review Questions 6-38 Copyright 2000, Cisco Systems, Inc. Advanced MPLS VPN Solutions vii

8 Separating Internet Access from VPN Service 6-39 Objectives 6-39 Usability of Separated Internet Access for Various Internet Access Services 6-44 Summary 6-46 Review Questions 6-46 Internet Access Backbone as a Separate VPN 6-47 Objectives 6-47 Usability of Internet in a VPN Solution for Various Internet Access Services 6-52 Summary 6-56 Review Questions 6-57 Chapter Summary 6-57 MPLS VPN DESIGN GUIDELINES 7-1 Overview 7-1 Objectives 7-1 Backbone and PE-CE Link Addressing Scheme 7-2 Objectives 7-2 Summary 7-15 Review Questions 7-16 Backbone IGP Selection and Design 7-17 Objectives 7-17 Summary 7-30 Review Questions 7-31 Route Distinguisher and Route Target Allocation Schemes 7-32 Objective 7-32 Summary 7-37 Review Questions 7-37 End-to-End Convergence Issues 7-38 Objectives 7-38 Summary 7-52 Review Questions 7-52 Chapter Summary 7-53 Answers to Review Questions 7-54 Backbone and PE-CE Link Addressing Scheme 7-54 Backbone IGP Selection and Design 7-55 Route Distinguisher and Route Target Allocation Scheme 7-56 End-to-End Convergence Issues 7-56 LARGE-SCALE MPLS VPN DEPLOYMENT 8-1 Overview 8-1 Objectives 8-1 MP-BGP Scalability Mechanisms 8-2 Objectives 8-2 Summary 8-12 Review Questions 8-12 Partitioned Route Reflectors 8-13 Objectives 8-13 Summary 8-28 Review Questions 8-28 Chapter Summary 8-29 viii Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

9 MPLS VPN MIGRATION STRATEGIES 9-1 Overview 9-1 Objective 9-1 Infrastructure Migration 9-2 Objective 9-2 Summary 9-9 Review Questions 9-9 Customer Migration to MPLS VPN service 9-10 Objective 9-10 Generic Customer Migration Strategy 9-11 Migration From Layer-2 Overlay VPN 9-13 Migration from GRE Tunnel-Based VPN 9-16 Migration from IPSec-Based VPN 9-19 Migration from L2F-Based VPN 9-20 Migration From Unsupported PE-CE Routing Protocol 9-22 Summary 9-26 Review Questions 9-26 Chapter Summary 9-26 INTRODUCTION TO LABORATORY EXERCISES A-1 Overview A-1 Physical And Logical Connectivity A-2 IP Addressing Scheme A-5 Initial BGP Design A-7 Notes Pages A-8 LABORATORY EXERCISES FRAME-MODE MPLS CONFIGURATION B-1 Overview B-1 Laboratory Exercise B-1: Basic MPLS Setup B-2 Objectives B-2 Command list B-2 Task 1: Configure MPLS in your backbone B-2 Task 2: Remove BGP from your P-routers B-2 Verification: B-3 Review Questions B-4 Laboratory Exercise B-2: Disabling TTL Propagation B-5 Objective B-5 Command list B-5 Task: Disable IP TTL Propagation B-5 Verification B-5 Laboratory Exercise B-3: Conditional Label Advertising B-6 Objective B-6 Command list B-6 Task: Configure Conditional Label Advertising B-6 Verification B-6 Review Questions B-7 Copyright 2000, Cisco Systems, Inc. Advanced MPLS VPN Solutions ix

10 LABORATORY EXERCISES MPLS VPN IMPLEMENTATION C-1 Overview C-1 Laboratory Exercise C-1: Initial MPLS VPN Setup C-2 Objectives C-2 Background Information C-2 Command list C-3 Task 1: Configure multi-protocol BGP C-3 Task 2: Configure Virtual Routing and Forwarding Tables C-4 Additional Objective C-5 Task 3: Configuring Additional CE routers C-5 Verification C-6 Laboratory Exercise C-2: Running OSPF Between PE and CE Routers C-9 Objectives C-9 Visual Objective C-9 Command list C-10 Task 1: Configure OSPF on CE routers C-10 Task 2: Configure OSPF on PE routers C-10 Verification C-11 Task 3: Configure OSPF connectivity with additional CE routers C-11 Verification C-12 Laboratory Exercise C-3: Running BGP Between the PE and CE Routers C-13 Objectives C-13 Background Information C-13 Command list C-14 Task 1: Configure Additional PE-CE link C-14 Task 2: Configure BGP as the PE-CE routing protocol C-14 Verification C-15 Task 3: Select Primary and Backup Link with BGP C-16 Verification: C-16 Task 4: Convergence Time Optimization C-17 Verification C-17 LABORATORY EXERCISES MPLS VPN TOPOLOGIES D-1 Overview D-1 Laboratory Exercise D-1: Overlapping VPN Topology D-2 Objective D-2 Visual Objective D-2 Command list D-3 Task 1: Design your VPN solution D-4 Task 2: Remove WGxA1/WGxB1 from existing VRFs D-4 Task 3: Configure new VRFs for WGxA1 and WGxB1 D-4 Verification: D-4 Laboratory Exercise D-2: Common Services VPN D-8 Objective D-8 Background Information D-9 Command list D-10 Task 1: Design your Network Management VPN D-10 Task 2: Create Network Management VRF D-10 Verification D-11 Task 3: Establish connectivity between NMS VRF and other VRFs D-11 Verification D-11 Task 4: Establish routing between WGxPE2 and the NMS router D-12 x Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

11 Verification D-13 Laboratory Exercise D-3: Internet Connectivity Through Route Leaking D-14 Objective D-14 Visual Objective D-14 Command list D-15 Task 1: Cleanup from the previous VPN exercises D-15 Task 2: Configure route leaking between customer VPN and the Internet D-15 Verification D-16 Additional exercise: Fix intra-vpn routing D-17 Laboratory Exercise D-4: Separate Interface for Internet Connectivity D-18 Objective D-18 Visual Objective D-19 Command list D-20 Task 1: Cleanup from the previous exercise D-20 Verification D-21 Task 2: Establishing connectivity in the global routing table D-21 Task 3: Routing between the PE-router and the CE-router D-21 Verification D-22 Laboratory Exercise D-5: Internet in a VPN D-23 Objective D-23 Visual Objective D-23 Command list D-24 Task 1: Design your Internet VPN D-24 Task 2: Migrate Internet routers in a VPN D-24 Verification D-25 Additional Task: Direct Internet connectivity for all CE-routers D-26 Verification D-26 INITIAL LABORATORY CONFIGURATION E-1 Overview E-1 Laboratory Exercise E-1: Initial Core Router Configuration E-2 Objective E-2 Task: Configure Initial Router Configuration E-2 Verification E-3 Laboratory Exercise E-2: Initial Customer Router Configuration E-4 Objective E-4 Task: Configure Customer Routers E-4 Verification E-5 Laboratory Exercise E-3: Basic ISP Setup E-6 Objective E-6 Task 1: Configure IS-IS in your backbone E-6 Task 2: Configure BGP in your backbone E-6 Task 3: Configure Customer Routing E-6 Task 4: Peering with other Service Providers E-7 Task 5: Establishing Network Management Connectivity E-7 Verification E-7 INITIAL ROUTER CONFIGURATION F-1 Overview F-1 Router WGxPE1 F-2 Router WGxPE2 F-4 Copyright 2000, Cisco Systems, Inc. Advanced MPLS VPN Solutions xi

12 Router WGxPE3 F-6 Router WGxPE4 F-8 Router WGxP F-10 Router WGxA1 F-12 Router WGxA2 F-14 Router WGxB1 F-15 Router WGxB2 F-17 xii Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

13 1 Advanced MPLS VPN Solutions Overview Advanced MPLS VPN Solutions (AMVS) is an instructor-led course presented by Cisco training partners to their end-user customers. This four-day course focuses on using Virtual Private Networks (VPN) implemented with Multi-Protocol Label Switching (MPLS) technology. Upon completion of this training course, you will be able to design, implement and troubleshoot MPLS VPN networks. This chapter outlines the course prerequisites and course highlights, as well as some administrative issues. It includes the following topics: Course Objectives Course Topics Prerequisites Participant Role General Administration Sources of Information Course Syllabus Graphic Symbols

14 Course Objectives This section lists the course objectives. Course Objectives Technology Upon completion of this course, you will be able to perform the following tasks: Identify major VPN categories and topologies, their applications and technologies that can be used to implement them Describe MPLS/VPN terminology and architecture Describe the routing and forwarding model of MPLS/VPN 2000, Cisco Systems, Inc. BSCN v Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

15 Course Objectives Implementation Course Objectives Implementation Upon completion of this course, you will be able to perform the following tasks: Configure Virtual Routing and Forwarding tables Configure Multi-protocol BGP in MPLS/VPN backbone and the PE-CE routing protocols Configure advanced MPLS/VPN features Monitor and troubleshoot MPLS/VPN operations Describe the specifics of OSPF operation inside a VPN network 2000, Cisco Systems, Inc. BSCN v Copyright 2000, Cisco Systems, Inc. Advanced MPLS VPN Solutions 1-3

16 Course Objectives Solutions Course Objectives Solutions Upon completion of this course, you will be able to perform the following tasks: Design and implement various MPLS/VPN topologies Connect your VPN customers to the Internet Design and implement MPLS/VPN backbone Build large-scale MPLS VPN backbones Develop a migration strategy toward MPLS/VPN from a wide range of existing network infrastructures 2000, Cisco Systems, Inc. BSCN v Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

17 Prerequisites This section lists the course prerequisites. Prerequisites Successful completion of: Building Scalable Cisco Networks (BSCN) Configuring BGP on Cisco Routers One of the MPLS technology courses Advanced MPLS VPN Solutions Recommended: CCNP or CCIE certification In-depth OSPF or IS-IS knowledge MPLS Traffic Engineering and QoS knowledge 2000, Cisco Systems, Inc. BSCN v To fully benefit from AMVS, you should already possess certain knowledge and skills gained in a structured learning environment. You need to be have: In-depth understanding of IP routing and route redistribution in Cisco IOS In-depth knowledge of Border Gateway Protocol (BGP) and practical experience in configuring BGP networks Baseline MPLS knowledge. These skills can be gained from self-paced or instructor-led training sessions and from work experience. The best way to gain the skills you need to follow the CBCR course is: To gain IP routing and route redistribution skills, attend Building Scalable Cisco Networks (BSCN) course To gain BGP-related skills, attend Configuring BGP on Cisco Routers (CBCR) course To gain MPLS knowledge, attend MPLS Technology Essentials or Cisco MPLS course. You will be able to gain more practical experience from the course if already have work experience and router configuration skills. These skills are best demonstrated through Cisco career certifications Cisco Certified Networking Professional (CCNP) or Cisco Certified Internetworking Expert (CCIE). In-depth knowledge of Open Shortest Path First (OSPF) or Integrated Intermediate System Intermediate System (IS-IS) routing protocol will help you perform the laboratory exercises Copyright 2000, Cisco Systems, Inc. Advanced MPLS VPN Solutions 1-5

18 better. MPLS Traffic Engineering and MPLS Quality of Service knowledge will help you understand how these technologies relate to MPLS VPN. 1-6 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

19 Participant Role This section discusses your responsibilities as a student. Participant Role Student role Meet prerequisites Introduce yourself Ask and answer questions 2000, Cisco Systems, Inc. BSCN v To take full advantage of the information presented in this course, you should meet the prerequisites for this class. Introduce yourself to the instructor and other students who will be working with you during the five days of this course. You are encouraged to ask any questions relevant to the course materials. If you have pertinent questions concerning other Cisco features and products not covered in this course, please bring these topics up during breaks or after class, and the instructor will try to answer the questions or direct you to an appropriate information source. Copyright 2000, Cisco Systems, Inc. Advanced MPLS VPN Solutions 1-7

20 Welcome: Please Introduce Yourself Your name and work location Your job responsibilities Your internetworking experience Your objectives for this week 2000, Cisco Systems, Inc. BSCN v Introduce yourself, stating your name and the job function you perform at your work location. Briefly describe what experience you have with installing and configuring Cisco routers, attending Cisco classes, and how your work experience helped you meet the prerequisites highlighted earlier. You should also state what you expect to learn from this course. 1-8 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

21 General Administration This section highlights miscellaneous administrative tasks that must be addressed. General Administration Class-related Sign-in sheet Length and times Participant materials Attire Facilities-related Rest rooms Site emergency procedures Break and lunch room locations Communications 2000, Cisco Systems, Inc. BSCN v The instructor will discuss the administrative issues in detail so you will know exactly what to expect from both the class and facilities. The following items will be discussed: Recording your name on a sign-in sheet The starting and anticipated ending time of each class day What materials you can expect to receive during the class The appropriate attire during class attendance Rest room locations What to do in the event of an emergency Class breaks and lunch facilities How to send and receive telephone, , and fax messages Copyright 2000, Cisco Systems, Inc. Advanced MPLS VPN Solutions 1-9

22 Sources of Information This section identifies additional sources of information. Sources of Information Student kit CD-ROMs Cisco Press 2000, Cisco Systems, Inc. BSCN v Most of the information presented in this course can be found on the Cisco Systems Web site or on CD-ROM. These supporting materials are available in HTML format and as manuals and release notes. To learn more about the subjects covered in this course, feel free to access the following sources of information: Cisco Documentation CD-ROM ITM CD-ROM Cisco IOS 12.1 Configuration Guide Cisco IOS 12.1 Command Reference Guide Many of these documents can be found at the following URL: Cisco Press books and documents can be found at the following URL: Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

23 Course Syllabus Technology Implementation Solutions MPLS VPN Technology MPLS VPN Configuration on IOS platforms Running OSPF in an MPLS VPN Environment MPLS VPN Topologies Internet Access from a VPN MPLS VPN Design Guidelines Large-Scale MPLS VPN Deployment MPLS VPN Migration Strategies 2000, Cisco Systems, Inc. BSCN v The following schedule reflects the recommended structure for this course. This structure allows enough time for your instructor to present the course information to you and for you to work through the laboratory exercises. The exact timing of the subject materials and labs depends on the pace of your specific class. Module 1, MPLS VPN Technology (0,5 day) The purpose of this module is to introduce you to the concept of Virtual Private Networks and MPLS VPN Architecture. The module also discusses routing and data forwarding model of MPLS VPN. Module 1 includes the following chapters: Chapter 1, Introduction Chapter 2, MPLS VPN Technology Module 2, MPLS VPN Implementation (1,5 day) The purpose of this module is to describe the operation and configuration of MPLS VPN on Cisco IOS platforms. Module 2 includes the following chapters: Chapter 3, MPLS VPN Configuration on IOS Platforms Chapter 4, Using OSPF in an MPLS VPN Environment Module 3, MPLS VPN Solutions (2 days) The purpose of the module is to describe typical MPLS VPN usage scenarios and give you design and implementation guidelines needed to deploy these scenarios in your network. Module 3 includes the following chapters: Chapter 5, MPLS VPN Topologies Chapter 6, Internet Access from a VPN Copyright 2000, Cisco Systems, Inc. Advanced MPLS VPN Solutions 1-11

24 Chapter 7, MPLS VPN Design Guidelines Chapter 8, Large-Scale MPLS VPN Deployment Chapter 9, MPLS VPN Migration Strategies 1-12 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

25 2 MPLS VPN Technology Overview Objectives This lesson introduces Virtual Private Networks (VPN) and two major VPN design options overlay VPN and peer-to-peer VPN. VPN terminology and topologies are introduced. The lesson then describes MPLS VPN architecture, operations and terminology. It details CE-PE routing from various perspectives and BGP extensions (route targets, and extended community attributes) that allow I-BGP to transport customer routes over a provider network. The MPLS VPN forwarding model is also covered together with its integration with core routing protocols Upon completion of this lesson, you will be able to perform the following tasks: Identify major Virtual Private network topologies, their characteristics and usage scenarios Describe the differences between overlay VPN and peer-to-peer VPN List major technologies supporting overlay VPNs and peer-to-peer VPNs Position MPLS VPN in comparison with other peer-to-peer VPN implementations Describe major architectural blocks of MPLS VPN Describe MPLS VPN routing model and packet forwarding

26 Introduction to Virtual Private Networks Objectives Upon completion of this section, you will be able to perform the following tasks: Describe the concept of VPN Understand VPN terminology as defined by MPLS VPN architecture 2-2 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

27 Traditional Router-Based Networks Site A Site B Site C Site D Traditional router-based networks connect customer sites through routers connected via dedicated point-to-point links 2000, Cisco Systems, Inc. Page5 Traditional router-based networks were implemented with dedicated point-to-point links connecting customer sites. The cost of such an approach was comparatively high for a number of 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-customer Every link required a dedicated port on a router, resulting in high equipment costs. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-3

28 Virtual Private Networks Virtual Circuit (VC) #1 Customer site Customer Premises router (CPE) Provider core device Provider edge device (Frame Relay switch) PE device PE device CPE router Other CPE router customer routers Large customer site Virtual Circuit (VC) #2 Service Provider Network Virtual Private Networks replace dedicated point-topoint links with emulated point-to-point links sharing common infrastructure Customers use VPNs primarily to reduce their operational costs 2000, Cisco Systems, Inc. Page6 Virtual Private Networks (VPNs) were introduced very early in the history of data communications with technologies like X.25 and Frame Relay, which use virtual circuits to establish the end-to-end connection over a shared service provider infrastructure. These technologies, although sometimes considered legacy and obsolete, still share the basic business assumptions with the modern VPN approaches: The dedicated links are replaced with common infrastructure that emulates point-to-point links for the customer, resulting in statistical sharing of Service Provider infrastructure Statistical sharing of infrastructure enables the service provider to offer the connectivity for lower price, resulting in lower operational costs for the end customers. The statistical sharing is illustrated in the graphic, where you can see the CPE router on the left has one physical connection to the service provider with two virtual circuits provisioned. Virtual Circuit 1 (VC # 1) provides connectivity to the top CPE router on the right. Virtual Circuit 2 (VC #2) provides the connectivity to the bottom CPE router on the right. 2-4 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

29 VPN Terminology Customer site Large customer site Provider Network (P-Network): the Service Provider infrastructure used to provide VPN services Customer Network (C-Network): the part of the network still under customer control Customer Site: a contiguous part of customer network (can encompass many physical locations) 2000, Cisco Systems, Inc. Page7 There are many conceptual models and terminologies describing various Virtual Private Network technologies and implementations. In this section we ll focus on the terminology introduced by MPLS VPN architecture. As you ll see, the terminology is generic enough to cover any VPN technology or implementation and is thus extremely versatile. The major parts of an overall VPN solution are always: The Service Provider network (P-network): the common infrastructure the Service Provider uses to offer VPN services to the customers The Customer network (C-network): the part of the overall customer network that is still exclusively under customer control. Customer sites: contiguous parts of customer network. A typical customer network implemented with any VPN technology would contain islands of connectivity completely under customer control (customer sites) connected together via the Service Provider infrastructure (P-network). Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-5

30 VPN Terminology Customer site Service Provider Network Large customer site Provider Edge (PE) device: the device in the P-network to which the CE-devices are connected Provider core (P) device: the device in the P-network with no customer connectivity Customer Edge (CE) device: the device in the C-network with link into P-network. Also called Customer Premises Equipment (CPE) 2000, Cisco Systems, Inc. Page8 The devices that enable the overall VPN solution are named based on their position in the network: Customer router that connected the customer site to the Service Provider network is called a Customer Edge router (CE-router). Traditionally this device is called Customer Premises Equipment (CPE). Note If the CE device is not a router, but, for example, a Packet Assembly and Disassembly (PAD) device, we can still use a generic term CE-device. Service Provider devices where the customer devices are attached are called Provider Edge (PE) devices. In traditional switched Wide Area Network (WAN) implementations, these devices would be Frame Relay or X.25 edge switches. Service Provider devices that only provide 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 would be core (or transit) switches. 2-6 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

31 VPN Terminology Specific to Switched WAN Virtual Circuit (VC) #1 Customer site Customer Premises Router (CPE) Provider core device Provider edge device (Frame Relay switch) PE device PE device CPE router Other CPE router customer routers Large customer site Virtual Circuit (VC) #2 Service Provider Network Virtual Circuit (VC): emulated point-topoint link established across shared layer-2 infrastructure Permanent Virtual Circuit (PVC) is established through out-of-band means (network management) and is always active Switched Virtual Circuit (SVC) is established through CE-PE signaling on demand from the CE device 2000, Cisco Systems, Inc. Page9 Switched WAN technologies introduced a term Virtual Circuit (VC), which is an emulated point-to-point link established across layer-2 infrastructure (for example, Frame Relay network). The virtual circuits are further differentiated into Permanent Virtual Circuits (PVC) which are pre-established by means of network management or manual configuration and Switched Virtual Circuits (SVC) which are established on demand through a call setup request from the CE device. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-7

32 Summary Virtual Private Networks were introduced by Service Providers to offer a more cost-effective alternative to traditional customer network design, which relied on dedicated point-to-point links between customer sites. The overall network implemented with a VPN solution is divided into the Customer network (C-network), which is exclusively under customer s control and the Provider network (P-network), the shared infrastructure used to offer the VPN services. A contiguous part of the C-network is called a customer site. The device linking a customer site with the P-network is called Customer Edge (CE) device. Most commonly this is a router, called CE-router. This component was traditionally named Customer Premises Equipment (CPE). The edge device in Service Provider network, to which the customers are attached, is called Provider Edge (PE) device. The device inside the Provider network with no customer connectivity is a Provider (P) device. Review Questions Answer the following questions: Why are customers interested in Virtual Private Networks? What is the main role of a VPN? What is a C-network? What is a customer site? What is a CE-router? What is a P-network? What is the difference between a PE-device and a P-device? 2-8 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

33 Overlay and Peer-to-Peer VPN Objectives Upon completion of this section, you will be able to perform the following tasks: Describe the differences between overlay and peer-to-peer VPN Describe the benefits and drawbacks of each VPN implementation option List major technologies supporting overlay VPNs Describe traditional peer-to-peer VPN implementation options Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-9

34 VPN Implementation Technologies VPN services can be offered based on two major paradigms: Overlay Virtual Private Networks where the Service Provider provides virtual point-topoint links between customer sites Peer-to-Peer Virtual Private Networks where the Service Provider participates in the customer routing 2000, Cisco Systems, Inc. Page14 Traditional VPN implementations were all based on the overlay paradigm the Service Provider sells virtual circuits between customer sites as a replacement for dedicated point-to-point links. The overlay paradigm has a number of drawbacks that will be identified in this section. To overcome these drawbacks (particularly in IP-based customer networks), a new paradigm called peer-to-peer VPN was introduced where the Service Provider actively participates in customer routing Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

35 Overlay VPN Implementation (Frame Relay Example) Customer Site Virtual Circuit (VC) #2 Customer Site Router A Customer Site (VC) #1 Provider Edge Device (Frame Relay Switch) Frame Relay Edge Switch Router C Customer Site Router B Frame Relay Edge Switch Virtual Circuit (VC) #3 Frame Relay Edge Switch Service Provider Network Router D 2000, Cisco Systems, Inc. Page15 The diagram above shows a typical overlay VPN, implemented by a Frame Relay network. The customer needs to connect three sites (site Alpha being the central site the hub) and orders connectivity between Alpha (Hub) and Beta (Spoke) and between Alpha (Hub) and Gamma (Spoke). The Service Provider implements this request by providing two PVCs across the Frame Relay network. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-11

36 Layer-3 routing in Overlay VPN implementation Router A Router B Router C Router D Service Provider infrastructure appears as point-topoint links to customer routes Routing protocols run directly between customer routers Service Provider does not see customer routes and is responsible only for providing point-to-point transport of customer data 2000, Cisco Systems, Inc. Page16 From the layer-3 perspective, the Service Provider network is invisible the customer routers are linked with emulated point-to-point links. The routing protocol is run 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 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

37 Overlay VPN Implementations There are a number of different overlay VPN implementations, ranging from traditional Time Division Multiplexing (TDM) to highly complex technologies running across IP backbones. In the following slides, we ll introduce major VPN technologies and implementations. Overlay VPN Layer-1 Implementation IP PPP HDLC ISDN E1, T1, DS0 SDH, SONET This is the traditional TDM solution: Service Provider establishes physical-layer connectivity between customer sites Customer takes responsibility for all higher layers 2000, Cisco Systems, Inc. Page17 In layer-1 overlay VPN implementation, the Service Provider sells layer-1 circuits (bit pipes) implemented with technologies like ISDN, DS0, E1, T1, SDH or SONET. The customer takes responsibility for layer-2 encapsulation between customer devices and the transport of IP data across the infrastructure. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-13

38 Overlay VPN Layer-2 Implementation IP X.25 Frame Relay ATM This is the traditional Switched WAN solution: Service Provider establishes layer-2 virtual circuits between customer sites Customer takes responsibility for all higher layers 2000, Cisco Systems, Inc. Page18 Layer-2 VPN implementation is the traditional switched WAN model, implemented with technologies like X.25, Frame Relay, ATM or SMDS. The Service Provider is responsible for transport of layer-2 frames between customer sites and the customer takes responsibility for all higher layers Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

39 Overlay VPN IP Tunneling Internet Protocol (IP) Generic Route Encapsulation (GRE) IP Security (IPSec) Internet Protocol (IP) 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 2000, Cisco Systems, Inc. Page19 With the success of Internet Protocol (IP) and associated technologies, some Service Providers started to implement pure IP backbones to offer VPN services based on IP. In other cases, the customers want to take advantage of low cost and universal availability of Internet to build low-cost private networks over it. Whatever the business reasons behind it, overlay Layer 3 VPN implementation over IP backbone always involves tunneling (encapsulation of protocol units at a certain layer of OSI model into protocol units at the same or higher layer of OSI model). Two well-known tunneling technologies are IP Security (IPSEC) and Generic Route Encapsulation (GRE). GRE is fast and simple to implement and supports multiple routed protocols, but provides no security and is thus unsuitable for deployment over the Internet. An alternate tunneling technology is IPSec, which provides network layer authentication and optional encryption to make data transfer over the Internet secure. IPSec only supports the IP routed protocol. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-15

40 Overlay VPN Layer-2 Forwarding Internet Protocol (IP) Point-to-Point Protocol (PPP) Layer-2 Transport Protocol (L2TP) Layer-2 Forwarding (L2F) Point-to-Point Tunneling (PPTP) Internet Protocol (IP) VPN is implemented with PPP-over-IP tunnels Usually used in access environments (dial-up, DSL) 2000, Cisco Systems, Inc. Page20 Yet another tunneling technique that was first implemented in dial-up networks, where the Service Providers wanted to tunnel customer dial-up data encapsulated in point-to-point protocol (PPP) frames over an IP backbone to the customer s central site. To make the Service Provider transport transparent to the customer, PPP frames are exchanged between the customer sites (usually a dial-up user and a central site) and the customer is responsible for establishing layer-3 connectivity above PPP. There are three well-known PPP forwarding implementations: Layer 2 Forwarding (L2F) Layer 2 Transport Protocol (L2TP) Point-to-Point Tunneling Protocol (PPTP) 2-16 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

41 Peer-to-Peer VPN Concept Customer Site Routing information is exchanged between customer and service-provider routers Service Provider Network Customer Site Router A Customer Site Provider Edge (PE) Router (PE) Router Router C Customer Site Router B Router D (PE) Router (PE) Router Service Provider routers exchange customer routes through the core network Finally, the customer routes propagated through the service-provider network are sent to other customer routers 2000, Cisco Systems, Inc. Page21 Overlay VPN paradigm has a number of drawbacks, most significant of them being the need for the customer to establish point-to-point links or virtual circuits between sites. The formula to calculate how many point-to-point links or virtual circuits you need in the worst case is ((n)(n-1))/2, where n is the number of sites you need to connect. For example, if you need to have full mesh connectivity between 4 sites, you will need a total of 6 point-to-point links or virtual circuits. To overcome this drawback and provide the customer with optimum data transport across the Service Provider backbone, the peer-to-peer VPN concept was introduced where the Service Provider actively participates in the customer routing, accepting customer routes, transporting them across the Service Provider backbone and finally propagating them to other customer sites. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-17

42 Peer-to-Peer VPN with Packet Filters Customer A Site #1 Service provider network Point-of-Presence Customer A Site #2 Customer B Site #1 Shared router POP router carries all customer routes Isolation between customers is achieved with packet filters on PE-CE interfaces 2000, Cisco Systems, Inc. Page22 The first peer-to-peer VPN solutions appeared several years ago. Architectures similar to the Internet were used to build them and special provisions had to be taken in account to transform the architecture, which was targeted toward public backbones (Internet) into a solution where the customers would be totally isolated and able to exchange their corporate data securely. The more common peer-to-peer VPN implementation uses packet filters on the PE-routers to isolate the customers. 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 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

43 Peer-to-Peer VPN with Controlled Route Distribution Customer A Site #1 Service provider network Point-of-Presence The P-router contains all customer routes Customer A Site #2 PE-router Customer-A P-router Uplink PE-router Customer-B Customer B Site #1 Each customer has a dedicated PE router that only carries its routes Customer isolation is achieved through lack of routing information on PE router 2000, Cisco Systems, Inc. Page23 Maintaining packet filters is a mundane and error-prone task. Some Service Providers thus implemented more innovative solutions based on controlled route distribution. In this approach, the core Service Provider routers (the P-routers) would contain all customer routes and the PE-routers would only contain routes of a single customer, requiring a dedicated PE-router per customer per Point-of- Presence (POP). The customer isolation is achieved solely through lack of routing information on the PE-router. Using route filtering between the P-router and the PE-routers, the PE-router for Customer A will only learn routes belonging to Customer A, and the PE-router for Customer B will only learn routes belonging to Customer B. Border Gateway Protocol (BGP) with BGP communities is usually used inside the Provider backbone since it offers the most versatile route filtering tools. Note Default routes used anywhere in the customer or Service Provider network break isolation between the customers and have to be avoided. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-19

44 Overlay VPN Benefits of Various VPN Implementations 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 the sites are provisioned, not the links between them 2000, Cisco Systems, Inc. Page24 Each VPN paradigm has a number of benefits: Overlay VPNs are well known and easy to implement, both from customer and Service Provider perspective The Service Provider does not participate in customer routing in overlay VPNs, making the demarcation point between the Service Provider and the customer easier to manage. On the other hand, the peer-to-peer VPN give you: Optimum routing between customer sites without any special design or configuration effort Easy provisioning of additional VPNs or customer sites, as the Service Provider only needs to provision individual sites, not the links between individual customer sites Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

45 Drawbacks of Various VPN Implementations Overlay VPN Implementing optimum routing requires fullmesh of virtual circuits Virtual circuits have to be provisioned manually Bandwidth must be provisioned on a site-tosite basis Always incurs encapsulation overhead Peer-to-Peer VPN Service Provider participates in customer routing SP becomes responsible for customer convergence PE routers carry all routes from all customers SP needs detailed IP routing knowledge 2000, Cisco Systems, Inc. Page25 Each VPN paradigm also has a number of drawbacks: Overlay VPNs require a full mesh of virtual circuit between customer sites to provide optimum inter-site routing All the virtual circuits between customer sites in an overlay VPN 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) also incur high encapsulation overhead (ranging from 20 to 80 bytes per transported datagram). The major drawbacks of peer-to-peer VPN arise from the Service Provider s involvement in customer routing: The Service Provider becomes responsible for correct customer routing and for fast convergence of customer network following a link failure. The Service Provider P-routers have to carry all customer routes that were hidden from the Service Provider in the overlay VPN paradigm. The Service Provider needs detailed IP routing knowledge, which is not readily available in traditional Service Provider teams. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-21

46 Drawbacks of Traditional Peerto-Peer VPNs Shared PE router All customers share the same (provider-assigned or public) address space High maintenance costs associated with packet filters Lower performance 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 2000, Cisco Systems, Inc. Page26 The pre-mpls VPN implementations of peer-to-peer VPNs all shared a common drawback the customers have to share the same address space, either using public IP addresses in their private networks or relying on service providerassigned IP addresses. In both cases, connecting a new customer to a peer-to-peer VPN service usually requires IP renumbering inside the customer network an operation, which most customers are reluctant to perform. The peer-to-peer VPNs based on packet filters also incur high operational costs associated with packet filter maintenance as well as performance degradation due to heavy usage of packet filters. The peer-to-peer VPNs implemented with per-customer PE-routers are easier to maintain and can give you optimum routing performance, but are usually more expensive since every customer requires a dedicated router in every POP. This approach is thus usually used in scenarios where the Service Provider only provides service to a small number of large customers Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

47 Summary VPN Taxonomy Virtual Private Networks Layer 2 VPN X.25 F/R ATM Virtual Networks Virtual Dialup Networks Overlay VPN Layer 3 VPN GRE IPSec Virtual LANs Peer-to-Peer VPN Access Lists (Shared Router) Split Routing (Dedicated Router) MPLS VPN 2000, Cisco Systems, Inc. Page27 There are a number of different Virtual Networking concepts present in the data communications fields: The Virtual Local Area Networks (VLAN) allow you to implement isolated LANs over the same physical infrastructure Virtual Private Dialup Networks (VPDN) allow customers to use dial-in infrastructure of a Service Provider for their private dial-up connections Virtual Private Networks (VPN) allow customers to use shared infrastructure of a Service Provider to implement their private networks. There are two major VPN paradigms: Overlay VPN, where the Service Provider gives the customer emulated pointto-point links across Service Provider backbone and Peer-to-peer VPN, where the Service Provider becomes actively involved in customer routing and acts as the core layer-3 backbone of the customer network. The overlay VPNs are implemented with a number of technologies, ranging from traditional layer-1 technologies (ISDN, SDH, SONET) and layer-2 technologies (X.25, Frame Relay, ATM) to modern IP-based solutions (GRE and IPSec). Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-23

48 The overlay VPNs, although well known and easy to implement, are harder to operate due to higher maintenance costs: Every individual virtual circuit needs to be provisioned Optimum routing between customer sites requires a full mesh of virtual circuits between sites Bandwidth has to be provisioned on site-to-site basis. Traditional peer-to-peer VPNs are implemented with packet filters on shared PErouters or with dedicated per-customer PE-routers. Along with high maintenance costs (for packet-filter approach) or equipment costs (for dedicated per-customer PE-router approach), both methods require customer to accept the Service Provider assigned address space or use public IP addresses in the private customer network. MPLS VPN, introduced in the next sections, provides all the benefits of peer-topeer VPNs and alleviates most of the peer-to-peer VPN drawbacks (for example, the need for common customer address space). Review Questions Answer the following questions: What is an overlay VPN? Which routing protocol runs between the customer and the service provider in an overlay VPN? Which routers are routing protocol neighbors of a CE-router in overlay VPN? List three IP-based overlay VPN technologies. What is the major benefit of peer-to-peer VPN as compared to overlay VPN? List two traditional peer-to-peer VPN implementations? What is the drawback of all traditional peer-to-peer VPN implementations? 2-24 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

49 Major VPN Topologies Objectives Upon completion of this section, you will be able to perform the following tasks: Identify the three major categorizations of VPN Identify the three Overlay VPN topologies Understand the implications of using overlay VPN approach with each topology List sample usage scenarios for each topology Identify the three VPN categorization based on business needs Identify the three VPN categorization based on connectivity needs VPN Categorizations There are three major VPN categorizations: Topology categorization, which only applies to overlay VPNs Business categorization, which categorizes VPNs based on the business needs they fulfill Connectivity categorization, which classifies VPNs based on their connectivity requirements. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-25

50 VPN Topology Categorization Overlay VPNs are categorized based on the topology of the virtual circuits: (Redundant) Hub-and-spoke topology Partial-mesh topology Full-mesh topology Multi-level topology combines several levels of overlay VPN topologies 2000, Cisco Systems, Inc. Page32 The oldest VPN categorization was based on the topology of point-to-point links in an overlay VPN implementation: Full-mesh topology provides a dedicated virtual circuit between any two CErouters in the network Partial-mesh topology reduces the number of virtual circuits, usually to the minimum number that still provides optimum transport between major sites Hub-and-spoke topology is the ultimate reduction of partial-mesh many sites (spokes) are only connected with the central site(s) (hubs) with no direct connectivity between the spokes. To prevent single points of failure, the huband-spoke topology is sometimes extended to redundant hub-and-spoke topology. Large networks usually deploy a layered combination of these technologies, for example: Partial mesh in the network core Redundant hub-and-spoke for larger branch offices (spokes) connected to distribution routers (hubs) Simple hub-and-spoke for non-critical remote locations (for example, home offices) Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

51 Overlay VPN Hub-and-Spoke Topology Remote site (spoke) Central site (HUB) Remote site (spoke) Central site router Remote site (spoke) Service Provider Network Remote site (spoke) 2000, Cisco Systems, Inc. Page33 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 distance-vector protocol like RIP are more than adequate. If you are using dynamic routing protocol like RIP, splithorizon must be disabled at the hub router, or you must use point-to-point subinterfaces at the hub router to overcome the split-horizon problem. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-27

52 Overlay VPN Redundant Hub-And-Spoke Remote site (spoke) Central site (HUB) Service Provider Network Remote site (spoke) Redundant Central site router Remote site (spoke) Redundant Central site router Remote site (spoke) 2000, Cisco Systems, Inc. Page34 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/backup configuration Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

53 Overlay VPN Partial Mesh Guam New York Moscow Virtual circuits (Frame Relay DLCI) Hong Kong Berlin Sydney 2000, Cisco Systems, Inc. Page35 Partial mesh is used in environments where the cost or complexity factors prevent a full-mesh between customer sites. The virtual circuits in a partial mesh can be established based on a wide range of criteria: Traffic pattern between sites Availability of physical infrastructure Cost considerations Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-29

54 Overlay VPN Multi-Level Hub-and-Spoke Distribution site Remote site (spoke) Distribution-layer router Central site (hub) Remote site (spoke) Redundant central site router Service Provider Network Remote site (spoke) Redundant central site router Distribution-layer router Distribution site Remote site (spoke) 2000, Cisco Systems, Inc. Page36 Various overlay VPN topologies are usually combined in a large network. For example, in the diagram above, a redundant hub-and-spoke topology is used in network core and a non-redundant hub-and-spoke is used between distribution sites and remote sites. This topology would be commonly used in environments where all traffic flows between the central site and remote sites and there is little (or no) traffic exchanged directly between the remote sites Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

55 VPN Business Categorization VPNs can be categorized on the business needs they fulfill: Intranet VPN connects sites within an organization Extranet VPN connects different organizations in a secure way Access VPN Virtual Private Dialup Network (VPDN) provides dial-up access into a customer network 2000, Cisco Systems, Inc. Page37 Another very popular VPN categorization classifies VPNs based on the business needs they fulfill: Intranet VPNs connect sites within an organization. Security mechanisms are usually not deployed in an Intranet, as all sites belong to the same organization. Extranet VPN connects different organizations. Extranets implementations usually rely on security mechanisms to ensure protection of individual organizations participating in the Extranet. The security mechanisms are usually the responsibility of individual participation organizations. Access VPN - Virtual Private Dialup Networks that provide dial-up access into a customer network. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-31

56 The following two diagrams compare overlay VPN implementation of an Extranet with a peer-to-peer one. Similar comparisons could be made for Intranets as well. Extranet VPN Overlay VPN Implementation Frame Relay Virtual Circuits (DLCI) GlobalMotors Provider IP backbone Firewall Frame Relay switch BoltsAndNuts Firewall Frame Relay switch Firewall AirFilters Inc. SuperBrakes Inc. Firewall Frame Relay switch Frame Relay switch Firewall 2000, Cisco Systems, Inc. Page38 In an overlay implementation of an Extranet, organizations are linked with dedicated virtual circuits. Traffic between two organizations can only flow if: There is a direct virtual circuit between the organizations or There is a third organization linked with both of them that is willing to provide transit traffic capability to them. As establishing virtual circuits between two organizations is always associated with costs, the transit traffic capability is almost never granted free-of-charge Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

57 Extranet VPN Peer-to-Peer VPN Implementation GlobalMotors Firewall Provider IP backbone Provider edge (PE) router BoltsAndNuts Firewall Provider edge (PE) router Provider edge (PE) router Firewall AirFilters Inc. SuperBrakes Inc. Firewall Provider edge (PE) router Provider edge (PE) router Firewall 2000, Cisco Systems, Inc. Page39 Peer-to-peer VPN implementation of an Extranet VPN is very simple compared to an overlay VPN implementation all sites are connected to the Service Provider network and the 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. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-33

58 VPN Connectivity Categorization VPNs can also be categorized by the connectivity required between sites: Simple VPN every site can communicate with every other site Overlapping VPN 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 2000, Cisco Systems, Inc. Page40 The virtual private networks discussed so far were usually very simple in connectivity terms: In most cases, full connectivity between sites was required (in overlay Intranet VPN implementations, this usually means that some customer sites act as transit sites) In the overlay implementation of the Extranet VPN, the connectivity was limited to sites that had direct virtual circuits established between them. There are, however, a number of advanced VPN topologies with more complex connectivity requirements: Overlapping VPNs, where a site participates in more than one VPN Central Services VPN, where the sites are split in two classes server sites that can communicate with all other sites and client sites that can only communicate with the servers, but not with other clients. Network Management VPN, which is used to manage CE devices in scenarios where the Service Provider owns and manages CE devices Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

59 Central Services Extranet Amsterdam Service provider Extranet Infrastructure Customer A VoIP GW London Customer B VoIP GW Paris Customer C VoIP GW Service Provider Network 2000, Cisco Systems, Inc. Page41 This diagram shows a sample Central Services extranet implementing international Voice-over-IP service. Every customer of this service can access voice gateways in various countries, but cannot access other customers using the same service. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-35

60 Central Services Extranet Hybrid (Overlay + P2P) Implementation Amsterdam London VoIP GW Service provider Extranet Infrastructure Provider Edge Router Provider Edge Router Frame Relay Infrastructure Frame Relay Edge switch Customer A Customer B VoIP GW Provider Edge Router Frame Relay Edge switch Paris Provider Edge Router Customer C VoIP GW Provider Edge Router Frame Relay Edge switch Service Provider Network Frame Relay Virtual Circuit 2000, Cisco Systems, Inc. Page42 The network diagram shown above describes an interesting scenario where peerto-peer VPN and overlay VPN implementation can be used to provide end-to-end service to the customer. The VoIP service is implemented with Central Services extranet topology, which is in turn implemented with peer-to-peer VPN. The connectivity between PErouters in the peer-to-peer VPN and the customer routers is implemented with an overlay VPN based on Frame Relay. The PE-router of the peer-to-peer VPN and the CE-routers act as CE-devices of the Frame Relay network Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

61 Managed Network Overlay VPN Implementation Service provider network Remote site (spoke) Central site (hub) Remote site (spoke) Redundant central site router Remote site (spoke) Redundant central site router Network Management Center Dedicated Virtual Circuits are used for network management 2000, Cisco Systems, Inc. Page43 Network management 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 router (NMS-router) to which the Network Management Station (NMS) is connected. This network management VPN implementation is sometimes called rainbow implementation, as 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. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-37

62 Summary There are three major categorizations of Virtual Private networks: Topology categorization, which classifies the VPNs based on the topology of point-to-point connections in overlay VPN implementation Business categorization, which classifies VPNs into Intranets, Extranets and niche solutions like Virtual Private Dialup Networks Connectivity categorization, which classifies VPNs based on the connectivity needs. The topology categorization ranges VPNs from full mesh, where there is a direct virtual circuit between any two sites, to partial mesh, which is built based on a number of constraints (traffic patterns and cost being the most important of them) and finally hub-and-spoke where a central site acts as the transit point between all spoke sites. Real-life large networks are usually implemented with a combination of these topologies. The connectivity categorization divides VPNs into simple VPNs (with any-to-any connectivity), overlay VPNs where a single site participates in more than one simple VPN, Central Services VPNs, where some sites have limited connectivity and Network Management VPNs, which are really only a special case of Central Services VPN. Review Questions Answer the following questions: What are the major Overlay VPN topologies Why would the customers prefer partial mesh over full mesh topology? What is the difference between an Intranet and an Extranet? What is the difference between a simple VPN and a Central Services VPN? What are the connectivity requirements of a Central Services VPN? 2-38 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

63 MPLS VPN Architecture Objectives Upon completion of this section, you will be able to perform the following tasks: Understand the difference between traditional peer-to-peer models and MPLS VPN List the benefits of MPLS VPN Describe major architectural blocks of MPLS VPN Explain the need for route distinguisher (RD) and route target (RT) Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-39

64 MPLS VPN Architecture MPLS VPN combines the best features of overlay VPN and peer-to-peer VPN PE routers participate in customer routing, guaranteeing optimum routing between sites and easy provisioning PE routers carry a separate sets of routes for each customer (similar to dedicated PE router approach) Customers can use overlapping addresses 2000, Cisco Systems, Inc. Page48 The MPLS VPN architecture provides the Service Providers with a peer-to-peer VPN architecture that combines the best features of overlay VPN (support for overlapping customer address spaces) with the best features of peer-to-peer VPNs: PE routers participate in customer routing, guaranteeing optimum routing between customer sites PE routers carry separate set of routes for each customer, resulting in perfect isolation between the customers Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

65 MPLS VPN Terminology Customer A Site #1 Remote Office Remote Office Site #1 CE router P-Network Customer A Site #4 Customer A Site #2 PE-Router POP-X P-Router PE-Router POP-Y Customer B Site #2 Customer A Site #3 Customer B Site #3 Customer B Site #1 Customer B Site #4 2000, Cisco Systems, Inc. Page49 The MPLS VPN terminology divides the overall network into customer controlled part (C-network) and provider controlled part (P-network). Contiguous portions of C-network are called sites and are linked with the P-network via CE-routers. The CE-routers are connected to the PE-routers, which serve as the edge devices of the Provider network. The core devices in the provider network (P-routers) provide the transit transport across the provider backbone and do not carry customer routes. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-41

66 Provider Edge Router Architecture Customer A Site #1 Virtual router for Customer A Global IP router Customer A Site #2 Virtual IP routing table for Customer A Global IP routing table P-router Customer A Site #3 Customer B Site #1 Virtual router for Customer B Virtual IP routing table for Customer B MPLS VPN architecture is very similar to the dedicated PE router peer-to-peer model, but the dedicated per-customer routers are implemented as virtual routing tables within the PE router PE-router 2000, Cisco Systems, Inc. Page50 The architecture of a PE-router in MPLS VPN is very similar to the architecture of a Point-of-Presence (POP) in the dedicated PE-router peer-to-peer model, the only difference being that the whole architecture is condensed into one physical device. Each customer is assigned an independent routing table (virtual routing table) that corresponds to the dedicated PE-router in traditional peer-to-peer model. Routing across the provider backbone is performed by another routing process that uses global IP routing table, corresponding to the intra-pop P-router in traditional peer-to-peer model. Note IOS implements isolation between customers via virtual routing and forwarding tables (VRFs). The whole PE-router is still configured and managed as a single device, not as a set of virtual routers Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

67 Routing Information Propagation Across P-Network IGP for Customer A IGP for Customer A Customer A IGP for Customer B IGP for Customer B Customer B IGP for Customer C IGP for Customer C Customer B PE-Router-X P-Router PE-Router-Y Customer C Customer C P-Network Customer A Q: How will PE routers exchange customer routing information? A1: Run a dedicated IGP for each customer across P-network. Wrong answer: The solution does not scale. P-routers carry all customer routers. 2000, Cisco Systems, Inc. Page51 While the virtual routing tables provide the 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. We therefore need a routing protocol that will transport all customer routes across the Provider network while maintaining the independency of individual customer address spaces. An obvious solution, implemented by various VPN vendors, is to run a separate routing protocol for each customer. The PE-routers could be connected via pointto-point tunnels (and the per-customer routing protocols would run between PErouters) or the P-routers could participate in the customer routing. This solution, although very simple to implement (and even used by some customers), is not appropriate in Service Provider environments, as it simply does not scale: The PE-routers have to run a large number of routing protocols The P-routers have to carry all customer routes. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-43

68 Routing Information Propagation Across P-Network Customer A A dedicated routing protocol used to carry customer routes Customer B Customer B PE-Router-X P-Router PE-Router-Y Customer C Customer C P-Network Customer A Q: How will PE routers exchange customer routing information? A2: 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 routers. 2000, Cisco Systems, Inc. Page52 A better approach to the route propagation problem is deployment of a single routing protocol that can exchange all customer routes across the Provider network. While this approach is better than the previous one, the P-routers are still involved in customer routing, so this proposal still retains some of the scalability issues of the previous one Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

69 Routing Information Propagation Across P-Network Customer A A dedicated routing protocol used to carry customer routes between PE routers Customer B Customer B PE-Router-X P-Router PE-Router-Y Customer C Customer C P-Network Customer A Q: How will PE routers exchange customer routing information? A3: 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. 2000, Cisco Systems, Inc. Page53 The best solution to customer route propagation is hence 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: The number of routing protocols running between PE-routers does not increase with increasing number of customers The P-routers do not carry customer routes. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-45

70 Routing Information Propagation Across P-Network Customer A A dedicated routing protocol used to carry customer routes between PE routers Customer B Customer B PE-Router-X P-Router PE-Router-Y Customer C Customer C P-Network Customer A Q: Which protocol can be used to carry customer routes between PE-routers? A: The number of customer routes can be very large. BGP is the only routing protocol that can scale to a very large number of routes. Conclusion: BGP is used to exchange customer routes directly between PE routers. 2000, Cisco Systems, Inc. Page54 The next design decision to be made is the choice of the routing protocol running between PE-routers. As 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). Conclusion: BGP is used in MPLS VPN architecture to transport customer routes directly between PE-routers 2-46 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

71 Routing Information Propagation Across P-Network Customer A A dedicated routing protocol used to carry customer routes between PE routers Customer B Customer B PE-Router-X P-Router PE-Router-Y Customer C Customer C P-Network Customer A Q: Customers can have overlapping address space. How will you propagate information about the same subnet of two customers via a single routing protocol? A: Customer addresses are extended with 64-bit prefix (Route Distinguisher RD) to make them unique. Unique 96-bit addresses are exchanged between PE-routers. 2000, Cisco Systems, Inc. Page55 MPLS VPN architecture provides an important differentiator against traditional peer-to-peer VPN solutions the support of 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 will make them unique even if they were previously overlapping. A 64-bit prefix, called route distinguisher, is used in MPLS VPN to convert non-unique 32-bit customer addresses into 96-bit unique addresses that can be transported between PE-routers. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-47

72 Route Distinguisher Route Distinguisher (RD) is a 64-bit quantity prepended to an IPv4 address to make it globally unique The resulting 96-bit address is called VPNv4 address VPNv4 addresses are only exchanged via BGP between PE routers BGP supporting other address families than IPv4 addresses is called multi-protocol BGP 2000, Cisco Systems, Inc. Page56 Route Distinguisher (RD) is a 64-bit prefix that is only used to transform nonunique 32-bit customer IPv4 addresses into unique 96-bit VPNv4 addresses (also called VPN_IPv4 addresses). The VPNv4 addresses are only exchanged between PE-routers; they are never used between CE-routers and CE-routers. BGP between PE-routers must therefore support exchange of traditional IPv4 prefixes as well as exchange of VPNv4 prefixes. The BGP session between PE-routers is consequently called multiprotocol BGP session. Note Initial MPLS VPN implementation in Cisco IOS only supports MPLS VPN services within a single autonomous system. In such a scenario, the BGP session between PE-routers is always an internal BGP (IBGP) session Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

73 Route Distinguisher Usage in MPLS VPN 64-bit Route Distinguisher is prepended to the customer IPv4 prefix to make it globally unique, resulting in 96-bit VPNv4 prefix P-network 96-bit VPNv4 prefix is propagated via BGP to the other PE router Customer-A Customer-A Customer-B PE-1 PE-2 CE-router sends an IPv4 routing update to the PE-router Customer-B 2000, Cisco Systems, Inc. Page57 Step 1 Step 2 Step 3 The customer route propagation across MPLS VPN network is performed in the following steps: CE-router sends an IPv4 routing update to the PE-router PE-router prepends 64-bit route distinguisher to the IPv4 routing update, resulting in globally unique 96-bin VPNv4 prefix The VPNv4 prefix is propagated via Multi-Protocol Internal BGP (MP-IBGP) session to other PE-routers Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-49

74 Route Distinguisher Usage in MPLS VPN Route Distinguisher is removed from the VPNv4 prefix, resulting in 32-bit IPv4 prefix P-network Customer-A Customer-A Customer-B PE-1 PE router sends the resulting IPv4 prefix to the CE router PE-2 Customer-B 2000, Cisco Systems, Inc. Page58 Step 4 Step 5 The receiving PE-routers strip the route distinguisher from the VPNv4 prefix, resulting in IPv4 prefix The IPv4 prefix is forwarded to other CE-routers within an IPv4 routing update Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

75 Route Distinguisher Usage in MPLS VPN RD has no special meaning it is only used to make potentially overlapping IPv4 addresses globally unique Simple VPN topologies require one RD per customer RD could serve as VPN identifier for simple VPN topologies, but this design could not support all topologies required by the customers 2000, Cisco Systems, Inc. Page59 The route distinguisher has no special meaning or role in MPLS VPN architecture its only function is to make overlapping IPv4 addresses globally unique. Note As there has to be a unique one-to-one mapping between the route distinguishers and virtual routing and forwarding tables, the route distinguisher could be viewed as the VRF identifier in Cisco s implementation of MPLS VPN. The route distinguisher is configured at the PE router as part of the setup of a VPN site. It is not configured on the customer equipment, and is not visible to the customer. Simple VPN topologies only require one route distinguisher per customer, raising the possibility that RD could serve as VPN identifier. This design, however, would not allow implementation of more complex VPN topologies, like when a customer site belongs to multiple VPNs. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-51

76 Complex VPN Sample VoIP Service Customer A Central Site PE-Router-X P-Router PE-Router-Y Customer A Site 2 Customer B Site 2 Customer B Central Site Customer A Site 1 VoIP gateway P-Network VoIP gateway Customer B Site 1 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 2000, Cisco Systems, Inc. Page60 To illustrate the need for more versatile VPN indicator than the route distinguisher, consider the Voice-over-IP service illustrated in the figure above. The connectivity requirements of this service are as follows: All sites of a single customer need to communicate Central sites of different customers subscribed to VoIP service need to communicate with the VoIP gateways (to originate and receive calls toward public voice network) as well as with other central sites to exchange intercompany voice calls. Note Additional security measures would have to be put in place at central sites to make sure that the central sites only exchange VoIP calls with other central sites, otherwise the corporate network of a customer could be compromised by another customer using VoIP service Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

77 Sample VoIP Service Connectivity Requirements Voice-over-IP VPN Customer A Central Site A Site A-1 Site A-2 POP-X VoIP Gateway POP-Y VoIP Gateway Customer B Central Site B Site B-1 Site B , Cisco Systems, Inc. Page61 The connectivity requirements of the VoIP service are illustrated in the diagram above. There are three VPNs needed to implement the desired connectivity two customer VPNs and a shared Voice-over-IP VPN. Central customer sites participate in the customer VPN as well as in the Voice-over-IP VPN Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-53

78 Route Targets Some sites have to participate in more than one VPN route distinguisher cannot identify participation in VPN A different method is needed where a set of identifiers can be attached to a route Route Targets were introduced in the MPLS VPN architecture to support complex VPN topologies 2000, Cisco Systems, Inc. Page62 The route distinguisher (which is a single entity prepended to an IPv4 route) cannot indicate that a site participates in more than one VPN. A different method is needed where a set of VPN identifiers could be attached to a route to indicate its membership in several VPNs. The route targets were introduced in the MPLS VPN architecture to support this requirement Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

79 What are Route Targets? Route Targets 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 route targets can be attached to a single route 2000, Cisco Systems, Inc. Page63 Route targets are extended BGP communities that are attached to a VPNv4 BGP route to indicate its VPN membership. 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 is encoded in the high-order 16 bits of the value, making them useful for a number of different applications. For example, the value of high-order 16 bits of extended BGP community is two (2) for MPLS VPN Route Targets. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-55

80 How do Route Targets Work? Export route targets identifying VPN membership are appended to customer route when it is converted into VPNv4 route Each virtual routing table has a set of associated import route targets that select routes to be inserted into the virtual routing table Route targets usually identify VPN membership, but can also be used in more complex scenarios 2000, Cisco Systems, Inc. Page64 MPLS VPN route targets are attached to a customer route at the moment when it s converted from IPv4 route to a VPNv4 route by the PE-router. The route targets attached to the route are called export route target and are configured separately for each virtual routing table in a PE-router. The export route targets 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 done based on import route targets. Each virtual routing table in a PE-router can have a number of import route targets configured, identifying the set of VPNs from which this virtual routing table is accepting routes. Note Please refer to MPLS VPN Implementation on Cisco IOS chapter for more details on import and export route targets. In overlapping VPN topologies, the route targets are used to identify VPN membership. Advanced VPN topologies (for example, central services VPN) use route targets in more complex scenarios please refer to MPLS VPN Topologies chapter of MPLS VPN Solutions lesson for more details Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

81 Virtual Private Networks Redefined With the support of complex VPN topologies, the VPNs have 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 CUG) Complex VPN topologies are supported by multiple virtual routing tables on the PE routers 2000, Cisco Systems, Inc. Page65 With the introduction of complex VPN topologies, the definition of a Virtual Private Network needs 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 closed user group (CUG). A site can be part of different VPNs, resulting in differing routing requirements for sites that belong to different sets of VPNs. These routing requirements have to be supported with multiple virtual routing tables on the PE-routers. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-57

82 Impact of Complex VPN Topologies on Virtual Routing Tables A virtual routing table in a PE router can only be used 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 2000, Cisco Systems, Inc. Page66 A single virtual routing table can only be used for sites with identical connectivity requirements. Complex VPN topologies therefore require more than one virtual routing table per VPN. Note If you would associate sites with different requirements with the same virtual routing table, some of them might be able to access destinations that should not be accessible to them otherwise. As each virtual routing table requires a distinctive route distinguisher value, the number of route distinguisher in MPLS VPN network increases with the introduction of overlapping VPNs. Moreover, the simple association between route distinguisher and VPN that was true for simple VPNs is also gone Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

83 Sample VoIP Service Virtual Routing Tables Voice-over-IP VPN Site A1 and A2 can share the same routing table Customer A Central Site A Site A-1 Site A-2 POP-X VoIP Gateway POP-Y VoIP Gateway Central Site A needs its own routing table Voice gateways can share routing tables Central Site B needs its own routing table Central Site B Site B-1 Site B-2 Site B1 and B2 can share Customer B the same routing table 2000, Cisco Systems, Inc. Page67 To illustrate the requirements for multiple virtual routing tables, consider the sample VoIP service with 3 VPNs (Customer A VPN, Customer B VPN, and the Voice-over-IP VPN). The following five virtual routing tables are needed to implement this service: All sites of customer A (apart from the central site) can share the same virtual routing table, as they only belong in a single VPN The same is true for all sites of Customer B (apart from the central site) The VoIP gateways are only participating in VoIP VPN and can belong to a single virtual routing table 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 Likewise, Central Site B requires a dedicated virtual routing table. So 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. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-59

84 Summary Benefits of MPLS VPN MPLS VPN technology has all the benefits of peer-to-peer VPN Easy provisioning Optimal routing It also bypasses most drawbacks of traditional peer-to-peer VPNs Route Distinguishers enable overlapping customer address spaces Route targets enable topologies that were hard to implement with other VPN technologies 2000, Cisco Systems, Inc. Page68 MPLS VPN architecture combines the benefits of peer-to-peer VPN paradigm with the benefits of the overlay VPN paradigm while avoiding most of the drawbacks of both of them: Like all peer-to-peer VPNs, MPLS VPN is easier to provision and provides automatic optimum routing between customer sites Like the overlay VPNs, MPLS VPN allow overlapping customer address space through the use of route distinguishers, 64-bit quantities that make overlapping customer addresses globally unique when prepended to them. Another building block of MPLS VPN architecture, route targets, allow you to build complex VPN topologies that far surpass anything that can be built with peer-to-peer VPNs Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

85 Review Questions Answer the following questions: How does MPLS VPN support overlapping customer address spaces? How are customer routes exchanged across the P-network? What is a route distinguisher? Why is the RD not usable as VPN identifier? Why were the route targets introduced in MPLS VPN architecture What is a route target? How are route targets used to build virtual routing tables in the PE routers? What is the impact of complex VPN topologies on virtual routing tables in the PE routers? Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-61

86 MPLS VPN Routing Model Objectives Upon completion of this section, you will be able to perform the following tasks: Understand the routing model of MPLS VPN Describe the MPLS VPN routing model from customer and provider perspective Identify the routing requirements of CE-routers, PE-routers and P-routers 2-62 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

87 MPLS VPN Routing Requirements Customer routers (CE-routers) have to run standard IP routing software Provider core routers (P-routers) have no VPN routes Provider edge routers (PE-routers) have to support MPLS VPN and Internet routing 2000, Cisco Systems, Inc. Page73 The designers of MPLS VPN technology were faced with the following routing requirements: The customer routers should not be MPLS VPN-aware. They should run standard IP routing software The provider core routers (P-routers) must not carry VPN routes to make the MPLS VPN solution scalable The provider edge routers (PE-routers) must support MPLS VPN services and traditional Internet services. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-63

88 MPLS VPN Routing CE-Router Perspective CE-router CE-router MPLS VPN Backbone PE-router Customer routers run standard IP routing software and exchange routing updates with the PE-router EBGP, OSPF, RIPv2 or static routes are supported PE-router appears as another router in the customer s network 2000, Cisco Systems, Inc. Page74 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 that appear as to them as normal routers in customer s network. Note In Cisco IOS 12.1, the choice of routing protocols that can be run between CErouter and PE-router is limited to static routes, RIP version 2, OSPF and external BGP Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

89 MPLS VPN Routing Overall Customer Perspective BGP backbone PE-router PE-router CE-router Site IGP Site IGP Site IGP PE-routers appear as core routers connected via a BGP backbone to the customer Usual BGP/IGP design rules apply P-routers are hidden from the customer 2000, Cisco Systems, Inc. Page75 From the customer s network designer, the MPLS VPN backbone looks like intracompany BGP backbone with PE-routers performing the route redistribution between individual sites and the core backbone. The standard design rules that are used for enterprise BGP backbones can be applied to the design of the customer s network. The P-routers are hidden from the customer s view; the internal topology of the BGP backbone is therefore totally transparent to the customer. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-65

90 MPLS VPN Routing P-Router Perspective MPLS VPN Backbone PE-router P-router PE-router 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 subnets (core links and loopbacks) 2000, Cisco Systems, Inc. Page76 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. They only run backbone IGP with other P-routers and with PE-routers and exchange information about core subnets. BGP deployment on P-routers is not needed for proper MPLS VPN operation; it might be needed, however, to support traditional Internet connectivity that was not yet migrated to MPLS Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

91 MPLS VPN Routing PE-Router Perspective CE-router MPLS VPN Backbone MP-BGP CE-router VPN routing VPN routing PE-router P-router PE-router Core IGP Core IGP CE-router CE-router 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 multiprotocol IBGP sessions 2000, Cisco Systems, Inc. Page77 The PE-routers are the only routers in the MPLS VPN architecture that see all routing aspects of the MPLS VPN: They exchange IPv4 VPN routes with CE-routers via various routing protocols running in the virtual routing tables. They exchange VPNv4 routes via multi-protocol internal BGP sessions with other PE-routers They exchange core routes with P-routers and other PE-routers via core IGP. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-67

92 MPLS VPN Support for Internet Routing CE-router MPLS VPN Backbone IPv4 BGP for Internet CE-router CE-router PE-router P-router PE-router Core IGP Core IGP CE-router PE-routers can run standard IPv4 BGP in the global routing table 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 2000, Cisco Systems, Inc. Page78 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, you should disable Internet routing on the P-routers to make your network core more stable (please see the design guidelines in Core MPLS Technology module for more details) Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

93 Routing tables on PE-Routers MPLS VPN Backbone CE-routerVPN routing MP-BGP VPN routing CE-router CE-router PE-router P-router PE-router Core IGP Core IGP IPv4 BGP for Internet CE-router PE-routers contain a number of routing tables: Global routing table that contains core routes (filled with core IGP) and Internet routes (filled with IPv4 BGP) Virtual Routing and Forwarding (VRF) tables for sets of sites with identical routing requirements VRFs are filled with information from CE-routers and MP-BGP information from other PE-routers 2000, Cisco Systems, Inc. Page79 The PE-routers support various routing requirements imposed on them by using a number of IP routing tables: The global IP routing table (the IP routing table that is always present in an IOS-based router even if it s not running MPLS VPN) contains all core routes (inserted by core IGP) and the Internet routes (inserted from 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 Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-69

94 The following slides give you an overview of end-to-end routing information flow in an MPLS VPN network. MPLS VPN End-to-End Routing Information Flow (1/3) MPLS VPN Backbone CE-router CE-router IPv4 update PE-router P-router PE-router CE-router CE-router PE-routers receive IPv4 routing updates from CE-routers and install them in the appropriate Virtual Routing and Forwarding (VRF) table 2000, Cisco Systems, Inc. Page80 The PE-routers receive IPv4 routing updates from the CE-routers and install them in appropriate Virtual Routing and Forwarding table Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

95 MPLS VPN End-to-End Routing Information Flow (2/3) MPLS VPN Backbone CE-router IPv4 update MP-BGP update PE-router P-router PE-router CE-router CE-router CE-router PE-routers export VPN routes from VRF into MP-IBGP and propagate them as VPNv4 routes to other PE-routers IBGP full mesh is needed between PE-routers 2000, Cisco Systems, Inc. Page81 The customer routes from VRFs tables are exported as VPNv4 routes into MP- BGP and propagated to other PE-routers. Initial MPLS VPN implementation in Cisco IOS (IOS releases 12.0T and 12.1) supports MPLS VPN services only within the scope of a single autonomous system. The MP-BGP sessions between the PE-routers are therefore IBGP sessions and are subject to the IBGP split horizon rules. Full mesh of MP-IBGP sessions is thus required between PE-routers or you could use route reflectors to reduce the full mesh IBGP requirement. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-71

96 MP-BGP Update MP-BGP update contains: VPNv4 address Extended communities (route targets, optionally site-of-origin) Label used for VPN packet forwarding Any other BGP attribute (AS-Path, Local Preference, MED, standard community ) 2000, Cisco Systems, Inc. Page82 Multi-protocol BGP update exchange between PE-routers contains: VPNv4 address Extended BGP communities (route targets are required, site of origin is optional) Label used for VPN packet forwarding (the MPLS VPN Packet Forwarding section later in this lesson explains how the label is used) Mandatory BGP attributes (for example, AS-path) Optionally, the MP-BGP update can contain any other BGP attribute, for example, local preference, MED or standard BGP community Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

97 MP-BGP Update VPNv4 address VPN-IPV4 address contains: Route Distinguisher 64 bits Makes the IPv4 route globally unique RD is configured in the PE for each VRF RD may or may not be related to a site or a VPN IPv4 address (32bits) 2000, Cisco Systems, Inc. Page83 The VPNv4 address propagated in the MP-BGP update is composed of a 64-bit route distinguisher and the 32-bit customer IPv4 address. The route distinguisher is configured in the virtual routing and forwarding table on the PE-router. In simple VPN topologies, where all sites in a VPN have identical routing requirements, the route distinguisher may be related to a VPN. In other complex VPN topologies, every site may require a dedicated VRF based on the connectivity requirements. In this case, the RD may be related to a particular site rather than to a particular VPN. In general, however, there is no clear correspondence between route distinguisher and either customer VPN or customer site. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-73

98 MP-BGP Update Extended Communities 64-bit long attribute attached to a route A set of communities can be attached to a single route High-order 16 bits identify extended community type Route-target (RT): identifies the set of sites the route has to be advertised to Site of Origin (SOO): identifies the originating site OSPF Route Type: identifies the LSA type of OSPF route redistributed into MP-BGP 2000, Cisco Systems, Inc. Page84 Extended BGP communities (at least route targets) are always attached to the VPNv4 routes in MP-BGP updates. These communities are 64-bit long attributes, where the high-order 16 bits identify the community meaning and the network administrator defines the low-order 48 bits. So far, three extended community types have been defined: Route target, which is used to indicate VPN membership of a customer route. Route targets are used to facilitate transfer of customer routes between virtual routing and forwarding tables. Site of origin (SOO), which identifies the customer site originating the route. Site of origin is used to prevent routing loops in network designs with multihomed sites. OSPF route type, which identifies the LSA type of an OSPF route converted into MP-BGP VPNv4 route. The following values are used in the high-order 16 bits of the extended BGP community to indicate community type: Community type Route target Site of origin OSPF route type Value in high-order 16 bits 0x0002 0x0003 0x Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

99 Extended BGP Community Display Format Two display formats are supported <16bits type>:<asn>:<32 bit number> Uses registered AS number <16bits type>:<ip address>:<16 bit number> Uses registered IP address 2000, Cisco Systems, Inc. Page85 The low-order 48 bits of the extended BGP community can be displayed in two different formats: Higher-order 16 bits are the public AS number of the Service Provider defining the community, lower-order 32 bits are defined by the network administrator. This is the recommended format Higher-order 32 bits are a public IP address belonging to the Service Provider defining the community; the network administrator defines lower-order 16 bits The display format is encoded in one of the high-order 16 bits of the extended community to ensure consistent formatting across all routers participating in an MPLS VPN network. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-75

100 MPLS VPN End-to-End Routing Information Flow (3/3) MPLS VPN Backbone CE-router MP-BGP update PE-router P-router PE-router CE-router CE-router CE-router Receiving PE-router imports incoming VPNv4 routes into the appropriate VRF based on route targets attached to the routes Routes installed in VRF are propagated to CE-routers 2000, Cisco Systems, Inc. Page86 The PE-routers receiving MP-BGP updates will import the incoming VPNv4 routes into their VRFs based on route targets attached to the incoming VPNv4 routes and import route targets configured in the VRFs. The VPNv4 routes installed in VRFs are converted to IPv4 routes then propagated to the CE-routers Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

101 Route Distribution to CE-routers Route distribution to sites is driven by the Site of Origin and Route-target extended BGP communities A route is installed in the site VRF that matches the Route-target attribute A PE which connects sites belonging to multiple VPNs will install the route into the site VRF if the Route-target attribute contains one or more VPNs to which the site is associated 2000, Cisco Systems, Inc. Page87 The route targets attached to a route and the import route targets configured in the VRF drive the import of VPNv4 routes into VRFs on the receiving PE-router the incoming VPNv4 route is imported into the VRF only if at least one route target attached to the route matches at least one import route target configured in the VRF. The site-of-origin attribute attached to the VPNv4 route controls the IPv4 route propagation to the CE-routers. A route inserted into a VRF is not propagated to a CE-router if the site-of-origin attached to the route is equal to the site-of-origin attribute associated with the CE-router. The site-of-origin can thus be used to prevent routing loops in MPLS VPN networks with multihomed sites. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-77

102 Summary MPLS VPN routing model differs widely based on the perspective you take: The CE-routers do not see any difference between a private network and a network built with MPLS VPN technology The customer network designer perceives the MPLS VPN backbone as the BGP backbone of the enterprise network The P-routers do not see the customers or their VPN routing, they only propagate subnets of the MPLS backbone The PE-routers, however, run a variety of routing protocols with the VPN customers, propagate customer routes via MP-BGP updates to other PErouters and at the same time participate in core IGP and Internet routing. These differences in perspective satisfy the routing requirements of an MPLS VPN solution: The CE-routers shall run standard IP software and shall not be MPLS VPNaware The P-routers shall not be MPLS VPN-aware and shall not carry customer routes The PE-routers shall support core IGP and Internet routing together with the MPLS VPN service. Review Questions Answer the following questions: What is the impact of MPLS VPN on CE-routers What is the customer s perception of end-to-end MPLS VPN routing? What is the P-router perception of end-to-end MPLS VPN routing? How many routing tables does a PE-router have? How many routing tables reside on a P-router? Which routing protocols fill the global routing table of a PE-router? Which routing protocols fill the Virtual Routing table (VRF) of a PE-router How is the Internet routing supported by MPLS VPN architecture? How is the VPN routing information exchanged between the PE-routers? Which attributes are always present in a MP-BGP update? Which attributes can be optionally present in a MP-BGP update? Which BGP attributes drive the import of VPNv4 route into a VRF? Which BGP attributes control the VPN route distribution toward CE-routers? 2-78 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

103 MPLS VPN Packet Forwarding Objectives Upon completion of this section, you will be able to perform the following tasks: Understand the MPLS VPN forwarding mechanisms Describe the VPN and backbone label propagation Explain the need for end-to-end LSP between PE routers Explain the implications of BGP next-hop on MPLS VPN forwarding Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-79

104 VPN Packet Forwarding Across MPLS VPN Backbone MPLS VPN Backbone CE-router IP CE-router IP Ingress-PE P-router P-router Egress-PE CE-router CE-router Q: How will PE routers forward VPN packets across MPLS VPN backbone? A1: Just forward pure IP packets. Wrong answer: P-routers do not have VPN routes, packet is dropped on IP lookup. How about using MPLS for packet propagation across backbone? 2000, Cisco Systems, Inc. Page93 With the customer routes being propagated across MPLS VPN backbone, all the routers are ready to start forwarding customer data. The customer traffic between CE-routers and PE-routers is always sent as pure IP packets, satisfying the requirement that the CE-routers run standard IP software and are not MPLS VPNaware. In a very simplistic approach to packet forwarding across MPLS VPN backbone, the PE-routers might just forward IP packets received from the customer routers toward other PE-routers. This approach would clearly fail, as the P-routers have no knowledge of the customer routes and therefore cannot forward customer IPpackets. A better approach would be to use MPLS Label Switched Path (LSP) between PE-routers and a label to determine the proper LSP to use Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

105 VPN Packet Forwarding Across MPLS VPN Backbone MPLS VPN Backbone CE-router IP L1 IP L2 IP L3 CE-router IP Ingress-PE P-router P-router Egress-PE CE-router CE-router Q: How will PE routers forward VPN packets across MPLS VPN backbone? A2: Label VPN packets with LDP label for egress PE-router, forward labeled packets across MPLS backbone. Better answer: P-routers perform label switching, packet reaches egress PE-router. However, egress PE-router does not know which VRF to use for packet lookup packet is dropped. How about using a label stack? 2000, Cisco Systems, Inc. Page94 An MPLS-oriented approach to MPLS VPN packet forwarding across the MPLS VPN backbone would be to label the customer packet with the LDP-assigned label for egress PE-router. The core routers would consequently never see the customer IP packet, just a labeled packet targeted toward egress PE-router. They would perform simple label switching operations, finally delivering the customer packet to the egress PE-router. Unfortunately, the customer IP packet contains no VPN or VRF information that could be used to perform VRF lookup on the egress PErouter. The egress PE-router would not know which VRF to use for packet lookup and would therefore have to drop the -packet. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-81

106 VPN Packet Forwarding Across MPLS VPN Backbone CE-router MPLS VPN Backbone IP V L1 IP V L2 IP V L3 CE-router IP Ingress-PE P-router P-router Egress-PE IP CE-router CE-router Q: How will PE routers forward VPN packets across MPLS VPN backbone? A3: Label VPN packets with a label stack. Use LDP label for egress PE-router as the top label, VPN label assigned by egress PE-router as the second label in the stack. Correct answer: P-routers perform label switching, packet reaches egress PE-router. Egress PE-router performs lookup on the VPN label and forwards the packet toward the CE-router. 2000, Cisco Systems, Inc. Page95 MPLS label stack can be used to indicate to the egress PE-router what to do with the VPN packet. When using the label stack, the ingress PE-router labels incoming IP packet with two labels. The top label in the stack is the LDP label for the egress PE-router that will guarantee 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 the router how to forward the incoming VPN packet. The second label in the stack could point directly toward an outgoing interface, in which case the egress PE-router only performs label lookup on the VPN packet. The second label could also point to a VRF, in which case the egress PE-router performs a label lookup first to find the target VRF and then performs an IP lookup within the VRF. Both methods are used in Cisco IOS. The second label in the stack points toward an outgoing interface whenever the 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 null interface and routes for directly connected VPN interfaces. Two-level MPLS label stack satisfies all MPLS VPN forwarding requirements: P-routers perform label switching on the LDP-assigned label toward the egress PE-router Egress PE-router performs label switching on the second label (that 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 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

107 VPN Packet Forwarding Penultimate Hop Popping CE-router MPLS VPN Backbone IP V L1 IP V L2 IP V CE-router IP Ingress-PE P-router P-router Egress-PE IP CE-router CE-router Penultimate hop popping on the LDP label can be performed on the last P-router Egress PE-router performs only label lookup on VPN label, resulting in faster and simpler label lookup IP lookup is performed only once in ingress PE router 2000, Cisco Systems, Inc. Page96 Penultimate hop popping (removal of top label in the stack on hop prior to the egress router) can be performed in frame-based MPLS networks. In these networks, the last P-router in the label switched path 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 Forwarding Information Base (FIB) is therefore performed only once in the ingress PErouter; even without the penultimate hop popping. Note Please refer to MPLS Technology chapter for more information on penultimate hop popping. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-83

108 VPN Label Propagation MPLS VPN Backbone CE-router CE-router Ingress-PE P-router P-router Egress-PE CE-router CE-router Q: How will the ingress PE-router get the second label in the label stack from the egress PE-router? A: Labels are propagated in MP-BGP VPNv4 routing updates. 2000, Cisco Systems, Inc. Page97 In the previous slides, you ve seen that MPLS label stack, with the second label being assigned by the egress PE-router, is mandatory for proper MPLS VPN operation. These labels have to be propagated between PE-routers to enable proper packet forwarding and 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 VPNv4 prefix Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

109 The following slides illustrate the VPN label propagation between PE-routers. VPN Label Propagation MPLS VPN Backbone CE-router CE-router Ingress-PE P-router P-router Egress-PE CE-router CE-router Step #1: VPN label is assigned to every VPN route by the egress PE router Egress-PE#show tag-switching forwarding vrf SiteA2 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 26 Aggregate /30[V] 0 37 Untagged /32[V] 0 Se1/0.20 point2point 38 Untagged /24[V] 0 Se1/0.20 point2point 2000, Cisco Systems, Inc. Page98 Step 1 Egress PE-routers assign a label to every VPN route received from attached CErouters 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. The VPN labels assigned locally by the PE-router can be inspected with the show tag-switching forwarding vrf command. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-85

110 VPN Label Propagation MPLS VPN Backbone CE-router CE-router Ingress-PE P-router P-router Egress-PE CE-router CE-router Step #2: VPN label is advertised to all other PE-routers in MP-BGP update Ingress-PE#show ip bgp vpnv4 all tags Network Next Hop In tag/out tag Route Distinguisher: 100:1 (vrf1) /notag /notag notag/ , Cisco Systems, Inc. Page99 Step 2 VPN labels assigned by the egress PE-routers are advertised to all other PErouters together with VPNv4 prefix in MP-BGP updates. These labels can be inspected with the show ip bgp vpnv4 all tags command on the ingress PE-router. The routes that have an input label but no output label are the routes received from 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 PErouters (and the output label was assigned by the remote PE-router). For example, the VPN label for destination is 38 and was assigned by another PE-router (Egress-PE in the previous slide). Note Like many other IOS show commands, the show ip bgp vpnv4 tags command uses the old terminology labels are still called tags Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

111 VPN Label Propagation MPLS VPN Backbone CE-router CE-router Ingress-PE P-router P-router Egress-PE CE-router CE-router Step #3: Label stack is built in Virtual Forwarding table Ingress-PE#show ip cef vrf Vrf detail /24, version 57, cached adjacency to Serial1/0.2 0 packets, 0 bytes tag information set local tag: VPN-route-head fast tag rewrite with Se1/0.2, point2point, tags imposed: {26 38} via , 0 dependencies, recursive next hop , Serial1/0.2 via /32 valid cached adjacency tag rewrite with Se1/0.2, point2point, tags imposed: {26 38} 2000, Cisco Systems, Inc. Page100 Step 3 The ingress PE-router has two labels associated with a remote VPN route a label for BGP next-hop assigned by the next-hop P-router via LDP (and taken from local Label Information Base LIB) as well as the label assigned by remote PErouter and propagated via MP-BGP update. Both labels are combined in a label stack and installed in the virtual forwarding (VRF) table. The label stack in the virtual forwarding table can be inspected with the show ip cef vrf detail command. The tags imposed part of the printout displays the MPLS label stack. The first label in the MPLS label stack is the TDP/LDP label toward the egress PE-router and the second label is the VPN label advertised by the egress PE-router. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-87

112 Impacts of MPLS VPN Label Propagation The VPN label has to be assigned by the BGP next-hop BGP next-hop should not be changed in MP-IBGP update propagation Do not use next-hop-self on confederation boundaries PE-router has to be BGP next-hop Use next-hop-self on the PE-router Label has to be re-originated if the next-hop is changed A new label is assigned every time the MP-BGP update crosses AS-boundary where the next-hop is changed Supported from IOS 12.1(4)T 2000, Cisco Systems, Inc. Page101 MPLS VPN packet forwarding works correctly if and only if the router specified as the BGP next-hop in incoming BGP update is the same router as the one that has assigned the second label in the label stack. There 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 external BGP session, the next-hop of the VPNv4 route is still the IP address of the CE-router (BGP next hop of an outgoing IBGP update is always identical to the BGP next hop of the incoming EBGP update). You have to configure next-hop-self 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. It can change, however, if you use next-hop-self on inter-as boundary inside a BGP confederation or if you use inbound route-map on a PE-route to change nexthop (a strongly discouraged practice). To prevent this, make sure that you never change BGP next-hop with a route-map or next-hop-self inside an autonomous system. The BGP next hop is always changed on an external BGP 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 re-originate the VPN label at the same time as the BGP next hop is changed. This functionality is supported from IOS releases 12.1(4)T and Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

113 Impacts of MPLS VPN Packet Forwarding VPN label is only understood by egress PE-router End-to-end Label Switched Path is required between ingress and egress PE-router BGP next-hops shall not be announced as BGP routes LDP labels are not assigned to BGP routes BGP next-hops announced in IGP shall not be summarized in the core network Summarization breaks LSP 2000, Cisco Systems, Inc. Page102 The second requirement for successful propagation of MPLS VPN packets across an MPLS backbone is an unbroken label switched path (LSP) between PE-routers. The second label in the stack is recognized only by the egress PE-router that has originated it and would not be understood by any other router, should it ever become exposed. There are two scenarios that could cause the LSP between PE-routers to break: If the IP address of the PE-router is announced as a BGP route, it has no corresponding LDP label and the label stack could 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 will be disrupted at the summarization point, as illustrated on the next slide. Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-89

114 VPN Packet Forwarding With Summarization in Core P-router performs penultimate hop popping P-router is faced with a VPN label it does not understand MPLS VPN Backbone CE-router IP V L1 IP V CE-router CE-router IP Ingress-PE P-router P-router Egress-PE P-router summarizes PE loopback CE-router Penultimate hop popping is requested through LDP PE-router builds a label stack and forwards labeled packet toward egress PE-router 2000, Cisco Systems, Inc. Page103 In the example above, the P-router summarizes the loopback address of the egress PE-router. LSP is broken at a summarization point, as the summarizing router needs to perform full IP lookup. In a frame-based MPLS network, the P-router would request penultimate hop popping 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. As the VPN label was not assigned 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 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

115 Summary Customer VPN packets are forwarded across MPLS VPN backbone encapsulated in an MPLS label stack composed of two labels: The top label in the stack is the LDP-assigned label toward the egress PErouter The second label in the stack is the VPN label assigned by the egress PErouter and propagated to other PE-routers in the MP-BGP update together with the VPNv4 route Successful forwarding of customer data packets across MPLS VPN backbone can only happen if the label switched path between ingress and egress PE-router is unbroken and if the router that is specified as the BGP next hop assigns the VPN label. There are a number of scenarios that can cause MPLS VPN connectivity to break: BGP next hop is the IP address of the CE-router fix by specifying next-hopself on the PE-router BGP next hop is changed inside the autonomous system fix by removing next-hop-self on BGP confederation boundary or by removing set next-hop from inbound route-maps BGP next hop is changed when the MP-BGP update crosses autonomous system boundary this is the default BGP behavior that cannot be changed, use IOS release that supports inter-as MPLS VPN (starting with IOS 12.1(4)T) Label switched path is broken between the PE-routers, for example due to route summarization in the MPLS core. Review Questions Answer the following questions: How are VPN packets propagated across MPLS VPN backbone? How can P-routers forward VPN packets if they don t have VPN routes? How is the VPN label propagated between PE-routers? Which router assigns the VPN label? How is the VPN label used on other PE-routers? What is the impact of changing BGP next-hop on MP-BGP update? How are MP-BGP updates propagated across AS boundary? What is the impact of BGP next-hop summarization in the network core? Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-91

116 Lesson Summary After completing this lesson, you should be able to perform the following tasks: Identify major Virtual Private network topologies, their characteristics and usage scenarios Describe the differences between overlay VPN and peer-to-peer VPN List major technologies supporting overlay VPNs and peer-to-peer VPNs Position MPLS VPN in comparison with other peer-to-peer VPN implementations Describe major architectural blocks of MPLS VPN Describe MPLS VPN routing model and packet forwarding 2-92 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

117 Answers to Review Questions Introduction to Virtual Private Networks Why are customers interested in Virtual Private Networks? Customers use VPNs to reduce their connectivity costs. What is the main role of a VPN? Virtual Private Networks replace private point-to-point links with connectivity over statistically shared infrastructure. What is a C-network? The C-network is the part of the network under customer control. What is a customer site? Customer site is a contiguous part of the C-network What is a CE-router? The CE-router is a router in the C-network with a link to the Service Provider network What is a P-network? Overlay and Peer-to-Peer VPN The P-network is part of the network under Service Provider control What is the difference between a PE-device and a P-device? Customers are attached only to PE-devices, not to P-devices. What is an overlay VPN? An overlay VPN is a VPN providing emulated point-to-point links to the customers. Which routing protocol runs between the customer and the service provider in an overlay VPN? There customer routing protocol in not extended to the Service Provider. The only routing protocol running between the customer and the service provider is the routing protocol needed to implement underlying Service Provider connectivity. Which routers are routing protocol neighbors of a CE-router in overlay VPN? In overlay VPN implementations, the CE-routers peer directly. List three IP-based overlay VPN technologies. Generic Route Encapsulation (GRE), IP Security (IPSec) and PPP forwarding. PPP forwarding can be implemented with Layer-2 Forwarding (L2F), Layer-2 Transport Protocol (L2TP) or Point-to-Point Transport Protocol (PPTP). Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-93

118 What is the major benefit of peer-to-peer VPN as compared to overlay VPN? Peer-to-peer VPN guarantee optimum routing between customer sites without the need for full-mesh of virtual circuits. List two traditional peer-to-peer VPN implementations? Peer-to-peer VPN can be implemented with IP packet filters on shared PE-routers or split routing with dedicated per-customer PE-routers. What is the drawback of all traditional peer-to-peer VPN implementations? The customers cannot use private IP addresses in traditional peer-to-peer VPN implementations. Major VPN Topologies MPLS VPN Architecture What are the major Overlay VPN topologies The major overlay VPN topologies are hub-and-spoke, partial mesh and full mesh. Why would the customers prefer partial mesh over full mesh topology? Connectivity costs usually dictate use of partial mesh. What is the difference between an Intranet and an Extranet? Intranet links sites within an organization, extranet links sites from different organizations. Security is usually not an issue inside an Intranet, but becomes major concern in an Extranet. What is the difference between a simple VPN and a Central Services VPN? Every customer site can exchange traffic with every other customer site in simple VPN. In central services VPN, the client sites can only exchange traffic with server sites. What are the connectivity requirements of a Central Services VPN? Client sites can only talk to the server sites. Server sites have unlimited connectivity. How does MPLS VPN support overlapping customer address spaces? MPLS VPN supports overlapping customer address spaces by using independent per-vpn routing tables. How are customer routes exchanged across the P-network? Multi-protocol BGP (MP-BGP) is used to exchange customer routes across the P-network. What is a route distinguisher? The route-distinguisher as a 64-bit prefix prepended to customer IPv4 address to make it globally unique Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

119 Why is the RD not usable as VPN identifier? The RD cannot be used as VPN identifier since it cannot support complex VPN topologies where a single site belongs to multiple VPNs. Why were the route targets introduced in MPLS VPN architecture? Route targets were introduced to support complex VPN topologies. What is a route target? Route target is a 64-bit value attached to a BGP route as extended BGP community. How are route targets used to build virtual routing tables in the PE routers? Every customer route exported from a VRF is tagged with appropriate export route targets. VPN Routes received by a PE-router are matched against import route targets configured in a VRF. What is the impact of complex VPN topologies on virtual routing tables in the PE routers? Complex VPN topologies might require more than one VRF per VPN. MPLS VPN Routing Model What is the impact of MPLS VPN on CE-routers The CE-routers are not MPLS VPN-aware. What is the customer s perception of end-to-end MPLS VPN routing? The customer perceives the MPLS VPN backbone as BGP backbone in its own network. What is the P-router perception of end-to-end MPLS VPN routing? P-router is not MPLS VPN aware. It only sees global subnets in the MPLS VPN backbone, not the customer routes. How many routing tables does a PE-router have? A PE-router has a global routing table and several virtual routing tables. How many routing tables reside on a P-router? The P-router only has the global routing table. Which routing protocols fill the global routing table of a PE-router? The global routing table in the PE-router is filled with information from the backbone IGP and the global BGP process. Which routing protocols fill the Virtual Routing table (VRF) of a PE-router The VRF table is filled with information from the VRF routing protocols running between the PE-routers and the CE-routers and with the information received by the PE-routers through MP-BGP. How is the Internet routing supported by MPLS VPN architecture? Internet routing is still supported in the global IP routing table. How is the VPN routing information exchanged between the PE-routers? Copyright 2000, Cisco Systems, Inc. MPLS VPN Technology 2-95

120 PE-routers exchange VPN routing information with MP-BGP. Which attributes are always present in a MP-BGP update? Every MP-BGP update carries VPNv4 prefix, route-targets, MPLS VPN label and all mandatory BGP attributes (AS-path, origin, BGP next-hop). Which attributes can be optionally present in a MP-BGP update? Any other discretionary or optional BGP attribute can be present in MP- BGP update. Which BGP attributes drive the import of VPNv4 route into a VRF? Route targets control the import of VPNv4 routes into VRFs. Which BGP attributes control the VPN route distribution toward CE-routers? Site-of-origin controls the distribution of VPN routes toward CE-routers. MPLS VPN Packet Forwarding How are VPN packets propagated across MPLS VPN backbone? The VPN packets are propagated across MPLS VPN backbone as labeled packets with two labels in the MPLS label stack. How can P-routers forward VPN packets if they don t have VPN routes? The P-routers only perform label lookup and thus never see the VPN packets. How is the VPN label propagated between PE-routers? VPN labels are attached to the VPNv4 routes in MP-BGP updates. Which router assigns the VPN label? The egress PE-router assigns the VPN label. How is the VPN label used on other PE-routers? All other PE-routers use the VPN label assigned by the PE-router as the second label in the MPLS label stack. What is the impact of changing BGP next-hop on MP-BGP update? MPLS VPN connectivity is broken unless the MPLS VPN label is reoriginated. How are MP-BGP updates propagated across AS boundary? Routers propagating MP-BGP updates across AS-boundary have to reoriginate the MPLS VPN labels. What is the impact of BGP next-hop summarization in the network core? MPLS VPN connectivity is broken if the BGP next-hops are summarized in the network core Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

121 3 MPLS/VPN Configuration on IOS Platforms Overview This lesson covers MPLS/VPN configuration on Cisco IOS platforms. It includes the following topics: MPLS/VPN Mechanisms in Cisco IOS Configuring Virtual Routing and Forwarding Tables Configuring a Multi-Protocol BGP session between the PE routers Configuring Routing Protocols between PE and CE routers Monitoring an MPLS/VPN Operation Troubleshooting MPLS/VPN Advanced VRF Import/Export Features Advanced PE-CE BGP Configuration Objectives Upon completion of this lesson, you will be able to perform the following tasks: Configure Virtual Routing and Forwarding tables Configure Multi-protocol BGP in a MPLS/VPN backbone Configure PE-CE routing protocols Configure advanced MPLS/VPN features Monitor MPLS/VPN operations Troubleshoot MPLS/VPN implementation

122 MPLS/VPN Mechanisms in Cisco IOS Objectives Upon completion of this section, you will be able to perform the following tasks: Describe the concept of Virtual Routing and Forwarding table Describe the concept of routing protocol contexts Describe the interaction between PE-CE routing protocols, backbone MP- BGP and virtual routing and forwarding tables 3-2 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

123 VRF: Virtual Routing and Forwarding Table VRF is the routing and forwarding instance for a set of sites with identical connectivity requirements Data structures associated with a VRF IP routing table CEF forwarding table Set of rules and routing protocol parameters (routing protocol contexts) List of interfaces that use the VRF Other information associated with a VRF Route distinguisher A set of import and export route targets 2000, Cisco Systems, Inc. 5 The major data structure associated with MPLS/VPN implementation in Cisco IOS is the Virtual Routing and Forwarding table (VRF). This data structure encompasses an IP routing table, identical in its function to the global IP routing table in IOS, a Cisco Express Forwarding (CEF) forwarding table, identical in its function to the global CEF forwarding table (Forwarding Information Base or FIB) and specifications for routing protocols running inside the VRF. A VRF is thus a routing and forwarding instance that can be used for a single VPN site or for many sites connected to the same PE router as long as these sites share exactly the same connectivity requirements. Other MPLS/VPN attributes associated with a VRF are: The route distinguisher which is prepended to all routes exported from the VRF into the global VPNv4 BGP table A set of export route targets which are attached to any route exported from the VRF A set of import route targets, which are used to select VPNv4 routes that are to be imported into the VRF Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-3

124 Need for routing protocol contexts VPN A /24 CE-VPN-A RIP Two VPNs with overlapping addresses MPLS/VPN backbone VPN B RIP PE router CE-VPN-B /24 RIP is running in both VPNs RIP in VPN-A has to be different from RIP in VPN-B, but IOS only supports one RIP process per router 2000, Cisco Systems, Inc. 6 Traditional Cisco IOS can support a number of different routing protocols; in some cases even several completely isolated copies of the same routing protocol (for example, several OSPF or EIGRP processes). For several important routing protocols (for example, RIP or BGP), IOS supports only a single copy of the protocol running in the router. These protocols cannot be used directly between PE and CE routers in VPN environments, as 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 space (for example, each VPN could use subnets of network ), which would also lead to routing confusions if all VPNs share the same copy of the routing protocol. 3-4 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

125 VPN-Aware Routing Protocols Routing context = routing protocol run in one VRF Supported by VPN aware Routing Protocols: ebgp, OSPF, RIPv2, Static routes Implemented as several instances of a single routing process (ebgp, RIPv2) or as several routing processes (OSPF) Each instance has independent per-instance router variables 2000, Cisco Systems, Inc. 7 Routing Contexts were introduced in Cisco IOS to support the need for separate isolated copies of VPN routing protocols. The routing contexts can be implemented as separate routing processes (OSPF), similar to traditional IOS 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 (for example, networks over which the routing protocol is run, timers, authentication parameters, passive interfaces, neighbors etc.), giving the network designer maximum flexibility in implementing routing protocols between PE and CE routers. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-5

126 VRF Routing Table VRF Routing table contains routes which should be available to a particular set of sites Analogous to standard IOS routing table, supports the same set of mechanisms VPN interfaces (physical interface, subinterfaces, logical interfaces) are assigned to VRFs Many interfaces per VRF Each interface can only be assigned to one VRF 2000, Cisco Systems, Inc. 8 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 IOS routing table, including filtering mechanisms (distribute lists or prefix lists) and inter-protocol route selection mechanisms (administrative distances). The 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. Any interface can be associated with a VRF, be it 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 12.1 include dialer interfaces, ISDN interfaces, and Switched Multimegabit Data Service (SMDS) interfaces. Some restrictions are already lifted in IOS 12.1T releases, please refer to the release notes of the IOS release you re using for the details of interfaces and media types supporting CEF switching. There is no limit to the number of interfaces associated with one VRF (the only limit is the number of interfaces supported by the router), however, each interface can be associated only with one VRF, because the router needs to uniquely identify the forwarding table to be used for packets received over an interface. 3-6 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

127 Routing Contexts, VRF and MP-BGP Interaction: 1/9 CE-RIP-A CE-RIP-B RIP routing process Instance for VRF-A Instance for VRF-B VRF-A routing table VRF-B routing table BGP routing process Backbone Multi-protocol BGP Instance for VRF-A CE-BGP-A CE-BGP-B Instance for VRF-B Two VPNs attached to the same PE router Each VPN is represented by a VRF RIP and BGP running between PE and CE routers 2000, Cisco Systems, Inc. 9 This and the following slides will illustrate the interactions between VRF instances of routing processes, VRF routing tables, and the global VPNv4 BGP routing process. A simple MPLS/VPN network will be used throughout the example. The network contains two VPN customers (called VPN-A and VPN-B). The customer sites are connected to a number of Provider Edge (PE) routers, but in the example we ll focus only on a single PE router, which contains two VRFs one for each customer. Two sites of each customer are connected to the PE router, one site running BGP, the other site running RIP as the PE-CE routing protocol. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-7

128 Routing Contexts, VRF and MP-BGP Interaction: 2/9 CE-RIP-A CE-RIP-B RIP routing process Instance for VRF-A Instance for VRF-B VRF-A routing table VRF-B routing table BGP routing process Backbone Multi-protocol BGP Instance for VRF-A CE-BGP-A CE-BGP-B Instance for VRF-B RIP-speaking CE routers announce their prefixes to the PE router via RIP Instance of RIP process associated with the VRF into which the PE-CE interface belongs collects the routes and inserts them into VRF routing table 2000, Cisco Systems, Inc RIP-speaking CE routers announce their networks to the PE router. These updates are received by appropriate instances of RIP routing process (the correct instance is identified through the association of inbound PE interface to a VRF) and inserted into the per-vrf IP routing tables. 3-8 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

129 Routing Contexts, VRF and MP-BGP Interaction: 3/9 CE-RIP-A CE-RIP-B RIP routing process Instance for VRF-A Instance for VRF-B VRF-A routing table VRF-B routing table BGP routing process Backbone Multi-protocol BGP Instance for VRF-A CE-BGP-A CE-BGP-B Instance for VRF-B BGP-speaking CE routers announce their prefixes to the PE router via BGP Instance of BGP process associated with the VRF into which the PE-CE interface belongs collects the routes and inserts them into VRF routing table 2000, Cisco Systems, Inc Similar to RIP-speaking routers, the BGP-speaking CE routers announce their networks via EBGP sessions to the PE router. The Customer Edge BGP neighbors of the PE router are associated with individual VRFs, which enables the various instances of the BGP routing process to put the received routing updates into the proper per-vrf routing table. 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, as the administrative distance of EBGP routes (20) is better than the administrative distance of RIP routes (120). Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-9

130 Routing Contexts, VRF and MP-BGP Interaction: 4/9 CE-RIP-A CE-RIP-B RIP routing process Instance for VRF-A Instance for VRF-B VRF-A routing table VRF-B routing table BGP routing process Backbone Multi-protocol BGP Instance for VRF-A CE-BGP-A CE-BGP-B Instance for VRF-B 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 proper MPLS/VPN operation 2000, Cisco Systems, Inc Multi-protocol BGP is used in the MPLS/VPN backbone to carry VPN routes (prefixed with route distinguisher) as 96-bit VPNv4 routes between the PE routers. The backbone BGP process looks exactly like a standard IBGP setup from the VRF s perspective. The per-vrf RIP routes therefore have to 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. Failure to redistribute non-bgp routes into per-vrf instance of BGP is one of the most common MPLS/VPN configuration failures Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

131 Routing Contexts, VRF and MP-BGP Interaction: 5/9 CE-RIP-A CE-RIP-B RIP routing process Instance for VRF-A Instance for VRF-B VRF-A routing table VRF-B routing table BGP routing process Backbone Multi-protocol BGP Instance for VRF-A CE-BGP-A Route distinguisher Instance for VRF-B is prepended during route export to the BGP routes from VRF instance of BGP process to convert them into VPNv4 prefixes. Route targets are attached to these prefixes CE-BGP-B VPNv4 prefixes are propagated to other PE routers 2000, Cisco Systems, Inc The RIP routes redistributed into the per-vrf instance of the BGP process as well as the BGP routes received from BGP-speaking CE routers are copied into the multi-protocol BGP table for further propagation to other PE routers. The IP prefixes are prepended with the Route Distinguisher (RD) and the set of route targets (extended BGP communities) configured as export route targets for the VRF is attached to the resulting VPNv4 route. Note The difference between per-vrf BGP table and global MP-BGP table holding VPNv4 routes is displayed only to illustrate the steps in the route propagation process. In reality, there is no separate per-vrf BGP table in the Cisco IOS. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-11

132 Routing Contexts, VRF and MP-BGP Interaction: 6/9 CE-RIP-A CE-RIP-B RIP routing process Instance for VRF-A Instance for VRF-B VRF-A routing table VRF-B routing table BGP routing process Backbone Multi-protocol BGP Instance for VRF-A CE-BGP-A CE-BGP-B Instance for VRF-B 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 Route distinguisher is removed during this process 2000, Cisco Systems, Inc As the other PE routers start originating VPNv4 routes, the MP-BGP process in our PE router will receive these routes. The routes are filtered based on route target attributes attached to them and inserted into the proper per-vrf IP routing tables based on the import route targets configured for individual VRF. The route distinguisher that was prepended by the originating PE router is removed before the route is inserted into IPv4 the per-vrf IP routing table Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

133 Routing Contexts, VRF and MP-BGP Interaction: 7/9 CE-RIP-A CE-RIP-B RIP routing process Instance for VRF-A Instance for VRF-B VRF-A routing table VRF-B routing table BGP routing process Backbone Multi-protocol BGP Instance for VRF-A CE-BGP-A CE-BGP-B Instance for VRF-B Routes received from backbone Multi-protocol BGP and imported into a VRF are forwarded as IPv4 routes to EBGP CE neighbors attached to that VRF 2000, Cisco Systems, Inc The MP-IBGP VPNv4 routes received from other PE routers and selected by the import route targets of a VRF are automatically propagated as 32-bit IPv4 routes to all BGP-speaking CE neighbors of the PE router. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-13

134 Routing Contexts, VRF and MP-BGP Interaction: 8/9 CE-RIP-A CE-RIP-B RIP routing process Instance for VRF-A Instance for VRF-B VRF-A routing table VRF-B routing table BGP routing process Backbone Multi-protocol BGP Instance for VRF-A CE-BGP-A CE-BGP-B Instance for VRF-B MP-IBGP routes imported into a VRF are redistributed into the instance of RIP configured for that VRF Redistribution between BGP and RIP has to be configured for endto-end RIP routing between CE routers 2000, Cisco Systems, Inc The same routes, although they are inserted in the per-vrf IP routing table, are not propagated to RIP-speaking CE routers automatically. To propagate these routes (which appear as standard BGP routes in the per-vrf IP routing table) to the RIP-speaking CE routers, redistribution between per-vrf instance of BGP and per-vrf instance of RIP needs to be manually configured Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

135 Routing Contexts, VRF and MP-BGP Interaction: 9/9 CE-RIP-A CE-RIP-B RIP routing process Instance for VRF-A Instance for VRF-B VRF-A routing table VRF-B routing table BGP routing process Backbone Multi-protocol BGP Instance for VRF-A CE-BGP-A CE-BGP-B Instance for VRF-B Routes redistributed from BGP into a VRF instance of RIP are sent to RIP-speaking CE routers 2000, Cisco Systems, Inc When the IBGP routes from the per-vrf IP routing table are successfully redistributed into the per-vrf instance of RIP process, the RIP process announces these routes to RIP-speaking CE routers, thus achieving transparent end-to-end connectivity between the CE routers. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-15

136 Summary MPLS/VPN enabled network separates the layer 3 routing task by splitting a single physical router into a number of virtual routers. Router s basic function is switching packets between interfaces. Virtual routing and forwarding or VRF is used to create a virtual router that contains its own routing table, CEF cache and interfaces. To optimize performance a single BGP process or RIP process is used for all VRFs. A Route Distinguisher is used to distinguish between IP version 4 networks belonging to different VPNs. We need, however, a separate OSPF process for every VRF configured. To send information from one CE router to another CE router an update is sent using one of the supported routing protocols. The update is received by the PE router that has to redistribute the information into BGP. The information is translated into MP-BGP format where, upon export, a Route Target is added. This information is then sent to other PE routers where it is imported into VRFs that are using the same Route Target. The other PE routers redistribute this information into the IGP used between the PE and the CE routers and send it to the CE routers. Review Questions Which data structures are associated with a VRF? How many interfaces can be associated with a VRF? How many VRFs can be associated with an interface? What is a routing protocol context? How are routing protocol contexts implemented in RIP? How are routing protocol contexts implemented in OSPF? How is a RIP route propagated into MP-BGP? When is a MP-BGP route inserted into a VRF? 3-16 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

137 Configuring Virtual Routing and Forwarding Table Objectives Upon completion of this section, you will be able to perform the following tasks: Create a Virtual Routing and Forwarding Table Specify Routing Distinguisher and Route Targets for the created VRF Associate interfaces with the VRF Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-17

138 Configuring VRF VRF Configuration tasks: Create VRF Assign Route Distinguisher to the VRF Specify export and import route targets Assign interfaces to VRFs 2000, Cisco Systems, Inc Configuring VRF and starting deployment of an MPLS/VPN service for a customer consists of four mandatory steps: Creating a new VRF Assigning a unique route distinguisher to the VRF Note A unique route distinguisher needs to be assigned to every VRF created in a PE router. The same route distinguisher might be used in multiple PE routers, based on customer connectivity requirements. The same route distinguisher should be used on all PE routers for simple VPN service. Please refer to Chapter #1 of the SS_MPLS_VPN lesson for more details on route distinguisher assignment for different VPN topologies. Specifying import and export route targets for a VRF Note Import and export route target should be equal to route distinguisher for simple VPN service. For other options, please refer to Chapter #1 of the SS_MPLS_VPN lesson. Assign the PE-CE interfaces to the new VRF Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

139 Creating VRF and Assigning Route Distinguisher router(config)# ip vrf name 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 router(config-vrf)# rd route-distinguisher Assigns a route distinguisher to a VRF You can use ASN:xx or A.B.C.D:xx format for RD Each VRF in a PE router has to have a unique RD 2000, Cisco Systems, Inc 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 Syntax Description vrf-name 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. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-19

140 rd To create routing and forwarding tables for a VRF, use the rd command in VRF submode. Syntax Description rd route-distinguisher route-distinguisher Adds an 8-byte value to an IPv4 prefix to create a VPN IPv4 prefix. The route distinguisher can be specified in one of two formats: 16-bit AS-number followed by a 32-bit decimal number (AS: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 to be functional Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

141 Specify Export and Import Route Targets router(config-vrf)# route-target export RT Specifies a route target that will be attached to every route exported from this VRF to MP-BGP You can specify many export RTs all of them will be attached to every exported route router(config-vrf)# route-target import RT Specifies a route target that is used as import filter only routes matching the route target are imported into the VRF You can specify many import RTs any route where at least one RT attached to the route matches any import RT is imported into the VRF Due to implementation issues, at least one export route target must also be an import route target of the same VRF in IOS releases 12.0T 2000, Cisco Systems, Inc route-target To create a route-target extended community for a VRF, use the route-target command in VRF submode. To disable the configuration of a route-target 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 Syntax Description Defaults import Imports routing information from the target VPN extended community. export Exports routing information to the target VPN extended community. both Imports both import and export routing information to the target VPN extended community. route-target-ext-community Adds the route-target extended community attributes to the VRF's list of import, export, or both (import and export) route-target extended communities. Similar to route distinguisher, the route targets can be specified in one of two formats: 16-bit AS-number followed by a 32-bit decimal number (AS:nn) 32-bit IP address followed by a 16-bit decimal number (A.B.C.D:nn) There are no defaults. A VRF has no route-target extended community attributes associated with it until specified by the route-target command. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-21

142 Specify Export and Import Route Targets router(config-vrf)# route-target both RT In cases where the export RT matches the import RT, use this form of route-target command Sample router configuration for simple customer VPN: ip vrf Customer_ABC rd 12703:15 route-target export 12703:15 route-target import 12703: , Cisco Systems, Inc Whenever a route target is both an import and an export route target for a VRF; you can use the route-target both command to simplify the configuration. For example, the two route-target configuration lines in the sample router configuration above could be reduced into a single command route-target both 12703: Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

143 Assigning an Interface to VRF router(config-if)# ip vrf forwarding vrf-name Associates an interface with the specified VRF Existing IP address is removed from the interface when you put the interface into VRF you have to reconfigure the IP address CEF switching must be enabled on the interface Sample router configuration: ip cef! interface serial 0/0 ip vrf forwarding Customer_ABC ip address , Cisco Systems, Inc 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 Syntax Description Defaults vrf-name Name assigned to a VRF. The default for an interface is the global routing table. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-23

144 Sample VPN Network CE-RIP-A1 MPLS/VPN backbone CE-RIP-A2 CE-BGP-A1 PE-Site-X PE-Site-Y CE-BGP-A2 CE-RIP-B1 CE-RIP-B2 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 , Cisco Systems, Inc To illustrate the use of MPLS/VPN configuration commands, we ll configure the PE router in a sample network with two VPN customers. Customer A with four sites is using BGP and RIP as the PE-CE routing protocol and customer B (with two sites) is only using RIP. Both customers use private IP address space (subnets of network ) 3-24 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

145 Sample VPN Network VRF Configuration CE-RIP-A1 CE-BGP-A1 CE-RIP-B1 MPLS/VPN backbone PE-Site-X ip vrf Customer_A rd 115:43 CE-RIP-A2 route-target both 115:43! ip vrf Customer_B rd 115:47 CE-BGP-A2 route-target PE-Site-Y both 115:47! interface serial 1/0/1 CE-RIP-B2 ip forwarding vrf Customer_A ip address ! interface serial 1/0/2 ip vrf forwarding Customer_A ip address ! interface serial 1/1/3 ip vrf forwarding Customer_B ip address , Cisco Systems, Inc The configuration steps we can perform on the PE router so far include: Configuring VRF for Customer A and Customer B Assigning route distinguishers and route targets to the VRFs. As these customers only require simple VPN connectivity, one route distinguisher per customer is used on all PE routers in the MPLS/VPN backbone. To simplify the configuration and troubleshooting process, the route targets are made equal to route distinguishers. Assigning PE-CE interfaces to individual VRFs Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-25

146 Summary To create a virtual router or a VRF use the ip vrf global command where the VRF is identified by a case-sensitive name. Within the VRF configuration mode use the rd command to set the Route Distinguisher. If sites belonging to the same VPN are connected to different PE routers you have to specify at least one Route Target extended community for import and export. Use the route-target import, route-target export or route-target both commands to set Route Target extended communities for import and export. The last step in the configuration is specifying the interfaces that belong to the virtual router. Use the ip forwarding vrf interface command to assign an interface to a VRF. Review Questions Which commands do you use to create a VRF? Which VRF parameters must be specified for a VRF to become operational? How do you associate an interface with a VRF? What happens to existing interface configuration when you associate the interface with a VRF? How many formats can you use to specify RD and RT? What are these formats? How many route targets can you configure on a VRF? How many import route targets have to match a route for the route to be imported into the VRF? 3-26 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

147 Configuring a Multi-Protocol BGP Session Between the PE Routers Objectives Upon completion of this section, you will be able to perform the following tasks: Configure BGP address families Configure MP-BGP neighbors Configure inter-as MP-BGP neighbors Configure additional mandatory parameters on MP-BGP neighbors Configure propagation of standard and extended BGP communities Selectively enable IPv4 and MP-BGP sections between BGP neighbors Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-27

148 BGP Address Families 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 EBGP sessions Address families (routing contexts) are used to configure these three tasks in the same BGP process 2000, Cisco Systems, Inc The MPLS/VPN architecture uses BGP routing protocol in two different ways: VPNv4 routes are propagated across a MPLS/VPN backbone using multiprotocol BGP between the PE routers BGP can be used as the PE-CE routing protocol to exchange VPN routes between the provider edge routers and the customer edge routers Independently from MPLS/VPN, the PE router can also use BGP to receive and propagate Internet routes in scenarios where the PE routers are also used to provide Internet connectivity to the customers. All three route exchange mechanisms take place in one BGP process (as you can only configure one BGP process per router) and the routing contexts (called address families from router configuration perspective) are used to configure all three independent route exchange mechanisms Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

149 Selecting BGP Address Family router(config)# router bgp as-number Selects global BGP routing process router(config-router)# address-family vpnv4 Selects configuration of VPNv4 prefix exchanges under MP-BGP sessions router(config-router)# address-family ipv4 vrf vrf-name Selects configuration of per-vrf PE-CE EBGP parameters 2000, Cisco Systems, Inc The address-family router configuration command is used to select the routing context that you d like to configure: Internet routing (global IP routing table) is the default address family that you configure when you start configuring the BGP routing process; To configure multi-protocol BGP sessions between the PE routers, use the vpnv4 address family To configure BGP between the PE routers and the CE routes within individual VRF, use the ipv4 vrf name address family router bgp To configure the Border Gateway Protocol (BGP) routing process, use the router bgp global configuration command. To remove a routing process, use the no form of this command. router bgp autonomous-system no router bgp autonomous-system Syntax Description autonomous-system Number of an autonomous system that identifies the router to other BGP routers and tags the routing information passed along. Default No BGP routing process is enabled by default. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-29

150 address-family To enter the address family submode for configuring routing protocols, such as BGP, RIP and static routing, use the address-family command in address family configuration submode. To disable the address family submode for configuring routing protocols, use the no form of this command. VPN-IPv4 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 Syntax Description ipv4 vpnv4 unicast vrf vrf-name Configures sessions that carry standard IPv4 address prefixes. Configures sessions that carry customer VPN-IPv4 prefixes, each of which has been made globally unique by adding an 8-byte route distinguisher. (Optional) Specifies unicast prefixes. Specifies the name of a VPN routing/forwarding instance (VRF) to associate with submode commands Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

151 BGP Neighbors Multi-protocol BGP neighbors are configured under BGP routing process These neighbors need to be activated for each global address family they support Per-address-family parameters can be configured for these neighbors VRF-specific EBGP neighbors are configured under corresponding address families 2000, Cisco Systems, Inc MPLS/VPN architecture defines 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 ipv4 vrf name address family Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-31

152 Configuring MP-BGP MPLS/VPN Multiprotocol 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 etc.) 2000, Cisco Systems, Inc BGP connectivity between two PE routers is configured in four steps: The remote PE router is configured as global BGP neighbor under BGP router configuration mode Parameters that affect all BGP route exchange (for example, source address for the TCP session) are defined on the global BGP neighbor VPNv4 address family is selected and the BGP neighbor is activated for VPNv4 route exchange Additional VPNv4-specific BGP parameters (filters, next-hop processing, route-maps) are configured 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 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

153 router(config)# Configuring MP-IBGP router bgp AS-number neighbor IP-address remote-as AS-number neighbor IP-address update-source loopback-interface All MP-BGP neighbors have to be configured under global BGP routing configuration MP-IBGP sessions have to run between loopback interfaces router(config-router)# address-family vpnv4 Starts configuration of MP-BGP routing for VPNV4 route exchange Parameters that apply only to MP-BGP exchange of VPNV4 routes between already-configured IBGP neighbors are configured under this address family 2000, Cisco Systems, Inc The initial commands that are needed to configure MP-IBGP session between PE routers are: neighbor address remote-as as-number command configures the neighboring PE-router neighbor address update-source interface command configures the source address used for TCP session carrying BGP updates as well as the IP address used as the BGP next-hop for VPNv4 routes address-family vpnv4 enters the VPNv4 configuration mode where the additional VPNv4-specific parameters have to be configured on the BGP neighbor. neighbor remote-as To add an entry to the 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. neighbor {ip-address peer-group-name} remote-as number no neighbor {ip-address peer-group-name} remote-as number Syntax Description ip-address peer-group-name number Neighbor's IP address. Name of a BGP peer group. Autonomous system to which the neighbor belongs. Default There are no BGP neighbor peers. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-33

154 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 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 neighbor {ip-address peer-group-name} update-source interface no neighbor {ip-address peer-group-name} update-source interface Syntax Description Default ip-address peer-group-name interface Best local address IP address of the BGP-speaking neighbor. Name of a BGP peer group. Loopback interface Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

155 router(config-router-af)# Configuring MP-IBGP neighbor IP-address activate BGP neighbor defined under BGP router configuration has to be activated for VPNV4 route exchange router(config-router-af)# neighbor IP-address next-hop-self Next-hop-self has to be configured on MP-IBGP session for proper MPLS/VPN configuration if you re running EBGP with a CE neighbor 2000, Cisco Systems, Inc After the remote PE router has been defined as a global BGP neighbor, it has to be activated for VPNv4 route exchange. The default IBGP next-hop processing needs to be disabled for VPNv4 route exchange with next-hop-self command. Note If you don t disable default next-hop processing, the VPN IP address of a BGPspeaking CE router might become VPNv4 BGP next hop and the connectivity across the MPLS/VPN backbone is broken. neighbor activate To enable the exchange of information with a BGP neighboring router, use the neighbor activate router configuration command. 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 Syntax Description ip-address peer-group-name 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 using the appropriate address family submode. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-35

156 neighbor next-hop-self Syntax Description To disable next-hop processing of BGP updates on the router, use the neighbor next-hop-self router configuration command. 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 ip-address peer-group-name IP address of the BGP-speaking neighbor. Name of a BGP peer group. Default Disabled 3-36 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

157 Configuring MP-EBGP router(config)# router bgp AS-number neighbor IP-address remote-as another-as-number 12.1(4)T Configure MP-EBGP under global BGP routing configuration EBGP sessions should be run over directly-connected interfaces MP-EBGP is supported from 12.1(3)T onwards router(config-router)# address-family vpnv4 neighbor IP-address activate Activates MP-EBGP neighbor for VPNv4 route exchange 2000, Cisco Systems, Inc Multi-protocol EBGP session is configured in exactly the same way as the multiprotocol IBGP session, the only difference being that the AS-number of the neighboring PE-router differs from the local AS-number. Note The support for VPNv4 information exchange over an EBGP session has been added in IOS release 12.1(4)T. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-37

158 Configuring EBGP Propagation of all VPNv4 Routes router(config-router)# no bgp default route-target filter 12.1(4)T By default, PE routers ignore VPNv4 routes that do not match any configured import route target (this rule does not apply to route-reflectors) This command disables route-target based filter and enables propagation of all VPNv4 routes between autonomous systems 2000, Cisco Systems, Inc By default, the PE routers discard VPNv4 updates not related to the VRFs configured on the PE routers, the only exceptions being BGP route reflectors. A PE router exchanging VPNv4 routes over an EBGP session would deploy the same filter (and drop some VPNv4 routes) unless it would be configured as a route reflector. The no bgp default route-target-filter command was introduced to disable the default VPNv4 filter and allow the PE router to propagate all VPNv4 routes between autonomous systems. bgp default route-target filter Use this BGP router configuration command to enable filtering of Multiprotocol BGP updates that are not imported into any VRF. Use the no form to disable this feature. bgp defult route-target filter no bgp defult route-target filter Default This feature is enabled by default Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

159 Configuring MP-BGP BGP Community Propagation router(config-router-af)# neighbor IP-address send-community [extended both] This command configures propagation of standard and extended BGP communities attached to VPNv4 prefixes Default value: only extended communities are sent 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 both option 2000, Cisco Systems, Inc neighbor send-community MPLS/VPN architecture has introduced the extended community BGP attribute. BGP still supports the standard community attribute, which has not been superseded with 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. You should use this command to configure propagation of standard and extended communities if your BGP design relies on usage of standard communities (for example, to propagate Quality of Service information across the network). To specify that a COMMUNITIES attribute should be sent to a BGP neighbor, use the neighbor send-community router configuration command. To remove the entry, use the no form of this command. Syntax Description Default neighbor {ip-address peer-group-name} send-community [ extended both ] no neighbor {ip-address peer-group-name} send-community ip-address peer-group-name Neighbor's IP address. Name of a BGP peer group. No COMMUNITIES attribute is sent to any neighbor. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-39

160 CE-RIP-A1 Sample VPN Network MP-IBGP Configuration MPLS/VPN backbone CE-RIP-A2 CE-BGP-A1 CE-RIP-B1 CE-BGP-A2 PE-Site-X PE-Site-Y interface loopback 0 ip address ! router bgp 115 neighbor remote-as 115 neighbor update-source loopback 0! address-family vpnv4 neighbor activate neighbor next-hop-self neighbor send-community both CE-RIP-B2 2000, Cisco Systems, Inc Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 The configuration example from page 25 continues with the configuration of multi-protocol IBGP sessions on the PE router. The following steps need to be performed: A loopback interface is defined that will serve as the BGP next-hop for VPNv4 routes and as the source address for IBGP session The remote PE router is configured as global BGP neighbor The source address for the TCP session is specified VPNv4 address family is selected The remote PE router is activated for VPNv4 route exchange Next-hop processing is disabled for VPNv4 route exchange in order to guarantee that the loopback 0 interface will always be the BGP next-hop for VPNv4 routes propagated by this router to its MP-IBGP neighbors Propagation of standard and extended communities is configured 3-40 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

161 Configuring MP-BGP Disabling IPv4 Route Exchange router(config-router)# no bgp default ipv4 unicast Exchange of IPv4 routes between BGP neighbors is enabled by default every configured neighbor will also receive IPv4 routes This command disables 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 don t want to propagate Internet routes to some PE neighbors 2000, Cisco Systems, Inc 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 don t need Internet routing and the IPv4 route exchange needs to be disabled. There are two ways of disabling IPv4 route exchange: If you only want to disable IPv4 route exchange for a few neighbors, the best option is to disable the IPv4 route exchange on a neighbor-by-neighbor basis by using no neighbor activate command If you want to disable IPv4 route exchange for most (or all) of the neighbors, you can use no bgp default ipv4 unicast command. After you enter this command, IPv4 route exchange has to be manually activated for each configured global BGP neighbor. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-41

162 Sample Router Configuration Neighbor shall receive only Internet routes Neighbor shall receive only VPNv4 routes Neighbor shall receive Internet and VPNv4 routes router bgp no bgp default ipv4 unicast neighbor remote-as neighbor remote-as neighbor remote-as 12703! Activate IPv4 route exchange neighbor activate neighbor activate! Step#2 VPNv4 route exchange address-family vpnv4 neighbor activate neighbor activate 2000, Cisco Systems, Inc In this example, only a subset of BGP neighbors needs to receive IPv4 routes. The default propagation of IPv4 routes is thus disabled and IPv4 route exchange as well as VPNv4 route exchange is manually activated on a neighbor-by-neighbor basis Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

163 Summary MP-BGP is used to propagate VPN specific information between PE routers. Standard BGP version 4 can also be used with the CE routers. Address families are used to tell the BGP process which routing table to use to find neighbor and where to put the received updates. There is a separate address family for each VRF and one address family for VPN-IPv4 updates. Other PE routers are configured as standard BGP neighbors in the global part of the BGP configuration and have to be activated in the vpn_ipv4 address family. Extended communities are propagated while standard communities are not. Use the neighbor neighbor send-community command to change the default. You should use the neighbor neighbor next-hop-self command to make sure the PE loopbacks are used as the next hop address. Review Questions What is a BGP address family? How many BGP address families do you have to configure on a PE router? In which address family is the MP-IBGP neighbor configured? Which are the mandatory parameters that you have to configure on MP-BGP neighbor? Which additional parameters have to be configured to support MP-EBGP neighbors? How do you enable community propagation for VPNv4 MP-BGP sessions? Why would you want to disable propagation of IPv4 routing updates between MP-BGP neighbors? How is the propagation of IPv4 routing updates between MP-BGP neighbors disabled? Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-43

164 Configuring Routing Protocols Between PE and CE Routers Objectives Upon completion of this section, you will be able to perform the following tasks: Configure VRF address families in routing protocols Configure per-vrf BGP parameters Configure static routes within a VRF Configure per-vrf OSPF process Propagate RIP, OSPF, and static routes across a MP-BGP backbone 3-44 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

165 Configuring PE-CE Routing Protocols PE-CE routing protocols are configured for individual VRFs Per-VRF routing protocols can be configured in two ways: There is only one BGP or RIP process per router, 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 Overall number of routing processes per router is limited to , Cisco Systems, Inc After configuring VRFs and establishing 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 PE-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 two ways: As individual address families belonging to the same routing process (similar to what you ve already seen for BGP) or As separate routing processes. This option is used for more complex routing protocols that need to maintain separate topology database for each VRF, for example, OSPF Note Current IOS 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 is therefore limited to 28. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-45

166 router(config)# Selecting VRF Routing Context for BGP and RIP router bgp AS-number address-family ipv4 vrf vrf-name... Per-VRF BGP definitions... Per-VRF BGP context is selected with the address-family command CE EBGP neighbors are configured in VRF context, not in the global BGP configuration router(config)# router rip address-family ipv4 vrf vrf-name... Per-VRF RIP definitions... Similar to BGP, select per-vrf RIP context with the address-family command Configure all per-vrf RIP parameters there starting with network numbers 2000, Cisco Systems, Inc The VRF routing context is selected with the address-family ipv4 vrf name command in the RIP and BGP routing processes. All per-vrf routing protocol parameters (network numbers, passive interfaces, neighbors, filters etc.) are configured under this address family. Note Common parameters defined in the router configuration mode are inherited by all address families defined for this routing process and can be overridden for each individual address family. router rip To configure the Routing Information Protocol (RIP) routing process, use the router rip global configuration command. To turn off the RIP routing process, use the no form of this command. router rip no router rip Syntax Description Default This command has no arguments or keywords. No RIP routing process is defined Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

167 Configuring per-vrf BGP Routing Context CE neighbors have to be specified within the per-vrf context, not in global BGP CE neighbors have to be activated with the neighbor activate command All non-bgp per-vrf routes have to be redistributed into per-vrf BGP context to be propagated by MP-BGP to other PE routers Per-VRF BGP context has auto summarization and synchronization disabled by default 2000, Cisco Systems, Inc When configuring BGP as the PE-CE routing protocol, start the per-vrf BGP configuration with the address-family ipv4 vrf name router configuration command. After entering the address family configuration mode, you define the BGP neighbors and activate them. You also have to configure redistribution from all other per-vrf routing protocols into BGP. Note You always have to configure BGP address-family for each VRF and configure route redistribution into BGP for each VRF even if you don t use BGP as the PE- CE routing protocol Several BGP options have different default values when you configure per-vrf BGP routing context: BGP synchronization is disabled (default = enabled) Auto-summarization (automatic generation of classful networks out of subnets redistributed into BGP) is disabled (default = enabled), as the MPLS/VPN backbone has to propagate customer subnets unchanged to facilitate transparent end-to-end routing between customer sites Redistribution of internal BGP routes into IGP is enabled (default = disabled) Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-47

168 CE-RIP-A1 Sample VPN Network PE-CE BGP Configuration router bgp neighbor remote-as 115 network mask CE-RIP-A2 MPLS/VPN backbone CE-BGP-A1 PE-Site-X PE-Site-Y CE-BGP-A2 CE-RIP-B1 CE-RIP-B2 router bgp 115! address-family ipv4 vrf Customer_A neighbor remote-as neighbor activate 2000, Cisco Systems, Inc Continuing the example from page 40, BGP is started on the CE router, and the PE router is defined as a BGP neighbor. Similarly, the CE router is defined as a BGP neighbor and activated under address-family ipv4 vrf Customer_A Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

169 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 RIP version 2 is supported 2000, Cisco Systems, Inc Configuring RIP as the PE-CE routing protocol is even simpler than configuring BGP. You start the configuration of individual routing context with the addressfamily ipv4 vrf name router configuration command. All standard RIP parameters can be entered 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 RIPv2 is supported as the PE-CE routing protocol. It s a good configuration practice to configure RIP version as a global RIP parameter using the version 2 router configuration command. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-49

170 router(config)# RIP Metric Propagation router rip address-family ipv4 vrf vrf-name redistribute bgp metric transparent BGP routes have to be redistributed back into RIP if you want to have end-to-end RIP routing in the customer network RIP hop count is copied into BGP MED attribute (default BGP behavior) RIP hop count has to be manually set for routes redistributed into RIP With metric transparent option, BGP MED is copied into RIP hop count, resulting in consistent end-toend RIP hop count 2000, Cisco Systems, Inc 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 only used as a route selection criterion and 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 router configuration command. The MPLS/VPN extension to the redistribute command metric transparent option allows MED to be inserted as the IGP metric of a route redistributed from BGP back into RIP. This extension gives you a transparent end-to-end (from customer s perspective) RIP routing: RIP hop count is inserted into BGP attribute MED when the RIP route is redistributed into BGP by the ingress PE router (enabled by default) The value of MED attribute (the original RIP hop count) is copied into RIP hop count, if so configured, when the BGP route is redistributed back into RIP. The whole MPLS/VPN backbone thus looks like a single hop to the CE routers. Note You should not change the MED value within BGP if you use the redistribute metric transparent option Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

171 CE-RIP-A1 Sample VPN Network RIP Configuration MPLS/VPN backbone CE-RIP-A2 CE-BGP-A1 CE-RIP-B1 PE-Site-X PE-Site-Y CE-BGP-A2 router rip CE-RIP-B2 version 2 address-family ipv4 vrf Customer_ABC network redistribute bgp metric transparent! router bgp address-family ipv4 vrf Customer_ABC redistribute rip 2000, Cisco Systems, Inc RIP configuration in our sample network is exceedingly simple: 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 be with standard RIP configuration Redistribution from BGP into RIP with metric propagation is configured BGP routing context is configured for every VRF. Redistribution of RIP routes into BGP has to be configured for every VRF for which you ve configured the RIP routing context Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-51

172 Configuring OSPF PE-CE Routing A separate OSPF routing process is configured for each VRF running OSPF OSPF route attributes are attached as extended BGP communities to OSPF routes redistributed into MP-BGP Routes redistributed from MP-BGP into OSPF get proper OSPF attributes No additional configuration is needed 2000, Cisco Systems, Inc To configure OSPF as a PE-CE routing protocol, you need to start a separate OSPF process for each VRF in which you want to run OSPF. The pre-vrf OSPF process is configured in the same way as a standard OSPF process; you can use all OSPF features available in Cisco IOS. Redistribution of OSPF routes into BGP has to be configured for RIP and the redistribution of BGP routes into OSPF can be configured if necessary. Alternatively, you can originate a default route into a per-vrf OSPF process by using the default-information originate always OSPF router configuration command. Multi-protocol BGP propagates more than just OSPF cost across the MPLS/VPN backbone please refer to the Running OSPF in a VPN lesson for more details. The propagation of additional OSPF attributes into MP-BGP is automatic and requires no extra configuration Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

173 router(config)# Configuring PE-CE OSPF Routing router ospf process-id vrf name... Standard OSPF parameters... This command configures per-vrf OSPF routing process Sample router configuration: router ospf 123 vrf Customer_ABC network area 0 redistribute bgp 12703! router bgp address-family ipv4 vrf Customer_ABC redistribute ospf , Cisco Systems, Inc OSPF is the only PE-CE routing protocol, which is not fully VPN aware. A separate OSPF process is run for every VRF. router ospf To configure an OSPF routing process within a VRF, use the router ospf global configuration command. 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 Syntax Description process-id vrf-name Internally used identification parameter for an OSPF routing process. It is locally assigned and can be any positive integer. A unique value is assigned for each OSPF routing process. The name of the VRF where the OSPF process will reside. Default No OSPF routing process is defined. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-53

174 router(config)# Configuring Per-VRF Static Routes ip route vrf name static route parameters This command configures per-vrf static routes The route is entered in the specified Virtual Routing Table You always have to specify outgoing interface, even if you specify the next-hop Sample router configuration: ip route vrf Customer_ABC serial 0/0! router bgp address-family ipv4 vrf Customer_ABC redistribute static 2000, Cisco Systems, Inc 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 [next-hop-address] [interface {interfacenumber}] [global] [distance] [permanent] [tag tag] no ip route vrf vrf-name prefix mask [next-hop-address] [interface {interfacenumber}] [global] [distance] [permanent] [tag tag] Syntax Description vrf-name prefix mask next-hop-address interface interface-number global distance permanent tag tag Name of the VPN routing/forwarding instance (VRF) for the static route. IP route prefix for the destination in dotted-decimal format. Prefix mask for the destination in dotted-decimal format. (Optional) IP address of the next hop (the forwarding router that can be used to reach that network). Type of network interface to use. Number identifying the network interface to use. (Optional) Specifies that the given next hop address is 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 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

175 Summary There is a limited range of routing protocols that can be used between PE and CE routers static routes, RIP version 2, external BGP and OSPF. RIP and BGP are fully VPN aware routing protocols where the configuration is split into address families representing VRFs. OSPF, on the other hand, is not fully VPN aware and, therefore, has to be enabled per VRF. All VRF specific routing information except BGP has to be redistributed into BGP. Review Questions How do you configure routing context in RIP? How do you configure routing context in OSPF? How many VPN OSPF processes can run simultaneously in an MPLS/VPN PE-router? Where do you configure CE EBGP neighbor? How do you propagate static VRF routes between PE routers? How do you propagate RIP metric across an MPLS/VPN backbone? Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-55

176 Monitoring MPLS/VPN Operation Objectives Upon completion of this section, you will be able to perform the following tasks: Monitor individual VRFs and routing protocols running in them Monitor MP-BGP sessions between the PE routers Monitor inter-as MP-BGP sessions between the PE routers Monitor an MP-BGP table Monitor CEF and TFIB structures associated with MPLS/VPN 3-56 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

177 router# show ip vrf Monitoring VRF Displays the list of all VRFs configured in the router router# show ip vrf detail Displays detailed VRF configuration router# show ip vrf interfaces Displays interfaces associated with VRFs 2000, Cisco Systems, Inc show ip vrf To display the set of defined VRFs (VPN routing/forwarding instances) and associated interfaces, use the show ip vrf command in EXEC mode. show ip vrf [{brief detail interfaces}] [vrf-name] [output-modifiers] Syntax Description brief detail interfaces vrf-name output-modifiers (Optional) Displays concise information on the VRF(s) and associated interfaces. (Optional) Displays detailed information on the VRF(s) and associated interfaces. (Optional) Displays detailed information about all interfaces bound to a particular VRF, or any VRF. (Optional) 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. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-57

178 show ip vrf Router#show ip vrf Name Default RD Interfaces SiteA2 103:30 Serial1/0.20 SiteB 103:11 Serial1/0.100 SiteX 103:20 Ethernet0/0 Router# 2000, Cisco Systems, Inc The show ip vrf command displays concise information on the VRF(s) and associated interfaces. The following table describes the fields displayed by this command. Table: show ip vrf field descriptions Field Name Default RD Interfaces Description Specifies the VRF name. Specifies the default route distinguisher. Specifies the network interfaces Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

179 show ip vrf detail Router#show ip vrf detail VRF SiteA2; default RD 103:30 Interfaces: Serial1/0.20 Connected addresses are not in global routing table No Export VPN route-target communities Import VPN route-target communities RT:103:10 No import route-map Export route-map: A2 VRF SiteB; default RD 103:11 Interfaces: Serial1/0.100 Connected addresses are not in global routing table Export VPN route-target communities RT:103:11 Import VPN route-target communities RT:103:11 RT:103:20 No import route-map No export route-map 2000, Cisco Systems, Inc To display detailed information on the VRFs and associated interfaces, use the show ip vrf detail command. The following table describes the additional fields shown by this command. Table: show ip vrf detail Field Descriptions Field Interfaces Export Import Description Specifies the network interfaces. Specifies VPN route-target export communities. Specifies VPN route-target import communities. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-59

180 show ip vrf interfaces Router#show ip vrf interfaces Interface IP-Address VRF Protocol Serial1/ SiteA2 up Serial1/ SiteB up Ethernet0/ SiteX up 2000, Cisco Systems, Inc 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 the following table. Table: show ip vrf interfaces Field Descriptions Field Interface IP-Address VRF Protocol Description Specifies the network interfaces for a VRF. Specifies the IP address of a VRF interface. Specifies the VRF name. Displays the state of the protocol (up/down) for each VRF interface Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

181 Monitoring VRF Routing router# show ip protocol vrf name Displays the routing protocols configured in a VRF router# show ip route vrf name Displays the VRF routing table router# show ip bgp vpnv4 vrf name Displays per-vrf BGP parameters (PE-CE neighbors ) 2000, Cisco Systems, Inc There are three commands that can be used to monitor VRF routing: show ip protocol vrf displays the summary information about routing protocols running in a VRF show ip route vrf displays the VRF routing table show ip bgp vpnv4 vrf displays the VRF BGP table show ip protocols vrf Syntax Description 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 vrf-name Name assigned to a VRF. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-61

182 show ip route vrf To display the IP routing table associated with a VRF (VPN routing/forwarding instance), use the show ip route vrf command in EXEC mode. show ip route vrf vrf-name [connected] [protocol [as-number] [tag] [outputmodifiers]] [list number [output-modifiers]] [profile] [static [output-modifiers]] [summary [output-modifiers]] [supernets-only [output-modifiers]] [trafficengineering [output-modifiers]] Syntax Description vrf-name connected protocol as-number tag output-modifiers list number profile static summary supernets-only traffic-engineering Name assigned to the VRF. (Optional) Displays all connected routes in a VRF. (Optional) To specify a routing protocol, use one of the following keywords: bgp, egp, eigrp, hello, igrp, isis, ospf, or rip. (Optional) Autonomous system number. (Optional) IOS 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. 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] [tags] Syntax Description all rd route-distinguisher vrf vrf-name ip-prefix/length longer-prefixes Displays the complete VPNv4 database. Displays NLRIs that have a matching route distinguisher. Displays NLRIs associated with the named VRF. (Optional) IP prefix address (in dotted decimal format) and length of mask (0 to 32). (Optional) Displays the entry, if any, that exactly matches the specified prefix parameter, as well as all entries that match the prefix in a "longest-match" sense. That is, prefixes for which the specified prefix is an initial substring Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

183 output-modifiers network-address mask cidr-only community community-list dampened-paths filter-list flap-statistics inconsistent-as neighbors paths line peer-group quote-regexp regexp summary tags (Optional) For a list of associated keywords and arguments, use context-sensitive help. (Optional) IP address of a network in the BGP routing table. (Optional) Mask of the network address, in dotted decimal format. (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) A regular expression to match the BGP AS paths. (Optional) Displays information about peer groups. (Optional) Displays routes matching the AS path "regular expression." (Optional) Displays routes matching the AS path regular expression. (Optional) Displays BGP neighbor status. (Optional) Displays incoming and outgoing BGP labels for each NLRI. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-63

184 show ip protocol vrf Router#show ip protocol vrf SiteX Routing Protocol is "rip" Sending updates every 30 seconds, next due in 10 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is Incoming update filter list for all interfaces is Redistributing: rip, bgp 3 Default version control: send version 2, receive version 2 Interface Send Recv Triggered RIP Key-chain Ethernet0/0 2 2 Routing for Networks: Routing Information Sources: Gateway Distance Last Update Distance: (default is 120) 2000, Cisco Systems, Inc The show ip protocol vrf command displays summary information about all routing protocol instances active in the specified VRF. The fields displayed by this command are shown in the following table. Table: show ip protocols vrf Field Descriptions Field Gateway Distance Last update Description Displays the IP address of the router identifier for all routers in the network. Displays the metric used to access the destination route. Displays the last time the routing table was updated from the source Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

185 show ip route vrf Router#show ip route vrf SiteA2 Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set O /24 [110/782] via , 02:52:13, Serial1/ /32 is subnetted, 1 subnets O [110/782] via , 02:52:13, Serial1/ /32 is subnetted, 1 subnets B [200/1] via , 01:14:32 B /24 [200/782] via , 02:05:38 B /24 [200/1] via , 02:05:38 B /24 [200/1] via , 01:14:32 rest deleted 2000, Cisco Systems, Inc The show ip route vrf command displays the contents of the VRF IP routing table in the same format as used by the show ip route command. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-65

186 show ip bgp vpnv4 vrf neighbor Router#show ip bgp vpnv4 vrf SiteB neighbor BGP neighbor is , vrf SiteB, remote AS 65032, external link BGP version 4, remote router ID BGP state = Established, up for 02:01:41 Last read 00:00:56, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received Address family IPv4 Unicast: advertised and received Received 549 messages, 0 notifications, 0 in queue Sent 646 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0 Minimum time between advertisement runs is 30 seconds For address family: VPNv4 Unicast Translates address family IPv4 Unicast for VRF SiteB BGP table version 416, neighbor version 416 Index 4, Offset 0, Mask 0x10 Community attribute sent to this neighbor 2 accepted prefixes consume 120 bytes Prefix advertised 107, suppressed 0, withdrawn 63 rest deleted 2000, Cisco Systems, Inc show ip bgp vpnv4 neighbors To display BGP neighbors configured in a VRF, use the show ip bgp vpnv4 vrf neighbors privileged EXEC command. show ip bgp vpnv4 {all vrf vrf-name} neighbors Syntax Description Defaults vpnv4 all vrf vrf-name neighbors Specifies VPN IPv4 information. Displays all VPN BGP neighbors Displays neighbors associated with the named VRF. Displays details on TCP and BGP neighbor connections. This command has no default values. Usage Guidelines Use this command to display detailed information about BGP neighbors associated with MPLS VPN Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

187 Monitoring MP-BGP Sessions router# show ip bgp neighbor Displays global BGP neighbors and the protocols negotiated with these neighbors 2000, Cisco Systems, Inc The show ip bgp neighbor command, described in details in the Basic BGP Technology and Configuration lesson is also used to monitor BGP sessions with other PE routers as well as the address families negotiated with these neighbors. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-67

188 show ip bgp neighbor Router#show ip bgp neighbor BGP neighbor is , remote AS 3, internal link BGP version 4, remote router ID BGP state = Established, up for 02:15:33 Last read 00:00:33, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received Address family IPv4 Unicast: advertised and received Address family VPNv4 Unicast: advertised and received Received 1417 messages, 0 notifications, 0 in queue Sent 1729 messages, 2 notifications, 0 in queue Route refresh request: received 9, sent 29 Minimum time between advertisement runs is 5 seconds For address family: IPv4 Unicast BGP table version 188, neighbor version 188 Index 2, Offset 0, Mask 0x4 1 accepted prefixes consume 36 bytes Prefix advertised 322, suppressed 0, withdrawn Continued 2000, Cisco Systems, Inc show ip bgp neighbors To display information about the TCP and Border Gateway Protocol (BGP) connections to neighbors, use the show ip bgp neighbors EXEC command. show ip bgp neighbors [address] [received-routes routes advertisedroutes {paths regular-expression} dampened-routes] Syntax Description address received-routes routes advertised-routes paths regular-expression dampened-routes (Optional) Address of the neighbor whose routes you have learned from. If you omit this argument, all neighbors are displayed. (Optional) Displays all received routes (both accepted and rejected) from the specified neighbor. (Optional) Displays all routes that are received and accepted. This is a subset of the output from the received-routes keyword. (Optional) Displays all the routes the router has advertised to the neighbor. (Optional) Regular expression that is used to match the paths received. (Optional) Displays the dampened routes to the neighbor at the IP address specified Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

189 Examples The following is sample output from the show ip bgp neighbors command: Router# show ip bgp neighbors BGP neighbor is , remote AS 10, external link Index 1, Offset 0, Mask 0x2 Inbound soft reconfiguration allowed BGP version 4, remote router ID BGP state = Established, table version = 27, up for 00:06:12 Last read 00:00:12, hold time is 180, keepalive interval is 60 seconds Minimum time between advertisement runs is 30 seconds Received 19 messages, 0 notifications, 0 in queue Sent 17 messages, 0 notifications, 0 in queue Inbound path policy configured Route map for incoming advertisements is testing Connections established 2; dropped 1 Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Local host: , Local port: Foreign host: , Foreign port: 179 Enqueued packets for retransmit: 0, input: 0, saved: 0 Event Timers (current time is 0x530C294): Timer Starts Wakeups Next Retrans x0 TimeWait 0 0 0x0 AckHold x0 SendWnd 0 0 0x0 KeepAlive 0 0 0x0 GiveUp 0 0 0x0 PmtuAger 0 0 0x0 iss: snduna: sndnxt: sndwnd: irs: rcvnxt: rcvwnd: delrcvwnd: 291 SRTT: 441 ms, RTTO: 2784 ms, RTV: 951 ms, KRTT: 0 ms minrtt: 0 ms, maxrtt: 300 ms, ACK hold: 300 ms Flags: higher precedence, nagle Datagrams (max data segment is 1460 bytes): Rcvd: 15 (out of order: 0), with data: 12, total data bytes: 291 Sent: 23 (retransmit: 0), with data: 11, total data bytes: 276 The following table describes the fields shown in the display. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-69

190 Field BGP neighbor BGP version BGP state table version up for Last read hold time keepalive interval Received notifications Sent notifications Connections established dropped Connection state unread input bytes Local host, Local port Foreign host, Foreign port Event Timers iss snduna sndnxt sndwnd irs rcvnxt rcvwnd delrecvwnd SRTT RTTO RTV KRTT Description IP address of the BGP neighbor and its autonomous system number. If the neighbor is in the same autonomous system as the router, then the link between them is internal; otherwise, it is considered external. BGP version being used to communicate with the remote router; the neighbor's router ID (an IP address) is also specified. Internal state of this BGP connection. Indicates that the neighbor has been updated with this version of the primary BGP routing table. Amount of time that the underlying TCP connection has been in existence. Time that BGP last read a message from this neighbor. Maximum amount of time that can elapse between messages from the peer. Time period between sending keepalive packets, which help ensure that the TCP connection is up. Number of total BGP messages received from this peer, including keepalives. Number of error messages received from the peer. Total number of BGP messages that have been sent to this peer, including keepalives. Number of error messages the router has sent to this peer. Number of times the router has established a TCP connection and the two peers have agreed speak BGP with each other. Number of times that a good connection has failed or been taken down. State of BGP peer. Number of bytes of packets still to be processed. Peering address of local router, plus port. Neighbor's peering address. Table displays the number of starts and wakeups for each timer. Initial send sequence number. Last send sequence number the local host sent but has not received an acknowledgment for. Sequence number the local host will send next. TCP window size of the remote host. Initial receive sequence number. Last receive sequence number the local host has acknowledged. Local host's TCP window size. Delayed receive window---data the local host has read from the connection, but has not yet subtracted from the receive window the host has advertised to the remote host. The value in this field gradually increases until it is larger than a full-sized packet, at which point it is applied to the rcvwnd field. A calculated smoothed round-trip timeout. Round-trip timeout. Variance of the round-trip time. New round-trip timeout (using the Karn algorithm). This field separately tracks the round-trip time of packets that have been retransmitted Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

191 Field minrtt maxrtt ACK hold Flags Datagrams: Rcvd with data total data bytes Sent with data total data bytes Description Smallest recorded round-trip timeout (hard wire value used for calculation). Largest recorded round-trip timeout. Time the local host will delay an acknowledgment in order to piggyback data on it. IP precedence of the BGP packets. Number of update packets received from neighbor. Number of update packets received with data. Total bytes of data. Number of update packets sent. Number of update packets with data sent. Total number of data bytes. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-71

192 show ip bgp neighbor Router#show ip bgp neighbor Continued For address family: VPNv4 Unicast BGP table version 416, neighbor version 416 Index 2, Offset 0, Mask 0x4 NEXT_HOP is always this router Community attribute sent to this neighbor 6 accepted prefixes consume 360 bytes Prefix advertised 431, suppressed 0, withdrawn 113 Connections established 7; dropped 6 Last reset 02:18:33, due to Peer closed the session... Rest deleted 2000, Cisco Systems, Inc The show ip bgp neighbor command displays per address-family information for neighbors that exchange MP-BGP updates with this router. The most interesting details of the printout produced by this command are highlighted in blue color in the example above Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

193 router# Monitoring MP-BGP VPNv4 Table show ip bgp vpnv4 all Displays whole VPNv4 table router# show ip bgp vpnv4 vrf name Displays only BGP parameters (routes or neighbors) associated with specified VRF Any BGP show command can be used with these parameters router# show ip bgp vpnv4 rd value Displays only BGP parameters (routes or neighbors) associated with specified RD 2000, Cisco Systems, Inc The show ip bgp command is used to display IPv4 BGP information as well as VPNv4 BGP information. To display VPNv4 BGP information, use the vpnv4 keyword followed by one of these keywords: all to display the whole contents of VPNv4 BGP table vrf name to display VPNv4 information associated with the specified VRF rd value to display VPNv4 information associated with the specified route distinguisher. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-73

194 show ip bgp vpnv4 vrf Router#show ip bgp vpnv4 vrf SiteA2 BGP table version is 416, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 103:30 (default for vrf SiteA2) *> / ? *>i / ? *>i / ? *>i / i *> / ? *>i i *> ? *>i / ? *>i / ? *>i ? *>i ? 2000, Cisco Systems, Inc show ip bgp vpnv4 vrf name Syntax Description To display VPNv4 information from the BGP database associated with a VRF, use the show ip bgp vpnv4 vrf name privileged EXEC command. show ip bgp vpnv4 vrf vrf-name [ip-prefix/length [longer-prefixes] [outputmodifiers]] [network-address [mask] [longer-prefixes] [output-modifiers]] [cidronly] [community][community-list] [dampened-paths] [filter-list] [flapstatistics] [inconsistent-as] [neighbors] [paths [line]] [peer-group] [quoteregexp] [regexp] [summary] [tags] vrf vrf-name Displays NLRIs associated with the named VRF. Defaults This command has no default values. Usage Guidelines Use this command to display VPNv4 information associated with a VRF from the BGP database. A similar command show ip bgp vpnv4 all displays all available VPNv4 information. The command show ip bgp vpnv4 summary displays BGP neighbor status Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

195 show ip bgp vpnv4 rd Router#show ip bgp vpnv4 rd 103: BGP routing table entry for 103:30: /32, version 164 Paths: (1 available, best #1, table SiteA2) Not advertised to any peer Local, imported path from 103:10: / (metric 10) from ( ) Origin incomplete, metric 1, localpref 100, valid, internal, best Extended Community: RT:103: , Cisco Systems, Inc show ip bgp vpnv4 rd value To display all VPNv4 routes that contain specified route distinguisher, use the show ip bgp vpnv4 rd privileged EXEC command. 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] [flapstatistics] [inconsistent-as] [paths [line]] [quote-regexp] [regexp] [summary] [tags] Syntax Description Defaults rd route-distinguisher Displays NLRIs that have a matching route distinguisher. This command has no default values. Usage Guidelines Use this command to display VPNv4 information associated with a VRF from the BGP database. A similar command show ip bgp vpnv4 all displays all available VPNv4 information. The command show ip bgp vpnv4 summary displays BGP neighbor status. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-75

196 router# Monitoring per-vrf CEF and LFIB Structures show ip cef vrf name Displays per-vrf CEF table router# show ip cef vrf name prefix detail Displays details of individual CEF entry, including label stack router# show tag-switching forwarding vrf name Displays labels allocated by MPLS/VPN for routes in specified vrf 2000, Cisco Systems, Inc There are three commands that can be used to display per-vrf FIB and LFIB structures: show ip cef vrf command displays the VRF Forwarding Information Base show ip cef vrf detail command displays detailed information about a single entry in the VRF FIB show tag-switching forwarding vrf command displays all labels allocated to VPN routes in the specified VRF Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

197 show ip cef vrf Router#show ip cef vrf SiteA detail /32, version 57, cached adjacency to Serial1/0.2 0 packets, 0 bytes tag information set local tag: VPN-route-head fast tag rewrite with Se1/0.2, point2point, tags imposed: {26 39} via , 0 dependencies, recursive next hop , Serial1/0.2 via /32 valid cached adjacency tag rewrite with Se1/0.2, point2point, tags imposed: {26 39} Show ip cef command can also display label stack associated with MP-IBGP route 2000, Cisco Systems, Inc show ip cef vrf To display the CEF forwarding table associated with a VRF, use the show ip cef vrf privileged EXEC command. show ip cef vrf vrf-name [ip-prefix [mask [longer-prefixes]] [detail] [outputmodifiers]] [interface interface-number] [adjacency [interface interface-number] [detail] [discard] [drop] [glean] [null] [punt] [output-modifiers]] [detail [outputmodifiers]] [non-recursive [detail] [output-modifiers]] [summary [outputmodifiers]] [traffic [prefix-length] [output-modifiers]] [unresolved [detail] [output-modifiers]] Syntax Description vrf-name ip-prefix mask longer-prefixes detail output-modifiers interface interface-number adjacency discard drop Name assigned to the VRF. (Optional) IP prefix of entries to show, in dotted decimal format (A.B.C.D). (Optional) Mask of the IP prefix in dotted decimal format. (Optional) Displays table entries for all of the more specific routes. (Optional) Displays detailed information for each CEF table entry. (Optional) (Optional) Type of network interface to use: ATM, Ethernet, Loopback, POS (packet over SONET) or Null. Number identifying the network interface to use. (Optional) Displays all prefixes resolving through adjacency. Discards adjacency. Drops adjacency. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-77

198 glean null punt non-recursive summary traffic prefix-length unresolved Gleans adjacency. Null adjacency. Punts adjacency. (Optional) Displays only non-recursive 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 argument, the show ip cef vrf command shows detailed information for all CEF table entries Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

199 show tag-switching forwarding vrf Router#show tag-switching forwarding vrf SiteA2 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 26 Aggregate /30[V] 0 37 Untagged /32[V] 0 Se1/0.20 point2point 38 Untagged /24[V] 0 Se1/0.20 point2point Router#show tag-switching forwarding vrf SiteA2 tags 37 detail Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 37 Untagged /32[V] 0 Se1/0.20 point2point MAC/Encaps=0/0, MTU=1504, Tag Stack{} VPN route: SiteA2 Per-packet load-sharing 2000, Cisco Systems, Inc show tag-switching forwarding vrf Syntax Description To display label forwarding information for advertised VRF routes, use the show tag-switching forwarding vrf command in EXEC mode. To disable the display of label forwarding information, use the no form of this command. show tag-switching forwarding vrf vrf-name [ip-prefix/length [mask]] [detail] [output-modifiers] vrf-name ip-prefix/length mask detail output-modifiers Displays NLRIs associated with the named VRF. (Optional) IP prefix address (in dotted decimal format) and length of mask (0 to 32). (Optional) Destination network mask in dotted decimal format. (Optional) Displays detailed information on the VRF routes. (Optional) For a list of associated keywords and arguments, use context-sensitive help. Defaults Usage Guidelines No default behavior or values. Use this command to display label forwarding entries associated with a particular VRF or IP prefix. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-79

200 Monitoring Labels Associated with VPNv4 Routes router# show ip bgp vpnv4 [ all rd value vrf name ] tags Displays labels associated with VPNv4 routes Router#show ip bgp vpnv4 all tags Network Next Hop In tag/out tag Route Distinguisher: 100:1 (vrf1) /notag /notag /notag /notag notag/ , Cisco Systems, Inc The show ip bgp vnpv4 tags command can be used to display tags assigned to local or remote VRF routes by the local or remote PE router. The command displays tags associated with all VPNv4 routes (when using all keyword) or tags associated with a specified route distinguisher or VRF. The following fields are displayed in the printout: Field Network Next Hop In Tag Out Tag Description Displays the network address from the BGP table. Specifies the BGP next hop address. Displays the label (if any) assigned by this router. Displays the label assigned by the BGP next hop router Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

201 Other MPLS/VPN Monitoring Commands router# telnet host /vrf name Performs PE - CE telnet through specified VRF router# ping vrf name Performs ping based on VRF routing table router# trace vrf name Performs VRF-based traceroute 2000, Cisco Systems, Inc Three additional IOS monitoring commands are VRF-aware: telnet command can be used to connect to a CE router from a PE router using the /vrf option ping vrf command can be used to ping a destination host reachable through a VRF trace vrf command can be used to trace a path toward a destination reachable through a VRF. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-81

202 Summary A number of monitoring commands is available to support management and troubleshooting of MPLS/VPN networks. There are some well-known commands that perform the same task for the VRF as they do for a normal router. They may also display some additional information. There are also many new commands that are either MPLS or MPLS/VPN specific. Review Questions How would you verify the contents of a VRF routing table? How would you display an individual entry in a VRF CEF table? How would you display routing protocols running in a VRF? Why is the BGP protocol always running in every VRF? How would you inspect a label stack associated with a remote MPLS/VPN route? How would you verify an VPNv4 information exchange with a MP-BGP neighbor? How would you display all routes with a specified route distinguisher? How would you display all labels associated with a VRF? Why do you only see labels for routes learned from CE routers? Would you ever see labels for routes received through MP-BGP in your TFIB? 3-82 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

203 Troubleshooting MPLS/VPN Objectives Upon completion of this section, you will be able to perform the following tasks: Verify proper PE-to-PE connectivity Verify proper redistribution of VPN routes and creation of MPLS labels Verify VPN route propagation and data forwarding Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-83

204 MPLS/VPN Troubleshooting Preliminary steps Perform basic MPLS troubleshooting Is CEF enabled? Are labels for IGP routes generated and propagated? Are large labeled packets propagated across MPLS backbone (MTU issues) 2000, Cisco Systems, Inc Before you start in-depth MPLS/VPN troubleshooting, you should ask the following standard MPLS troubleshooting questions: Is CEF enabled on all routers in the transit path between the PE routers? Are labels for BGP next-hops generated and propagated? Are there any MTU issues in the transit path (for example, LAN switches not supporting jumbo Ethernet frame)? Please refer to the Configuring Frame-mode MPLS on Cisco IOS Platforms and Configuring Cell-mode MPLS on Cisco IOS Platforms for detailed description of these troubleshooting steps Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

205 MPLS/VPN Troubleshooting Verify routing information flow Are CE routes received by PE? Are routes redistributed into MP-BGP with proper extended communities? Are VPNv4 routes propagated to other PE routers? Is BGP route selection process working correctly? Are VPNv4 routes inserted into VRFs on other PE routers? Are VPNv4 routes redistributed from BGP into PE-CE routing protocol? Are VPNv4 routes propagated to other CE routers? 2000, Cisco Systems, Inc MPLS/VPN troubleshooting consists of two major steps: Verify the routing information flow using the checks outlined in the slide Verify the packet forwarding (discussed later in this section) Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-85

206 MPLS/VPN Routing Information Flow Troubleshooting - 1/7 P-network CE-Spoke CE-Spoke CE-Spoke PE-1 PE-2 CE-Spoke Are CE routes received by PE? Verify with show ip route vrf name on PE-1 Perform traditional routing protocol troubleshooting if needed 2000, Cisco Systems, Inc Routing information flow troubleshooting has to verify end-to-end routing information propagation between CE routers. The first step to check is the CE to PE router routing information exchange. Use the show ip route vrf name command to verify that the PE router receives customer routers from the CE router. Use traditional routing protocol troubleshooting if needed (the troubleshooting of standard enterprise routing protocols is described in the Cisco Internetworking Troubleshooting course and BGP-specific troubleshooting is described in the individual implementation lessons of the BGP curriculum) Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

207 MPLS/VPN Routing Information Flow Troubleshooting - 2/7 P-network CE-Spoke CE-Spoke CE-Spoke PE-1 PE-2 CE-Spoke Are routes redistributed into MP-BGP with proper extended communities? Verify with show ip bgp vrf name prefix on PE-1 Troubleshoot with debug ip bgp commands 2000, Cisco Systems, Inc The CE routes received by the PE router need to be redistributed into MP-BGP; otherwise, they will not get propagated to other PE routers. Common configuration mistakes in this step include: Not configuring redistribution between the PE-CE routing protocol and per- VRF routing context of the BGP Using route-map on redistribution that filters CE routes Proper redistribution of CE routes into per-vrf instance of BGP can be verified with the show ip bgp vrf name command. The route distinguisher prepended to the IPv4 prefix and the route targets attached to the CE route can be verified with the show ip bgp vrf name prefix command. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-87

208 MPLS/VPN Routing Information Flow Troubleshooting - 3/7 P-network CE-Spoke CE-Spoke CE-Spoke PE-1 PE-2 CE-Spoke Are VPNv4 routes propagated to other PE routers? Verify with show ip bgp vpnv4 all prefix Troubleshoot PE-PE connectivity with traditional BGP troubleshooting tools 2000, Cisco Systems, Inc The CE routes redistributed into MP-BGP need to be propagated to other PE routers. Verify the proper route propagation with the show ip bgp vpnv4 command on the remote PE router. Note Routes sent by the originating PE router might not be received by remote PE router because of automatic route-target-based filters installed on the remote PE router. Please refer to the chapter Large Scale MPLS VPN Deployment in the MPLS VPN Solutions lesson for more details on automatic route filters. Automatic route filters are based on route targets; verify that the route targets attached to the CE route in the originating PE router match at least one of the route targets configured as import route targets in the VRF on the receiving PE router Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

209 MPLS/VPN Routing Information Flow Troubleshooting - 4/7 P-network CE-Spoke CE-Spoke CE-Spoke PE-1 PE-2 CE-Spoke Is BGP route selection process working correctly on PE-2? Verify with show ip bgp vrf name prefix Change local preference or weight settings if needed Do not change MED if you re using BGP-to-IGP redistribution on PE , Cisco Systems, Inc In complex environments with multi-homed customer sites, the BGP route selection process might affect the proper MPLS/VPN operation. Use standard BGP route selection tools (weights or local preference) to influence BGP route selection. MED 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. Please refer to the BGP Filtering and Route Selection lesson for more information on BGP weights and to Advanced BGP Configuration lesson for more information on BGP local preference and MED. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-89

210 MPLS/VPN Routing Information Flow Troubleshooting - 5/7 P-network CE-Spoke CE-Spoke CE-Spoke PE-1 PE-2 CE-Spoke Are VPNv4 routes inserted into VRFs on PE-2? Verify with show ip route vrf Troubleshoot with show ip bgp prefix and show ip vrf detail Perform additional BGP troubleshooting if needed 2000, Cisco Systems, Inc The VPNv4 routes received by the PE router have to be inserted into the proper VRF, which can be verified with show ip route vrf command. Common configuration mistakes in this step include: Wrong import route targets configured in the VRF The route-map configured as import route-map is rejecting the VPNv4 routes (please refer to further sections in this lesson for more information on import route-map). The validity of the import route targets can be verified with the show ip bgp vpnv4 all prefix command, which displays the route targets attached to a VPNv4 route and with the show ip vrf detail command that lists the import route targets for a VRF. At least one route target attached to the VPNv4 route needs to match at least one route-target 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 worst circumstances. Please refer to the MPLS VPN Solutions lesson for more information on improving route import speed Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

211 MPLS/VPN Routing Information Flow Troubleshooting - 6/7 P-network CE-Spoke CE-Spoke CE-Spoke PE-1 PE-2 CE-Spoke Are VPNv4 routes redistributed from BGP into PE- CE routing protocol? Verify redistribution configuration - is IGP metric specified? Perform traditional routing protocol troubleshooting 2000, Cisco Systems, Inc 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 sometimes occur here, starting with missing redistribution metrics. Please refer to the Building Scalable Cisco Networks (BSCN) and Cisco Internetworking Troubleshooting (CIT) courses for more information on route redistribution troubleshooting. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-91

212 MPLS/VPN Routing Information Flow Troubleshooting - 7/7 P-network CE-Spoke CE-Spoke CE-Spoke PE-1 PE-2 CE-Spoke Are VPNv4 routes propagated to other CE routers? Verify with show ip route on CE-spoke Alternatively, does CE-spoke have default route toward PE-2? Perform traditional routing protocol troubleshooting if needed 2000, Cisco Systems, Inc Last but not least, the routes redistributed into the PE-CE routing protocol have to be propagated to CE routers (or the CE routers need a default route toward 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 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

213 MPLS/VPN Troubleshooting Verify proper data flow Is CEF enabled on ingress PE router interface? Is the CEF entry correct on the ingress PE router? Is there an end-to-end LSP between PE routers? Is the LFIB entry on egress PE router correct? 2000, Cisco Systems, Inc After you ve verified a proper route exchange, start MPLS/VPN data flow troubleshooting using the checks listed in the slide. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-93

214 MPLS/VPN Data Flow Troubleshooting - 1/4 P-network CE-Spoke CE-Spoke CE-Spoke PE-1 PE-2 CE-Spoke Is CEF enabled on ingress PE router interface? Verify with show cef interface MPLS/VPN needs CEF enabled on ingress PE router interface for proper operation CEF might become disabled due to additional features deployed on the interface 2000, Cisco Systems, Inc One of the most common data-flow related configuration mistakes is the failure to enable CEF in ingress PE router interface, which 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. There are three common reasons for this problem (assuming that CEF is enabled on the router): CEF is manually disabled on an interface The interface is using an encapsulation method that is not supported by CEF, for example, X.25 or multi-link PPP with interleaving Another feature has been configured on the interface that disables CEF (for example, IP precedence accounting) 3-94 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

215 show cef interface Router#show cef interface serial 1/0.20 Serial1/0.20 is up (if_number 18) Internet address is /30 ICMP redirects are always sent Per packet loadbalancing is disabled IP unicast RPF check is disabled Inbound access list is not set Outbound access list is not set IP policy routing is disabled Interface is marked as point to point interface Hardware idb is Serial1/0 Fast switching type 5, interface type 64 IP CEF switching enabled IP CEF VPN Fast switching turbo vector VPN Forwarding table "SiteA2" Input fast flags 0x1000, Output fast flags 0x0 ifindex 3(3) Slot 1 Slot unit 0 VC -1 Transmit limit accumulator 0x0 (0x0) IP MTU , Cisco Systems, Inc show cef interface To display Cisco Express Forwarding (CEF) related interface information, use the show cef interface command in EXEC mode. show cef interface type number [detail] Syntax Description type number detail Interface type and number for displaying CEF-related information. (Optional) Displays detailed CEF information for the specified interface type and number. Usage Guidelines This command is available on routers that have RP cards and line cards. The detail keyword displays more CEF-related information for the specified interface. You can use this command to show the CEF state on an individual interface. The following table describes the fields shown in the output. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-95

216 Table: show cef interface detail Field Descriptions Field Description interface type number is {up down} Indicates status of the interface. Internet address Internet address of the interface. ICMP packets are {always sent never sent} Indicates how packet forwarding is configured. Per-packet load balancing Status of load balancing in use on the interface (enabled or disabled). Inbound access list {# Not set} Number of access lists defined for the interface. Outbound access list Number of access lists defined for the interface. Hardware idb is type number Interface type and number configured. Fast switching type Used for troubleshooting; indicates switching mode in use. IP Distributed CEF switching {enabled disabled} Indicates the switching path used. Slot n Slot unit n The slot number. Hardware transmit queue Indicates the number of packets in the transmit queue. Transmit limit accumulator Indicates the maximum number of packets allowed in the transmit queue. IP MTU The value of the MTU size set on the interface Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

217 MPLS/VPN Data Flow Troubleshooting - 2/4 P-network CE-Spoke CE-Spoke CE-Spoke PE-1 PE-2 CE-Spoke Is the CEF entry correct on the ingress PE router? Display the CEF entry with show ip cef vrf name prefix detail Verify label stack in the CEF entry 2000, Cisco Systems, Inc If the CEF switching is enabled on ingress interface, you can verify the validity of CEF entry and the associated label stack with the show ip cef vrf name prefix detail command. The top label in the stack should correspond to the BGP nexthop label as displayed by the show tag forwarding command on the ingress router and the second label in the stack should correspond to the label allocated by the egress router as displayed by the show tag forwarding command on the egress router. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-97

218 MPLS/VPN Data Flow Troubleshooting - 3/4 P-network CE-Spoke CE-Spoke CE-Spoke PE-1 PE-2 CE-Spoke Is there an end-to-end LSP between PE routers? Check summarization issues - BGP next hop shall be reachable as host route Quick check - if the 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 larger label header than pure MPLS 2000, Cisco Systems, Inc If the 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 IGP and MTU issues. The quickest check on a potential summarization problem can be done by disabling IP TTL propagation into the MPLS label header by using the no tagswitching ip ttl-propagate command. The traceroute command toward BGP nexthop shall display no intermediate hops when the TTL propagation is disabled. If the intermediate hops are displayed, the label switched path between PE routers is broken at those hops and the VPN traffic cannot flow Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

219 MPLS/VPN Data Flow Troubleshooting - 4/4 P-network CE-Spoke CE-Spoke CE-Spoke PE-1 PE-2 CE-Spoke Is the LFIB entry on egress PE router correct? Find out the second label in the label stack on PE-2 with show ip cef vrf name prefix detail Verify correctness of LFIB entry on PE-1 with show tag forwarding vrf name tag value detail 2000, Cisco Systems, Inc As a last troubleshooting measure (usually not needed), you can verify the contents of Label Forwarding Information Base (LFIB) on the egress PE router and compare it with the second label in the label stack on the ingress PE router. A mismatch indicates an internal IOS error that has to be reported to Cisco Technical Assistance Center (TAC). Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-99

220 Summary To verify the proper operation of the MPLS/VPN network first perform the internal connectivity tests within the core network by pinging between the loopbacks of the PE routers. Make sure that ICMP packets were label-switched. In the second step you should verify the propagation of customer networks through MP-BGP and installation of VPN labels into the forwarding table. Pinging between the CE routers should confirm that the VPN is functional. Review Questions What are the preliminary MPLS/VPN troubleshooting steps? How would you verify routing information exchange between PE routers? How would you verify that the VPNv4 routes are entered in the proper VRF? How would you verify redistribution of VPNv4 routes into the PE-CE routing protocol? How would you test end-to-end data flow between PE routers? How would you verify that the CE routes get redistributed into MP-BGP with proper route targets? How would you check for potential MTU size issues on the path taken by PEto-PE LSP? How would you verify that the PE router ingress interface supports CEF switching? Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

221 Advanced VRF Import/Export Features Objectives Upon completion of this section, you will be able to perform the following tasks: Configure import and export route maps within VRFs Configure limits on number of routes accepted from a BGP neighbor Configure limits on total number of routes in a VRF Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-101

222 Advanced VRF Features Selective Import Specify additional criteria for importing routes into VRF Selective export Specify additional route targets attached to exported routes VRF Limit Specify the maximum number of routes in a VRF to prevent memory exhaustion on PE router or denial-of-service attacks 2000, Cisco Systems, Inc There are a number of advanced VRF features that allow you to deploy advanced MPLS/VPN topologies or to increase the stability of your MPLS/VPN backbone: The selective import feature allows you to select routes to be imported into a VRF based on criteria other than route target The selective export feature allows you to attach specific route targets only to a subset of routes exported from a VRF (by default, the same route targets get attached to all exported routes) The VRF route limit feature allows you to limit the number of routes the customer (or other PE routers) can insert in the VRF, therefore preventing fatal consequences of configuration errors or denial-of-service attacks Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

223 Selective VRF Import VRF import criteria might be more specific than just the match on Route Target, for example: Import only routes with specific BGP attributes (community ) Import routes with specific prefixes or subnet masks (only loopback addresses) A route-map can be configured in VRF to make route import more specific 2000, Cisco Systems, Inc Selective route import into a VRF allows you to narrow the route import criteria by using a route-map that can filter the routes selected by the route-target import filter. The routes imported into a VRF are BGP routes, so you can use match conditions in a route-map to match any BGP attribute of a route, including, for example, communities, local-preference, MED, AS-path, etc. The import route-map filter is combined with the route-target import filter a route has to pass the route-target import filter first and then the import route map. The necessary conditions for a route to be imported into a VRF are thus: At least one of the route-targets attached to the route matches one of the import route targets configured in the VRF The route is permitted by the import route-map. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-103

224 router(config-vrf)# Configuring Selective VRF import import map route-map-name Attaches a route map to VRF import process A route is only imported into VRF if at least one RT attached to route matches one RT configured in the VRF and the route is accepted by the route-map 2000, Cisco Systems, Inc import map To configure an import route map for a VRF, use the import map command in VRF submode. import map route-map Syntax Description route-map 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 import map command Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

225 Selective Import Example Site A AS 213 AS 115 VPN-IPv4 update: RD: /32 RT=115:317 VPN-IPv4 update: RD: /24 RT=115:317 CE-BGP-A1 Second update has matching PE-Site-X RT but is not accepted by the route-map ip vrf Site_A rd 115:317 First update has matching import map RTMAP RT and is accepted by the route-target both 115:317 route-map! access-list 10 permit ! route-map RTMAP permit 10 match ip address , Cisco Systems, Inc The slide shows an example where an import route-map is used to match the IPv4 portion incoming of VPNv4 routes and import only routes matching a certain prefix into the VRF. A configuration similar to this one could be used to: Deploy advanced MPLS/VPN topologies (for example, managed router services topology see the MPLS/VPN Topologies chapter of the MPLS VPN Solutions lesson for more details or Increase the security of extranet VPN by allowing only predefined subnets to be inserted into a VRF, thus preventing an extranet site from inserting unapproved subnets into the extranet. Note A similar function is usually not needed in an intranet scenario, because all the customer routers in an intranet are usually under common administration. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-105

226 Selective Export Routes from a VRF might have to be exported with different route-targets Example: export management routes with particular RT Export route map can be configured on VRF This route map can set extended community Route Target No other set operations might be performed by this route map 2000, Cisco Systems, Inc Some advanced MPLS/VPN topologies are easiest to implement if you can attach a variety of route targets to routes exported from the same VRF, so that only a subset of the routes exported from a VRF is imported into another VRF. Most of the services where the customer routers need to connect to a common server, be it a network management station, voice gateway or an application server, 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 route targets to routes exported from a VRF. The export route-map performs only the attachment of route targets, it does not perform any filtering function and you cannot change any other route attributes with this route-map. Attributes attached to a route with an export route-map are combined with the export route-target attributes. If you specify export route-targets in a VRF and set route targets with an export route-map, all of the specified route targets are attached to the exported route. Note Export route-map provides functionality that is almost identical to the import routemap, 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, but usually in a more awkward manner Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

227 router(config)# Configuring Selective VRF Export route-map name permit seq match condition set extcommunity RT value [additive] Create a route map that matches routes based on any route-map condition and sets RT router(config-vrf)# export map name Attaches a route map to VRF export process All exported routes always get route targets configured with route-target export in the VRF A route that is matched by the export route map will have additional route targets attached 2000, Cisco Systems, Inc set extcommunity To set the extended communities attribute, use the set extcommunity route-map configuration command. To delete the entry, use the no form of this command. set extcommunity extcommunity-type community-number [additive] no set extcommunity extcommunity-type community-number [additive] Syntax Description Default extcommunity-type extcommunity-number additive Valid parameters are rt (Route Target) and soo (Site of Origin). Valid parameter is entered in a x:y format where x can either be an AS number ( ) and y is in the range from 1 to or x is an IP address where y is in the range from 1 to (Optional) Adds the extended community to the already existing extended communities. No BGP extended community attributes are set by the route map. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-107

228 export map To apply a route map to filter and modify exported routes, use the export map VRF configuration command. To remove the route map from the VRF, use the no form of this command. export map route-map-name no export map route-map-name Syntax Description route-map-name specify the name of the route map to be used. Default No route map is used Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

229 Selective Export Example Site A AS 213 AS 115 VPN-IPv4 update: RD: /32 RT=115:317 VPN-IPv4 update: RD: /24 RT=115: :273 CE-BGP-A1 PE-Site-X ip vrf Site_A rd 115:317 export map RTMAP route-target both 115:317! access-list 10 permit ! route-map RTMAP permit 10 match ip address 10 set extcommunity rt 115:273 additive 2000, Cisco Systems, Inc This example mirrors the example from page 105, this time implemented with an export-map. In the example on page 105, the 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 certain address block are marked with an additional route-target in the originating VRF and are automatically inserted into the receiving VRF based on their route target. The main difference between import and export route-map is therefore the deployment point: Import route-map is deployed in the receiving VRF Export route-map is deployed in the originating VRF Based on your network design, one or the other functionality might be preferred. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-109

230 Limiting the Number of Routes in a VRF Service Providers offering MPLS/VPN are exposed to denial-of-service attacks similar to ISPs offering BGP connectivity Any customer can generate any number of routes, using resources in the PE-routers Resources used by a single customer have to be limited IOS offers two limits: Limit number of routes received from a BGP neighbor Limit the total number of routes in a VRF 2000, Cisco Systems, Inc MPLS/VPN architecture achieves a very tight coupling of 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 network is all of a sudden exposed to design and configuration errors in customer networks, as well as to a number of new denial-of-service attacks based on routing protocol behavior. To limit the effect of configuration errors as well as malicious user behavior, Cisco IOS offers two features that limit the number of routes (and consequently resource consumption at a PE router) that a VPN user can have: The BGP maximum-prefix feature limits the number of routes that an individual BGP peer can send The VRF route limit limits the total number of routes in a VRF, regardless of whether they are received from CE routers or from other PE routers via MP- IBGP Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

231 Limiting the Number of Prefixes Received from a BGP Neighbor router(config-router-af)# neighbor ip-address maximum-prefix maximum [threshold] [warning-only] 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%) Optional warning-only keyword specifies the action on exceeding the maximum number (default is to drop neighborship) 2000, Cisco Systems, Inc neighbor maximum-prefix Syntax Description To control how many prefixes can be received from a neighbor, use the neighbor maximum-prefix router configuration command. 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 Default ip-address peer-group-name maximum threshold IP address of the neighbor. Name of a BGP peer group. Maximum number of prefixes allowed from this neighbor. (Optional) Integer specifying at what percentage of maximum the router starts to generate a warning message. The range is 1 to 100; the default is 75 (percent). warning-only (Optional) Allows the router to generate a log message when the maximum is exceeded, instead of terminating the peering. Disabled; there is no limit on the number of prefixes. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-111

232 VRF Route Limit The VRF route-limit limits the number of routes that are imported into a VRF Routes coming from CE routers Routes coming from other PEs (imported routes) The route limit is configured for each VRF If the number of routes exceeds the route-limit Syslog message is generated (Optional) routes are not inserted into VRF anymore 2000, Cisco Systems, Inc 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 BGP maximumprefix, the network operator might be warned when the number of routes exceeds a certain threshold via the syslog mechanism. Additionally, you can configure IOS 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, giving you maximum design and configuration flexibility. Note The per-vrf limit could be used to implement add-on MPLS/VPN services, where a user paying for a better service might be able to insert more VPN routes into the network Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

233 Configuring VRF Route Limit router(config-vrf)# maximum route number { warning-percent warn-only} Configures the maximum number of routes accepted into a VRF: Number is the route limit for the VRF Warning-percent is the percentage value over which a warning message is sent to syslog With warn-only the PE continues accepting routes after the configured limit Syslog messages generated by this command are rate-limited 2000, Cisco Systems, Inc 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 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 Syntax Description limit warn threshold warn-only 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. Rejects routes when the threshold limit is reached. The threshold limit is a percentage of the limit specified, from 1 to 100. 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 No default behavior or values. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-113

234 VRF Route Limit Example Site A AS 213 AS 115 IPv4 update: CE-BGP-A /32 IPv4 update: /24 IPv4 update: /24 PE-Site-X VPN-IPv4 update: RD: /24 RT=100:1 VPN-IPv4 update: RD: /24 RT=100:1 PE-Site-Y ip vrf Site_A rd 115:317 route-target both 115:317 maximum-routes 4 75 %IPRT-3-ROUTELIMITWARNING: IP routing table limit warning - vpn01 %IPRT-3-ROUTELIMITWARNING: IP routing table limit warning - vpn01 %IPRT-3-ROUTELIMITEXCEEDED: IP routing table limit exceeded -Site_A, / , Cisco Systems, Inc In this example, the network designer has decided to limit the number of routes in a VRF to four, with the warning threshold being set at 75% (or three routes). When the first two routes are received and inserted in 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 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

235 Summary Route maps can be used to filter routes to be imported and exported. Route maps used to import routes can match on standard and extended BGP parameters. Route maps used to export routes can match on standard BGP parameters. To prevent CE routers from flooding the PE routers with excessive number of routes, a limit can be set on the number of updates accepted from BGP neighbors. A limit can also be set for the number of routing entries in the VRF. Review Questions Why would you need selective VRF import? How does the import route-map affect VRF import process? Why would you need selective VRF export? How does the export route-map affect VRF export process? Which BGP attributes can be set with an export route-map? Why would you need VRF route limit? How many VRF route-limiting options does IOS offer? When would you want to use BGP maximum-prefix parameter? When would you want to use VRF route-limit? Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-115

236 Advanced PE-CE BGP Configuration Objectives Upon completion of this section, you will be able to perform the following tasks: Use the AS-Override feature Use the Allowas-in feature Configure Site-Of-Origin (SOO) on incoming interface or BGP neighbor Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

237 Sample VPN Network Reusing AS Number Across Sites Site A AS 213 P-Network AS 115 Site B AS 213 CE-BGP-A / CE-BGP-A2 PE-Site-X PE-Site-Y i / / The customer wants to reuse the same AS number on several sites: CE-BGP-A1 announces network /16 to PE-Site-X The prefix announced by CE-BGP-A1 is propagated to PE-Site-Y as internal route through MP-BGP PE-Site-Y prepends AS115 to the AS-path and propagates the prefix to CE-BGP-A2 CE-BGP-A2 drops the update because the AS213 is already in AS-Path 2000, Cisco Systems, Inc There are two ways an MPLS/VPN customer can deploy the BGP as the routing protocol between the PE and the 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 customer s autonomous systems; every site could be a separate autonomous system If, however, the customer has been using BGP as the routing protocol before, there is a good chance that all the sites (or a subset of the sites) were using the same autonomous system number BGP loop prevention rules disallow discontiguous autonomous systems in other words, two customer sites with the identical AS number cannot be linked by another autonomous system. If such a setup happens (as in the example above), the routing updates from one site would be dropped when the other site receives them and there would be no connectivity between the sites. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-117

238 AS-Override Overview New AS-Path update procedures have been implemented in order to re-use the same ASN on all VPN sites The procedures allow the use of private as well as public ASN Same ASN may be used for all sites, whatever is their VPN 2000, Cisco Systems, Inc To support customer topologies where the same customer AS number is used at more than one site, the AS-path update procedure in BGP has been modified to overcome the loop prevention rules of BGP. The new AS-path update procedure supports usage of one AS number at many sites (even between several overlapping VPNs) and does not rely on distinction between private or public AS numbers Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

239 AS-Override Implementation With AS-Override configured, the AS_PATH update procedure on the PE router is as follows: If the first ASN in the AS_PATH is equal to the neighbouring one, it is replaced by the provider ASN If first ASN has multiple occurrences (due to AS_PATH prepend) all the occurrences are replaced with provider-asn value After this operation, provider AS number is prepended to the AS_PATH 2000, Cisco Systems, Inc The modified AS-path update procedure (also called AS-override) is extremely simple: The procedure is only used if the first AS number in the AS-path is equal to the AS-number of the receiving BGP router In this case, all 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 (further down the AS path) of the receiving router s AS number are not replaced because they indicate a real routing information loop An extra copy of the sending router s AS number is prepended to the AS-path (standard AS number prepending procedure that occurs on every EBGP update) Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-119

240 Configuring AS-Override router(config-router-af)# neighbor ip-address as-override This command configures AS-override AS-path update procedure for specified neighbor AS-override is configured for CE EBGP neighbors in the VRF address family of the BGP process 2000, Cisco Systems, Inc neighbor as-override To configure a PE router to override a site's ASN with a provider's ASN, use the neighbor as-override router configuration command. To remove VPN IPv4 prefixes from a specified router, use the no form of this command. neighbor ip-address as-override no neighbor ip-address as-override Syntax Description ip-address Specifies the router's IP address to override with the ASN provided. Defaults No default behavior or values Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

241 AS-Override in Action router bgp 115 address-family ipv4 vrf Customer_A neighbor remote-as 213 neighbor activate neighbor as-override Site A AS 213 AS 115 Site B AS 213 CE-BGP-A1 CE-BGP-A2 PE-Site-X PE-Site-Y / i / / PE-Site-Y replaces AS213 with AS115 in AS-path, prepends another copy of AS115 to the AS-path and propagates the prefix 2000, Cisco Systems, Inc In the example above, two customer sites (Site A and Site B) use BGP to communicate with the MPLS/VPN backbone. Both sites use AS 213 and Site B would drop the update sent by Site A without the AS-override mechanism. The AS-override mechanism, configured on PE-Site-Y router, replaces the customer AS number (213) with the provider AS number (115) 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 processing. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-121

242 AS-Override with AS-Path Prepending router bgp 115 address-family ipv4 vrf Customer_A neighbor remote-as 213 neighbor activate neighbor as-override Site A AS 213 AS 115 Site B AS 213 CE-BGP-A1 CE-BGP-A2 PE-Site-X PE-Site-Y / i / / PE-Site-Y replaces all occurrences of AS213 with AS115 in AS-path, prepends another copy of AS115 to the AS-path and propagates the prefix 2000, Cisco Systems, Inc If the customer is using AS prepending to influence BGP path selection within the MPLS/VPN backbone, 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 above) and the third occurrence of the provider AS number is prepended to the BGP update before it s sent out to the CE router Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

243 Sample VPN Network Customer Site Linking two VPNs VPN-A VPN-B CE-BGP-A1 Customer site links two VPNs Not a usual setup - traffic between VPNs should not flow over the customer site Sometimes used for enhanced security 2000, Cisco Systems, Inc In some security-conscious implementations, customer VPNs are linked by a customer router that performs security functions like access filters or access logging. Note This setup is not a usual setup because it deviates from the basic goal of MPLS/VPN replace hub-and-spoke routing of traditional overlay VPN with optimum any-to-any routing. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-123

244 Customer Site Linking VPNs Various Perspectives VPN-A VPN-B PE-1 CE-BGP-A1 PE-2 P-Network C-Network P-Network AS 115 AS 213 AS 115 VPN perspective: VPN-a connected to VPN-B via CE-BGP-A1 Physical topology: CE router is connected to two PE routers MPLS/VPN perspective: CE router has two links into the P-network BGP perspective: CE router has two connections to AS , Cisco Systems, Inc The setup where a customer router links two VPN networks in an MPLS/VPN backbone can be viewed from several different perspectives: 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 P-network There is no problem with the proposed customer setup if analyzed through these perspectives they all represent valid connectivity or routing options. The problem occurs when we analyze the BGP perspective, where the CE router has to propagate routes between two PE routers, which are both in the same autonomous system Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

245 Customer Site Linking VPNs BGP Loop Prevention Issues VPN-A VPN-B PE / CE-BGP-A / PE-2 P-Network C-Network P-Network AS 115 AS 213 AS 115 PE-1 announces network /16 to CE-BGP-A1 CE-BGP-A1 prepends its AS number to the AS Path and propagates the prefix to PE-2 PE-2 drops the update because it s AS number is already in the AS-Path AS-Override is needed on CE-BGP-A1, but that would require IOS upgrade on the CE router 2000, Cisco Systems, Inc Similar to the situation where two customer sites were using the same AS number, 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). The solution to this BGP routing problem could be identical to the previous one AS-override has to be used on the CE router. This solution would, however, require a very recent IOS version (12.0T or 12.1 IOS release) on the CE router and is therefore not enforceable in every customer situation. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-125

246 Allowas-in The Allowas-in BGP option disables AS_PATH check on the PE router The number of occurrences of router s own AS number is limited to suppress real routing loops The limit has to be configured PE router will only REJECT the update if its AS number appears in the AS_PATH more often than the configured limit 2000, Cisco Systems, Inc To support topologies where a CE router with no AS-override support links two VPNs, the BGP loop prevention mechanism on the PE routers was modified to support the situations where the PE router would receive routes with its own AS number already in the AS path. With the allowas-in 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 they 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 and the incoming updates that exceed the limit are dropped Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

247 Configuring Allowas-in router(config-router)# neighbor ip-address allowas-in limit This command disables traditional BGP AS_PATH check Incoming update is only rejected if router s own AS number appears in the AS_PATH more often than the configured limit 2000, Cisco Systems, Inc neighbor allowas-in To configure PE routers to allow readvertisement of all prefixes containing duplicate ASNs, use the neighbor allowas-in command in router configuration mode. To disable the readvertisement of a PE router's ASN, use the no form of this command. neighbor allowas-in number no neighbor allowas-in number Syntax Description number Specifies the number of times to allow the advertisement of a PE router's ASN. Valid values are from 1 to 10 times. Defaults No default behavior or values. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-127

248 Additional BGP Loop Prevention Mechanisms AS-Path based BGP loop prevention is bypassed with AS-Override and Allowas- In features Site of Origin (extended BGP community) can be used to prevent loops in these scenarios Site of Origin (SOO) is only needed for multihomed sites SOO is not needed for stub sites 2000, Cisco Systems, Inc Most aspects of BGP loop prevention are bypassed when you re using either asoverride or allowas-in features. Although the routing information loops can still be detected by counting occurrences of an autonomous system number in the AS path in end-to-end BGP routing scenario, the situation can get worse when BGP is mixed with other PE-CE routing protocols. The Site-of-origin extended BGP community can be used as an additional loop prevention mechanism in these scenarios. Note Site-of-origin and any other loop prevention mechanisms are only needed for customer networks with multi-homed sites. Loops can never occur in customer networks that only have stub sites Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

249 Setting Site of Origin When running EBGP between PE and CE, SOO is configured through a routemap command For other routing protocols, SOO can be applied to routes learned through a particular VRF interface during the redistribution into BGP 2000, Cisco Systems, Inc There are two ways to set site-of-origin attribute on a BGP route: For routes received from the BGP-speaking CE routers, the site-of-origin is set by incoming route map on the PE-router For all other routes, a route-map setting site-of-origin is applied to the incoming interface and the site-of-origin as set by the route-map is attached to the BGP route when an IGP route received through that interface is redistributed into BGP. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-129

250 Filters based on SOO Route-maps are used on EBGP PE-CE connections to filter on SOO values For other routing protocols, routes redistributed from BGP are filtered based on Site of Origin values configured on outgoing interfaces 2000, Cisco Systems, Inc Outgoing filters based on site-of-origin attribute also depend on the routing protocol used: For situations where BGP is used as the PE-CE routing protocol, outbound route maps can be used on the PE router to deny routes matching particular value of site-of-origin For all other routing protocols, filtering is performed based on site-of-origin route-map configured on the outgoing interface before the update is sent across that interface to the CE router Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

251 router(config)# Setting Site-of-Origin on Inbound EBGP Update route-map name permit seq match conditions set extcommunity soo value Creates a route map that sets Site-of-Origin attribute router(config-router-af)# neighbor ip-address route-map name in Applies inbound route-map to CE EBGP neighbor 2000, Cisco Systems, Inc set extcommunity To set the extended communities attribute, use the set extcommunity route-map configuration command. To delete the entry, use the no form of this command. set extcommunity extcommunity-type community-number [additive] no set extcommunity extcommunity-type community-number [additive] Syntax Description Default extcommunity-type extcommunity-number additive Valid parameters are rt (Route Target) and soo (Site of Origin). Valid parameter is entered in a x:y format where x can either be an AS number ( ) and y is in the range from 1 to or x is an IP address where y is in the range from 1 to (Optional) Adds the extended community to the already existing extended communities. No BGP extended community attributes are set by the route map. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-131

252 Setting Site-of-Origin on Other Inbound Routing Updates router(config)# route-map name permit seq match conditions set extcommunity soo value Creates a route map that sets Site-of-Origin attribute router(config-if)# ip vrf sitemap route-map-name Applies route-map that sets Site-of-Origin to inbound routing updates received from this interface 2000, Cisco Systems, Inc ip vrf sitemap To set the Site of Origin extended community attribute, use the ip vrf sitemap interface configuration command. To delete the entry, use the no form of this command. ip vrf sitemap route-map-name no ip vrf sitemap route-map-name Syntax Description route-map-name Set the name of the route map to be used. Default No route map is used to set the Site of Origin extended community Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

253 Site-of-origin based Filter of Outbound EBGP Updates router(config)# ip extcommunity-list number permit soo value! route-map name deny seq match extcommunity number! route-map name permit 9999 Defines a route map that discards routes with desired Site-of-Origin value router(config-router-af)# neighbor ip-address route-map name out Applies the route-map to outbound updates sent to EBGP CE neighbor 2000, Cisco Systems, Inc In this example, a route-map matching a specific site-of-origin value was defined using ip extcommunity-list to establish a site-of-origin filter and route-map command 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. Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-133

254 Summary External BGP can be used with the CE routers to exchange routing information. If the CE sites are all using the same AS number, the information coming from one site is regarded as a routing loop on other sites. AS-Override feature should be enabled on all neighborships with the CE routers to overcome this problem. If there is a multihomed site that needs to be able to re-announce the information back into the core (Hub-and-Spoke design), the PE routers will regard this as a routing loop. Allowas-in feature should be used to overcome this problem. This may, however, cause routing loops and an additional extended community Site of Origin can be used to prevent them. Review Questions When would you need the AS-override feature? How does the AS-override feature work? When would you need the Allowas-In feature? Why can t you use the AS-override feature instead of the Allowas-In feature? How do you prevent BGP loops when using AS-override? How do you prevent BGP loops when using Allowas-in? When would you have to use Site-of-Origin? What is Site-of-Origin? Where can you set the Site-of-Origin? How do you implement filters based on Site-of-Origin? Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

255 4 Using OSPF in an MPLS VPN Environment Overview This chapter introduces the interaction between multi-protocol Border Gateway Protocol (MP-BGP) running between Provider Edge routers (PE-routers) and Open Shortest Path First (OSPF) protocol running inside a Virtual Private Network (VPN) implemented with MPLS VPN technology. Objectives Upon completion of this chapter, you will be able to perform the following tasks: Describe OSPF operation inside a VPN Describe enhanced OSPF hierarchical model Describe the interactions between OSPF and MP-BGP Use OSPF as the PE-CE routing protocol in a complex MPLS VPN environment

256 Using OSPF as the PE-CE Protocol in an MPLS VPN Environment Objectives Upon completion of this section, you will be able to perform the following tasks: Describe the enhanced OSPF hierarchical model Describe the propagation of OSPF customer routes across the MPLS VPN backbone Explain why the OSPF routes propagated through MP-BGP are not reinserted into OSPF as external (LSA type-5) routes Describe the route selection process in PE routers Explain loop prevention mechanisms 4-2 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

257 Traditional OSPF Routing Model OSPF Area 0 (backbone area) Area Border Router Area Border Router Area Area Area OSPF divides a network into areas, all of them linked through the backbone (area 0) Areas could correspond to individual sites from MPLS VPN perspective 2000, Cisco Systems, Inc. Page-5 The Open Shortest Path First (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 areas connected to it) is called the OSPF domain. The OSPF areas in the customer network could correspond to individual sites, but there are also other often-encountered options: 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 Networks (BSCN) course or OSPF curriculum for background information on OSPF. Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-3

258 MPLS VPN Routing Model BGP backbone PE-router PE-router CE-router Site IGP Site IGP Site IGP From the customer perspective, a MPLS VPN-based network has BGP backbone with IGP running at customer sites Redistribution between IGP and BGP is performed to propagate customer routes across MPLS VPN backbone 2000, Cisco Systems, Inc. Page-6 The MPLS VPN routing model introduces a BGP backbone into the customer network. Isolated copies of IGP run at every site and the multi-protocol 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. 4-4 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

259 OSPF-BGP Redistribution Issue BGP backbone OSPF route is redistributed into BGP MP-BGP route is propagated to other PE routers PE-router PE-router MP-BGP route is redistributed into OSPF OSPF route is propagated as external route into other sites Area 1 Area 2 Area 3 Local subnet is announced to the PE-router as type-1 or type-2 LSA 2000, Cisco Systems, Inc. Page-7 The IGP - BGP redistribution introduced by the MPLS VPN routing model does not fit well into the customer networks running OSPF. Whenever a route is redistributed into OSPF from another routing protocol, it s redistributed as an external OSPF route, and this is what would happen when the customer is migrated to MPLS VPN service. The OSPF routes received by one PE-router would be propagated across the MPLS backbone and redistributed back into OSPF at another site as external OSPF routes. Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-5

260 Classic OSPF-BGP Redistribution OSPF route type is not preserved when OSPF route is redistributed into BGP All OSPF routes from a site are inserted as external (LSA type 5) 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 2000, Cisco Systems, Inc. Page-8 With the traditional OSPF to 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 in OSPF, it s always redistributed as an external OSPF route. There are a number of 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 (NSSA) areas Internal routes are always preferred over external routes, regardless of their cost. Because of all these caveats, migrating an OSPF customer toward MPLS VPN service might severely impact a customer s routing. The MPLS VPN architecture must therefore extend the classic OSPF - BGP routing model to support transparent customer migration. 4-6 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

261 OSPF-BGP Hierarchy Issue BGP backbone PE-router PE-router Area 0 Area 2 Area 0 Area 3 OSPF area 0 might extend into individual sites MPLS VPN backbone has to become a super-backbone for OSPF 2000, Cisco Systems, Inc. Page-9 The MPLS VPN architecture extends the OSPF architecture by introducing another backbone above OSPF area 0 (superbackbone). The OSPF superbackbone is implemented with MP-BGP between the PE-routers, but is otherwise completely transparent to the OSPF routers. The architecture even allows disjoint OSPF backbone areas (area 0) at MPLS VPN customer sites. Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-7

262 OSPF in MPLS VPN Goals OSPF between sites shall not use normal OSPF-BGP redistribution OSPF continuity must be provided across 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 2000, Cisco Systems, Inc. Page-10 The goals that have to be met by the OSPF super-backbone are as follows: The super-backbone shall not use standard OSPF - BGP redistribution OSPF continuity must be provided between OSPF sites: 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 super-backbone shall be transparent to the CE-routers that run standard OSPF software. 4-8 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

263 MPLS VPN backbone as OSPF Super-backbone MPLS VPN backbone = OSPF super-backbone ABR ABR Area 0 Area 2 Area 0 Area 3 The MPLS VPN backbone appears as a backbone above OSPF area 0 PE routers act as OSPF Area Border Routers (ABR) 2000, Cisco Systems, Inc. Page-11 The MPLS VPN super-backbone 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 (ABR) in the OSPF areas to which they are attached. In Cisco IOS implementation, they also appear as AS Boundary Routers (ASBR) in non-stub areas. From the perspective of a standard OSPF-speaking CE-router, the PE-routers insert inter-area routes from other areas into the area in which the CE-router is present. The CE-routers are not aware of the super-backbone or of other OSPF areas present beyond the MPLS VPN super-backbone. Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-9

264 OSPF Super-backbone Route Propagation Example OSPF super-backbone PE-router propagates the route into super-backbone. Route summarization can be performed on area boundary Route from super-backbone is inserted into other areas as inter-area route ABR ABR Inter-area route is propagated into other areas Area 0 Area 2 Area 0 Area 3 Local subnet is announced to the PE-router as type-1 or type-2 LSA 2000, Cisco Systems, Inc. Page-12 With the OSPF super-backbone architecture, the continuity of OSPF routing is preserved: The OSPF intra-area route (described in OSPF router LSA or network LSA) is inserted into the OSPF super-backbone 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. Since the super-backbone appears as another area behind the PE-router (acting as ABR), the MP-BGP route derived from intraarea route is always inserted as an inter-area route. The inter-area route could then be propagated into other OSPF areas by ABRs within the customer site Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

265 OSPF Super-backbone Rules OSPF super-backbone behaves exactly like area 0 in regular OSPF PE-routers are advertised as Area Border Routers Routes redistributed from BGP into OSPF appear as inter-area summary routes or as external routes (based on their original LSA type) in other areas Routes from area 0 at one site appear as inter-area routes in area 0 at another site 2000, Cisco Systems, Inc. Page-13 The OSPF super-backbone rules could be summarized as follows: PE-routers are advertising themselves as Area Border Routers. The superbackbone appears as another area to the CE-routers Routes redistributed into MP-BGP from OSPF will appear as inter-area routes in other OSPF sites if the original route was an intra-area or inter-area route and as external routes if the original route was an external route. As a consequence to the second rule, routes from the backbone area at one site appear as inter-area routes (not as backbone routes) in backbone areas at other sites. Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-11

266 OSPF Super-backbone Implementation Extended BGP communities are used to propagate OSPF route type across BGP backbone OSPF cost is copied into MED attribute 2000, Cisco Systems, Inc. Page-14 The OSPF super-backbone is implemented with the help of several BGP attributes: Field 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 the following table: 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. Low-order bit is set for External Type 2 routes. Note The Option field in OSPF route type extended community is not equivalent to the Option field in the OSPF Link State Advertisement (LSA). As in the standard OSPF - BGP redistribution, the OSPF cost is carried in the MED attribute Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

267 OSPF Super-backbone Implementation BGP backbone /8 OSPF RT=1:1:0 MED=768 PE-router /8 LSA type 1 OSPF cost 768 Area 1 PE-router /8 LSA type 3 OSPF cost 768 Area 2 OSPF route type is copied into extended BGP community on redistribution into BGP Egress PE-router performs inter-area transformation 2000, Cisco Systems, Inc. Page-15 This figure illustrates the propagation of internal OSPF routes across the MPLS VPN super-backbone. The sending PE-router redistributes the OSPF route into MP-BGP, copies OSPF cost into 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 inter-area summary LSA. An inter-area summary LSA is always generated, because the receiving PErouter acts as an ABR between the super-backbone and the OSPF area(s). Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-13

268 OSPF Super-backbone Propagation of External Routes BGP backbone /8 OSPF RT=1:5:1 MED=20 PE-router /8 LSA type 5 E2 metric 20 Area 1 PE-router /8 LSA type 5 E2 metric 20 Area 2 External OSPF routes are propagated in the same way as internal OSPF routes across super-backbone External metric and route type are preserved 2000, Cisco Systems, Inc. Page-16 The external OSPF routes are redistributed into the MP-BGP in exactly the same way as the internal OSPF routes. The process changes slightly on the receiving PE-router: For external routes (LSA type 5), the LSA is re-originated 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 (LSA type 7), the route is announced to the other OSPF sites as LSA type-5 external route, since the route has already crossed the area boundary Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

269 OSPF Super-backbone Mixing Routing Protocols BGP backbone /8 MED=3 PE-router /8 Hop count 3 PE-router /8 LSA type 5 E2 metric 20 RIP Area 2 Routes from MP-BGP backbone that did not originate in OSPF are still subject to standard redistribution behavior when inserted into OSPF 2000, Cisco Systems, Inc. Page-17 The MPLS VPN super-backbone still retains the traditional BGP - OSPF 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). Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-15

270 OSPF-BGP Routing Loops BGP backbone The OSPF route is received by a PE-router, redistributed into MP-BGP and propagated across the MPLS VPN backbone The route from super-backbone is inserted as inter-area route PE-router PE-router PE-router Area 1 The OSPF route is propagated across the area The other PE router would redistribute the route back into BGP Area 2 Local subnet is announced to the PE-router 2000, Cisco Systems, Inc. Page-18 Step 1 Step 2 Step 3 Step 4 Step 5 OSPF developers took many precautions to avoid routing loops between OSPF areas for example, intra-area routes are always preferred over inter-area routes. These rules don t work after the super-backbone is introduced. Consider, for example, a network in the figure above, where the receiving OSPF area has two PE-routers attached to it. The sending PE-router receives an intra-area OSPF route. The intra-area OSPF route is redistributed into MP-BGP. OSPF community is attached to the route to indicate it was an OSPF route before being redistributed. Receiving PE-router redistributes the MP-BGP route into OSPF as an internal inter-area summary route. The summary route is propagated across OSPF area and received by the other PErouter attached to the same area. The administrative distance of the OSPF route is better than the administrative distance of the MP-IBGP 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 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

271 OSPF Down Bit 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 Down bit set into MP-BGP 2000, Cisco Systems, Inc. Page-19 Two mechanisms were introduced to prevent route redistribution loops between OSPF running between PE- and CE-routers and multi-protocol BGP running between PE-routers: BGP site-of-origin, which is covered in the MPLS VPN Implementation chapter Down bit in the Options field of the OSPF LSA header The down bit is used between the PE-routers to indicate which routes were inserted into the OSPF topology database from the MPLS VPN super-backbone and thus shall not be redistributed back in the MPLS VPN super-backbone. The PE-router that redistributes the MP-BGP route as OSPF route into the OSPF topology database sets the down bit. Other PE-routers use the down bit to prevent this route from being redistributed back into MP-BGP. Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-17

272 OSPF-BGP Interaction with Down Bit BGP backbone An OSPF route is received by a PE-router, redistributed into MP-BGP and propagated across the MPLS VPN backbone The route from super-backbone is inserted as inter-area route PE-router PE-router Down PE-router Area 1 The OSPF route is propagated with the Down bit set The route is never redistributed back into MP-BGP backbone Area 2 The Local subnet is announced without Down bit 2000, Cisco Systems, Inc. Page-20 Step 1 Step 2 Step 3 Step 4 The typical usage of the down bit is shown in the diagram above: PE-router receives an OSPF route PE-router redistributes OSPF route into MP-BGP. The MP-BGP route is propagated to other PE-routers The MP-BGP route is inserted as inter-area route into an OSPF area by the receiving PE-router. The receiving PE-router sets the down bit in the summary (type-3) LSA. When the other PE-routers receive the summary LSA with the down bit set, they do not redistribute the route back into MP-BGP Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

273 Routing Loops Across Multiple OSPF Domains BGP backbone A non-ospf route is redistributed as an external OSPF route into the OSPF domain by a PE router The OSPF route is propagated with the Down bit set PE-router Down PE-router The route is redistributed back into MP-BGP OSPF Domain 1 - Area 0 The route is propagated without the Down bit OSPF Domain 2 - Area 0 External OSPF route is redistributed into another OSPF domain. Down bit is cleared 2000, Cisco Systems, Inc. Page-21 Step 1 Step 2 Step 3 Step 4 The down bit stops the routing loops between MP-BGP and OSPF. It cannot, however, stop the routing loops when redistribution between multiple OSPF domains is involved, as is the case in the network in the figure above. The routing loop in the network above occurs in these steps: The PE-router redistributes a non-ospf route into an OSPF domain as an external route. The down bit is set because the route should not be redistributed back into MP-BGP. 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. The OSPF route is propagated through the other OSPF domain with the down bit cleared. A PE-router receives the OSPF route, down bit is not set, so the route is redistributed back into the MP-BGP backbone, resulting in a routing loop. Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-19

274 OSPF Tag Field The Tag field in external OSPF routes is used to detect cross-domain routing loops PE routers set the Tag field to the BGP ASnumber when redistributing non-ospf routes from MP-BGP into OSPF Tag field is propagated between OSPF domains when the external OSPF routes are redistributed between OSPF domains PE routers never redistribute OSPF routes with Tag field equal to their BGP AS-number into MP-BGP 2000, Cisco Systems, Inc. Page-22 The routing loops introduced by route redistribution between OSPF domains can be solved with the help of the tag field, using standard BGP - OSPF redistribution rules. In standard BGP - OSPF or OSPF - OSPF redistribution, the following 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 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 routes with tag field equal to the BGP AS-number into MP-BGP Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

275 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 Tag field can be set manually on the router redistributing routes between OSPF domains with redistribute tag command Alternatively, only internal OSPF routes could be redistributed into MP-BGP on the PErouters 2000, Cisco Systems, Inc. Page-23 The OSPF tag field is only present in the external OSPF routes (type-5 LSA or type-7 LSA). This technique therefore cannot detect cross-domain loops involving internal OSPF routes. There are two manual methods that can be used to overcome this OSPF limitation: The tag field can be set 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. Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-21

276 Routing Loop Prevention with OSPF Tag Field BGP backbone AS number 6 A non-ospf route is redistributed as an external OSPF route into the OSPF domain by a PE router The external OSPF route has the Down bit set and the Tag field set to 6 PE-router Down Tag field matches AS-number - the route is not redistributed back into MP-BGP OSPF Domain 1 - Area 0 The route is propagated with Tag set to 6 OSPF Domain 2 - Area 0 External OSPF route is redistributed into another OSPF domain. Down bit is cleared. The value of the tag field is retained 2000, Cisco Systems, Inc. Page-24 Step 1 Step 2 Step 3 Step 4 The diagram above illustrates how the OSPF tag field could be used to prevent routing loops when the redistribution is done between OSPF domains. A non-ospf route is redistributed as an external OSPF route by a PE-router. The tag field is set to the BGP AS-number; the down bit is set. The redistributed route is propagated across the OSPF domain. When the route is redistributed into another OSPF domain, the tag field is propagated, but the down bit is cleared. 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 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

277 Packet Forwarding through MPLS VPN Backbone Due to administrative distances, BGP backbone an OSPF route is preferred over an MP-IBGP route PE-router PE-router Down PE-router Area 1 Packet flow across the network is clearly suboptimal The OSPF route is propagated with the Down bit set Area 2 Another site 2000, Cisco Systems, Inc. Page-25 Step 1 Step 2 Step 3 The OSPF super-backbone implementation with MP-BGP has other implications beyond the potential for routing loops between OSPF and BGP. Consider, for example, the network in the figure above: The PE-router redistributes the OSPF route into MP-BGP. The route is propagated to other PE-routers as an MP-BGP route. It is also redistributed into other OSPF areas. The redistributed OSPF route is propagated across the OSPF area with the down bit set. 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 MP-IBGP route and the data packets flow across customer sites, not directly over the MPLS VPN backbone. Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-23

278 Optimizing Packet Forwarding Across MPLS VPN Backbone PE-routers ignore OSPF routes with Down bit set for routing purposes These routes originated at other sites, therefore the traffic toward them should go via MP-BGP backbone Routing bit is not set on OSPF routes with Down bit set These routes do not enter IP routing table even when they are selected as the best routes using the SPF algorithm 2000, Cisco Systems, Inc. Page-26 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, as 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 bit set, 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 Cisco s extension to OSPF and is used only internally in the router. It is never propagated between routers in LSA updates Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

279 Packet Forwarding with Down Bit Processing BGP backbone The OSPF route is ignored since the Down bit is set PE-router PE-router Down PE-router Area 1 Packet flow across the network is optimal The OSPF route is propagated with the Down bit set Area 2 Another site 2000, Cisco Systems, Inc. Page-27 Step 1 Step 2 Step 3 With the new route OSPF selection rules in place, the packet forwarding in the network shown above follows the desired path: The OSPF route is redistributed into MP-BGP by a PE-router and propagated to other PE-routers. 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. Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-25

280 Summary The MPLS VPN architecture introduces a routing model where a BGP backbone is inserted into the customer network. Traditional OSPF - BGP interactions would imply that the OSPF routes received from one customer site would be inserted as external OSPF routes into other customer sites. As the external OSPF routes are treated differently from internal OSPF routes and the customer OSPF routing often relies on properties of various OSPF route types, this option is not acceptable. A different model is needed where the MPLS VPN backbone would be implemented transparently to the customer. The OSPF super-backbone was introduced in MPLS VPN architecture to support the transparency requirements. The OSPF super-backbone, although implemented with MP-BGP, looks like a regular area to the CE-routers and the PE-routers look like Area Border Routers (ABR) even though they are in reality redistributing routes between MP-BGP and OSPF. Additional extended BGP communities are used to propagate the OSPF route type across an MP-BGP backbone. The OSPF route type carried in the MP-BGP update received by the PE-router is used to generate a summary LSA in the OSPF topology database. An additional bit (called the down bit) is used in the Options field of the OSPF header to prevent routing loops between MP-BGP and OSPF. The same bit is also used on the PE-routers to prefer MP-BGP routes over OSPF routes derived from MP-BGP routes through redistribution. Review Questions Answer the following questions: Why is the OSPF super-backbone needed in MPLS VPN environments? What is the interaction between Area 0 and a super-backbone? What is the interaction between a super-backbone and other areas? How are OSPF route attributes propagated across an MPLS VPN backbone? What is the purpose of the Down bit in an LSA header? What is the influence of the Down bit on route selection process? Why is this influence needed? 4-26 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

281 Configuring and Monitoring OSPF in an MPLS VPN Environment Objectives Upon completion of this section, you will be able to perform the following tasks: Configure OSPF in a customer VPN Monitor MPLS VPN-specific attributes in an OSPF topology database Monitor OSPF-specific extended communities in an MP-BGP table Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-27

282 Configuring OSPF in MPLS VPN Environments 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 2000, Cisco Systems, Inc. Page-32 Step 1 Step 2 Step 3 Configuring OSPF as a PE-CE routing protocol is performed in three steps: Configure per-vrf copy of OSPF process and define all usual OSPF parameters (networks, areas, neighbors). Configure redistribution of MP-BGP into OSPF. Configure redistribution of OSPF into MP-BGP. Note Contrary to conventional wisdom, two-way redistribution between OSPF and MP- BGP is safe in MPLS VPN environments because of additional mechanisms that prevent routing loops or suboptimal routing Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

283 Per-VRF OSPF Configuration router(config)# router ospf process-id vrf name... Standard OSPF parameters... This command starts per-vrf OSPF routing process The total number of routing processes per router is limited to 32 router(config-router)# redistribute bgp as-number subnets This command redistributes MP-BGP routes into OSPF. The Subnets keyword is mandatory for proper operation 2000, Cisco Systems, Inc. Page-33 The per-vrf OSPF process is started with the router ospf process-id vrf name command. Note A separate OSPF process is needed for every VRF in the router, even if the VRFs participate in the same VPN. As the number of routing processes in Cisco IOS is limited to 32, the number of OSPF customers that can be supported by any single PE-router is limited. The redistribution of MP-BGP routes into OSPF is configured with the redistribute bgp as-number subnets command. The subnets keyword is mandatory for proper MPLS VPN operation; otherwise only the major networks would be redistributed from MP-BGP into OSPF. Instead of route redistribution from MP-BGP, the default route could be announced into OSPF sites with the default-information originate always command. Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-29

284 router(config)# Configuring Route Redistribution router bgp as-number address-family ipv4 vrf vrf-name redistribute ospf process-id [match [internal] [external-1] [external-2]] OSPF to BGP route redistribution is configured with the redistribute command under the proper addressfamily Without the OSPF match keyword specified, only internal OSPF routes are redistributed into OSPF 2000, Cisco Systems, Inc. Page-34 The OSPF routes are redistributed into MP-BGP with the redistribute ospf process-id command, which needs to be configured in the proper VRF address family. The VRF address family is selected with the address-family ipv4 vrf name command. Note Please refer to the MPLS VPN Implementation chapter for more information on BGP address families. The redistribute command with no addition parameters will redistribute only internal OSPF routes into MP-BGP. Redistribution of external OSPF routes into MP-BGP must be configured manually with the match option of the redistribute command. The command redistribute ospf process-id match internal external 1 external 2 can be used to redistribute all OSPF routes into MP-BGP Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

285 router# show ip ospf Monitoring OSPF in MPLS VPN Environment This command specifies whether an OSPF process is attached to an MPLS VPN backbone router# show ip ospf database type prefix This command displays the down bit in the LSA router# show ip bgp vpnv4 vrf name prefix [mask] This command displays the OSPF-specific extended BGP communities 2000, Cisco Systems, Inc. Page-35 The majority of OSPF-related show commands will display MPLS VPN-specific OSPF parameters on the PE-routers. The show ip bgp vpnv4 vrf name prefix mask command will also display detailed information on the MP-BGP route including the extended BGP route communities. Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-31

286 show ip ospf Router#show ip ospf Routing Process "ospf 250" with ID Supports only single TOS(TOS0) routes Supports opaque LSA Connected to MPLS VPN Superbackbone It is an area border and autonomous system boundary router Redistributing External Routes from, bgp 1, includes subnets in redistribution 2000, Cisco Systems, Inc. Page-36 The show ip ospf command displays whether the router is a PE-router (and thus connected to the MPLS VPN super-backbone). A PE-router is always an area border router (ABR) or an AS boundary router (ASBR) Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

287 show ip ospf type prefix Router#show ip ospf database summary OSPF Router with ID ( ) (Process ID 250) Summary Net Link States (Area 0) LS age: 1298 Options: (No TOS-capability, DC, Downward) LS Type: Summary Links(Network) Link State ID: (summary Network Number) Advertising Router: LS Seq Number: Checksum: 0x5C2F Length: 28 Network Mask: /24 TOS: 0 Metric: , Cisco Systems, Inc. Page-37 The show ip ospf database type prefix command displays the status of the down bit. If the down bit is set, you will see the keyword Downward displayed in the Options field of the LSA. If the bit is not set, the keyword Upward will be displayed. Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-33

288 show ip bgp vpnv4 vrf name prefix Router#show ip bgp vpnv4 vrf Customer_A BGP routing table entry for 1:10: /24, version 64 Paths: (1 available, best #1, table Customer_A) Advertised to non peer-group peers: Local from ( ) Origin incomplete, metric 2, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:100:27 OSPF RT:0:3:0 2000, Cisco Systems, Inc. Page-38 The show ip bgp vpnv4 vrf customer prefix command displays all details of a MP-BGP route, including the OSPF extended BGP community. In the printout above, the route redistributed into MP-BGP from OSPF was a summary route (LSA type 3) redistributed from OSPF area Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

289 Summary The OSPF process in a VRF is started with the router ospf process vrf name command. As the overall number of routing processes per router is limited to 32, a single PE-router can serve only a small number of VRFs. Two-way redistribution between BGP and OSPF is usually configured. The redistribution is safe because of additional attributes introduced with the superbackbone architecture. By default, only major networks are redistributed into OSPF. Redistribution of subnets needs to be configured with the redistribute subnets command. By default, only internal OSPF routes are redistributed from OSPF into MP-BGP. Redistribution of external routes has to be configured with the redistribute match route-type-list command. The show ip ospf command will display whether a router is a PE-router connected to the MPLS VPN backbone. The detailed printouts from the show ip ospf database command will display the value of the down bit. The detailed printouts from the show ip bgp command will display the OSPF-specific extended BGP community. Review Questions How can you verify if an OSPF route was received from a local OSPF router or through an MPLS VPN backbone? How can you verify if your router is participating in an OSPF superbackbone? How can you display OSPF-related extended communities attached to a route? Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-35

290 Summary After completing this chapter, you should be able to perform the following tasks: Describe OSPF operation inside a VPN Describe the enhanced OSPF hierarchical model Describe the interactions between OSPF and MP-BGP Use OSPF as the PE-CE routing protocol in a complex MPLS VPN environment 4-36 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.

291 Answers to Review Questions Using OSPF as the PE-CE Protocol in an MPLS VPN Environment Why is the OSPF super-backbone needed in MPLS VPN environments? The super-backbone is needed to ensure that the internal OSPF routes are not inserted as external OSPF routes into other customer sites. What is the interaction between Area 0 and a super-backbone? The super-backbone appears as just another OSPF area to the routers in the OSPF backbone area (area 0). What is the interaction between a super-backbone and other areas? The super-backbone appears as area 0 (backbone area) to non-backbone OSPF routers. How are OSPF route attributes propagated across MPLS VPN backbone? OSPF area, route type, and metric type are propagated in an extended BGP community. OSPF cost or external metric is propagated in the BGP MED attribute. What is the purpose of the Down bit in an LSA header? The down bit prevents redistribution loops between MP-BGP and OSPF. It also ensures proper route selection in the PE-routers. What is the influence of the Down bit on the route selection process? Why is this influence needed? OSPF routes with the Down bit set are never entered in the routing table. This ensures that the MP-IBGP routes from which the OSPF routes were derived will be used for packet forwarding even though the IBGP routes have a higher administrative distance than the OSPF routes. Configuring and Monitoring OSPF in an MPLS VPN Environment How can you verify if your router is participating in an OSPF superbackbone? Use the show ip ospf command. How can you display OSPF-related extended communities attached to a route? Use the show ip bgp vpnv4 vrf name prefix command. Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-37

292 4-38 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.