2

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?

Mike Pennington
  • 41,899
  • 19
  • 136
  • 174
Hashken
  • 4,396
  • 7
  • 35
  • 51

2 Answers2

2

As per my understanding Route Targets are used in MPLS-VPNs to distinguish between the different VRFs in a PE router.

Put another way, route-targets are used to implement VRF route import and export policies for a VRF on a PE router.

My doubt is, how is this allotment of route targets handled when there are sites that belong to more than one VPN?

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...

MPLS VPN Sample Topology

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 with rt 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 with rt 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 and rt 100:51. PE_2 would now import VPNv4 routes tagged with rt 100:2 into VRF_B and import rt 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 with rt 100:52, so this could be imported into VRF_A on PE_1.

Mike Pennington
  • 41,899
  • 19
  • 136
  • 174
  • Sure Mike. I don't have enough rep to upvote, but I will certainly accept your answer. I just need a little more clarification. Site_AA now belongs to two VPNs, VPN_A and the one comprising Site_AA and Site_BB (let us call it VPN_C). The fact that site_BB has to have two import targets 100:5 and 100:51 is fine. But consider the PE router attached to site_AA. How does it know which route target to attach for incoming packets from site_AA. Do we have two different connections via two different interfaces between site_AA and it's PE or is it done via some other method? – Hashken Jun 01 '12 at 10:36
  • Apparently I have enough rep to upvote. :) – Hashken Jun 01 '12 at 10:37
  • Karthik, only routes are tagged with route-targets, packets receive an MPLS label as they are forwarded into the MPLS LSP. After a PE router imports routes from multiple route-targets into its FIB, the PE router also knows the BGP next-hop associated with a particular route and thus the PE router knows how to forward packets to the appropriate destination. Sometimes you need multiple interfaces for these situations, but this is not always the case... We need to be much more specific about the topology before I can go into those details – Mike Pennington Jun 01 '12 at 10:54
  • Sorry, my question wasn't clear. I meant to ask, How does the router know which route target to attach to incoming **BGP control packets**. Your explanation works fine once the LSP has been set up. But in the control plane, the BGP information is needed to set up the LSP. So, in that case, how are BGP packets sent across during the control plane phase. – Hashken Jun 01 '12 at 10:59
  • Karthik, when I say that route-targets are "exported", it means that customer routes received by a PE from a directly-attached CE router within that VRF are tagged with those "exported" route targets. Multiprotocol BGP then announces those routes tagged with route-targets (using [BGP extended-communities](http://tools.ietf.org/rfc/rfc4360.txt)) to every other BGP PE router in the provider's network. The receiving PE looks at the route-targets on the routes it receives and "imports" routes tagged with the appropriate route targets into the local VRF on that PE router. – Mike Pennington Jun 01 '12 at 12:10
  • Your explanation is really good. But it still doesn't answer my question. When the sending PE "exports" the routes which were received from a site belonging to two different VPNs, how does the PE know which export route target to tag with. – Hashken Jun 01 '12 at 12:19
  • The PE for Site_AA tags all routes originating in Site_AA with `rt 100:1` and `rt 100:51`. – Mike Pennington Jun 01 '12 at 12:21
  • If that is the case, packets originating from site_AA, meant for VPN_A, will be received in both VPN_A and VPN_C. My understanding is that we need separate links between the same PE and CE for different VRFs. Please correct me if I am wrong. And many thanks for your efforts. It is difficult to find such a helpful **networking professional** in StackExchange. – Hashken Jun 01 '12 at 12:41
  • Karthik, I think you need to explicitly define what you mean by VPN_C as a different question, because my example did not define a different VPN... it merely allowed the exchange of traffic from one VPN site to a DMZ in another VPN site. Please be specific about links, prefixes, etc... and ask on [sf]. Questions about specific topologies would be more appropriate there – Mike Pennington Jun 01 '12 at 13:01
  • Ok. please edit your answer to include the contents of our comments, so that others will also get benefitted. – Hashken Jun 01 '12 at 13:06
  • Karthik, I am happy to help. I am at work, but will revise my answer with the highlights of the comments when I get home tonight. I will also look at your [sf] question this evening. – Mike Pennington Jun 01 '12 at 14:33
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/12053/discussion-between-karthik-and-mike-pennington) – Hashken Jun 02 '12 at 05:15
  • @Karthik, we can chat if you like but I am busy most of the day today... I will endeavor to find you when you are online. – Mike Pennington Jun 02 '12 at 11:49
  • @Karthik, I updated my answer with different examples... – Mike Pennington Jun 02 '12 at 23:08
0

After doing some research on the topic and some fruitful discussion with Mike, I think I have a good idea on how the Route Targets are assigned. So I decided to answer my own question.

Quoting from Mike's answer

Route-targets are used to implement VRF route import and export policies for a VRF on a PE router.

The problem arises when we have a PE router sending control plane information received from a site belonging to multiple VPNs. There should be some way for the PE to decide which route target (thereby signalling to which VPN this control information belongs to) to assign to the BGP control packet it sends.

The important point to be noted is that VRFs are configured on particular interfaces and Route Targets are configured for interfaces.

So, if we have a site that belongs to, say, 3 VPNs, the site's CE and the corresponding PE should be connected via 3 different interfaces (or sub-interfaces) and a specific route Target assigned to each interface (or sub-interface).

Regarding my other question

Are the route targets to various VRFs manually installed in all the PEs?

From what I had gathered from searching online, Route targets are indeed configured manually on the routers.

Community
  • 1
  • 1
Hashken
  • 4,396
  • 7
  • 35
  • 51