Environment
To illustrate the need for a
more versatile VPN indicator than the RD, consider the VoIP
service. Figure illustrates the need for a more versatile VPN
indicator than the RD. There are two connectivity requirements
of the VoIP service: - All sites of a single customer
need to communicate.
- The central sites of different
customers who subscribe to the VoIP service need to communicate
with the VoIP gateways to originate and receive calls in the
public voice network. The sites also need to communicate with
other central sites to exchange inter-company voice
calls.
Note
Additional security measures
have to be put in place at central sites to ensure that the
central sites exchange only VoIP calls with other central
sites. Otherwise, the corporate network of a customer could be
compromised by another customer who is using the VoIP service.
Connectivity Requirements
Figure illustrates the
connectivity requirements of the VoIP service. Three VPNs are
needed to implement the desired connectivity: two customer VPNs
(Customer A and Customer B) and a shared VoIP VPN. These sites
are related as follows: - Central site A participates
in the Customer A VPN and in the VoIP VPN.
- Central
site B participates in the Customer B VPN and in the VoIP
VPN.
- Customer sites A-1 and A-2 participate in
Customer A VPN.
- Customer sites B-1 and B-2
participate in Customer B VPN.
Content
4.4 Describing MPLS VPN Technology
4.4.6 Using Route Targets in an MPLS VPN Figure
shows a simplified view of a typical large enterprise network.
In this case there are five customer sites that are
communicating within three VPNs. The VPNs can communicate with
the following sites: - VPN1 with Sites 2 and 4
- VPN2 with Sites 1, 3, and 4
- VPN3 with Sites 1,3,
and 5
Each VPN contains customer devices that are
attached to the CE routers. These customer devices use VPNs to
exchange information between devices. Only the PE routers are
aware of the VPNs. Each VPN is associated with one or more VPN
routing-forwarding instances (VRFs). A VRF defines the VPN
membership of a customer site that is attached to a PE router.
A VRF consists of an IP routing table, a derived CEF table, a
set of interfaces that use the forwarding table, and a set of
rules and routing protocol parameters that control the
information that is included in the routing table. A one-to-one
relationship does not necessarily exist between customer sites
and VPNs. A given site can be a member of multiple VPNs.
However, a site can only associate with one VRF. A customer
site's VRF contains all the routes available to the site from
the VPNs of which that site is a member. At this point, you may
ask that since there is no one-to-one mapping between VPN and
VRF, how does the router know which routes need to be inserted
into which VRF? The introduction of another concept in the
MPLS/VPN architecture, the route target, solves this dilemma.
Every VPN route is tagged with one or more route targets when
it is exported from a VRF (to be offered to other VRFs). You
can also associate a set of route targets with a VRF, and all
routes tagged with at least one of those route targets will be
inserted into the VRF. Packet forwarding information is stored
in the IP routing table and the CEF table for each VRF. A
separate set of routing and CEF tables is maintained for each
VRF. These tables prevent information from being forwarded
outside a VPN and also prevent packets that are outside a VPN
from being forwarded to a router within the VPN. The
distribution of VPN routing information is controlled using VPN
route target communities, implemented by BGP extended
communities. Distribution of VPN routing information follows
two steps: - When a VPN route that is learned from a CE
router is injected into BGP, a list of VPN route target (RT)
extended community attributes are associated with the route.
Typically, the list of route target community values is set
from an export list of route targets that are associated with
the VRF that the route was learned from.
- An import
list of route target extended communities is associated with
each VRF. The import list defines the route target extended
community attributes that a route must have for the route to be
imported into the VRF. For example, if the import list for a
particular VRF includes route target communities A, B, and C,
then any VPN route that carries any of those route target
extended communities—A, B, or C—is imported into the VRF.
RTs in the MPLS VPN architecture support the requirements
for multi-VPN membership. RTs are attributes that are attached
to a VPNv4 BGP route to indicate the route’s VPN membership.
The RD (a single entity prepended to an IPv4 route) cannot
indicate that a site participates in more than one VPN. We need
a method in which a set of VPN identifiers can be attached to a
route to indicate the site’s membership in several VPNs. How
Do RTs Work?
MPLS VPN RTs are attached to a customer
route at the moment the route is converted from an IPv4 route
to a VPNv4 route by the PE router. The RTs that are attached to
the route are called export RTs and are configured separately
for each virtual routing table in a PE router. Export RTs
identify a set of VPNs to which sites that are associated with
the virtual routing table belong. When the VPNv4 routes are
propagated to other PE routers, those routers need to select
the routes to import into their virtual routing tables. This
selection is based on import RTs. Each virtual routing table in
a PE router can have a number of configured import RTs that
identify the set of VPNs that the virtual routing table is
accepting routes from. In overlapping VPN topologies, RTs are
used to identify VPN membership. Advanced VPN topologies (for
example, central services VPNs) use RTs in more complex
scenarios.
Content 4.4 Describing MPLS VPN
Technology 4.4.7 End-to-End Routing Information
Flow MPLS VPN Routing Criteria
The designers of
MPLS VPN technology aimed to meet these criteria shown in
Figure : - CE routers should not be MPLS VPN-aware; they
should run standard IP routing software.
- PE routers
must support MPLS VPN services and traditional Internet
services.
- To make the MPLS VPN solution scalable, P
routers must not carry VPN routes.
- From the
perspective of a CE router, the MPLS VPN backbone should look
like a standard corporate backbone to the CE routers.
- The CE routers run standard IP routing software and
exchange routing updates with the PE routers, which appear to
them as normal routers in the C-network.
PE-CE
Routing Protocol
After you configure VRFs and
establish MPBGP connectivity between PE routers, you must
configure routing protocols between the PE router and the
attached CE routers. You configure the PE-CE routing protocols
on the PE router for individual VRFs. Configuring routing
protocol on the CE site is very simple. The customer has no
information on VRFs that are configured on the provider site.
Customer configuration is the same configuration as if the
customer is routing between two devices in the C-network.
Overall Customer Perspective
Figure shows the
customer perspective. The MPLS VPN backbone looks like an
intra-company BGP backbone with PE routers performing 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 C-network. The P
routers are hidden from the customer view; the internal
topology of the BGP backbone is, therefore, transparent to the
customer. P Router Perspective
Figure shows how the
P router performs. From the P router perspective, the MPLS VPN
backbone looks even simpler—the P routers do not participate in
MPLS VPN routing and do not carry VPN routes. The P routers run
only a backbone Interior Gateway Protocol (IGP) with other P