Main purpose of RD is to make a prefix unique to a VPN. Which prefix belongs to which VPN? When the router receives a bgp update regarding a vpn prefix, it ask this question to he prefix and finds the answer in RD value inside of MP_NLRI of bgp update message.
Think about a PE device which has lots of VPN customers configured. And 2 of the customers are using the same prefix for their sites. So when this router receives this prefix from it's route reflector, how does it knows in which VPN it belongs to? Because each VPN on the PE are configured with a unique RD value, the router decide which VPN according to the RD. If the RD value of the bgp update is 65000:1 then it's the update of vrf custA.
vrf custA rd 65000:100 vrf custB rf 65000:200Route Target
Main purpose of RT is to share routes between VPNs and import/export the routes inside VPNs. RT value is actually an extended community.
With export, vrf custA prefixes on this router are exported with RT 65000:500. This actually means that this router is going to advertise vrf custA prefixes with an extended community of 65000:500.
vrf custA rd 65000:100 route-target export 65000:500
With import, the vrf custA is going to import the routes exported from other vrfs with an RD value of 65000:500. We always want all instances of a vrf accross the network must learn all prefixes belongs to that vrf on all routers. So vrfs are usually configures as below, both with import and export statements.
custA vrf is going to export it's own routes with RD 65000:500 and going to import the routes exported from other vrfs with RD 65000:500.
custA vrf is going to export it's own routes with RD 65000:500 and going to import the routes exported from other vrfs with RD 65000:500.
vrf custA rd 65000:100 route-target export 65000:500 route-target import 65000:500
The capture below shows the RD and RT values. They can be same or not it's up to you. Usually This is why they are confused so much!
Let's think you have a monitoring vrf. In order to monitor the customers routes, you need to know them. Because your monitoring servers should reach to customer routes and customer devices should also answer to the packets from monitoring servers. Server is sending icmp packets and customer devices are sending back a icmp reply to it, basic monitoring. You can success this by configuring a different vrf.
We need to import vrf monitor routes to customer vrfs, we did it. Now we can see the monitoring server routes in vrf custA and custB. We also need to import customers routes to vrf monitor. We can do it by configuring additional imports under monitor vrf for each customer RT. (import 65000:500 and 65000:600) But this is not a good way. When you have new customers, you always need to configure the RDs under monitor vrf. So it's better to use an another RT different then import.
With this solution, the customers can reach to monitor vrf and monitor vrf can reach to customers. But the customers cannot learn their routes.
We need to import vrf monitor routes to customer vrfs, we did it. Now we can see the monitoring server routes in vrf custA and custB. We also need to import customers routes to vrf monitor. We can do it by configuring additional imports under monitor vrf for each customer RT. (import 65000:500 and 65000:600) But this is not a good way. When you have new customers, you always need to configure the RDs under monitor vrf. So it's better to use an another RT different then import.
With this solution, the customers can reach to monitor vrf and monitor vrf can reach to customers. But the customers cannot learn their routes.
ip vrf monitor rd 65000:300 route-target export 65000:999 route-target import 65000:666
ip vrf custA
rd 65000:100
route-target export 65000:500
route-target import 65000:500
route-target import 65000:999
route-target export 65000:666
!
ip vrf custB
rd 65000:200
route-target export 65000:600
route-target import 65000:600
route-target import 65000:999
route-target export 65000:666
!
