Implementing a Multiple ISP Configuration Using VRFs & MP-BGP | Just Another Design to Consider

everyone welcome back to the channel my name's rob so are you looking for the most organized design when it comes to multiple isp connections well if that's the case then you have come to the right place i won't lie the configuration is a little bit complex at first we'll be using vrfs and multi-protocol bgp so that way we can leak routes between vrfs but once that's done you'll be left with one clean flexible and scalable setup so with that being said let's jump right over to gns3 and i'll show you what this is all about [Music] we look over here at the topology we have uh two isps uh and then they all terminate into r1 so i'm kind of faking the internet up here so these clouds uh in gns3 actually terminate into my actual physical computer network so we're essentially just using virtual routers right here and performing that on the isp side so that way it looks like the traffic coming from these isps is directly connected uh into these uh subnets so they both terminate into r1 this is actually going to be the center of the configuration uh for the entire video actually so i haven't configured anything on r1 yet except for the host name so if i issue the show run command everything is going to be at its defaults okay and then everything southbound of this router is just layer two so we have a layer two switch here with a pc hanging off of it and this is the pc that we're going to be using at the end to test to make the make sure things work so if we look at these subnets they are all uh rfc 1918 private addresses again that's because like i just mentioned we're faking the internet so it doesn't really matter for this example but we're looking at 172 16 1.0 24 for isp1 so it's interface that's facing us and for isp2 it is on the 10 0 0 0 24 network so we have the dot one over here and then dot one over here so isp one uh we'll have the ip address of 172 16 1.1 then over here 10.0.0.1 uh on the lan side of our router we are on the 192.168.1.0.24 subnet with the dot one up here on r1 okay so we are going to configure um three vrfs we're going to have a wan one a wan ii and a lan vrf after we create the vrf we're going to leak routes between isp1 in the lan and then vice versa and then isp2 in the lan and vice versa so again like i stated at the beginning of the video this kind of cleans up the routing tables a little bit because you're not lumping everything into the global routing table and you're essentially by using vrf's you are breaking the router up into separate virtual routers so in this case we're looking at three virtual routers and we have that more granular control over of what routes are populated where we're going to configure those vrf's bgp and then we're also going to move to the uh ipsla configuration so we can have failover as well as nat and everything like that so let's pop open r1 and we will start with the vrf configuration so i'm going to have three vrfs when one went to and land so i'll start by saying vrf definition when one address family ipv4 and we will give it the route distinguisher of one one so we're going to keep this real simple and so i don't have to go back into the vrf configuration um i'm going to add the route target export and import commands right now and i can do that because i already know i'm going to assign went to a route distinguisher of 2 2 and the lan i'm going to assign a route distinguisher of 3 3. so when i say route target export 1-1 what i'm essentially saying is is that when i fire up multi-protocol bgp i'm allowing routes to be exported into multi-protocol bgp so that way i can import them into other vrf so we are exporting our own routes since we are 1-1 and then i want to import 3-3 which again i haven't configured it yet but when i do the land vrf will have the route distinguisher 3-3 so i'll say route target import three three okay and then vrf definition when two address family ipv4 route distinguisher 2-2 route target export 2-2 route target import 3-3 so again we're we are going to be exporting our own routes into multi-protocol bgp as well as importing routes from the land vrf okay last but not least vrf definition lan address family ipv4 route distinguisher 3 3 route target export 33 and then since we want to import into the lan vrf routes from both isp1 and isp2 we're going to say route target import 1 1 and 2 2. okay so the vrf's have been configured the next thing i'm going to do is move to the individual interfaces and apply those vrf's to uh the corresponding interfaces so we'll start with gig zero for isp move over to gig001 for isp2 and then gig007 for the lan so i'll say interface gig00 vrf forwarding when one no shut interface gig zero one vrf forwarding when two no shutdown and then interface gig07 vrf forwarding lan no shutdown okay so let's work our way back around starting with gig00 and start assigning ip addresses so we'll go back to gig zero zero and the ip address will be so like i mentioned since this is the this segment right here is uh one seven two sixteen one dot zero slash twenty four and this is the dot one uh we will say on gig zero zero the ip address is 172 16 1.2 and in case anybody out there is wondering why i'm not using slash 30s for these which i can completely understand if that's what you're thinking uh it's because this was uh when i set this up i was mainly trying to simulate uh an isp like a residential isp like comcast or spectrum where they just throw you on a um you know a big giant subnet and uh this is not actually meant to be a point to point link like uh if you are running bgp with these providers okay so ip address 172 16 1.2 slash 24 mask gig 0 one ip address 10 0 0 2 24 mask we already did a no shutdown um interface gig07 will be 192.168.1.1 okay so let's go ahead and issue the do show iprout command and we have nothing nothing at all because this is the global routing table we're using vrfs for all of our interfaces there's gonna be nothing in there so now we have this more like i was mentioning this granular control over again like what routes we want to um leak between vrfs but also what routing table we want to see so we can say do show iprout when one i do this every time and then get stuck in this and then when control shift six doesn't work okay it looks like it did that time but i know uh some of you watching are like you know what when when uh you see translating whatever and uh the control shift six doesn't work it might you might as well just take a coffee break um so we'll say do show iprout vrf lan1 and we see that we have routes in the way on one vrf that only pertain to isp1 so we have a directly connected route so we have the one seven two sixteen one dot zero slash twenty four subnet and then local would be that one seven two sixteen one dot two uh the ip address that we just assigned to gig zero zero and it'll be the same four-way and two and the same for lan we only see in these vrfs what is directly connected what are directly connected interfaces that are part of these individual vrf so the next step is is to start leaking routes between vrfs so we already configured the vrfs themselves we configured the route distinguisher and the route target import and export commands we configured the interfaces with uh what vrf they belong to as well as an ip address so now if we go into router configuration mode so we'll say router bgp and we'll just say one for the autonomous system number since it doesn't uh doesn't really matter since this is a lab and we'll say bgp router id all ones and then address family ipv4 vrf when one and this is where we're going to redistribute what we want between vrf so we will say we just want to redistribute everything that is a connected route so we'll say redistribute connected and then we're also going to have a static route for our default pointing to this router on isp1 we also want that to be visible in the lan vrf so we also want to redistribute static along with the default information originate command now uh really quick and i don't want to go um off on a side track but let me just pull something up really quick for anybody that's curious i thought that i would throw this in here really quick because i um there are multiple ways to redistribute a default route in bgp there are three of them in fact and i made notes of this so let me just pop open my documents go into cisco bgp bgp default route originate so um we use the the default information originate command and the conditions are that the default route exists in the routing table plus you have to redistribute static so you see that the the default route doesn't exist yet because we haven't created it but it's going to but along with redistribute static and default information originate it will originate that default route the two other ones are you can say network and then all zeros and with this this is kind of like saying default information originate the default route still needs to exist in the routing table in order for that to work and you could also go if it was traditional bgp peering obviously we're using bgp in this example uh for um leaking routes between vrfs but you could issue the neighbor and then whatever the neighbor was you know blah blah blah blah and then default originate after that and that will originate the default route unconditionally so with the neighbor you know say 192.168. 1.10 default originate the default route does not have to be in the routing table for it to originate the default route so i just uh i didn't mean to become sidetracked i just wanted to throw that out there for anybody that's curious um and maybe i can save them some time down the road in figuring out the different ways to redistribute a default route in bgp okay so back to this we have redistribute connected you want to throw everything into this that's connected and everything that's a static which is mainly for the purpose of that default route so we're going to hop over to wan2 and we're going to say the same thing redistribute connected redistribute static and you know what i'm actually getting a little bit ahead of myself right now i'm going to have to go back in here and change this because i'm going to have to add a metric because the idea when we're done is that ip isp1 will be primary isp2 will be secondary so we're going to be performing route failover by just saying redistribute static uh under both of these address families for wayne uh one in wayne two they're just going to fight over each other and since there's no uh equal cost multipathing by default in bgp even though i could change the ma change that by the maximum paths command by default it's going to pick one of them and when we redistribute things the metric is lost so even when we configure the default route and we put a higher metric or should i say a higher administrative distance uh on isp2 so that way isp1 will be primary and then of course we're going to link it to a tracking object once it's redistributed into multi-protocol bgp that metric is lost so we need to uh set that in here so we're going to be revisiting this and we're going to be setting a metric on these statics when all is said and done but as of right now i'm going to leave it as it is and then just move on to configuring the lan vrf so with the lan we're just redistributing connected okay so let's exit back out to global config and issue the do show ip route vrf and we'll say when one do you see the difference from when we previously issued this command you should notice that we now have a bgp route that is directly connected on gig zero seven so we now have the one nine two one six eight one dot zero slash 24 network visible in the way in one vrf so when traffic is coming in from isp1 it knows how to get there so we just leaked that between the land vrf into the way on one vrf and the same will be true for wan 2. see we have that bgp route there and the same will also be true of the land vrf so we should see two routes for both providers now we don't see a default route yet or anything because we haven't configured that yet but that is what we're going to be moving to next so the next step is going to be configuring first i think i want to do a tracking or an ipsla probe and then link to a tracking object so that way we can set ourselves up for route failover then we'll create those default routes change the metric and multi-protocol bgp and configure nat so let's start with actually um for i don't want to waste too much time talking about it for anybody that might already understand this but for those of you that don't let me just give you a very brief uh overview so we have isp1 isp2 isp1 is going to be primary isp2 will be secondary the way we accomplish this with route failover is essentially tracking the status of the primary isp since we're not running bgp with the provider there's no dynamic routing protocol running here the only way to find out if they're down or not is to send like a sonar over the wire and see if we have reachability or not so you want to pick a well-known ip address on the internet so say something like google or a typical one is google's 8.8.8.8 dns servers um you might want to track two so that way you don't erroneously fail over if that service happened to be unavailable for whatever reason but essentially you set up your ipsla monitor to ping that well-known service on the internet and then tie it to a tracking object you tie the default route to that tracking object so if that tracking object goes down the route will be pulled from the routing table and then we're going to have a secondary default route with a higher administrative distance that will then be installed in the routing table uh once that one is pulled for the primary and then that will essentially guide all traffic through isp2 so that is what we're doing right now we're gonna configure the ipsla monitor schedule it configure the tracking object default routes and then we'll move on to nat so we'll start by saying ipsla1 icmp echo and we'll just use 8.8.8.8 now like i just mentioned in production you probably want to track more than one uh well-known ip address so again just it would be very unlikely but this once we tie this to the default route and this this is going to be what's keeping isp1 alive so if for whatever reason 8.8.8.8 or whatever ip address you choose to ping were to go down then that could cause the link to or the route to flap over to isp2 even though isp1 wasn't actually in fact down so what you can do in that scenario is create two icmp i'm sorry ipsla probes two tracking objects and then essentially tie those together into a third tracking object like an aggregate uh tracking object and then tie that tracking object to the default route so what would need to happen is there would need to be no reply from either of those addresses in order to cause that third aggregate tracking object to actually go down and pull that route from the routing table so uh for this example we're just using one for the sake of time so we'll say icmp echo 8.8.8.8 source interface gig zero zero say frequency 10 and then vrf wan one okay and that's all there is to that we just need to schedule it so ipsla schedule one start time now life forever and then track one ipsla one reachability and then uh in production you'd probably want to set a delay as well for up and down but again this is a lab so i'm not going to worry about that not too important for this so we'll do do show ipsla summary and it has timed out why did that happen well the reason that happened is because the router doesn't actually know how to get to 8.8.8.8 so if we do do show iprout vrf lan1 we we don't have any way to get there so um this is where i need to make something uh additionally clear i've seen this set up wrong uh several times and i'm not exactly understanding uh why but uh some might just stick a default route in there and say okay well it needs the default route and we can get to 8.8.8.8 or whatever well-known ip you choose to ping ipsla probe will get a response tracking options will come up but here's the thing if the default route is tied to the tracking object and the ipsla probe is tied to the default route it's either not going to come up to begin with or if it does once it goes down once isp 1 goes down it's not going to come back up because the default route will be pulled track one will be down and it's the ipsla probe is relying on that default route to get out to 8.8.8.8 so what we need to do is we need to specifically tell the router you need to go this way to get to this well-known address that is being probed by the ips la monitor so we can do that one of two ways we can create a static route for in this instance we're tracking 8.8.8.8 the only problem with that is that all traffic then that traverses this router uh will be forced to go that way so even if this pc down here say it's using 8.8.8.8 is its dns server uh it's going to take the path of isp1 every time because there's a static that says hey go out this way no matter what the cleaner way to do it is to create a route map and then essentially assign it to the router as a local policy so that way we say hey any traffic originating from the router itself icmp traffic destin2 8.8.8.8 send it out this way so we're going to do that and we're going to start by creating an access list and we'll just say we'll call it um self because it's this is going to pertain to uh the router's self traffic so this ic or ipsla monitor is going to be self traffic originating from the router itself so we'll say i p access list extent extended self permit icmp any to host 8.8.8 route map self match ip address self set ip next hop 172 16 1.1 actually set ip default vrf when one next top 172 16 1.1 so once we apply this route map it's going to tell the router any traffic generating generated from yourself send it to or should i say more specifically because we created that access list any icmp traffic coming from yourself to host 8.8.8.8 send it this way and we can apply this by saying ip local policy route map itself now as soon as we apply this we should see this come up at least within 10 seconds so just give that a moment and we are back up do show iprout vrf1 there's our default and now if we do a do show iprout vrf lan we should see that default route leaked into the lan vrf and there it is so we have a default put in there by bgp and it's kind of nice as well because it also tells us in parentheses uh which vrf it is so we see when one right there okay so the next thing is is we need to create a default route for the secondary so this is going to be the one with a higher administrative distance and then remember we'll have to go back into multi-protocol bgp and modify the metric because it doesn't matter what we set it in the vrf once it's redistributed into bgp that gets the the metric and the administrative distance gets it's muddied uh if you will so but we'll create this first and say iprout vrf wan2 quad zero quad zero ten 0 0 1 and we will put a um we'll put an administrative distance of 10. do show iprout vrf lan do you see why we need to go back into bgp and change that because now it automatically chose this as its preferred path we want when one to be primary so even though i put that metric in there so if you if i do a do show run type section ip route we see that this one is the default administrative distance we just have track one on there because it's being tracked this one isn't an ad as an ad of 10 but once we redistributed it into bgp it still wanted to choose when to despite of this right here i and i just want to clarify something i believe that this actually is the administrative distance and not the metric because i know i keep switching back and forth calling it a metric and then the administrative distance but let me just uh use the context sensitive help here a distance metric so i'm assuming that means administrative distance and i think i can confirm that by issuing the do show iprout vrf wan2 command and there we go okay so yes that is the administrative distance in the metric would be there okay so let's go back into bgp so we'll say router bgp one address family uh we're actually going to leave the way on one vrf alone we're just gonna leave the redistribute static we're not to mess with the metric just with wan2 so we want to make it match the metric uh that we assigned it when we plugged it into the wind to vrf's routing table so we'll say address family ipv4 vrf when to redistribute static metric 10. now if we issue the do show ip route vrf land command we are back on wayne one for our primary so really quick let me just make sure i have reachability out to the internet uh from one of these interfaces nothing else is going to work because we don't have nat set up and obviously we're not routing we don't have uh we're not running a routing protocol or anything like that to share routes between these routers so stuff up here wouldn't be aware of the 192.168.1.0 network or anything like that but just to make sure we have reachability out to the internet let me see if i can ping from each of these vrfs out to the internet um sourcing it from the uh isp uh facing interface so i'll say do do ping 1.1.1.1 we want to specify the vrf so when one source gig zero zero okay something about 1.1.1.1 is always funky for some reason when i when i uh send an icmp echo but you can see that we do have reachability there and we have reachability via wan ii although not very good good enough though okay all right so uh let's move on to uh finalizing this configure nat and we're going to test and see if this works using pc1 so let's go to gig00 we'll say ipnat outside interface gig zero one ipnet outside interface gig07 ip nat inside okay let's create our nat access list so we'll say i p access list um we'll keep it simple i p access list standard nat in production you want to be more granular more specific but in this lab i'm just going to say permit any and since we have two different paths and since from the inside the outside the order of operations goes routing and then translation we need to create a route map and apply it to our nat statement to say hey if you're going this way translate it to this address if you're going this way translate it to this address so we'll say route map nat 1 permit 10 match ip address nat match interface gig zero zero and then route map nat two match ip address nat match interface gig zero one okay now we can go in here and say ipnat inside source route map nat1 interface gig zero zero vrf lan overload and then ipnat inside source route map nat to interface gig zero one vrf lan overload okay um i think we have reached the end so let's let's test it out let's uh go over to pc1 see if we can reach the internet i already set the ip address on pc1 as well as a dns server so i'll say ping google.com and we have reachability go to r1 do show ipnet translations you see that we're translating so inside local it's the ip addresses for pc1821681.10 inside global which is the ip address on this interface right here 172 16 1.2 and then we have the ip address uh whatever when we ping google whatever that resolve to which it looks like it's 172 217 4.78 so we have reachability out to the internet let me simulate a failure of isp1 and see if we have this working so again up here i'll do a do show ip route vrf lan just to show once again that we're going out wan one and to simulate the failure what i'll do is i'll just suspend this right here which is going to temporarily give us a timeout and on router 1 you should see the tracking object go down as soon as that happens this route is going to fail over so we see that the ipsla monitor just went down again we'll issue the do show ip route vrf lan command we should see that we're now on wan 2. which we are it's in an icmp echo and we are now back on the internet via isp2 i'll unsuspend this to make sure that we switch back over so we see that track one went from down to up this route should now be changed back over to wan one and it is ping google.com and we're back through isp1 and that is all so uh video ran a little bit longer than i originally anticipated um uh i guess that's how it goes sometimes though so but anyways i really hope that you learned something from this video i hope that it was informative uh please let me know if you have any comments leave them in the comment section below or you can reach me by email at rob rmtechcentral.com i'd like to thank you for watching this video and i'll see on the next one

Channel: Robert Mayer

Views: 193

Keywords: Cisco, BGP, MP-BGP, VRFs, VRF-Lite, Multiprotocol BGP, Redundant ISPs, Multiple ISPs, Dual ISPs, Route Leaking, Route Distinguisher, Route Target

Id: xvj7Mw8HqW0

Length: 39min 47sec (2387 seconds)

Published: Sun Jun 27 2021