I am not sure if I should ask this question here or in ServerFault. But since the question is more about the concept of networking rather than it's implementation in a specific hardware, I decided to post it here.
As per my understanding Route Targets are used in MPLS-VPNs to distinguish between the different VRFs in a PE router.
Assuming that no site is shared between any two VPNs, then the export and import route targets are the same, so a PE can compare the route target in an incoming BGP packet to it's own export route target and install in the appropriate VRF.
My doubt is, how is this allotment of route targets handled when there are sites that belong to more than one VPN?
Are the route targets to various VRFs manually installed in all the PEs?
If so won't it lead to scalability issues?
If not, how are the route targets for the VRFs installed?
Put another way, route-targets are used to implement VRF route import and export policies for a VRF on a PE router.
As written, this question is ambiguous about what you mean when you say "belong to more than one VPN", because it's unclear whether you simply want retain separation of VRFs inside a single site (see Site_C in Example 1, below), or whether you want a single site's routing table to receive routes from two different VRFs (see Site_BB in Example 2, below). This answer will use the following diagram as a reference...
Concepts
Take special note of the small square boxes near the PE routers. Those boxes represent routing and forwarding tables that are local to an interface; Cisco calls those tables a VRF. VRF_A only processes packets to / from CE routers attached to pink clouds. VRF_B only processes packets to / from CE routers attached to blue clouds.
Multiprotocol BGP is used to announce the routes from each VRF across the service provider network (white cloud). Devices inside the white cloud never install the pink and blue routes (even if those other ISP routers are running bgp); this is because after the PE routers receive them, the routes are translated into a special BGP address family called VPNv4. The VPNv4 address family provides a way to distinguish between similar routes from different customers; VPNv4 also carries special BGP attributes attached to each route called route-distinguishers and route-targets, which are extended BGP communities.
Route targets are usually specified in the form of
<asn>:<custom_numer>
. Route targets are manually assigned to a VRF on each PE router. After the PE router receives routes from a CE in the VRF, it tags those routes with the route-distinguisher to make them service-provider-unique VPNv4 addresses, and tags them with route targets to implement routing import and export policies.Example 1
Suppose VPN_A has Site_AA, Site_AB and Site_C. CE_Site_AA, CE_Site_AB, and the pink interface CE_Site_C run OSPF with their respective PE router over pink links. PE routers export routes received via OSPF on VRF_A with
rt 100:1
and announce those routes with Multiprotocol BGP. When PE routers receive MP-BGP routes tagged withrt 100:1
, they import those routes into VRF_A and carry them with OSFP on pink interfaces.Suppose VPN_B has Site_BA and Site_BB. CE_Site_BA, CE_Site_BB, and the blue interface on CE_Site_C run OSPF with their respective PE router over blue links. PE routers export routes received via OSPF on VRF_B with
rt 100:2
and announce those routes with Multiprotocol BGP. When PE routers receive MP-BGP routes tagged withrt 100:2
, they import those routes into VRF_B and carry them with OSFP on blue interfaces.It is worth noting that CE_Site_C must use VRFs on both interfaces / subinterfaces to PE_3 to keep traffic from VRF_A and VRF_B separate.
Example 2
We will extend Example 1 to expose 172.16.1.0/24 to Site_BB.
Let's suppose we need to expose 172.16.1.0/24 from Site_AA to VRF_B at Site_BB. At this point PE_1 needs to export 172.16.1.0/24 with
rt 100:1
andrt 100:51
. PE_2 would now import VPNv4 routes tagged withrt 100:2
into VRF_B and importrt 100:51
to receive 172.16.1.0/24 into VRF_B. If Site_BB needed to expose its routes to Site_AA in a similar manner, PE_2 would need to tag one or more appropriate DMZ subnets withrt 100:52
, so this could be imported into VRF_A on PE_1.