MPLS VPN Configurations

MPLS VPN Configurations
Khalid Raza
CQFE rev17 Russ Davis © 1999, Cisco Systems, Inc. 1

Agenda
• Introduction to VPNs concepts

• VPN definitions
• Types of VPNs (Overlay/Peer)
• Comparison between Overlay and Peer model
• Benefits for MPLS VPNs
CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 2

Agenda
• Idea behind VRF, RD, RT

• Route propagation in MP-BGP
• Routing between PE-CE
• MPLS Packet Forwarding

Agenda
• MPLS configuration
VRF
MP-BGP
PE-CE configuration
Advance configuration

Agenda
• MPLS topologies
• VPN connectivity
• Design considerations
• Deployment strategies

VPN/MPLS Concepts
• VPN
Concept is to use the service providers shared
resources connecting multiple customer sites
Technologies such as X.25, Frame-relay which use
virtual circuits to establish end-to-end connection
using shared service of the provider infrastructure
This statistical sharing of resources enables the
service provider to offer low cost services to the
end user

VPN Terminology
• Provider Network (P-Network)

The backbone under control of a Service
Provider
• Customer Network (C-Network)
Network under customer control
• CE router
Customer Edge router. Part of the C-
network and interfaces to a PE router

VPN Terminology
• Site
Set of (sub)networks part of the C-network and co-
located
A site is connected to the VPN backbone through
one or more PE/CE links
• PE router
Provider Edge router. Part of the P-Network and
interfaces to CE routers
• P router
Provider (core) router, without knowledge of VPN

VPN Terminology
Provider core
(P) device VPN Site
CPE (CE) CPE (CE)

Provider Edge Provider Edge
Device Device
(PE) device (PE) device
VPN Site
Service Provider Network

Types of VPNs
• VPN services are offered in two major

ways
Overlay Model where the service provider
provides the virtual connections between sites
Peer model where the service provider
participates in the layer routing of the
customer

VPN Overlay Model
• Service provider network is a connection

of point-to-point links
• Routing within the customer network is
transparent to the service provider
network
• Service provider is responsible purely for
data transport between customer sites

VPN Overlay Model
• Layer 1 implementation (IP, HDLC,

PPP (customer) - provider gives bit
pipes only
• Layer 2 implementation - service
provider responsible for L2 VC via
ATM, Frame-relay

VPN Overlay Model
Virtual Circuit
Layer-3 Routing Adjacency
CPE (CE) CPE (CE)

Device Device
(PE) device (PE) device
VPN Site VPN Site


VPN Peer Model
• Both provider and customer network use

same network protocol
• CE and PE routers have a routing
adjacency at each site
• All provider routers hold the full routing
information about all customer networks
• Private addresses are not allowed
• May use the virtual router capability
Multiple routing and forwarding tables based
on Customer Networks

VPN Peer-to-Peer Model
Layer-3 Routing Adjacency Layer-3 Routing Adjacency
CPE (CE) CPE (CE)

Router Router
(PE) Router (PE) Router
VPN Site VPN Site


VPN Peer Model
• Peer model used two types of

approach
Shared router
Dedicated router

VPN Peer Model
• Shared router
Where a common router was used, extensive packet
filtering is used on the PE router to isolate customer
Service provider allocated addresses out of its space
to the customer and managed the packet filter to
ensure same customer reachability, and isolation
between customers.
High maintenance cost associated with packet filters
Performance impact due to packet filtering

Peer-to-Peer Model
Shared Router Approach
PE Routing Table
VPN-A routes
VPN-B routes
VPN-C routes
VPN-A
CE
interface Serial0/1
Paris PE description ** interface to VPN-A customer
ip address 192.168.61.6 255.255.255.252
ip access-group VPN-A in
VPN-B CE
ip access-group VPN-A out
!
interface Serial0/2
description ** interface to VPN-B customer
London ip address 192.168.61.9 255.255.255.252
ip access-group VPN-B in
ip access-group VPN-B out
VPN-C CE !
interface Serial0/3
description ** interface to VPN-C customer
ip address 192.168.62.6 255.255.255.252
Munich ip access-group VPN-C in
ip access-group VPN-C out
Shared router approach with complex filters

VPN Peer Model
• Dedicated router
Customer isolation is achieved via dedicated
routers connected to customer
POP edge router filter routing updates between
different provider edge routers
Route filtering is achieved via BGP Communities
Not cost effective

Peer-to-Peer Model
Dedicated Router Approach
router bgp 111
neighbor 10.13.1.2 remote-as 111
neighbor 10.13.1.2 route-reflector-client
neighbor 10.13.1.2 route-map VPN-A out
!
VPN-A route-map VPN-A permit 10
CE match community-list 75
!
ip community-list 75 permit 111:1
Paris
VPN-B P Router CE VPN-A

VPN-A PE
Brussels
VPN-A routes ONLY
VPN-B CE
P Routing Table
VPN-B PE VPN-A routes (community 111:1)
VPN-B routes (community 111:2)
London
Dedicated router approach expensive to deploy

Comparison Between
the Two Models
• Overlay Model • Peer Model

Easy to implement Optimal routing
No knowledge of Easy to provision
customer routing additional VPNs
through site
Isolation between provisioning - no
the two network need for link
provisioning

Comparison Between
the Two Models
• Overlay Model • Peer Model

Optimal routing between Customer
sites requires full mesh convergence is
Bandwidth provisioning depended on SP
Virtual circuits have to
routing convergence
be manually configured Lot of routes with
the provider
networks causes
scalability problems

Benefits of MPLS VPNs
• Best of both worlds

• PE participates in routing so you can
achieve optimal routing between sites
• PE isolates customer routing information
like dedicated router solution
• Overlapping addresses are permitted
between customers

• PE router is subdivided into virtual routers

• Similar to the dedicated router approach
• Each customer is assigned independent
routing tables
• IOS does this isolation through the
concept of VRF (Virtual Routing and
Forwarding)

VPN Routing Table
VPN-A
CE
Paris
PE
VRF for VPN-A
VPN-A CE
IGP &/or BGP
London
VRF for VPN-B
VPN-B CE
Munich
Global Routing Table
Multiple routing & forwarding instances (VRFs) provide

the separation
Problem
• How to propagate routing across the

network between the PE devices?
• We need a routing protocol that will
transport the customer routes across the
provider network
• Need to maintain the independency of
customers routing and address space

Easy and Lazy Answer
• Run multiple routing protocols, one each for customer

• But PE routers will have to run large number of
routing instances
• Poor P router will have to carry all the VPN routes
• P routers still will run into overlapping address
problem unless you configure all the vrfs on the PE
router
• Does not scale

Better Solution
• Run a routing protocol that can

exchange the routing updates only
between PE routers
• P router is protected from customer
routes

But how to do it ?
• Use BGP to pass the routing information

between PE devices
• Use MPLS labels to exchange packets
between next-hops (PE routers)
• Extend BGP to be able to handle
overlapping addresses

VPN Routing & Forwarding
Instance (VRF)
• PE routers maintain separate routing tables

Global routing table
contains all PE and P routes (perhaps BGP)
populated by the VPN backbone IGP
VRF (VPN routing & forwarding)
routing & forwarding table associated with one or more directly connected sites (CE
routers)
VRF is associated with any type of interface, whether logical or physical (e.g.
sub/virtual/tunnel)
interfaces may share the same VRF if the connected sites share the same routing
information

Instance (VRF)
VPN Routing Table
VPN-A
CE
Paris
PE
VRF for VPN-A
VPN-A CE
IGP &/or BGP
London
VRF for VPN-B
VPN-B CE
Munich
Global Routing Table
Multiple routing & forwarding instances (VRFs) provide

the separation
MPLS/VPN Connectivity Model
• Private addressing in multiple VPNs no

longer an issue
provided that members of a VPN do not use the
same address range
VPN A
London Paris Munich
10.2.1.0/24 10.3.3.0/24 10.2.12.0/24
Address space for 10.4.12.0/24

VPN A and B must be
unique Milan Brussels Vienna
VPN B 10.2.1.0/24 10.22.12.0/24 VPN C

Instance (VRF)
• VRF can be thought of as a virtual router with the

following structures:
forwarding table based on CEF
a set of interfaces that use the derived forwarding table
rules to control import/export of routes from/into the VPN routing table
set of routing protocols/peers which inject information into the VPN
routing table (including static routing)
router variables associated with the routing protocol used to populate
the VPN routing table

VRF Route Population
• VRF is populated locally through PE and CE

routing protocol exchange
RIP Version 2, OSPF, BGP-4 & Static routing
• Separate routing context for each VRF
routing protocol context (BGP-4 & RIP V2)
separate
CE
process (OSPF)
Site-1
PE
EBGP,OSPF, RIPv2,Static
CE
Site-2

Local VRF Route Population
VPN-A
CE
Paris VRF for VPN-A

PE
VPN-A Which routing Global
CE
protocol context or
process ?
London
VRF for VPN-B

VPN-B CE
Munich
Local VRF population driven by routing protocol context

or process (OSPF)
VRF Route Distribution
• PE routers distribute local VPN information
across the MPLS/VPN backbone
through the use of MP-BGP & redistribution from VRF
receiving PE imports routes into attached VRFs
P Router
CE Router PE PE CE Router
VPN Site MP-BGP

VPN Site
MPLS/VPN Backbone

Concept of RD
• If customers have overlapping address,

BGP will treat them is single prefix
• Extend the prefix with a 64-bit prefix
(route-distinguisher)
• Now, with 32 bit IP address and 64 bit RD,
the two overlapping IP address are unique

Concept of RD
• 32 bit IP prefix is the IPv4 address

• With 64 bit RD, it is now extended to
96 bit and is now VPNv4 address
• This address is exchanged only
between the PE routers via BGP
• This is carried in Multi-Protocol BGP

Concept of RD
VPN-A PE router converts it into a 96 bit VPNv4 prefix

CE
PE1 PE2
MPLS/VPN Backbone
VPN-B
MP-BGP
CE
VPN-B
BGP Table
Munich
CE router sends 32 bit IPv4 prefix
Routes from VPN-A
Routes from VPN-B

Processing of RD
• RD is propagated between the PE

routers
• RD is removed by the receiving PE
routers
• CE router receives just the IPv4
prefixes

Usage of RD
• RD is only used to extend the IP prefix

such that overlapping address are unique
• Simple VPN topologies require single RD
per customer
• In some cases multiple RDs may be
required

Can RD be the VPN Identifier?
• Yes - it could be a VPN identifier

• Complex topologies require another
component for VPN topologies other
than RD, just like communities are
more flexible.

Concept of RT
• Sites that have to participate in more than

one VPN- RD is not sufficient
• You need another way of deciding the
membership
• RT was introduced to support complex
topologies such that separation and
grouping is easier

Concept of RT
• RT is extended BGP communities,

attached to VPNv4 address
• Give more flexibility to the VPN
membership
• Any number of RT can be attached to a
route
• Extended communities are 64 bit values

Concept of RT
• RTs are either exported or imported

• Export route target are attached to the
route the moment it is converted from IPv4
to VPNv4
• Import RT is used to decide the routes that
would be imported into the VPN

Routing Within MPLS VPN
• Pass IPv4 to the customer routers

• No VPN routes within the MPLS core (P
routers)
• P routers run IGP and global BGP (if
needed)
• Provider Edge router carries connected
VPN routes and Internet routes

Routing P-router Perspective
• Runs IGP with all the P and PE

routers in the network
• No MPLS VPN routing information
• Very simple view of the network

Routing PE-router Perspective
• Exchanges IPv4 routes with CE router

• Exchange VPNv4 routes with other PE
routers
• Run common IGP with P router and also
internet BGP with P routers (if needed)

Routing Table on PE Router
• PE router has to maintain number of

routing tables
• Global routing table (IGP, Internet routes)
• VRF routing information for VPNs
connected
• VRF routing is populated via CE and other
PE routes

PE to PE Route
Information Flow
• PE router creates VPNv4 update

• Adds extended community attribute (RT, SOO)
• All other BGP attributes
• Received route is imported into appropriate
VRF according to RT values
• Routes installed into VRF are propagated to
CE routers

MP-BGP Update
• Any other standard BGP attribute
Local Preference
MED
Next-hop
AS_PATH
Standard Community
• A Label identifying:
The outgoing interface or VRF where a lookup has to be
performed (aggregate/connected)
The BGP label will be the second label in the label stack
of packets travelling in the core

VRF Population of MP-BGP
ip vrf VPN-A
route-target import VPN-A
VPN-v4 update is translated
into IPv4 address and put
into VRF VPN-A as RT=VPN-
A and optionally advertised
to CE-2
PE-1 VPN-v4 update: PE-2

CE-1 RD:1:27:149.27.2.0/24, CE-2
Next-hop=PE-1
SOO=Paris, RT=VPN-A,
Paris Label=(28) London
• Receiving PE routers translate to IPv4

Insert the route into the VRF identified by the RT
attribute (based on PE configuration)
• The label associated to the VPN-V4 address will be
set on packets forwarded toward the destination
Routing Between PE-CE
• CE does not need any understanding of

MPLS
• CE needs standard IP software
• Currently EBGP, OSPF, RIP, and static
routing is supported
• PE router looks like a standard corporate
backbone to the CE router

MPLS/VPN Packet Forwarding
In Label FEC Out Label In Label FEC Out Label In Label FEC Out Label
- 197.26.15.1/32 - 41 197.26.15.1/32 POP - 197.26.15.1/32 41
PE-1 197.26.15.1 PE-2
Use label implicit-null for Use label 41 for destination

destination 197.26.15.1/32 197.26.15.1/32
Paris VPN-v4 update:

RD:1:27:149.27.2.0/24, London
149.27.2.0/24 NH=197.26.15.1
SOO=Paris, RT=VPN-A,
Label=(28)
• PE and P routers have BGP next-hop reachability

through the backbone IGP
• Labels are distributed through LDP corresponding
to BGP Next-Hops or RSVP with Traffic Engineering

• Label Stack is used for packet forwarding

Top label indicates BGP Next-Hop (interior label)
Second level label indicates outgoing interface or VRF
(exterior VPN label)
• MPLS nodes forward packets based on top label
any subsequent labels are ignored
• Penultimate Hop Popping procedures used one hop

prior to egress PE router

Penultimate Hop Popping
In Label FEC Out Label In Label FEC Out Label In Label FEC Out Label
- 197.26.15.1/32 41 197.26.15.1/32 POP - 197.26.15.1/32 41
197.26.15.1
London Brussels Paris
Use label implicit-null for Use label 41 for destination

destination 197.26.15.1/32 197.26.15.1/32
London# show tag-switching tdp binding 197.26.15.1

tib entry: 197.26.15.1/32, rev 10
local binding: tag: imp-null(1)
remote binding: tsr: 172.16.3.1:0, tag: 41
Brussels# show tag-switching tdp binding 197.26.15.1

tib entry: 197.26.15.1/32, rev 10
local binding: tag: 41
remote binding: tsr: 172.16.3.2:0, tag: imp-null(1)
Brussels# show tag-switching forwarding

Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
41 Pop tag 197.26.15.1/32 0 Se0/0/2 point2point

In Label FEC Out Label
- 197.26.15.1/32 41
VPN-A VRF
149.27.2.0/24,
NH=197.26.15.1
PE-1 Label=(28)
41 28 149.27.2.27
149.27.2.27
Paris London
149.27.2.0/24
• Ingress PE receives normal IP packets

• PE router performs IP Longest Match from
VPN FIB, finds iBGP next-hop and imposes
a stack of labels <IGP, VPN>
In Label FEC Out Label In Label FEC Out Label
28(V) 149.27.2.0/24 - 41 197.26.15.1/32 POP
VPN-A VRF
VPN-A VRF 149.27.2.0/24,
149.27.2.0/24, NH=197.26.15.1
NH=Paris PE-1 Label=(28)
28 149.27.2.27 41 28 149.27.2.27
149.27.2.27 149.27.2.27
Paris London
149.27.2.0/24
• Penultimate PE router removes the IGP label

Penultimate Hop Popping procedures (implicit-null label)
• Egress PE router uses the VPN label to select

which VPN/CE to forward the packet to
• VPN label is removed and the packet is routed
toward the VPN site
MPLS/VPN Configuration and
Implementation

MPLS Configuration
• VRF: Sites requiring same routing

policies share same VRF
IP routing table
CEF forwarding
Route distinguisher
Route Target (export, import)

MPLS Configuration
• VRF configuration
Step 1. Create VRF
Step 2. Assign an RD
Step 3. RT export
Step 4. RT import
Step 5. Define an interface to a VRF

MPLS Configuration
Step 1.
Creating a VRF
ip vrf name
Example ip vrf bootcamp
Where bootcamp is just a name like route-
map name

MPLS Configuration
• VRF configurations
Step 2.
Every VRF needs an associated RD
rd route-distinguisher
Could be AS:X or IP address :X
Example: rd 109:12345

MPLS Configuration
Step 3.
Defining a route target that will be exported
with every route that is send from the VRF
Multiple route-target can be attached to a vrf
route-target export RT
Example: route-target export 109:1234

MPLS Configuration
Step 4.
Define a route-target that will be accepted by
the router to be imported into the VRF
route-target import
Example: route-target import 109:1345

MPLS Configuration
Step 5.
Associate an interface to the VRF; this will remove
the interface from the global routing process
Existing IP address is removed once the interface
is defined to a VRF; you will have to re-configure
the IP address

MPLS Configuration
Ip vrf GREEN
rd 109:145
route-target export 109:145
route-target import 109:145
interface serial 1/0/1

ip forwarding vrf GREEN
ip address 10.1.1.5 255.255.255.252

MPLS Configuration
• MP-BGP configuration
BGP process is extended to perform three
functions
Tasks are configured in same BGP process
through address families
1. Maintain and exchange global routing information (IPv4
routing)
2. VPNv4 routing
3. VRF routing exchange with CE

MPLS Configuration
• MP-BGP configurations
Global neighbor are configured under the
global BGP process (All P and PE neighbors)
These neighbors need to be activated under
the appropriate address family according to
requirements
VRF specific neighbors are defined under the
corresponding VRFs

MPLS Configuration
Step 1. Configure neighbors and their
parameters under the global process
Step 2. Configure address family VPNv4
Step 3. Activate neighbors to carry VPNv4
routes
Step 4. Activate the VPNv4 specific parameters
under the address family (filter, etc.)

MPLS Configuration
Step 1. Configure BGP process
router bgp 110
neighbor 131.108.1.1 update-source loopback 0

MPLS Configuration
• MP-BGP Configurations
Step 2. Configure the address family, activate the
neighbor under the address family for VNPv4
routes. Neighbor that was defined earlier under
main BGP process
address-family vpnv4
neighbor 131.108.1.1 activate
neighbor 131.108.1.1 next-hop-self

MPLS Configuration
• Let’s talk a little about the IPv4

address family
Address-family IPv4 is same is your
regular BGP process
Configurations done under this family
will be added to the global BGP
configurations

MPLS Configuration
no bgp default ipv4 unicast

• Disables the default behavior of IPv4 route
propagation
• Activate the neighbors that need to get IPv4
routes
• Isolation of VPNv4 and IPv4 routes such that
few neighbors get both and few receive VPnv4
only

MPLS Configuration
• Example: 3 neighbors: two of them

need IPv4 routes, one does not
• Requirements
Neighbor 131.108.1.1 (IPv4, VPNv4)
Neighbor 131.108.1.2 (IPv4 only)
Neighbor 131.108.1.3 (VPNv4 only)

MPLS Configuration
Router bgp 110

No bgp default ipv4 unicast
Neighbor 131.108.1.1 remote-as 110
Neighbor 131.108.1.1 activate

Address-family vpnv4

MPLS Configuration
• Configuring PE-CE Routing

BGP between PE-CE
RIP between PE-CE
OSPF between PE-CE
Static routes

MPLS Configuration
• BGP/RIP require single routing process

• Distance/path vector no database
separation needed; done through address-
families
• OSPF requires a separate routing process
for each VRF to maintain a separate
database

MPLS Configuration
• All non-BGP VRF routes have to be

redistributed
• No sync is default
• No auto summary is default

MPLS Configuration
• BGP
Define the neighbor under the address-family
vrf and not under the global BGP
router bgp 110
!
address-family ipv4 vrf Green
neighbor 10.1.1.1 activate

MPLS Configuration
• RIP
Single routing process
RIP parameters in each VRF
router rip
version 2
address-family ipv4 vrf BLUE

network 10.0.0.0
CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc.
redistributewww.Cisco.com
bgp 110 metric transparent 81
MPLS OSPF
• IGP-BGP redistribution is done by

MPLS
• Not a very good thing for OSPF
• Routes redistributed in OSPF are
external
• Single LSA for every external route

MPLS OSPF
• If all the routes are carried as external

• Route summarization would be a
problem
• Stub areas would be hard to
implement

MPLS OSPF
• MPLS VPNs needed to be extended to

carry OSPF information
• Per se create a concept of super backbone
• Super backbone is created with MP-BGP
between the PE-routers
• This super backbone is between the PE
routers; it is transparent to OSPF

MPLS OSPF
MPLS BGP
backbone
VPN-A VPN-A
VPN-B CE VPN-A
VPN-B CE
Area 0
CE CE
Area 1 London
Area 2
Paris
Area 0

MPLS OSPF
• OSPF between sites does not use normal

OSPF-BGP redistribution
• Internal OSPF routes are kept internal to OSPF
• External routes are kept external
• OSPF metrics are preserved
• MPLS OSPF backbone is transparent to CE
OSPF that runs standard software

MPLS OSPF
• PE routers act as ABRs

• In the case of no stub area, PE
routers also act as ASBRs
• For CE routers’ perspective, send an
inter-area route into the connected
area

MPLS OSPF
• Intra-area OSPF routes are

redistributed into BGP by the PE
router
• Route Summarization can be done at
the redistribution point by the PE
router

MPLS OSPF
• Super backbone acts just like area 0 in regular

OSPF
• Redistributed routes at the PE routers appear as
inter-area routes
• Routes from one area 0 site into another area 0
sites appear as inter-area routes
• Redistributed intra- and inter-area routes appear as
inter-area routes; external still appear as external

MPLS OSPF
• For MP-BGP, extended community of

0x8000 is used
• OSPF cost is copied as MED for BGP
• LSA type and metric are carried
across

MPLS OSPF
• OSPF-BGP loop avoidance

MPLS BGP
backbone
OSPF route PE1 PE3 PE2

Redistributed into BGP
VPN-A VPN-A
VPN-B VPN-A
VPN-B
Area 0
CE
Paris
Area 0

MPLS OSPF
• PE1 learns the route via OSPF intra-area

• PE1 advertises the route to PE2 and PE3
via MP-BGP
• One of the PE router redistributes it first
(sort of race condition)
• PE2 sends the route to PE3 via OSPF
summary LSA

MPLS OSPF
• PE3 removes the iBGP route for the

destination and installs the OSPF summary
route, due to lower admin distance
• You can solve the problem by lowering the
administrative distance of iBGP to be
less… not a clean solution

MPLS OSPF
• To solve this problem a (Down bit) has

been added to option field of the header
like ISIS TLV 135
• PE router sets the down bit when
redistributing routes from MP-BGP to OSPF
• PE router will never redistribute OSPF
route back into BGP with down bit set

MPLS OSPF
• Double redistribution loop is still possible

• When the CE does redistribution between
domains and the down bit is lost
• For this purpose, tag field is used as done by
standard BGP-OSPF redistribution
• PE routers never redistributes OSPF routes
with Tag field equal to their own AS number
into MP-BGP

MPLS Configuration
• OSPF
Configuration is still simple
router ospf 110 vrf RED
network 10.1.0.0 0.0.255.255 area 0
redistribute bgp 110

MPLS IS-IS
• VPN backbone is treated as a level

above L2
• All L1/L2 routes will be redistributed
into BGP at the PE router
• New extended community in BGP
0x0006

MPLS IS-IS
• Same as route leaking concept: don’t

send out IS-IS back into BGP if
UP/Down bit is set
• Don’t send route if the route in the
table is not learned via IS-IS

MPLS IS-IS
• At the receiving site redistribute the

route into IS-IS with UP/Down bit set
• Same concept as separation of
LSDB: one DB can belong to one VPN

MPLS IS-IS
• Configuration is similar to OSPF

router isis tag1 vrf vpn-blue
net 49.0001.1201.0003.0001.00
redistribute bgp 65000 metric transparent level-1-2
MPLS Configuration
• Static
Used to configure VRF specific routes
Always need to specify the interface
even though you have the next-hop
ip route vrf YELLOW 10.1.0.0 255.255.0.0 10.1.1.5 serial 2/0

MPLS VPN Configurations

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

MPLS VPN Configurations

Cargado por

Copyright:

Formatos disponibles

MPLS VPN Configurations

CQFE rev17 Russ Davis © 1999, Cisco Systems, Inc. 1

• Introduction to VPNs concepts

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 2

• Idea behind VRF, RD, RT

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 3

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 4

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 5

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 6

• Provider Network (P-Network)

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 7

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 8

CPE (CE) CPE (CE)

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 9

• VPN services are offered in two major

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 10

• Service provider network is a connection

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 11

• Layer 1 implementation (IP, HDLC,

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 12

Layer-3 Routing Adjacency

CPE (CE) CPE (CE)

VPN Site VPN Site

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 13

• Both provider and customer network use

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 14

Layer-3 Routing Adjacency Layer-3 Routing Adjacency

CPE (CE) CPE (CE)

VPN Site VPN Site

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 15

• Peer model used two types of

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 16

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 17

Shared router approach with complex filters

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 18

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 19

VPN-B P Router CE VPN-A

Dedicated router approach expensive to deploy

• Overlay Model • Peer Model

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 21

• Overlay Model • Peer Model

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 22

• Best of both worlds

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 23

• PE router is subdivided into virtual routers

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 24

Multiple routing & forwarding instances (VRFs) provide

• How to propagate routing across the

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 26

• Run multiple routing protocols, one each for customer

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 27

• Run a routing protocol that can

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 28

• Use BGP to pass the routing information

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 29

• PE routers maintain separate routing tables

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 30

Multiple routing & forwarding instances (VRFs) provide

• Private addressing in multiple VPNs no

London Paris Munich

10.2.1.0/24 10.3.3.0/24 10.2.12.0/24

Address space for 10.4.12.0/24

VPN B 10.2.1.0/24 10.22.12.0/24 VPN C

CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com 32