1. get some rest before screwing your brain
2. increase the coffee-dose
3. if 2 doesn't help, switch to coffee intravenously
4. tackle the problem after a good night sleep
5. mark the question and skip it to deal with it later
6. in my eyes there is exactly this one method to tackle the problem but I guess they are asking if you are modifying the routing table in different ways. I can imagine using SLAs to modify a static route, AD and redistribution-rules, so 3 methods.
7. don't take this post too serious, I have to say that this kind of question in your book is just to give you a hard time
The IV coffee works best. The problem with a question like this is that there are many variables. So how many different ways to do sla = many. How many different ways to do pbr = many. In addition, are you concerned about doing policy based nat and are you considering that part of pbr? So many * many * ? == MANY
Modified--I didn't realize this was a Challenge Q. Hope I didn't give too much away.
oh man, shoot, thanks Paul for bringing up one topic not even popping up in my mind. Policy NAT is a wonderful thing to make it horribly complex and variable. Maybe one needs a security-related brain like Pauls and not a voice-related brain like mine to get this into consideration as another variety - lol
And the nicest thing at all: It always throws me off when I try to remember what comes first when a packet traverses the router... ACL, Route-map, NAT, routing table......
Sorry for not being of much help here, too many variables. Let's then go another path down the road:
8. Rephrase quesion please....
lol thanks guys. Actually I'm looking for some ways to do this using SLAs and PBR to route across the internet connection on R1 primarily, and use R2s internet connection as backup only. Lets say the IGP in the Enterprise is EIGRP, and internet routing is via default static routing only.
How do you accomplish this using PBR and SLA? How many various ways are there? Let's just say NAT isn't used.
What's even funnier about this is this is a open ended question I made up LOL. I'm just trying to do some discovery study on PBR and SLA for the sake of getting to know them better.
Can you guys help me?
Message was edited by: Joshua, CCNA
ok, so to get a better grasp on that, let's throw some picture into here:
the classic way is to propagate a default route into the internal cloud from the preferred gateway and to use IP SLA to control which one is propagated into your own EIGRP cloud. So on R1 create a default route tracked by ip sla pinging an IP in ISP1's cloud. EIGRP can propagate this route so everybody in the cloud will be able to use it. On R2 have a floating static route with an AD above 170 (EIGRP external AD) pointing to ISP2. This is used when the external route will disappear if ISP1 becomes unreachable. Sounds very easy and can be done completely without PBR as it seems, but watch out the effects. You may need the PBR to control that the secondary default route injected into EIGRP will not be learned through a possible second router (for redundancy) and is leading to route flapping. EIGRP is pretty robust but not immune.
You can easily think of using PBR to control AD and implementing split-horizon to do this. The next thing is to make sure the pings are not routed through the EIGRP cloud using ISP2 after the failover to get to the SLA-test-ip in ISP1. If this would be the case, then R1 will think the IP is back being reachable and will propagate his default route again. Latest then you have a flapping issue for sure. There are two ways to prevent this. Either within the SLA config (specifying the outbound interface) or (more flexible) via a "local policy" which only affects packets originating from the router.
Now how may possibilities do we have....... I just showed only one. Most of the others may just be variations of the shown approach.
After thinking a little more about the task you like to solve, it popped in my mind that doing this on a router with a dynamic IP (DHCP) form your provider will cause some issues here. The reason is the installed dynamic default route with an AD of 254. This route will continue to be there even if the ping to your control-IP will die but the provider still has a working connection to you. There is no way to let the router understand not to redistribute one or the other. Routemaps cannot match on AD and the distance command in the routing process sets the AD for a given IP/mask which is the same for both. A chance would be suppressing the DHCP learned route, but honestly I don't know a way to do this. You may use a second router for this to work or if you need to do this in one router, use VRFs and route leaking to split the routing tables into separate entities and redistribute between them if needed. I attached the config files for my demo network:
The client PC will use ISP1 as the main provider. R1 has the IP SLA configured and uses 18.104.22.168 as a reference IP to see if the connection is alive. If ISP1 has an issue internally (shut down the north interface of ISP1) then the default route from R2 should be taken into account to route the packets. Make sure that the metric of the R2 default route is larger than the diameter of the internal routing domain to avoid suboptimal routes. R2 is getting the IP via DHCP which also installs the default route. EIGRP is acting a little different when it comes to static routes pointing to interfaces. Interface static routes are automatically redistributed, IP-static routes need redistribution configured.
configs.zip 3.6 K
I am using 2691s and an AdvancedIPservices IOS. For this topology you don't need this level of IOS. I guess an IP-Only would do it as well. I use AdvanedIPservices because it will do the job for Voice and security as well but needs 256Mb RAM. I chose 2691s because on my laptop these are running rock solid.