31 MPLS Layer 3 VPN Overview

[Music] in our next section we're gonna start to combine what we previously saw in our MPLS example with BGP routing and also with the virtual routing and forwarding instances the VR F's put these together to find to form our final solution which is the layer 3 MPLS VPNs that are b2b based now in this section specifically we're going to talk about what are the different components in l3 VPN where does VPN v4 fit in where do the route distinguishers and Route targets fill in and then what is the difference between the transport labels and the VPN labels we'll take a look at some basic configuration examples and then in later sections we'll start to get into the details of what are the different l3 l3 VPN designs in terms of what are the PE to seee routing variations what are the intra a s vs. inter a s options and then for nras what are the different ways we can do exchange in terms of options a B and C both for l3 VPN as well as for l2 VPN now ultimately layer 3 VPN s for MPLS have two basic components we have the separation of the customer routing information which is going to be based on the virtual routing and forwarding instances and then we have the exchange of this information with inside of the service provider that is going to be based on BGP now we talked about specifically what the vr af-s do in terms of separating both the control plane and the data plane on a per interface basis we're then going to combine this with the BGP routing over the MPLS core in order to exchange the customer routes for beyond multiple hops because with our previous example in vrf flight when we want to exchange the information in the routing table we have to do this on a hop by hop basis so what I mean by this is if we go back to our previous design and in the topology we had a case where we were running a VR flight config that went between router 4 and xr1 we had this in VR F a and let's assume that we want to exchange this information down to router 7 that it's going to be in the same virtual routing and forwarding instance so this means that means that we would have to run an instance vrf a between router seven and xr3 vin instance of vrf a between XR one and xr3 another instance of VAR fa between XR 1 and XR to basically on a hop by hop basis to get all the way to whatever the final destination is that we're trying to reach so the problem then becomes within the service provider core we don't want to have have to have every single hop along the way know about the final customer routes and have to define this vrf on a hop by hop basis so the solution for this then is to combine these two features together where we're going to be running BGP between the service provider edge routers the provider edge routers and we're going to exchange the customer information encoded into a new BGP update and this is going to be accomplished through two things in the BGP update the route distinguisher plus the prefix which makes up the VPN v4 routing information and then the MPLS VPN label which is going to be an extended community attribute of the actual BGP update now from a high-level overview and when we look at the total steps in order to form the MPLS l3 VPN the first thing we need to do is to make sure that we establish a label switch path between the provider edge routers so in our particular case if we're gonna say that our pease our XR 1 and XR 3 this means that we already have to be running igb routing between them which is typically either going to be either OSPF or iOS is and then we have to run some sort of labeling which is typically going to be the label distribution protocol and again as we previously saw with LD P the main advantage of this is that it's very plug-and-play that under the OSP a process or under the iOS is process you simply say MPLS LD be Auto config and it's going to run the protocol everywhere the end result is that whatever igb routes were advertising we also have an MPLS label bound so we have an any to any full mesh of label switch packets or label switch tunnels ok next step would be that we have to exchange the routes with the customer so in our particular case this is going to be from XR 1 to router for from router 3 to router 7 from router 2 down to router 10 we need to be running some type of control plane routing exchange between them this could be IGP this could be BGP this could be as simple as static routing could be policy routing doesn't really matter but we have to run some sort of vrf aware protocol in order to get the routes in from the customer to the service provider edge now once we've accomplished that we then need to take these routes in exchange and them between the PE routers within the MPLS network so this means that we're going to be running i bgp and we're also going to be advertising an MPLS VPN a label for these routes or more specifically we're going to be running the VPN version 4 address family between the PE s now in our previous examples of internal BGP routing the same logic is going to carry over for VP and v4 BGP where we could either do a full mesh of ibgp we could do route reflection we could do confederation just as long as somehow we advertise the routes between the PE routers and we use the next top of the BGP update to send our traffic towards the MPLS tunnel that is ultimately how we're going to be separating the traffic in the data playing and when the customer traffic transit over transits over the service provider core so the very last step is going to be this actual label switch path the LSP so the LSP is going to be following the IG p+ l DP tunnel or what we what we refer to as the transport label between the loop X of the provider edge routers now we'll see in later examples once we start to get into details of troubleshooting l3 VPN this is one of the the simple ways that you could cause problems that if for some reason you're advertising the route with a next hop value that is not reachable via a label switch path it means that ultimately the customers traffic over the MPLS core is going to get dropped but again the simple way to prevent against this is that if we're running I GP + LD pees everywhere and we're averaging advertising our loop X into I GP it should mean that we have a full mesh of connectivity everywhere in terms of our label switch path now specifically the way that we're going to be exchanging the updates between the provider edge routers is an extension to BGP that's defined in RFC 4364 which is BGP for MPLS Virtual Private Networks where specifically this is going to be a new address family identifier in sub address family identifier which is 1/1 28 which we commonly refer to as simply VPN v4 now VP and v4 routes are going to be adding a key attribute to the update which is what we call the route distinguished or the Rd now the Rd will see that we can have this as a unique value per provider edge router but at a minimum we have to have this as a unique value per customer so typically one customer vrf a is gonna get route distinguisher one call in one a different customer vrf B is going to get distinguished or 2 : 2 and then from a BGP path selection point of view this is the way that we're going to keep the traffic separate in the control plane now in addition to the actual routing update the VB MV for route is also going to include the MPLS label this is the way that we're going to keep the traffic separate in the data plane so when we specifically look at the VPN v4 network layer reach ability information or the NLRA format we're including the route distinguisher the IP prefix and the length the next hop in the MPLS label beyond this the rest of the BGP attributes are going to stay the same as if it was a regular ipv4 unicast route so this means thing things like the weight local preference AAS path origin code med the communities the processing of those in the BGP policy application would remain the same from ipv4 unicast to VPN V for unicast the main thing that we really care about that has been changing is the route distinguisher which makes the route unique and then the VPN label which is ultimately going to control how we forward the traffic in the data plane now as I mentioned previously the reason that we use the route distinguisher is that multiple customers might be advertising the same addressing information into the BGP network so let's say for example that the customer attached on router 6 let's say that router 4 is customer edge router 5 is customer edge and router 7 is customer is it 10 as well so we have between router 4 + XR 1 XR 1 is the provider edge router let's assume that we're receiving the network from router 6 that is 10000 / 24 and we'll say that this is going to be in VR f/a okay we also have customer router 7 who is in VR FA we're advertising this 10 network from XR 1 / 2 router 3 we're advertising this in a bgp bgp evpn v4 update and then we have another customer that's router 10 that is advertising in VR FB the same prefix 10000 / 24 so if router 2 advertises this this update over to XR 1 again through VPN v4 BGP from a BGP path selection point of view XR 1 would get confused to say well which customer really owns this route if both of the routes are equally 1000 / 24 I'm not going to be able to tell the difference between them and how do I know that I'm not advertising to router 3 that the destination we're going to is really this customer B this is what the job of the route distinguisher is so the only thing the RAB distinguisher is doing is making the route unique it's additional padding that we're that we're inserting into the front of the B TV prefix to say that when you do your path selection decision you're now you're no longer doing it against 10000 / 24 you're doing it against 1 : 1 : 10000 so less 24 or 2 : 2 : 1000 / 24 so this means that customer a emps prefixes even if the routes overlap or I should say even if the IP prefixes overlap the route does not overlap because the route distinguisher is giving it global significance now the route distinguisher however doesn't control which particular VPNs the route is actually going to belong to this is what we use the route to target for so the route target is an extended community of the VPN v4 route and the key is that we can have multiple targets on a per route basis whereas the distinguisher there will be only one her prefix but the route targets we can have multiples of what this is gonna allow us to do is have granular control over what particular sites will have reach ability to each other by using import and export policies that specify who is able to receive who is able to advertise the routes based on the specific route targets so this commonly gets confusing though because the route distinguisher and the route target have the same format from a bit bitwise basis and from a visual formatting but the main difference between them is that that's the distinguisher is used to make the route unique there's only one per prefix the route target is what defines the VPN membership there has to be at least one for the route but there can be multiples now likewise the route target like I mentioned the reason that it's confusing it is that is that it's the same type of field so it's an 8 byte field defined as a b2b extended community format is similar to the route distinguisher where we have typically the BGP a s number : a locally significant number or the IP address format of the provider edge router calling a locally significant number now we'll see that in terms of receiving VPN v4 routes there is an exception to route filtering where when you receive an update in you're only going to accept routes that match a target that has that is matching your local V RFS now we'll talk about this in more detail later what are the other implications of this in terms of inter AAS routing whether we're doing in Ras option B option C we'll see that we need to change this this filtering behavior around but you can think of this as an automatic optimization that if we were to have let's say a route reflector design and let's say that router 1 is going to be our route reflector for the VPN v4 address family and we have again brf's a on the left a on the right a on the right we have B on the bottom and we have B on the top so router 2 is receiving this route in advertising it to one one is advertising it over to xr3 xr1 receive this route in from for it advertises it to router one a router one reflects it to XR 3 XR 3 says I have routes that are coming from vrf a and VFD but I only have yarrabee configured locally so ideally I want to discard those other prefixes and that's the default behavior of the route target filter that when you receive an update inbound you look at the extended communities and if the route target value does not match a local VRS route target import policy you delete the update now we'll see later there are cases where you would not want to do this and one of the main ones is when you are running as a route reflector but the route reflector ignores this filter and it reflects all of the VPN updates to all of the other remote peers but just keep this in mind that this is the default behavior that you only accept the routes that match against one of your local route target import policies now as I mentioned additionally we can't have multiple route targets per prefix this is going to allow us to establish complex topologies where we can do not only a full mesh of connectivity where every site has reachability to every other site but also we could do hub-and-spoke we could do Central Services where the service provider is hosting a service on behalf of the customer like they're doing shared mail hosting or share shared VoIP like voicemail hosting but in the vast majority of cases we're typically going to have a full mesh of connectivity between the layer 3 VPN sites but the idea is that we define this by configuring what is the route target import and the route target export policy now the VPN update though as I mentioned is used to separated the control plane of the customer not of the data plane because we receive the route in from the customer through OSPF through BGP through whatever protocol we advertise it into a VPN v4 route and it goes to the other customer sites now once the advertisements are done then we start to receive the traffic in the data plane and we need to figure out that if we have multiple customers that are located on the same PE router so let's say from X are ones point of view that it has a case where we are attached to customer a on router 4 and customer B on router 8 and let's just assume again that they're advertising the same prefix we have 1000 0/24 and we have 1000 0/24 now we said from a BGP updating point of view the way that we can keep these separate is by adding the different route distinguisher we could say 1 : 1 : 10000 and 2 : 2 : 10000 so now whatever other devices are in the middle they can say that there's a difference between path a and path B because the route distinguisher is making them unique however when the traffic comes in in the data plane the IP packet doesn't know about the route distinguisher the IP packet is simply going to say the destination that I'm trying to ping is 1000 1 we might have 1001 on router 8 we might have 1000 1 on router 4 so somehow this provider edge router needs to be able to tell the difference between the two of them this is where we see the difference between the MPLS transport label versus the VPN label so in l2 VPN in l3 VPN implementations we need at least two MPLS labels in order to keep track of what provider edge router is the traffic going to egress out of to leave the service provider network and once it gets to that PE router which customer is it going to go to now the first of these the topmost label or the transport label is telling the service provider core which provider edge router are we going to use to egress the traffic or what is the exit point now this label is the one that is typically derived from IGP because we're running l DP + IG P in the core of the network and this is the one that's saying well how do you get between XR 1 and router 3 the way we do that is label switch packets 2 3 3 3 3 we label switch packets to 1111 1111 and these these routes were already advertised into is is or already advertised into OSPF any of the devices in the core of the network they should already have reach ability to those now once the traffic gets to the PE though xr1 needs to say why if packets that are going to 1000 won 1000 won but they're two different customers how do I know that the way is by encoding is second label in the stack so the VPN label this is the one that is derived by the bgp VPN v4 advertisement once the traffic actually arrives at the PE router this is the one that tells it what customer is a destined to so we'll do a secondary lookup once we remove the transport label do a secondary lookup on the VPN label and then say hey this VPN label really relates to vrf a on interface gig zero zero zero zero 1 1 1 and I now know to forward the packets out there so we'll see that the key with VPN v4 is that it's separating the control plane information but then also using this label to encode in the data plane how are we actually going to forward the traffic when it gets to the egress PE okay so this questions here so the control plane is defined by the route distinguisher and the data plane is defined by the route target the the route target of the route distinguisher they both define the control plane only what defines the data plane is the VPN v4 label that's advertised in the the VPN v4 update which we'll see in a couple minutes here when we actually do the implementation how do you tell what number that specifically is and then where is that going to be used for label switching in the the core of the network but the b2b update in terms of the route distinguisher that's what's keeping the path unique in terms of path selection the route target is is defining the VPN membership and then the VPN label is what's keeping it separate in the the data plane there's another question so the VPN label is created when you start receiving VPN v4 routes for a particular vrf located on the PE via a route reflector it doesn't necessarily be via our route reflector but it's when you redistribute from the V RF into bgp or more specifically when you do a VPN v4 export from the vrf end of EGP that's when the VPN v4 update is created and that's when the MPLS label is created so what we'll see specifically in this case is that if router 6 is the final destination and router 6 is advertising updates out to router 4 ok let's say that we're gonna run a GP here let's say we're running EHR P that goes between router 6 and router 4 and 5 and then between router 4 and 5 we're running BGP with the provider so router 4 and router 5 these are going to be the customer edge devices router 1 and XR 1 these are going to be the provider edge these updates are going to come in is regular ipv4 unicast BGP and we are converting them by exporting them to VPN v4 unicast when we do this export it's basically like a redistribution from one table to another when we do the redistribution that's where we create the VPN label then when we do the advertisement router one is gonna advertise over to router three hey I want you to use label one two three four in order to get to the destination and the next hop of the update is pointing towards my loopback so router three is going to say well I need to get to one one one one first I already know this via IGP and I already know this via LD P so I'm gonna take whatever the IP packet is that came in and I'm gonna put on the top of it my transport label so the transport label this is the one that is defined by a I GP and LD P then in after the transport label I'm going to put in the VPN label so the VPN label is going to be whatever there's one two three four is that was received from the VPN v4 update then inside of that we're going to have the original IP packet whatever router seven is sending the packet is going to be switched through the core based on the transport label it's eventually gonna arrive at the final destination router one router one is going to see the VPN label it's gonna do a lookup and say hey this route this relates to customer router five and then I'm going to forward the traffic out to them so the core of the network is going to be forwarding based on the outer label the edge of the network is going to be forwarding based on the inner label the VPN label there's another question here is there a correlation between the VPN label and the route target no there's not so the VPN update will only have one label but it can have multiple route targets so whoever is is learning the the label number that is locally significant between those two VPN v4 BGP peers so you may see the number 1 2 3 4 used again and transport somewhere else but it since it's locally significant between you and your directly connected peer you will see that it's normal that the label numbers overlap but they have different significance depending on where they are in the specific label stack if they're on the top of the label stack that's the transport label talking about the provider edge exit if it's at the bottom of the stack that is the VPN lei Abell that's talking about the final customer destination now let's see the logic is going to be similar in terms of layer 2 VPN where the top label is typically the LDP bound label going to the transport the exit PE and the bottom label is going to be the pseudo wire label that is either generated from a targeted LDP session or from a BGP vpl VPLS section session excuse me which is going to be a new address family it's basically address family VPLS or address family LT VPN but we'll see once we understand the l3 VPN logic it's going to be a little bit easier to understand how the l2 VPN logic works and we'll see the ltu VPN configuration is actually a lot simpler than the the l3 VPN is now there's another question here the VPN label is advertised via multi-protocol BGP correct

Channel: Boneless Man

Views: 2,707

Rating: 5 out of 5

Keywords:

Id: 9fuFA45b0O4

Length: 24min 30sec (1470 seconds)

Published: Mon Apr 23 2018