MPLS VPNs: RD, RT & VPNv4 Routes Explained Simply

Hello! This is Lazarus at telecomTech, where  telecom and networking technologies... are simply   explained! Today we'll be simply explaining route  distinguishes, route targets, and VPNv4 routes in   the context of MPLS. Νow this video is a part  of a series on MPLS that starts from scratch,  

where each video builds on the next one. So  if you haven't yet seen the previous videos   in this series, it's a good idea to do so at some  point, so that you can get the full benefit of the   information I share here today. Also, subscribe,  enable notifications to be informed of new videos,  

and like this video if you like this video.  In the previous video we introduced virtual   routing and forwarding instances or VRFs,  and we touched a bit upon how they are used   in the context of MPLS to separate one  customer's traffic from that of another.  

We saw how these VRFs are configured on the  PE routers, one for each customer network   connected there. Now we know that the PE routers  use BGP to talk to each other on the MPLS network,   where the next hop IP of the iBGP peer is  advertised using iBGP peerings. MPLS labels,  

in turn, are assigned to those next hop IPs so  that the PEs can find each other using label   switching. The last piece of the puzzle however  is this: How does PE1 here know to which PE it   should send the packets that are destined for  the network behind CE2? What mechanism is used  

to match up the VRF associated with that customer  with the appropriate destination PE? We would like   to use the IP address of the customer ideally,  however the problem is that these addresses are   not unique! Notice here how these two customers  have used the same IP address ranges. In order  

to give customers the freedom of using whatever IP  address ranges they choose, we need something else   to make these destinations unique. To do this,  we use what are called route distinguishers or   RDs. RDs are 64-bit values that are prepended to  these routes to make them unique within this MPLS  

infrastructure. How is that done? Well, let's take  a look! We'll be examining how this network here   is advertised, such that PE1 here will learn about  it appropriately, and in turn, it will inform CE1   of that network. Now keep in mind that everything  we're going to be looking at here is on the  

control plane. No user data is being exchanged!  We're just talking about the advertising of   networks. So initially CE3 here informs PE2 about  its 10.10.20.0/24 network using whatever routing   protocol is configured between these two devices.  Once PE2 receives this, it takes a look at the  

VRF on which the interface is configured and it  checks to see what RD corresponds to that VRF.   The RD is something we configure ourselves. We  see that the VRF BLUE corresponds to RD 100:20.   Now this RD value is a 64-bit number, but we  often write it in this format with two 32-bit  

numbers separated by a colon. The first number  is that of the BGP ASN which in our case is 100,   and the second number is an arbitrary number. Now  you can actually use any values you like within   the range but the use of the ASN is simply  a convention that is often followed. For now  

keep in mind that this simply corresponds to a  64-bit value. So this is our RD for VRF BLUE.  What happens next? When PE2 sends out its iBGP  update, it will prepend that RD to the prefix   it shares like so, and it will place that within  the iBGP update. So now, when PE1 receives this,  

it receives a route with a unique prefix along  with the next hop IP of PE2. Now there's a name we   give to this combination of the 32-bit IP address  with the 64-bit prepended RD, and that's called   a VPNv4 route, which is unique to the whole of  this MPLS infrastructure. We now have a method to  

differentiate between the advertised prefixes of  our customers. Now take a look at this here we see   the routes to the BLUE and GREEN customers being  advertised with the RDs prepended. They use the   corresponding RD for the VRF in question that's  configured in PE2 before being advertised over  

the iBGP peering. Now along with the VPNv4 routes  which are composed of that RD and the IPv4 prefix,   these iBGP updates between PE routers contain some  more information. This is one of the reasons why   the protocol being used to share this information  is called multi-protocol BGP, because it's not  

just the IP protocol that's being advertised,  but additional information that corresponds to   other protocols. Specifically, we are sharing  the RD and the IPv4 prefix which, as we said,   constitute the VPNv4 route. We advertise the next  hop IP address of the advertising PE router which  

is PE2 in our case, and we also advertise one more  piece of information: we advertise the VPN label.   Now what is the VPN label? This is where our VRFs  meet MPLS labels! Well, let me just reiterate   again that we are still talking about the control  plane. We're not talking about user data. This is  

not the header of a data packet. We're talking  about route information that's contained within   the iBGP update. Now the VPN label is actually a  piece of information that's used on the data plane   so when PE1 receives this iBGP update, it gets the  following information: The RD and the IPv4 prefix  

which together constitute the VPNv4 route, the  iBGP next hop IP, which is that of the iBGP peer   that has advertised the route, as well as that  new VPN label that we talked about. In this case,   the VPN label has a value of 19. So now PE1 has  all the information it needs to send user data  

to this destination on CE3. Now our PE1 router  has learned about both routes on CE3 and CE4   and it has them with the information like so.  The only thing differentiating between the two   is the RD. But that's fine because they are  unique in the MP-BGP set of information as  

destination routes. Now the PE1 router must  share this information with the CE routers   so that they know how to reach the intended  destinations as well, but there's a problem.   There's no information that tells our PE1 router  which of the two VPNv4 routs belongs to which  

customer! An additional piece of information is  necessary, and that's where route targets come in.   Now RTs are used to decide to which VRF we import  and export VPNv4 routes on PEs. Like the RD,   the RT is also a 64-bit value that is advertised  between PE routers. It uses the same format of two  

numbers separated by a colon, but the RT is not  shared by default within the body of a BGP update   like the RD is, but it is added as a BGP extended  community value. For each VRF that we configure in   our PE, we must also configure the corresponding  RT that will be used to import and export VPNv4  

routes. So when PE2 shares the iBGP update for the  10.10.20.0/24 network received from CE3, which is   on VRF BLUE, it uses an RT of 100:30, and it puts  that in the BGP extended community so that when   that BGP update reaches PE1, it will use that RT  of 100:30 to differentiate between the two routes,  

and it will know that it must send that over to  VRF BLUE. Thus the VPNv4 route must be exported   to the CE1 router. Now both the RD and the RT must  be configured on all PE routers that connect to   this customer's devices so that the routes will be  unique and so that VPNv4 routes will be imported  

and exported to the appropriate customer devices.  So as you can see, MPLS works with many different   technologies: VRFs, RTs RDs, MP=BGP, an underlying  IGP, as well as LDP in order to deliver a robust   efficient network that provides Layer 3 VPNs over  an MPLS infrastructure to separate the traffic of  

many customers leveraging that ISP network.  So that's MPLS and how it works with VRFs,   route distinguishers, route targets, and  VPNv4 routes. I hope this was helpful and   enlightening for you! For now, I hope you found  this video useful, and if you have, please click  

that thumbs up button. If you have feedback or  comments, please feel free to write them in the   comments below. I always like reading them and  responding to them. And please don't forget to   subscribe and enable notifications so that you'll  be informed of newly published videos. I'm Lazarus  

at telecomTech, I hope this has been helpful  for you, and I'd like to thank you for watching!