RDs are simply a construct used in MPBGP to prepend onto the IPv4 route to make the RD:IPv4 combination unique in any particular MPLS network. Thus if routes are not repeated in the network RDs can be the same across all sites on a particular VPN/VRF. However if some sites have multiple access points then the RD must differ on the attached PE routers as BGP can only advertise one particular path to a destination.
RTs are extended communities that are appended to a route as a BGP attribute. They are used to define which routes are exported and imported into a VRF routing table. So for example at one PE exporting all routes in VRF-A with RT64520:200 and at another PE importing all routes with RT64520:200 into VRF-A will mean that all routes on the first PE router in VRF-A will also appear in VRF-A on the second PE router. This is CRUCIAL – nothing except the route target export import statements and the BGP extended community value they add onto a route define which VRF a route belongs to.
Note that here I have used a private AS number as the first part of the extended community – these numbers (the original 16-bit range rather than the extended 32-bit range) start at 64512 and finish at 65534.
Route Target Exports & Imports
RT Exports & Imports ares totally unrelated to the Export / Import Maps. I.e. Route Target Export is very generic and adds a BGP extended community value to all routes from a particular VRF, an export map can achieve the same thing but allows for finer control of what exactly is exported.
It is sometimes possible to achieve the same effect using import map or export map. For example to select a specific route either an export map could be used on source PE and a route-target import on destination PE or route-target export on source PE and a import map on destination PE. Its probably better to try to minimize the number of places where route maps are used and thus use an export map at source in preference to an import map at destination based on the One-to-Many scenario.
BGP requires a full mesh network unless route reflectors are in use. Consequently a route that is advertised by one peer to another peer will not then be advertised onwards by that peer except to any route reflector clients. This means that if one router has a route in one VRF and then uses route-target export / import to place the route into another VRF when the route is advertised to another PE router this PE router must also import the route based on the route-target export value used on the first PE router not the route-target export value used on the first PE router in the destination VRF. For example on PE-1 10.10.10.0/24 is exported from VRF-1 using RT65001:1 and imported into VRF-2 which exports all its routes using RT65001:2. PE-2 is a peer of PE-1 and should import RT65001:1 to place 10.10.10.0/24 into VRF-2, importing RT65001:2 will not bring 10.10.10.0/24 into the VRF as the route will not be tagged with this extended community. KEY POINT here is that the route-target import statement is only locally relevant as routes making up a VRF are made of locally connected routes, static routes and routes imported into the local VRF based on the BGP extended community string.
(Or things that necessarily come from the above)
- RD value needs to different on all VRFs on a particular PE router and can be the same or different from one PE router to another depending on the complexity of a network.
- RD value for a particular VRF will need to be different on any two PE routers if both PE routers connect to the same subnet on a particular site.
- Each VRF should have its own universal Import/Export route target number in order that all BGP routes in a particular VRF have the same BGP extended community value.
- Management routes should be exported once at source in order to apply the required BGP extended community (or twice if there are two ways to the management network) and imported on every PE router into the relevant VRFs… i.e. to provide management connectivity for an edge site the VRFthat connects to that edge site needs to have a path within its VRF to the management subnet.
- Management IPs for edge sites should be exported once at source and imported on the PE routers that connect to the management network… i.e. if it’s the WAN interface that is used for management and this is always in a particular VRF then all routes in this VRF will already be exported with a specific extended community string so the import statement can be central and the export statement used on every PE router having this VRF.
- Unidirectional route leaks between two VRFs such as default route will be accomplished through a central route export to add the BGP extended community string and an import statement on each PE router that has the target VRF.
- It is probably obvious but if you have more than a few RT extended communities its probably worth documenting what they are rather than just hoping you remember.
(Or things to think about how this works in practice)
For a particular VRF all route-target import statements and import map statements should be the same on all PE routers – but not all VRFs need to exist on all PE routers
In general for a particular VRF all route-target export statements and export map statement should be the same on all PE routers – but not all VRFs need to exist on all PE routers
It is possible that for leaking a specific route from one VRF to another VRF at one or two locations may be done rather than everywhere the VRF occurs, for example with the default route it may be desirable to attach a different external community string in order that both routes can be imported through a import map but with a different metric applied, this will allow one default route to be a higher priority than the other for example.
Leaking routes is not like redistribution from one routing protocol to another… redistribution takes the routes in a particular routing protocol and adds them to the routes for another routing protocol which then advertises the routes to its peers, route leaking allows a remote BGP process to know which routes are attached to which VRFs based on the extended community value, the route will already be advertised with its source extended community value before the route leak is configured, all the route leak does is add another extended community value in order that the remote PE router can import the route into two different VRFs, the original VRF and the “leak target” VRF.
How we can help
MPLS and MPBGP are highly complex technologies and can challenge even the most experienced network engineers or architects. I (Andrew Horler) wrote this article some years ago in order to help me remember what I’d learnt and it has turned out to be one of the most popular on my website – presumably other network engineers and architects are finding it helpful too.
My business, AMDH Services, has many years of experience working on complex network environments, helping our customers to get the most from their WAN, LAN or Wireless environments.
We have worked on a number of WAN migrations, switch replacement projects, and wireless rollouts over the years. If you are looking for help with such a project then please get in touch and lets see if your requirements are a match for what we can provide.
Get in touch today for an informal chat.