It is explained to us that RTs are used to tell a receiving PE router which VRF to place received iBGP routes.
Isnt that RD enough to accomplish this for INTRA-vpn control plane convergence?
PE1 and PE2 will have the same VRFs configured for customers that traverse both routers.
PE1 and PE2 configs
So, if PE2 advertises vpn A and vpn B prefixes to PE1 wth the rd prepending the ipV4 NLRI, shouldnt PE 1 automatically know in which VRF to place the received prefix just by examining the RD? Why the RT?
I can see the need for an RT for inter-vpn traffic (A to B) or third part (A to C and B to C)...
Why the RT ?
Because the RD and RT function at different times within the MPLS VPN process. The RD is used to keep separate each vrf's routes so that overlapping address space can be used in different VRFs. On receiving the routes the PE router then places the unique routes into it's MP-IBGP table.
Only when this has been done does the RT come into effect. The RT is then used to determine which vrfs to place these routes into.
So i can hear the cogs turning from here ie. you are going to say that with your example the RT is superfluous. And as far as i can see you are right. But what would you rather do when designing and more importantly coding a protocol -
1) Code the RT code to do what it does but have an exception based on your example so the RD and RT code now become inter-dependant to some extent
2) Have the RT code just do what it does without having to take into account anything else. This keeps the RD and RT code separate in the sense that you don't have to code exceptions into both the RD and RT code.
Obviously i'm making assumptions about the design but the general principle stands.
PE nodes exchange VPN routes using VPNv4 routes.
A VPNv4 prefix is made of RD:IPv4 address
RD is a 64 bits integer.
The VPNv4 prefix has at least one (more then one) BGP route target extended community attribute that defines the "colors" of the route
A PE exports toward core signalling plane the VRF routes learned by CE routers (or simply connected and static routes in VRF)
A PE node imports in a specific VRF VA all those VPNv4 prefixes that match the route target import commands defined under locally defined VRF VA obejct.
In most basic examples RD and RT are set to same value creating some confusion.
Actually, RD can be different in each VRF site without causing any issues
Multiple RT values can be used to create connectivity models beyond simple any to any connectivity between VRF sites.
For example an Hub and spoke can be simulated using two RT values
spoke VRF site: imports RT1 exports RT2
Hub site: exports RT2, imports RT1
using spoke it does not learn routes of other spokes routes but only routes coming from Hub site.
In this case Hub site should send a default route or an aggregate route to allow connectivity.
Other more complex models are possible like the use of a double HUB VRF site to have spoke to spoke traffic processed by firewalls in central site.
Other possible use are the need to setup extranet:
only sites that need to participate to the extranet add route target import and export for the route target of that extranet.
The control can be made with import maps and export maps to build partial extranets
Hope to help
I understand the point you are both making. My problem is with the narrow definition given for RTs.
It seems to me that, unless there is a requirement for INTER-vrf communication or third party vrf communication, as I described before, the RT is really not necessary for the PE to know which vrf to inject a VPNv4 prefix. It seems to me that it can use the RD, which will be configured the SAME at both ends, to know which NLRI belongs to which vrf.
That is the problem I have with the narrow definition given.
I have never configured VRFs from an SP perspective, so I am wondering if configuring the RT is ALWAYS a requirement.
Lets say I have something as simple as one VPN called cutomer_a.
Customer_a CE1 advertises corporate prefixes through eBGP to PE1.
PE1 runs iBGP with PE2 and PE2 is connected to customer_a CE2.
No inter-vpn comms with any other customer and no 3rd party vpn requirement.
Given this, is the SP engineer still required to configure an RT to support this simple peer to peer vpn? Or will the receiving PE routers have the built-in intelligence to examine the RD and place the NLRIs in the proper VRF tables?
No they won't have the built in intelligence because as i said the RD and RT are used at different stages in the MPLS VPN process. So the RD is not used to import routes into the vrf, that is what the RT is used for. So if you don't configure the RT then how will the PE know which routes to import. You can argue it could use the RD in your example and i don't disagree with your example but i suspect the way the MPLS code works is when it comes to importing into the vrf it looks for the RT value.
Whether or not if the RT value is missing it can use the RD i don't know for sure but i doubt it. Happy to be proved wrong though
Thanks, Jon....Hate to have been a pain in the arse....I just want to fully understand how something works and it is sometimes through questions like these that one leatrns the nuances of it all....
By the way, are you working now or still living the good (read:unemployed/independently wealthy) life? :-)
Never have a problem with your questions, they often make me revist technologies to make sure i know what i'm talking about because if i don't i know damn well you'll point that out
Still not working, still through choice but i think this year may be the year i go back to work as there is VSS, Nexus switches etc. to get to grips with.
>> have never configured VRFs from an SP perspective, so I am wondering if configuring the RT is ALWAYS a requirement.
yes, otherwise no other PE nodes can import the VPNv4 routes
>> It seems to me that, unless there is a requirement for INTER-vrf communication or third party vrf communication, as I described before, the RT is really not necessary for the PE to know which vrf to inject a VPNv4 prefix
No, it is necessary to have someone with which to talk with. Actually is needed also on a single PE node making VRF lite and where you want to have two VRFs locally defined to exchange routes and traffic.
without setting an RT only leakage with static routes is possible (some in VRFs and some in GRT but with a common link between)
>> Given this, is the SP engineer still required to configure an RT to support this simple peer to peer vpn?
yes, a simple any-to-any VPN uses a single RT value for import and export but it is needed
>> Or will the receiving PE routers have the built-in intelligence to examine the RD and place the NLRIs in the proper VRF tables?
You have faculty to use whatever RD value with no other requirement to be unique in local node, effective inter site connectivity is built by RT values exported and imported.
Some years ago I've helped to setup and test a provision tool and we made the choice to code in the 64 bit RD value the following fields:
16 bit ASN, customer-id, site-id and a two bits field to discriminate between single and multihomed VRF sites (with two PE nodes connecting to it).
we then give the opportunity to create one or more RT per customer-id with a similar assigning method.
Hope to help
Thank you very much, amici..
One last question....does the RD value configured on the CE router have to match the RD value on the PE router for a particular vrf?
Also, does the CE need to configure the RT - assuming it is not running vrf-lite and doing simple peer to peer with SP?
if the CE acts as multi VRF CE it treats the SP PE as its CE node!
no there is no need to have matching RD or RT values between a multi VRF CE (customer managed or SP managed) and the PE node)
a simple CE has only its standard global routing table with no special features and this has been one of the reasons of the success of MPLS L3 VPN service.
so in a simple CE no RD are required
Hope to help