How can this be accomplished?

A network is composed of several VRFs. It is required that VRF users VRF_A and VRF_B be able
to route to and from VRF_C, which hosts shared services. However, traffic must not be allowed to
flow between VRF_A and VRF_B. How can this be accomplished?

A.
Route redistribution

B.
Import and export using route descriptors

C.
Import and export using route targets

D.
Cisco MPLS Traffic Engineering

Explanation:
An MPLS VPN implementation is very similar to a dedicated router peer-to-peer model
implementation. From a CE router’s perspective, only IPv4 updates, as well as data, are forwarded
to the PE router. The CE router does not need any specific configuration to enable it to be a part of
a MPLS VPN domain. The only requirement on the CE router is a routing protocol (or a
static/default route) that enables the router to exchange IPv4 routing information with the
connected PE router. In the MPLS VPN implementation, the PE router performs multiple functions.
The PE router must first be capable of isolating customer traffic if more than one customer is
connected to the PE router. Each customer, therefore, is assigned an independent routing table
similar to a dedicated PE router in the initial peer-to-peer discussion. Routing across the SP
backbone is performed using a routing process in the global routing table. P routers provide label
switching between provider edge routers and are unaware of VPN routes. CE routers in the
customer network are not aware of the P routers and, thus, the internal topology of the SP network
is transparent to the customer
The P routers are only responsible for label switching of packets. They do not carry VPN routes
and do not participate in MPLS VPN routing. The PE routers exchange IPv4 routes with connected
CE routers using individual routing protocol contexts. To enable scaling the network to large
number of customer VPNs, multiprotocol BGP is configured between PE routers to carry customer
routes.
Customer isolation is achieved on the PE router by the use of virtual routing tables or instances,
also called virtual routing and forwarding tables/instances (VRFs). In essence, it is similar to
maintaining multiple dedicated routers for customers connecting into the provider network. The
function of a VRF is similar to a global routing table, except that it contains all routes pertaining to
a specific VPN versus the global routing table. The VRF also contains a VRF-specific CEF
forwarding table analogous to the global CEF table and defines the connectivity requirements and
protocols for each customer site on a single PE router. The VRF defines routing protocol contexts
that are part of a specific VPN as well as the interfaces on the local PE router that are part of a
specific VPN and, hence, use the VRF. The interface that is part of the VRF must support CEF

switching. The number of interfaces that can be bound to a VRF is only limited by the number of
interfaces on the router, and a single interface (logical or physical) can be associated with only
one VRF. The VRF contains an IP routing table analogous to the global IP routing table, a CEF
table, list of interfaces that are part of the VRF, and a set of rules defining routing protocol
exchange with attached CE routers (routing protocol contexts). In addition, the VRF also contains
VPN identifiers as well as VPN membership information (RD and RT are covered in the next
section).
Route targets (RTs) are additional identifiers used in the MPLS VPN domain in the deployment of
MPLS VPN that identify the VPN membership of the routes learned from that particular site. RTs
are implemented by the use of extended BGP communities in which the higher order 16 bits of the
BGP extended community (64 total bits) are encoded with a value corresponding to the VPN
membership of the specific site. When a VPN route learned from a CE router is injected into
VPNv4 BGP, a list of VPN route target extended community attributes is associated with it. The
export route target is used in identification of VPN membership and is associated to each VRF.
This export route target is appended to a customer prefix when it is converted to a VPNv4 prefix
by the PE router and propagated in MP-BGP updates. The import route target is associated with
each VRF and identifies the VPNv4 routes to be imported into the VRF for the specific customer.
The format of a RT is the same as an RD value.