29 Virtual Routing & Forwarding Instances VRFs

[Music] in our next section we're going to talk about virtual routing and forwarding incense instances or vr af-s which we'll see is going to be one of the big components that are related to MPLS layer 3 VPN so we'll talk about just in general what our VRS what are the applications we'll talk about what are the different VR where routing protocols and then specifically go through the configuration and the verification of the vrf config both in regular iOS and iOS x r now we'll see that we're going to be spending a significant amount of time on this within the scope of layer 3 VPN so we're not going to go through all of the routing protocols now we'll just talk about what are the options and look at some of the some of the the minor ones of them and then come back a much more detail later when we talk about using bgp as provide our edge to customer edge OSPF EIGRP etc because there are specific caveats for the individual protocols that change when you're using them for global routing vs v RF aware routing and specifically with in the case of l3 VPN now what is a v RF to begin with or a virtual routing and forwarding instance it's essentially a virtual router inside of iOS or inside of iOS X R now what the V RF is designed to do is to separate traffic in both the data plane and the control plane based on a logical interface or a physical interface that you were assigning the virtual router instance to or the virtual routing and forwarding instance to so by default will see that all interfaces are in the default vieira for the global v RF which is when you're normally doing global bgp routing or your normal igb routing we'll see this is where typically the core of the MPLS network is going to be running in the global table and then for the individual customer links those are going to be in separate routing tables separate virtual routing and forwarding instances and the end result of this is essentially a virtual private network so the V RF is going to be running its separate control plane instances in terms of when we're routing OSPF in the global table versus a customer table those are two independent OSP of processes separate neighbor adjacencies their separate shortest path first calculations and then ultimately separate traffic forwarding in the data plane so not only are we separating that the control plane instances but we're also separating the data plane simply based on the routing table so the idea is that have two customers do not have routes to each other then they will not be able to leak their traffic between the different vrf instances now we'll see a little bit later once we get into some more advanced examples there are cases when you can leak traffic between brf's but you have to explicitly do that by importing and exporting routes between the multiple tables or by doing static routing or by using a physical cable in order to leak traffic from one table to another but with the typical default behavior each vrf instance is its own control plane its own data plane and it's going to separate the traffic from the other customer tables now since we're also running separate control plane instances the other important point here is that addressing can overlap between multiple VRS and we'll see when we start to talk in more detail about layer 3 VPN how BGP deals with this by introducing a field that is called the route distinguished or the Rd in the l3 VPN where the VPN v4 or VPN v6 update to make sure that we have if we have overlapping addressing between customers we can keep that separate from a BGP best path selection point of view now once we create the vrf and assign it to the interfaces we then need to still run some sort of control plane protocol in order to exchange our routing information whether this just be simple static routing whether it be policy routing or any of the I GPS or BGP essentially all of the browsing protocols can be vrf aware now we'll see with specifically the behavior of erp OSPF is is and BGP there are loop prevention mechanisms change and some of the other logic changes when we are running in vrf aware instances so again we are going to come back to this in much more detail later in talk specifically about OSPF SPE to seee BGP atrophy etcetera but assume that basically is long as you understand the core logic of how does erp route routing work in the global table it's going to be very similar to how it works in the via RF table now in terms of configuration for regular iOS we'll see that there are two different ways that we can define a virtual routing and forwarding instance we can either say IEP v RF and the name or v RF definition and the name the main difference between them being that the first option is for IP version 4 only the second option is for both IP version 4 and for ipv6 however if you have the older config the older syntax that uses the IP v RF there is an automated way on the syntax to change the format into the new v RF definition syntax so if you're running ipv4 only and then you want to add v6 later you can get the iOS to automatically convert the syntax over for you without having to delete it to delete it and then restart so once we define the bearer of instance we give it a name then we give it this specific value that we call the route distinguisher this we'll talk about much more in detail in a multi protocol BGP specifically with v PM v4 and v PM v 6 but as the name implies this is how we keep the route unique how we distinguish one route from another when we have overlapping addresses in the prefix and the prefix in length and we want to keep this separate from a multi protocol BGP path selection point of view so what I mean by this is that if we have two customers if we have customer a and we have customer B and they're both advertising the prefix 1000 0/24 when we advertise this into BGP we would be running one beth's path a best path selection of a versus B because it's the same prefix but in the case of VPN v4 or VPN v6 routing we're going to add an additional field that is the route distinguisher we'll say the route distinguisher for a is going to be 1 : 1 the route distinguisher for b is 2 : 2 and now we're doing two separate path selection decisions in terms of 1 : 1 : 1000 0/24 vs. - : to : 1000 0/24 and now from bgb best path selection point of view these are going to count as two separate routes we're gonna advertise them as separate prefixes run different best path selections and then ultimately keep the control plane information and typically the data plane information separate between these different customers now you'll see that in some versions of iOS it requires that you configure the route distinguisher in some of the newer ones you can skip over this step but within our scope for l3 VPN assume that we always have to define the route distinguisher then last but not least we're going to apply it to the interface so we either say IP vrf forwarding followed by the name or vieira forwarding depending on if we define the vrf with the legacy syntax the IP vrf or the newer syntax the PRF definition now regardless of which way that we had defined the vrf one of the most important things to remember here is that when you apply to the vrf to the interface it automatically removes any of the IP addressing configuration that you have on the link so this means that if you don't know what the address is before you ply the vrf you want to make sure to look at the running config of the interface beforehand now within the scope of the lab exam if you accidentally delete the address and you don't know what was there beforehand you can revert the virtual routers back to their initial config but ideally you don't have to you don't want to do that because it's gonna be a waste of time to reapply whatever other configuration changes that you had previously made so do yourself a favor look at the show run on the interface or the show IP interface brief make sure you know what are both the ipv4 and the ipv6 addresses before you actually apply the vrf now in terms of iOS XR the logic is going to be pretty similar where we define the vrf globally but then we define the route distinguisher under the bgp process which technically makes more sense because the distinguisher is a function of the bgp route not of vrf light routing or the v RF on its own and then we apply the v RF to the link so just like in the case of regular iOS it means that we have to remove the IP addressing the ipv6 addressing but in the case of iOS XR it doesn't do this for you automatically it'll just give you an air message saying hey you need to delete the address before you can apply the vrf now we'll see that we can do this in one step through a single commit that you can delete the address apply the vrf and then reapply the address and then commit it's just that it is you need to be aware that it is an order of operations potential issue that you're going to run into so let's go ahead and take a look at this from the command line and let's say that between routers one in five and one and two we're gonna run in two separate VI wraps so let's say that this is going to be a and B and then likewise on XR one going to router for will say that this is in vrf a and then over to XR two likewise this is going to be in vrf a now we'll see that in this case we're gonna leave router 4 5 XR 2 and router 2 in the global routing table and the reason for this is that the vrf instance is locally significant on typically the provider edge router so if the PE routers in this case we're router 1 and X are one from the customers point of view they're doing just normal global routing the vrf information does not need to match on both sides of the link and we'll see a little bit later this is one of the ways that we can do route leaking from the global table to a different vrf is by putting one side of the link in a vrf one side of the link in global and then we can advertise the routes between the vrf instance control plane and the global control plane so let's go ahead and start down on router one and first we're going to define our vrf instance so let's say that we have IP vrf a and once we define the name we specify what is the route distinguisher we'll say the distinguisher is gonna be 1 : 1 and then we also have IP v RF be the era of B is going to be distinguisher 2 : 2 now notice here I had a typo when I created the v RF I said IP v RF v as in victor and then I deleted it afterwards and it says ipv4 addresses from all interfaces in the v RF have been removed and I don't know why they do it this way in iOS that they don't have a confirmation dialogue to say hey if you do this you're not only going to delete the vrf you're going to delete any of the addressing in the vrf you're also going to delete any of the routing protocol config so if you accidentally say no IP BR after no vrf definition it's basically just gonna wipe all of that config out of global so you do need to be careful of this you could you know really shoot yourself in the foot with this single single typo okay so next if we look at the show IP BRF it says we have verify and b they have the default Rob distinguishers 1 : 1 & 2 : 2 respectively but right now they're not actually assigned to any interfaces so next we're gonna go ahead and assign these and we're gonna sign them two interfaces gig 1 1.15 and gig 1.12 respectively so this is gonna be a and this is gonna be B and on interface gig 1 1.15 before we make the config change we're gonna show run on the interface then we'll go to interface gig 115 and say IP v RF forwarding is a it says on interface gig 115 we've disabled all ipv4 addresses and due to the disabling of the v RF where it's basically said due to enabling of the v RF but if we now look at the show run on interface gig 1.15 and the end result is that it removed the ipv4 address but notice that it didn't remove the IEP v6 address this is because I'm using the legacy syntax format for the v RF and right now this is only running the ipv4 address family so next step would be to re-enable IP so just copy and paste the syntax that has the IP address and if now we look at the show IP route what we should see is that we no longer have interface gig 1.15 listed in the global routing table so if we show IP route include 1.15 we see that that interface is not there the reason why is that it's now been moved to a separate routing table which we would have to view by saying show IP route for VRA now when you first start to get into this syntax and if you you haven't used VRS before it can be kind of frustrating because basically all of the verification all of the testing syntax now has to be vrf aware to tell the router what particular route occurring to you when you want to do a ping or a trace route or any type of show command you have to make sure that you're using the right table otherwise you could be troubleshooting something that's not broken and you say well hey why can I not ping between router 1 and router 5 when I ping 10.1 dot 5.5 looks like connectivity is broken well in reality the issue is that you're you're sending the traffic in the wrong routing table where I should be saying I want to ping in VR F a and the destination is 10 155 so basically all the commands whether it's a ping whether it's a trace route whether it is a telnet SSH we should see that pretty much everything that you can do in iOS you should see that it should have a vrf option onto it okay well see especially when we're talking about the BGP syntax it can get very involved and very complicated as we're trying to verify one vrf s-- config versus another in terms of what are the peers what are the routes we're learning what are the routes were advertising and you want to make sure that you're very comfortable with that syntax for verification because otherwise you could be wasting a bunch of time within the scope of the lab exam using the question mark trying to figure out does the V ref go before or afterwards or in the middle and that's just something that really definitely needs to be second nature within the the scope of the exam okay so next let's do the same thing with V rfb if we look at the show run v RF right now we have the v RF defined but we don't have it applied to the link level yeah we could also see that this output here Chauvet our show run v RF is really useful to show you the specific config that is v RF aware it shows you the definition globally plus the config on the link level plus all of the routing processes and in this case right now we're now doing any varying we're just having our directly connected lengths okay so next if we show run interphase gig 112 we're gonna say interface gig 112 is on IP vrf forwarding A or B excuse me it says it's disabling ipv4 on the interface and then we're gonna re-enable our IP address okay if we also show we're on a-- on interface gig 112 notice that it kept some of the other config like the the MPLS config but it did not keep the is is config the reason why is that I had already defined is is as a global process so process number one exists in the global routing table so we're not enable we're not able to configure process one both in the global table and the vrf table at the same time because the end result would be that we would leak the traffic between the brf's and we typically don't want to do that we want to keep it separate so likewise if I was to go to the interface and try to reapply the routing process it's going to say you can't do this because it's not in that particular virtual routing and forwarding instance since it's in the global table and your interface is in VR FB okay that's go ahead and do the same thing on X r1 so between X r1 and router for we're gonna say that this is in v RF a and then the interface going over to X r2 this is going to be in B so similar to iOS our first step is that we're going to define the v RF we'll say VAR f a we specify what are the address families that we want to run in this case we're gonna run address family IP version 4 IP version 4 unicast and we'll see a little bit later this is where we're then going to apply our import and export policy for our VPN version 4 or VPN version 6 routes when we're running MPLS layer 3 VPN s so basically what what routes do we want to receive from the customers what routes do we want to advertise back to the customers now in our case since we're running just v RF light we don't necessarily need to define the the import and export route target and then likewise we don't necessarily need to define the route distinguisher which would typically go under the via the BGP process but assuming that we are running l3 VPN the way that we would do this is go to BGP like router bgp one say for vrf a what is the route distinguisher and we'll say this is one call and one okay so we'll save these changes then we're going to apply this at the link level so specifically in this case our link level is going to be gig zero zero zero zero adopt four eleven so if we show run do show run interface gig zero zero zero zero four or eleven and we need to remove our ipv4 address and actually before I do that let's do this just at the link level let's say V RFA and commit and it says we failed to commit one of the items the changes have been reverted look at the show config failed to see what are the errors it says we detected a fatal condition the interface is numbered or unnumbered ipv4 ipv6 addresses must be removed prior to changing or deleting the vrf so again from an order of operations point of view what this means is that I need to know out the IP I can apply the v RF and then reapply the IP address but it has to be in that specific order when I'm doing the commands so in this case what I'm going to do is abort go back to global config go back to the interface then I'm going to say no ipv4 address apply the v RF and then reapply the IP address and then command now it says in this case we still can't do this because we have not only an ipv4 address but an ipv6 address so it'll say no ipv6 address show config and commit it should still give me an error here actually know it now it allows it now if I were to reapply the ipv6 address tell I believe it's gonna argue with me because the vrf is not enabled for that address family so let's now look at the show run interface gig zero zero zero zero adopt 411 and let's say show run vrf which is kind of odd here because right now the V RF is only a enable for ipv4 address family but it allows the v6 address on the link I'm not sure whether this is actually gonna show up in the routing table though so let's say show route V RFA for ipv4 unicast and for ipv6 unicast it does listed as connected but I'm not sure whether it's actually going to accept routing protocol configuration in general though if you want to run a v4 and v6 you need to enable those address families under the V RF mode now in the case of regular iOS I didn't need to do this though because I was using the legacy syntax and the legacy syntax was allowing only ipv4 so if I was to go back to router one and we look at the show round v RF and I think it's an exec round I think we can say upgrade the now maybe it's in maybe it's under the v RF let's say IP v RF a 2 in global config vrf upgrade CLI we want to send it to multi AF mode and we're going to use we'll say common policies this will come back to you and talk about later yes I want to do this number number of ers upgraded it says also you will lose any ipv6 addresses configured on the interfaces so if we look back to the running config of the link if I go to replace this IP address it says you can't do that because the interface is linked to a v RF and the v RF doesn't have ipv6 enabled so now when we look at the show run v RF do you show Ron v RF it changed my syntax from IP vrf to vrf definition which is the new format of the syntax and in this case you do need to explicitly list what address families that you are using so in reality there's no reason to use the older format the reason I'm showing this is just to say that if for some reason they do have it pre-configured with IP vrf you don't have to delete the config in order to change it to the new syntax format you could simply say VAR f upgrade the CLI and then the iOS does it automatically for you but assuming that we want to run both ipv4 and ipv6 we need to go back under the PRF definition and then say the address family is gonna be ipv6 okay both for VRA and for VAR FB if we now show run vrf now it's running both address families but I'm still gonna need to go back to the individual interfaces and then reapply whatever the ipv6 addressing was so I can pretty much just paste this config back in it is going to give me an error when it says you have to use the vieira forwarding command before this particular V RF because now it's in the new index format but the end result is if we show IP route for V RFA and show ipv6 route for a VRA we see that we have both v4 and v6 applied ok likewise same should be true for VfB but we can see these all at the same time if we were to look at simply the show IP route v RF star this shows you what are all the different routing tables so this is a this is B same would be true of v6 if we show IP route or show ipv6 route for a vrf star for v RF actually now in v6 this version you cannot do that so let's see can we say show route no for v6 you have to call them individually so be show ipv6 proud vrf a and notice here that they are case sensitive so uppercase a is not the same as lowercase a so I would say in general unless they give you a specific naming convention within the scope of the exam use all uppercase so then you don't run into problems with mixed case when you're trying to define it or do show commands apply to the interface etc

Channel: Boneless Man

Views: 8,703

Rating: 4.9047618 out of 5

Keywords:

Id: 8EDz8xQM1pA

Length: 24min 48sec (1488 seconds)

Published: Mon Apr 23 2018