Professional Documents
Culture Documents
Advanced MPLS
VPN Solutions
Volume 1
Version 1.0
Student Guide
Text Part Number: 97-0624-01
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 52.227-19. 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 252.227-7015 and DFARS 227.7202.
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
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 © 1981-1988, 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)
Volume 1
Copyright 2000, Cisco Systems, Inc. Advanced MPLS VPN Solutions vii
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
viii Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
xii Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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
1-2 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
Copyright 2000, Cisco Systems, Inc. Advanced MPLS VPN Solutions 1-3
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
1-4 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Prerequisites
This section lists the course prerequisites.
Prerequisites
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
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.
Participant Role
This section discusses your responsibilities as a student.
Participant Role
Student role
• Meet prerequisites
• Introduce yourself
• Ask and answer questions
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
Welcome: Please
Introduce Yourself
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.
General Administration
This section highlights miscellaneous administrative tasks that must be addressed.
General Administration
Class-related Facilities-related
• Sign-in sheet • Rest rooms
• Length and times • Site emergency
• Participant materials procedures
• Attire • Break and lunch
room locations
• Communications
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, e-mail, and fax messages
Copyright 2000, Cisco Systems, Inc. Advanced MPLS VPN Solutions 1-9
Sources of Information
This section identifies additional sources of information.
Sources of Information
• Student kit
• www.cisco.com
• CD-ROMs
• Cisco Press
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:
http://www.cisco.com
Cisco Press books and documents can be found at the following URL:
http://www.ciscopress.com
1-10 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Course Syllabus
MPLS VPN
Migration Strategies
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
■ 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.
2
Overview
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
Objectives
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
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.
Traditional Router-Based
Networks
Site B
Site A
Site C
Site D
PE device
CPE router
Customer site
Provider core
device Other
CPE router customer
Customer Premises Provider edge device PE device routers
router (CPE) (Frame Relay switch) Large customer site
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.
VPN Terminology
Customer site
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).
Customer site
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.
VPN Terminology
Specific to Switched WAN
Virtual Circuit (VC) #1
PE device
CPE router
Customer site
Provider core
device Other
CPE router customer
Customer Premises Provider edge device PE device routers
Router (CPE) (Frame Relay switch) Large customer site
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.
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
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.
2-10 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Overlay VPN Implementation
(Frame Relay Example)
Customer Site Virtual Circuit (VC) #2 Customer Site
Router A Router C
Provider Edge Device Frame Relay
(VC) #1 (Frame Relay Switch) Edge Switch
Customer Site Customer Site
Router B Router D
Frame Relay Frame Relay
Edge Switch Edge Switch
Virtual Circuit (VC) #3
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.
Router A
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.
2-12 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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.
IP
2-14 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Overlay VPN
IP Tunneling
Internet Protocol (IP)
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.
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.
Peer-to-Peer VPN Concept
Routing information is exchanged between
customer and service-provider routers
Service Provider Network Customer Site
Customer Site
Router A Router C
Provider Edge (PE)
(PE) Router
Router Customer Site
Customer Site
Router B Router D
Shared router
Customer A
Site #2 POP router carries all
customer routes
Isolation between
customers is achieved
Customer B
Site #1 with packet filters on
PE-CE interfaces
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.
2-18 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Peer-to-Peer VPN with
Controlled Route Distribution
Customer A Service provider network The P-router contains all
Site #1
customer routes
Point-of-Presence
Uplink
PE-router
Customer A Customer-A
P-router
Site #2
PE-router
Customer-B
Customer B
Site #1 Each customer has a
dedicated PE router that
only carries its routes
Note Default routes used anywhere in the customer or Service Provider network break
isolation between the customers and have to be avoided.
2-20 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Drawbacks of Various VPN
Implementations
Overlay VPN Peer-to-Peer VPN
• Implementing optimum • Service Provider
routing requires full- participates in customer
mesh of virtual circuits routing
• Virtual circuits have to • SP becomes responsible
be provisioned manually for customer
• Bandwidth must be convergence
provisioned on a site-to- • PE routers carry all
site basis routes from all
• Always incurs customers
encapsulation overhead • SP needs detailed IP
routing knowledge
2-22 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Summary
VPN Taxonomy
Virtual Networks
Virtual Private Virtual Dialup Networks Virtual LANs
Networks
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 point-
to-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).
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.
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
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 CE-
routers 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 hub-
and-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).
2-26 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Overlay VPN
Hub-and-Spoke Topology
Remote site (spoke)
Central site
router Remote site (spoke)
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, split-
horizon must be disabled at the hub router, or you must use point-to-point sub-
interfaces at the hub router to overcome the split-horizon problem.
Central site
(HUB)
Service Provider Network Remote site (spoke)
Redundant
Central site Remote site (spoke)
router
Redundant
Remote site (spoke)
Central site
router
2-28 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Overlay VPN
Partial Mesh
Berlin Sydney
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
Redundant central
site router
Service Provider Network Remote site (spoke)
Redundant central
site router
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.
2-30 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
VPN Business Categorization
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.
Extranet VPN—
Overlay VPN Implementation
Frame Relay Virtual
Circuits (DLCI)
Firewall BoltsAndNuts
Frame Relay
switch
Firewall Firewall
Frame Relay
switch
2-32 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Extranet VPN—Peer-to-Peer
VPN Implementation
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.
2-34 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Central Services Extranet
Amsterdam Service provider Extranet Customer A
Infrastructure
VoIP GW
London Customer B
VoIP GW
Paris Customer C
VoIP GW
The network diagram shown above describes an interesting scenario where peer-
to-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 PE-
routers 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.
2-36 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Managed Network
Overlay VPN Implementation
Service provider network Remote site (spoke)
Redundant central
site router
Remote site (spoke)
Redundant central
site router
Dedicated Virtual
Circuits are used for
Network Management Center network management
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.
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)
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.
2-40 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
MPLS VPN Terminology
Customer A
Site #1
Remote
Office
Site #1
P-Network Customer A
Remote CE router Site #4
Office
Customer B
Customer A PE-Router P-Router PE-Router
Site #2
Site #2 POP-X POP-Y
Customer A Customer B
Site #3 Site #3
Customer B Customer B
Site #1 Site #4
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.
PE-router
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.
2-42 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Routing Information Propagation
Across P-Network
Customer B Customer C
PE-Router-X P-Router PE-Router-Y
P-Network
Customer C Customer A
Wrong answer:
• The solution does not scale.
• P-routers carry all customer routers.
© 2000, Cisco Systems, Inc. www.cisco.com 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 point-
to-point tunnels (and the per-customer routing protocols would run between PE-
routers) 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.
Customer B Customer C
PE-Router-X P-Router PE-Router-Y
P-Network
Customer C Customer A
2-44 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Routing Information Propagation
Across P-Network
A dedicated routing protocol used
to carry customer routes between PE routers
Customer A Customer B
Customer B Customer C
PE-Router-X P-Router PE-Router-Y
P-Network
Customer C Customer A
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.
Customer B Customer C
PE-Router-X P-Router PE-Router-Y
P-Network
Customer C Customer A
Conclusion:
BGP is used to exchange customer routes directly between PE routers.
© 2000, Cisco Systems, Inc. www.cisco.com 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.
Routing Information Propagation
Across P-Network
A dedicated routing protocol used
to carry customer routes between PE routers
Customer A Customer B
Customer B Customer C
PE-Router-X P-Router PE-Router-Y
P-Network
Customer C 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.
Route Distinguisher (RD) is a 64-bit prefix that is only used to transform non-
unique 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 multi-
protocol 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.
2-48 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
Customer-A Customer-A
PE-1 PE-2
Customer-B Customer-B
The customer route propagation across MPLS VPN network is performed in the
following steps:
Step 1 CE-router sends an IPv4 routing update to the PE-router
Step 2 PE-router prepends 64-bit route distinguisher to the IPv4 routing update, resulting
in globally unique 96-bin VPNv4 prefix
Step 3 The VPNv4 prefix is propagated via Multi-Protocol Internal BGP (MP-IBGP)
session to other PE-routers
P-network
Customer-A Customer-A
PE-1 PE-2
Customer-B Customer-B
Step 4 The receiving PE-routers strip the route distinguisher from the VPNv4 prefix,
resulting in IPv4 prefix
Step 5 The IPv4 prefix is forwarded to other CE-routers within an IPv4 routing update.
2-50 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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.
Customer A Customer A
Central Site PE-Router-X P-Router PE-Router-Y Site 2
Customer B Customer B
Site 2 Central Site
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
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 inter-
company 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.
2-52 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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-2
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
2-54 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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.
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.
2-56 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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.
2-58 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Sample VoIP Service
Virtual Routing Tables
Site A1 and A2 can share
Voice-over-IP VPN the same routing table
Customer A
Central Site A Site A-1 Site A-2
Central Site A needs its
POP-X own routing table
VoIP Gateway
Voice gateways can
share routing tables
POP-Y
VoIP Gateway Central Site B needs its
own routing table
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.
2-60 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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?
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.
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
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.
PE-router
CE-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. www.cisco.com 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 CE-
router and PE-router is limited to static routes, RIP version 2, OSPF and external
BGP.
2-64 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
MPLS VPN Routing
Overall Customer Perspective
BGP backbone
PE-router PE-router
CE-router
Site IGP Site IGP Site IGP
From the customer’s network designer, the MPLS VPN backbone looks like intra-
company 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.
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.
2-66 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
MPLS VPN Routing
PE-Router Perspective
MPLS VPN Backbone
CE-router MP-BGP 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 multi-
protocol IBGP sessions
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.
2-68 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Routing tables on PE-Routers
MPLS VPN Backbone
CE-routerVPN routing MP-BGP VPN routing CE-router
IPv4 update
PE-router P-router PE-router
CE-router CE-router
The PE-routers receive IPv4 routing updates from the CE-routers and install them
in appropriate Virtual Routing and Forwarding table.
2-70 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
MPLS VPN End-to-End
Routing Information Flow (2/3)
MPLS VPN Backbone
CE-router CE-router
CE-router CE-router
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.
2-72 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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)
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:
2-74 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Extended BGP Community
Display Format
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.
MP-BGP update
PE-router P-router PE-router
CE-router CE-router
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.
2-76 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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.
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.
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
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?
Wrong answer:
• P-routers do not have VPN routes, packet is dropped on IP lookup.
• How about using MPLS for packet propagation across backbone?
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 VPN-
aware.
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 IP-
packets. 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.
2-80 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
VPN Packet Forwarding Across
MPLS VPN Backbone
MPLS VPN Backbone
IP L1 IP L2 IP L3
CE-router 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?
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. www.cisco.com 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.
2-82 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
VPN Packet Forwarding
Penultimate Hop Popping
MPLS VPN Backbone
IP V L1 IP V L2 IP V
CE-router CE-router
IP
IP
Ingress-PE P-router P-router Egress-PE
CE-router CE-router
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 PE-
router; even without the penultimate hop popping.
Note Please refer to MPLS Technology chapter for more information on penultimate hop
popping.
CE-router CE-router
Q: How will the ingress PE-router get the second label in the label stack
from the egress PE-router?
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.
2-84 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
The following slides illustrate the VPN label propagation between PE-routers.
CE-router CE-router
Step #1: VPN label is assigned to every VPN route by the egress
PE router
Egress-PE#show
Egress-PE#show tag-switching
tag-switching forwarding
forwarding vrf
vrf SiteA2
SiteA2
Local
Local Outgoing
Outgoing Prefix
Prefix Bytes
Bytes tag
tag Outgoing
Outgoing Next
Next Hop
Hop
tag
tag tag
tag or
or VC
VC or
or Tunnel
Tunnel Id
Id switched
switched interface
interface
26
26 Aggregate
Aggregate 150.1.31.36/30[V]
150.1.31.36/30[V] 00
37
37 Untagged
Untagged 203.1.2.1/32[V]
203.1.2.1/32[V] 00 Se1/0.20
Se1/0.20 point2point
point2point
38
38 Untagged
Untagged 203.1.20.0/24[V]
203.1.20.0/24[V] 00 Se1/0.20
Se1/0.20 point2point
point2point
Step 1 Egress PE-routers assign a label to every VPN route received from attached CE-
routers and to every summary route summarized inside the PE-router. This label is
then used as the second label in the MPLS label stack by the ingress PE-routers
when labeling VPN packets.
The VPN labels assigned locally by the PE-router can be inspected with the show
tag-switching forwarding vrf command.
CE-router CE-router
Ingress-PE#show
Ingress-PE#show ip
ip bgp
bgp vpnv4
vpnv4 all
all tags
tags
Network
Network Next
Next Hop
Hop In
In tag/Out
tag/Out tag
tag
Route
Route Distinguisher:
Distinguisher: 100:1
100:1 (vrf1)
(vrf1)
12.0.0.0
12.0.0.0 10.20.0.60
10.20.0.60 26/notag
26/notag
10.20.0.60
10.20.0.60 26/notag
26/notag
203.1.20.0
203.1.20.0 10.15.0.15
10.15.0.15 notag/38
notag/38
Step 2 VPN labels assigned by the egress PE-routers are advertised to all other PE-
routers 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 PE-
routers (and the output label was assigned by the remote PE-router).
For example, the VPN label for destination 203.1.20.0 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.
2-86 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
VPN Label Propagation
MPLS VPN Backbone
CE-router CE-router
CE-router CE-router
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 PE-
router 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.
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 next-
hop (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 12.2.
2-88 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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.
IP
Ingress-PE P-router P-router Egress-PE
P-router summarizes
CE-router PE loopback
CE-router
Penultimate hop popping is
requested through LDP
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.
2-90 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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 PE-
router
■ The second label in the stack is the VPN label assigned by the egress PE-
router 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-hop-
self 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?
2-92 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Answers to Review Questions
2-94 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
■ 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.
2-96 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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.
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
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-3
Need for routing protocol
contexts
VPN A
10.1.1.0/24
• Two VPNs with overlapping addresses
RI
P MPLS/VPN backbone
CE-VPN-A
VPN B
RIP PE router
CE-VPN-B
• RIP is running in both VPNs
10.1.1.0/24
• RIP in VPN-A has to be different from
RIP in VPN-B, but IOS only supports one
RIP process per router
3-4 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
VPN-Aware Routing Protocols
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
VRF Routing Table
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.
Routing Contexts, VRF and
MP-BGP Interaction: 1/9
RIP routing process VRF-A routing table BGP routing process
Instance for VRF-A Backbone
CE-RIP-A Multi-protocol
BGP
Instance for VRF-B VRF-B routing table
CE-RIP-B
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
Routing Contexts, VRF and
MP-BGP Interaction: 2/9
RIP routing process VRF-A routing table BGP routing process
Instance for VRF-A Backbone
CE-RIP-A Multi-protocol
BGP
Instance for VRF-B VRF-B routing table
CE-RIP-B
3-8 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Routing Contexts, VRF and
MP-BGP Interaction: 3/9
RIP routing process VRF-A routing table BGP routing process
Instance for VRF-A Backbone
CE-RIP-A Multi-protocol
BGP
Instance for VRF-B VRF-B routing table
CE-RIP-B
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-9
Routing Contexts, VRF and
MP-BGP Interaction: 4/9
RIP routing process VRF-A routing table BGP routing process
Instance for VRF-A Backbone
CE-RIP-A Multi-protocol
BGP
Instance for VRF-B VRF-B routing table
CE-RIP-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. www.cisco.com 12
Failure to redistribute non-BGP routes into per-VRF instance of BGP is one of the most
common MPLS/VPN configuration failures.
3-10 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Routing Contexts, VRF and
MP-BGP Interaction: 5/9
RIP routing process VRF-A routing table BGP routing process
Instance for VRF-A Backbone
CE-RIP-A Multi-protocol
BGP
Instance for VRF-B VRF-B routing table
CE-RIP-B
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
Routing Contexts, VRF and
MP-BGP Interaction: 6/9
RIP routing process VRF-A routing table BGP routing process
Instance for VRF-A Backbone
CE-RIP-A Multi-protocol
BGP
Instance for VRF-B VRF-B routing table
CE-RIP-B
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.
3-12 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Routing Contexts, VRF and
MP-BGP Interaction: 7/9
RIP routing process VRF-A routing table BGP routing process
Instance for VRF-A Backbone
CE-RIP-A Multi-protocol
BGP
Instance for VRF-B VRF-B routing table
CE-RIP-B
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
Routing Contexts, VRF and
MP-BGP Interaction: 8/9
RIP routing process VRF-A routing table BGP routing process
Instance for VRF-A Backbone
CE-RIP-A Multi-protocol
BGP
Instance for VRF-B VRF-B routing table
CE-RIP-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 end-
to-end RIP routing between CE routers
© 2000, Cisco Systems, Inc. www.cisco.com 16
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.
3-14 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Routing Contexts, VRF and
MP-BGP Interaction: 9/9
RIP routing process VRF-A routing table BGP routing process
Instance for VRF-A Backbone
CE-RIP-A Multi-protocol
BGP
Instance for VRF-B VRF-B routing table
CE-RIP-B
• Routes redistributed from BGP into a VRF instance of RIP are sent to
RIP-speaking CE routers
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
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.
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
Configuring 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.
3-18 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Creating VRF and Assigning
Route Distinguisher
router(config)#
ip vrf name
router(config-vrf)#
rd route-distinguisher
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
rd
To create routing and forwarding tables for a VRF, use the rd command in VRF
submode.
rd route-distinguisher
Syntax Description
route-distinguisher Adds an 8-byte value to an IPv4 prefix to create a VPN
IPv4 prefix.
Defaults
There is no default. An RD must be configured for a VRF to be functional.
3-20 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Specify Export and Import
Route Targets
router(config-vrf)#
route-target export RT
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.
Syntax Description
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)
Defaults
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-21
Specify Export and Import
Route Targets
router(config-vrf)#
route-target both RT
ip vrf Customer_ABC
rd 12703:15
route-target export 12703:15
route-target import 12703:15
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:15.
3-22 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Assigning an Interface to VRF
router(config-if)#
ip vrf forwarding vrf-name
ip cef
!
interface serial 0/0
ip vrf forwarding Customer_ABC
ip address 10.0.0.1 255.255.255.252
ip vrf forwarding
Syntax Description
vrf-name Name assigned to a VRF.
Defaults
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-23
Sample VPN Network
MPLS/VPN backbone
CE-RIP-A1 CE-RIP-A2
CE-BGP-A1 CE-BGP-A2
PE-Site-X PE-Site-Y
CE-RIP-B1 CE-RIP-B2
3-24 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Sample VPN Network
VRF Configuration
MPLS/VPN backbone
ip vrf Customer_A
CE-RIP-A1 rd 115:43 CE-RIP-A2
route-target both 115:43
!
ip vrf Customer_B
CE-BGP-A1 rd 115:47 CE-BGP-A2
PE-Site-X PE-Site-Y
route-target both 115:47
!
CE-RIP-B1 interface serial 1/0/1 CE-RIP-B2
ip forwarding vrf Customer_A
ip address 10.1.0.1 255.255.255.252
!
interface serial 1/0/2
ip vrf forwarding Customer_A
ip address 10.1.0.5 255.255.255.252
!
interface serial 1/1/3
ip vrf forwarding Customer_B
ip address 10.2.0.1 255.255.255.252
© 2000, Cisco Systems, Inc. www.cisco.com 28
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-25
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.
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
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
The MPLS/VPN architecture uses BGP routing protocol in two different ways:
■ VPNv4 routes are propagated across a MPLS/VPN backbone using multi-
protocol 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.
3-28 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Selecting BGP Address Family
router(config)#
router bgp as-number
router(config-router)#
address-family vpnv4
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.
Syntax Description
Default
No BGP routing process is enabled by default.
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-29
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
IPv4 unicast
Syntax Description
ipv4 Configures sessions that carry standard IPv4 address prefixes.
vpnv4 Configures sessions that carry customer VPN-IPv4 prefixes, each
of which has been made globally unique by adding an 8-byte
route distinguisher.
unicast (Optional) Specifies unicast prefixes.
vrf vrf-name Specifies the name of a VPN routing/forwarding instance (VRF)
to associate with submode commands.
3-30 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
BGP Neighbors
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-31
Configuring MP-BGP
Note IPv4-specific BGP parameters are still configured under the BGP router
configuration mode – there is no special IPv4 address family.
3-32 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Configuring MP-IBGP
router(config)#
router bgp AS-number
neighbor IP-address remote-as AS-number
neighbor IP-address update-source loopback-interface
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.
Syntax Description
ip-address Neighbor's IP address.
peer-group-name Name of a BGP peer group.
number 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
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
Syntax Description
ip-address IP address of the BGP-speaking neighbor.
peer-group-name Name of a BGP peer group.
interface Loopback interface.
Default
Best local address
3-34 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Configuring MP-IBGP
router(config-router-af)#
neighbor IP-address activate
router(config-router-af)#
neighbor IP-address next-hop-self
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 BGP-
speaking 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.
Syntax Description
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
neighbor next-hop-self
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.
Syntax Description
Default
Disabled
3-36 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Configuring MP-EBGP
router(config)#
router bgp AS-number
neighbor IP-address remote-as another-AS-number 12.1(4)T
Multi-protocol EBGP session is configured in exactly the same way as the multi-
protocol 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
Configuring EBGP Propagation
of all VPNv4 Routes
router(config-router)#
no bgp default route-target filter 12.1(4)T
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.
Default
This feature is enabled by default.
3-38 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Configuring MP-BGP
BGP Community Propagation
router(config-router-af)#
neighbor IP-address send-community [extended | both]
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. www.cisco.com 41
neighbor send-community
Default
No COMMUNITIES attribute is sent to any neighbor.
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-39
Sample VPN Network
MP-IBGP Configuration
MPLS/VPN backbone
CE-RIP-A1 CE-RIP-A2
CE-BGP-A1 CE-BGP-A2
PE-Site-X PE-Site-Y
interface loopback 0
CE-RIP-B1 ip address 172.16.1.1 255.255.255.255 CE-RIP-B2
!
router bgp 115
neighbor 172.16.1.2 remote-as 115
neighbor 172.16.1.2 update-source loopback 0
!
address-family vpnv4
neighbor 172.16.1.2 activate
neighbor 172.16.1.2 next-hop-self
neighbor 172.16.1.2 send-community both
© 2000, Cisco Systems, Inc. www.cisco.com 42
3-40 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Configuring MP-BGP
Disabling IPv4 Route Exchange
router(config-router)#
no bgp default ipv4 unicast
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
Sample Router Configuration
• Neighbor 172.16.32.14 shall receive only Internet routes
• Neighbor 172.16.32.15 shall receive only VPNv4 routes
• Neighbor 172.16.32.27 shall receive Internet and VPNv4 routes
router bgp 12703
no bgp default ipv4 unicast
neighbor 172.16.32.14 remote-as 12703
neighbor 172.16.32.15 remote-as 12703
neighbor 172.16.32.27 remote-as 12703
! Activate IPv4 route exchange
neighbor 172.16.32.14 activate
neighbor 172.16.32.27 activate
! Step#2 – VPNv4 route exchange
address-family vpnv4
neighbor 172.16.32.15 activate
neighbor 172.16.32.27 activate
© 2000, Cisco Systems, Inc. www.cisco.com 44
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.
3-42 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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.
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 32
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.
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
Selecting VRF Routing
Context for BGP and RIP
router(config)#
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 ...
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
This command has no arguments or keywords.
Default
No RIP routing process is defined.
3-46 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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
Sample VPN Network
PE-CE BGP Configuration
router bgp 65001
MPLS/VPN backbone
neighbor 10.200.1.2 remote-as 115
CE-RIP-A1 network 10.1.0.0 mask 255.255.0.0
CE-RIP-A2
CE-BGP-A1 CE-BGP-A2
PE-Site-X PE-Site-Y
CE-RIP-B1 CE-RIP-B2
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.
3-48 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
Configuring RIP as the PE-CE routing protocol is even simpler than configuring
BGP. You start the configuration of individual routing context with the address-
family 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
RIP Metric Propagation
router(config)#
router rip
address-family ipv4 vrf vrf-name
redistribute bgp metric transparent
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.
3-50 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Sample VPN Network
RIP Configuration
MPLS/VPN backbone
CE-RIP-A1 CE-RIP-A2
CE-BGP-A1 CE-BGP-A2
PE-Site-X PE-Site-Y
router rip
CE-RIP-B1 CE-RIP-B2
version 2
address-family ipv4 vrf Customer_ABC
network 10.0.0.0
redistribute bgp 12703 metric transparent
!
router bgp 12703
address-family ipv4 vrf Customer_ABC
redistribute rip
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-51
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
3-52 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Configuring PE-CE OSPF
Routing
router(config)#
router ospf process-id vrf name
... Standard OSPF parameters ...
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.
Syntax Description
process-id 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.
vrf-name 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
Configuring Per-VRF
Static Routes
router(config)#
ip route vrf name static route parameters
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.
Syntax Description
3-54 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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.
Monitoring VRF
router#
show ip vrf
router#
show ip vrf detail
router#
show ip vrf interfaces
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.
Syntax Description
brief (Optional) Displays concise information on the VRF(s) and
associated interfaces.
detail (Optional) Displays detailed information on the VRF(s) and
associated interfaces.
interfaces (Optional) Displays detailed information about all interfaces
bound to a particular VRF, or any VRF.
vrf-name (Optional) Name assigned to a VRF.
output-modifiers (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
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#
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.
Field Description
Name Specifies the VRF name.
Default RD Specifies the default route distinguisher.
Interfaces Specifies the network interfaces.
3-58 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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.
Field Description
Interfaces Specifies the network interfaces.
Export Specifies VPN route-target export communities.
Import Specifies VPN route-target import communities.
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-59
show ip vrf interfaces
To display the interfaces bound to a particular VRF (or interfaces bound to any
VRF), use the show ip vrf interfaces command, which displays the fields
described in the following table.
Field Description
Interface Specifies the network interfaces for a VRF.
IP-Address Specifies the IP address of a VRF interface.
VRF Specifies the VRF name.
Protocol Displays the state of the protocol (up/down) for each VRF
interface.
3-60 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Monitoring VRF Routing
router#
show ip protocol vrf name
router#
show ip route vrf name …
router#
show ip bgp vpnv4 vrf name …
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
To display the routing protocol information associated with a VRF, use the show
ip protocols vrf command in EXEC mode.
Syntax Description
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-61
show ip route vrf
Syntax Description
To display VPN address information from the BGP table, use the show ip bgp
vpnv4 command in EXEC mode.
Syntax Description
3-62 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
output-modifiers (Optional) For a list of associated keywords and
arguments, use context-sensitive help.
network-address (Optional) IP address of a network in the BGP routing
table.
mask (Optional) Mask of the network address, in dotted
decimal format.
cidr-only (Optional) Displays only routes that have non-natural net
masks.
community (Optional) Displays routes matching this community.
community-list (Optional) Displays routes matching this community list.
dampened-paths (Optional) Displays paths suppressed on account of
dampening (BGP route from peer is up and down).
filter-list (Optional) Displays routes conforming to the filter list.
flap-statistics (Optional) Displays flap statistics of routes.
inconsistent-as (Optional) Displays only routes that have inconsistent
autonomous systems of origin.
neighbors (Optional) Displays details about TCP and BGP neighbor
connections.
paths (Optional) Displays path information.
line (Optional) A regular expression to match the BGP AS
paths.
peer-group (Optional) Displays information about peer groups.
quote-regexp (Optional) Displays routes matching the AS path "regular
expression."
regexp (Optional) Displays routes matching the AS path “regular
expression.”
summary (Optional) Displays BGP neighbor status.
tags (Optional) Displays incoming and outgoing BGP labels
for each NLRI.
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-63
show ip protocol vrf
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 Description
Gateway Displays the IP address of the router identifier for all routers in
the network.
Distance Displays the metric used to access the destination route.
Last update Displays the last time the routing table was updated from the
source.
3-64 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
… rest deleted …
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
show ip bgp vpnv4 vrf
neighbor
Router#show ip bgp vpnv4 vrf SiteB neighbor
BGP neighbor is 150.1.32.34, vrf SiteB, remote AS 65032, external link
BGP version 4, remote router ID 203.2.10.1
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
… rest deleted …
To display BGP neighbors configured in a VRF, use the show ip bgp vpnv4 vrf
neighbors privileged EXEC command.
Syntax Description
vpnv4 Specifies VPN IPv4 information.
all Displays all VPN BGP neighbors
vrf vrf-name Displays neighbors associated with the named VRF.
neighbors Displays details on TCP and BGP neighbor connections.
Defaults
Usage Guidelines
3-66 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Monitoring MP-BGP Sessions
router#
show ip bgp neighbor
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
show ip bgp neighbor
... Continued
Syntax Description
address (Optional) Address of the neighbor whose routes you
have learned from. If you omit this argument, all
neighbors are displayed.
received-routes (Optional) Displays all received routes (both accepted
and rejected) from the specified neighbor.
routes (Optional) Displays all routes that are received and
accepted. This is a subset of the output from the
received-routes keyword.
advertised-routes (Optional) Displays all the routes the router has
advertised to the neighbor.
paths regular-expression (Optional) Regular expression that is used to match
the paths received.
dampened-routes (Optional) Displays the dampened routes to the
neighbor at the IP address specified.
3-68 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Examples
The following is sample output from the show ip bgp neighbors command:
Router# show ip bgp neighbors 171.69.232.178
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
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-69
Field Description
BGP neighbor 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 BGP version being used to communicate with the remote router;
the neighbor's router ID (an IP address) is also specified.
BGP state Internal state of this BGP connection.
table version Indicates that the neighbor has been updated with this version of
the primary BGP routing table.
up for Amount of time that the underlying TCP connection has been in
existence.
Last read Time that BGP last read a message from this neighbor.
hold time Maximum amount of time that can elapse between messages from
the peer.
keepalive interval Time period between sending keepalive packets, which help
ensure that the TCP connection is up.
Received Number of total BGP messages received from this peer, including
keepalives.
notifications Number of error messages received from the peer.
Sent Total number of BGP messages that have been sent to this peer,
including keepalives.
notifications Number of error messages the router has sent to this peer.
Connections Number of times the router has established a TCP connection and
established the two peers have agreed speak BGP with each other.
dropped Number of times that a good connection has failed or been taken
down.
Connection state State of BGP peer.
unread input bytes Number of bytes of packets still to be processed.
Local host, Local Peering address of local router, plus port.
port
Foreign host, Neighbor's peering address.
Foreign port
Event Timers Table displays the number of starts and wakeups for each timer.
iss Initial send sequence number.
snduna Last send sequence number the local host sent but has not
received an acknowledgment for.
sndnxt Sequence number the local host will send next.
sndwnd TCP window size of the remote host.
irs Initial receive sequence number.
rcvnxt Last receive sequence number the local host has acknowledged.
rcvwnd Local host's TCP window size.
delrecvwnd 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.
SRTT A calculated smoothed round-trip timeout.
RTTO Round-trip timeout.
RTV Variance of the round-trip time.
KRTT New round-trip timeout (using the Karn algorithm). This field
separately tracks the round-trip time of packets that have been
retransmitted.
3-70 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Field Description
minRTT Smallest recorded round-trip timeout (hard wire value used for
calculation).
maxRTT Largest recorded round-trip timeout.
ACK hold Time the local host will delay an acknowledgment in order to
piggyback data on it.
Flags IP precedence of the BGP packets.
Datagrams: Rcvd Number of update packets received from neighbor.
with data Number of update packets received with data.
total data bytes Total bytes of data.
Sent Number of update packets sent.
with data Number of update packets with data sent.
total data bytes Total number of data bytes.
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-71
show ip bgp neighbor
... Continued
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.
3-72 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Monitoring MP-BGP VPNv4
Table
router#
show ip bgp vpnv4 all
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
show ip bgp vpnv4 vrf …
To display VPNv4 information from the BGP database associated with a VRF, use
the show ip bgp vpnv4 vrf name privileged EXEC command.
Syntax Description
Defaults
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.
3-74 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
show ip bgp vpnv4 rd …
Router#show ip bgp vpnv4 rd 103:30 203.1.127.3
BGP routing table entry for 103:30:203.1.127.3/32, version 164
Paths: (1 available, best #1, table SiteA2)
Not advertised to any peer
Local, imported path from 103:10:203.1.127.3/32
192.168.3.101 (metric 10) from 192.168.3.101 (192.168.3.101)
Origin incomplete, metric 1, localpref 100, valid,
internal, best
Extended Community: RT:103:10
To display all VPNv4 routes that contain specified route distinguisher, use the
show ip bgp vpnv4 rd privileged EXEC command.
Syntax Description
rd route-distinguisher Displays NLRIs that have a matching route distinguisher.
Defaults
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
Monitoring per-VRF CEF and
LFIB Structures
router#
show ip cef vrf name
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.
3-76 Advanced MPLS VPN Solutions Copyright 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.
Syntax Description
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-77
glean Gleans adjacency.
null Null adjacency.
punt Punts adjacency.
non-recursive (Optional) Displays only non-recursive routes.
summary (Optional) Displays a CEF table summary.
traffic (Optional) Displays traffic statistics.
prefix-length (Optional) Displays traffic statistics by prefix size.
unresolved (Optional) Displays only unresolved routes.
Defaults
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.
3-78 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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 150.1.31.36/30[V] 0
37 Untagged 203.1.2.1/32[V] 0 Se1/0.20 point2point
38 Untagged 203.1.20.0/24[V] 0 Se1/0.20 point2point
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.
Syntax Description
Defaults
No default behavior or values.
Usage Guidelines
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
Monitoring Labels Associated
with VPNv4 Routes
router#
show ip bgp vpnv4 [ all | rd value | vrf name ] tags
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 Description
Network Displays the network address from the BGP table.
Next Hop Specifies the BGP next hop address.
In Tag Displays the label (if any) assigned by this router.
Out Tag Displays the label assigned by the BGP next hop router.
3-80 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Other MPLS/VPN Monitoring
Commands
router#
telnet host /vrf name
router#
ping vrf name …
router#
trace vrf name …
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-81
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.
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
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)
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.
3-84 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
MPLS/VPN Troubleshooting
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-85
MPLS/VPN Routing Information
Flow Troubleshooting - 1/7
P-network
CE-Spoke CE-Spoke
PE-1 PE-2
CE-Spoke CE-Spoke
3-86 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
MPLS/VPN Routing Information
Flow Troubleshooting - 2/7
P-network
CE-Spoke CE-Spoke
PE-1 PE-2
CE-Spoke CE-Spoke
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-87
MPLS/VPN Routing Information
Flow Troubleshooting - 3/7
P-network
CE-Spoke CE-Spoke
PE-1 PE-2
CE-Spoke CE-Spoke
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.
3-88 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
MPLS/VPN Routing Information
Flow Troubleshooting - 4/7
P-network
CE-Spoke CE-Spoke
PE-1 PE-2
CE-Spoke CE-Spoke
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-89
MPLS/VPN Routing Information
Flow Troubleshooting - 5/7
P-network
CE-Spoke CE-Spoke
PE-1 PE-2
CE-Spoke CE-Spoke
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.
3-90 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
MPLS/VPN Routing Information
Flow Troubleshooting - 6/7
P-network
CE-Spoke CE-Spoke
PE-1 PE-2
CE-Spoke CE-Spoke
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
MPLS/VPN Routing Information
Flow Troubleshooting - 7/7
P-network
CE-Spoke CE-Spoke
PE-1 PE-2
CE-Spoke CE-Spoke
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.
3-92 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
MPLS/VPN Troubleshooting
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
MPLS/VPN Data Flow
Troubleshooting - 1/4
P-network
CE-Spoke CE-Spoke
PE-1 PE-2
CE-Spoke CE-Spoke
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.
show cef interface
To display Cisco Express Forwarding (CEF) related interface information, use the
show cef interface command in EXEC mode.
Syntax Description
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.
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-95
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.
3-96 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
MPLS/VPN Data Flow
Troubleshooting - 2/4
P-network
CE-Spoke CE-Spoke
PE-1 PE-2
CE-Spoke CE-Spoke
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 next-
hop 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
MPLS/VPN Data Flow
Troubleshooting - 3/4
P-network
CE-Spoke CE-Spoke
PE-1 PE-2
CE-Spoke CE-Spoke
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 tag-
switching ip ttl-propagate command. The traceroute command toward BGP next-
hop 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.
3-98 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
MPLS/VPN Data Flow
Troubleshooting - 4/4
P-network
CE-Spoke CE-Spoke
PE-1 PE-2
CE-Spoke CE-Spoke
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
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 PE-
to-PE LSP?
■ How would you verify that the PE router ingress interface supports CEF
switching?
3-100 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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
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.
3-102 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Selective VRF Import
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
Configuring Selective
VRF import
router(config-vrf)#
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
import map
To configure an import route map for a VRF, use the import map command in
VRF submode.
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.
3-104 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Selective Import Example
Site A AS 115
VPN-IPv4 update:
AS 213 VPN-IPv4 update:
RD:192.168.30.3/32 RD:192.168.31.0/24
RT=115:317 RT=115:317
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
Selective Export
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 route-
map, but applied to a different VRF. Any requirement that can be implemented
with an export route-map can also be implemented with an import route-map, but
usually in a more awkward manner.
3-106 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Configuring Selective
VRF Export
router(config)#
route-map name permit seq
match condition
set extcommunity RT value [additive]
router(config-vrf)#
export map name
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.
Syntax Description
extcommunity-type Valid parameters are rt (Route Target) and soo (Site of
Origin).
extcommunity-number Valid parameter is entered in a x:y format where x can
either be an AS number (1-65535) and y is in the range
from 1 to 4294967200 or x is an IP address where y is in
the range from 1 to 65535.
additive (Optional) Adds the extended community to the already
existing extended communities.
Default
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-107
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.
Syntax Description
Default
3-108 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Selective Export Example
Site A AS 115
VPN-IPv4 update:
AS 213 VPN-IPv4 update:
RD:192.168.0.5/32 RD:192.168.30.0/24
RT=115:317 RT=115:317 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 192.168.30.0 0.0.0.0
!
route-map RTMAP permit 10
match ip address 10
set extcommunity rt 115:273 additive
© 2000, Cisco Systems, Inc. www.cisco.com 112
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
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
3-110 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Limiting the Number of Prefixes
Received from a BGP Neighbor
router(config-router-af)#
neighbor ip-address maximum-prefix maximum [threshold]
[warning-only]
neighbor maximum-prefix
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.
Syntax Description
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-111
VRF Route Limit
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 maximum-
prefix, 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.
3-112 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
maximum routes
Syntax Description
Defaults
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-113
VRF Route Limit Example
Site A AS 115
AS 213
VPN-IPv4 update: VPN-IPv4 update:
RD:192.168.60.0/24 RD:192.168.70.0/24
IPv4 update: IPv4 update: RT=100:1 RT=100:1
192.168.0.5/32
CE-BGP-A1 192.168.50.0/24
PE-Site-X PE-Site-Y
IPv4 update:
192.168.55.0/24 ip vrf Site_A
rd 115:317
route-target both 115:317
maximum-routes 4 75
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.
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.
3-114 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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
3-116 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Sample VPN Network
Reusing AS Number Across Sites
Site A P-Network Site B
AS 213 AS 115 AS 213
CE-BGP-A1 CE-BGP-A2
PE-Site-X PE-Site-Y
10.1.0.0/16 213 i 10.1.0.0/16 213 10.1.0.0/16 115 213
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
AS-Override Overview
3-118 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-119
Configuring AS-Override
router(config-router-af)#
neighbor ip-address as-override
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.
Syntax Description
Defaults
3-120 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
AS-Override in Action
router bgp 115
address-family ipv4 vrf Customer_A
neighbor 10.200.2.1 remote-as 213
neighbor 10.200.2.1 activate
neighbor 10.200.2.1 as-override
CE-BGP-A1 CE-BGP-A2
PE-Site-X PE-Site-Y
10.1.0.0/16 213 i 10.1.0.0/16 213 10.1.0.0/16 115 115
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
AS-Override with AS-Path
Prepending
router bgp 115
address-family ipv4 vrf Customer_A
neighbor 10.200.2.1 remote-as 213
neighbor 10.200.2.1 activate
neighbor 10.200.2.1 as-override
CE-BGP-A1 CE-BGP-A2
PE-Site-X PE-Site-Y
10.1.0.0/16 213 213 i 10.1.0.0/16 213 213 10.1.0.0/16 115 115 115
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.
3-122 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Sample VPN Network
Customer Site Linking two VPNs
VPN-A VPN-B
CE-BGP-A1
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
Customer Site Linking VPNs
Various Perspectives
VPN-A VPN-B
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.
3-124 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Customer Site Linking VPNs
BGP Loop Prevention Issues
VPN-A VPN-B
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
Allowas-in
3-126 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Configuring Allowas-in
router(config-router)#
neighbor ip-address allowas-in limit
neighbor allowas-in
Syntax Description
Defaults
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-127
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
Most aspects of BGP loop prevention are bypassed when you’re using either as-
override 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.
3-128 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Setting Site of Origin
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-129
Filters based on SOO
3-130 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Setting Site-of-Origin on
Inbound EBGP Update
router(config)#
route-map name permit seq
match conditions
set extcommunity soo value
router(config-router-af)#
neighbor ip-address route-map name in
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.
Syntax Description
extcommunity-type Valid parameters are rt (Route Target) and soo (Site of
Origin).
extcommunity-number Valid parameter is entered in a x:y format where x can
either be an AS number (1-65535) and y is in the range
from 1 to 4294967200 or x is an IP address where y is in
the range from 1 to 65535.
additive (Optional) Adds the extended community to the already
existing extended communities.
Default
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-131
Setting Site-of-Origin on Other
Inbound Routing Updates
router(config)#
route-map name permit seq
match conditions
set extcommunity soo value
router(config-if)#
ip vrf sitemap route-map-name
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.
Syntax Description
route-map-name Set the name of the route map to be used.
Default
3-132 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
Copyright 2000, Cisco Systems, Inc. MPLS/VPN Configuration on IOS Platforms 3-133
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?
3-134 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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
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.
Traditional OSPF Routing
Model
OSPF Area 0 (backbone area)
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
MPLS VPN Routing Model
BGP backbone
PE-router PE-router
CE-router
Site IGP Site IGP Site IGP
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.
OSPF-BGP Redistribution
Issue
OSPF route is redistributed into BGP
BGP backbone MP-BGP route is propagated
to other PE routers
MP-BGP route is
redistributed into OSPF
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
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. www.cisco.com 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.
OSPF-BGP Hierarchy Issue
BGP backbone
PE-router PE-router
Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-7
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. www.cisco.com 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.
MPLS VPN backbone as OSPF
Super-backbone
MPLS VPN backbone = OSPF super-backbone
ABR ABR
Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-9
OSPF Super-backbone
Route Propagation Example
PE-router propagates the route into
OSPF super-backbone super-backbone. Route summarization
can be performed on area boundary
ABR ABR
Inter-area route is
propagated into
other areas
4-10 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
OSPF Super-backbone Rules
Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-11
OSPF Super-backbone
Implementation
• Extended BGP communities are used to
propagate OSPF route type across BGP
backbone
• OSPF cost is copied into MED attribute
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.
4-12 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
OSPF Super-backbone
Implementation
BGP backbone
10.0.0.0/8
OSPF RT=1:1:0
MED=768
PE-router PE-router
10.0.0.0/8 10.0.0.0/8
LSA type 1 LSA type 3
OSPF cost 768 OSPF cost 768
Area 1 Area 2
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 PE-
router 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
OSPF Super-backbone
Propagation of External Routes
BGP backbone
10.0.0.0/8
OSPF RT=1:5:1
MED=20
PE-router PE-router
10.0.0.0/8 10.0.0.0/8
LSA type 5 LSA type 5
E2 metric 20 E2 metric 20
Area 1 Area 2
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.
4-14 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
OSPF Super-backbone
Mixing Routing Protocols
BGP backbone
10.0.0.0/8
MED=3
PE-router PE-router
10.0.0.0/8 10.0.0.0/8
Hop count 3 LSA type 5
E2 metric 20
RIP Area 2
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
OSPF-BGP Routing Loops
The OSPF route is received by a PE-router,
redistributed into MP-BGP and propagated
BGP backbone across the MPLS VPN backbone
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.
Step 1 The sending PE-router receives an intra-area OSPF route.
Step 2 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.
Step 3 Receiving PE-router redistributes the MP-BGP route into OSPF as an internal
inter-area summary route.
Step 4 The summary route is propagated across OSPF area and received by the other PE-
router attached to the same area.
Step 5 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.
4-16 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
OSPF Down Bit
Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-17
OSPF-BGP Interaction with
Down Bit
An OSPF route is received by a PE-router,
redistributed into MP-BGP and propagated
BGP backbone across the MPLS VPN backbone
The typical usage of the down bit is shown in the diagram above:
Step 1 PE-router receives an OSPF route
Step 2 PE-router redistributes OSPF route into MP-BGP. The MP-BGP route is
propagated to other PE-routers
Step 3 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.
Step 4 When the other PE-routers receive the summary LSA with the down bit set, they
do not redistribute the route back into MP-BGP.
4-18 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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 PE-router
Do The route is redistributed
w
n back into MP-BGP
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:
Step 1 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.
Step 2 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.
Step 3 The OSPF route is propagated through the other OSPF domain with the down bit
cleared.
Step 4 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
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 AS-
number 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. www.cisco.com 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.
4-20 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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 PE-
routers
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
Routing Loop Prevention with
OSPF Tag Field
A non-OSPF route is redistributed as an external
BGP backbone OSPF route into the OSPF domain by a PE router
AS number 6
The external OSPF route has the Down bit set and
the Tag field set to 6
The diagram above illustrates how the OSPF tag field could be used to prevent
routing loops when the redistribution is done between OSPF domains.
Step 1 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.
Step 2 The redistributed route is propagated across the OSPF domain.
Step 3 When the route is redistributed into another OSPF domain, the tag field is
propagated, but the down bit is cleared.
Step 4 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.
4-22 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Packet Forwarding through
MPLS VPN Backbone
Due to administrative distances,
BGP backbonean OSPF route is preferred over
an MP-IBGP route
Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-23
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. www.cisco.com 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.
4-24 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Packet Forwarding with Down
Bit Processing
The OSPF route is ignored
BGP backbone since the Down bit is set
With the new route OSPF selection rules in place, the packet forwarding in the
network shown above follows the desired path:
Step 1 The OSPF route is redistributed into MP-BGP by a PE-router and propagated to
other PE-routers.
Step 2 The receiving PE-routers redistribute the MP-BGP route into OSPF.
Step 3 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
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.
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
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
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.
4-28 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Per-VRF OSPF Configuration
router(config)#
router ospf process-id vrf name
... Standard OSPF parameters ...
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.
Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-29
Configuring Route
Redistribution
router(config)#
router bgp as-number
address-family ipv4 vrf vrf-name
redistribute ospf process-id [match [internal] [external-1] [external-2]]
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.
4-30 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
Monitoring OSPF in MPLS
VPN Environment
router#
show ip ospf
router#
show ip bgp vpnv4 vrf name prefix [mask]
Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-31
show ip ospf
Router#show
Router#show ip
ip ospf
ospf
Routing
Routing Process
Process "ospf
"ospf 250"
250" with
with ID
ID 10.2.3.4
10.2.3.4
Supports
Supports only
only single
single TOS(TOS0)
TOS(TOS0) routes
routes
Supports
Supports opaque
opaque LSA
LSA
Connected
Connected to
to MPLS
MPLS VPN
VPN Superbackbone
Superbackbone
It
It is
is an
an area
area border
border and
and autonomous
autonomous system
system boundary
boundary
router
router
Redistributing
Redistributing External
External Routes
Routes from,
from,
bgp
bgp 1,
1, includes
includes subnets
subnets in
in redistribution
redistribution
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).
4-32 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
show ip ospf type prefix
Router#show
Router#show ip
ip ospf
ospf database
database summary
summary 10.0.1.0
10.0.1.0
OSPF
OSPF Router
Router with
with ID
ID (10.4.3.2)
(10.4.3.2) (Process
(Process ID
ID 250)
250)
Summary
Summary Net
Net Link
Link States
States (Area
(Area 0)
0)
LS
LS age:
age: 1298
1298
Options:
Options: (No
(No TOS-capability,
TOS-capability, DC,
DC, Downward)
Downward)
LS
LS Type:
Type: Summary
Summary Links(Network)
Links(Network)
Link
Link State
State ID:
ID: 10.0.1.0
10.0.1.0 (summary
(summary Network
Network Number)
Number)
Advertising
Advertising Router:
Router: 10.2.3.4
10.2.3.4
LS
LS Seq
Seq Number:
Number: 80000002
80000002
Checksum:
Checksum: 0x5C2F
0x5C2F
Length:
Length: 28
28
Network
Network Mask:
Mask: /24
/24
TOS:
TOS: 00 Metric:
Metric: 7435
7435
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
show ip bgp vpnv4
vrf name prefix
Router#show
Router#show ip
ip bgp
bgp vpnv4
vpnv4 vrf
vrf Customer_A
Customer_A 10.0.1.0
10.0.1.0
BGP
BGP routing
routing table
table entry
entry for
for 1:10:10.0.1.0/24,
1:10:10.0.1.0/24, version
version 64
64
Paths:
Paths: (1
(1 available,
available, best
best #1,
#1, table
table Customer_A)
Customer_A)
Advertised
Advertised to
to non
non peer-group
peer-group peers:
peers:
10.2.3.6
10.2.3.6
Local
Local
10.2.3.4
10.2.3.4 from
from 0.0.0.0
0.0.0.0 (10.2.3.4)
(10.2.3.4)
Origin
Origin incomplete,
incomplete, metric
metric 2,
2, localpref
localpref 100,
100, weight
weight
32768,
32768, valid,
valid, sourced,
sourced, best
best
Extended
Extended Community:
Community: RT:100:27
RT:100:27 OSPF
OSPF RT:0:3:0
RT:0:3:0
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 0.
4-34 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.
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 super-
backbone 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 super-
backbone?
■ 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
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.
Answers to Review Questions
Copyright 2000, Cisco Systems, Inc. Using OSPF in an MPLS VPN Environment 4-37
4-38 Advanced MPLS VPN Solutions Copyright 2000, Cisco Systems, Inc.