Route Targets
A careful reader might start asking an interesting question: If 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? This dilemma is solved by the introduction of another concept in the MPLS/VPN architecture: the route target. 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.
NOTE
The route target is the closest approximation to a VPN identifier in the MPLS/VPN architecture. In most VPN topologies, you can equate them, but in other topologies (usually a central services topology), a single VPN might need more than one route target for successful implementation.
The route target is a 64-bit quantity, the format of which is explained in the next chapter. For simplicity reasons, we will use names for route targets in this chapter.
The SuperCom network contains three VPNs and thus requires three route targets. The association between route targets and VRFs in the SuperCom network is outlined in Table 9-4.
Table 9-4 Correspondence Between VRFs and Route Targets in SuperCom Network
|
PE Router |
VRF |
Sites in the VRF |
Route Target Attached to Exported Routes |
Import Route Targets |
|
San Jose |
FastFood_ Central |
FastFood SanJose site |
FastFood, VoIP |
FastFood, VoIP |
|
|
FastFood |
FastFood Santa Clara site FastFood Redwood site |
FastFood |
FastFood |
|
|
EuroBank |
EuroBank San Francisco site |
EuroBank |
EuroBank |
|
|
VoIP |
San Jose VoIP gateway |
VoIP |
VoIP |
|
Paris |
FastFood |
FastFood Lyon site |
FastFood |
FastFood |
|
|
EuroBank_ Central |
EuroBank Paris site |
EuroBank, VoIP |
EuroBank, VoIP |
|
|
EuroBank |
EuroBank Chartres site EuroBank Nantes site |
EuroBank |
EuroBank |
|
|
VoIP |
Paris VoIP gateway |
VoIP |
VoIP |
NOTE
Based on Table 9-4, you might assume that the route targets attached to routes exported from a VRF always match the set of import route targets of a VRF. Although that's certainly true in simpler VPN topologies, there are widespread VPN topologies (for example, central services VPN) in which this assumption is not true.