Source-Sensitive Routing

jezg76

I am not sure where this process falls in the grander scheme of Cisco experience/certifications track, but I am quite sure, after being 2/3 of the way through my first of many BSCI books, it is not at my level. The only reason I happened upon this is because we have this exact issue at work.

Being as our IT staff has no one higher than CCNA-level knowledge, I need to look elsewhere for help.

I have scoured the depths of the Interwebs and found some very cool stuff, but this use of policy and route-maps is quite the bear, initially, if you have no one to help fill in the missing pieces.

As the little picture above shows, we have ISP1 and ISP2 at work. Both connected to a 2811, F0/0 and F0/1, respectively.

Our ultimate goal is to have ISP1 be our main Internet connection, but we'd like to have ISP2 be up as well, providing other non-surfing services, such as backup DNS and AS services.

We'd also like for ISP2 to be the backup in case ISP1 goes down. (COMCAST WHY!!!!!)

Now the problem I am seeing is how do you account for two connections always up, providing different services, but, if need be, have the backup connection provide all the services for the site. I have labbed my network in GNS3 and am not sure how to handle the default routes. I thought I was on the right track when I did an ip policy on each interface matching the IP addresses and next-hop address of each interface, but alas it is not working. I debugged the policy process and, after seeing the results, am quite sure there is something I am missing in regards to how they are applied. Need to do more reading on that...

Like I said I hit route-maps a week ago in my BSCI studies and they are making way more sense today than they did a week ago, but, as always, implementation, configuration, and troubleshooting are different animals from theory. Policies seem to be a step up from them, so therein lies my problem. I am trying to implement ideas that I do not fully understand. Never good...

Anyway, if anyone has any links to sites I may have missed or some input on this, it would be greatly appreciated.

Thanks!

dtlokee

Sounds like a case for OER (Optimized edge routing) or possibly an SLA monitor using icmpEcho and add the track statement to you ip route command

Paul Boz

http://www.netcraftsmen.net/welcher/papers/oer01.html

Some good papers on OER.

jezg76

I thank you both for your input. It is very much appreciated.

Here is what I ended up doing, although after reading about the OER solution, that may be the way to go.

I have the two default routes like this:

ip route 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx 100 track 123
ip route 0.0.0.0 0.0.0.0 yyy.yyy.yyy.yyy 110 track 345

I think having just the main one (xxx) in the routing table is the way to go with the idea I am using.

The two track keywords are defined like this:

track timer interface 5
!
track 123 rtr 1 reachability
delay down 5 up 2
!
track 345 rtr 2 reachability
delay down 5 up 2

To be 100% perfectly honest I am not certain if these timers are optimal and will have to research that a little more in depth.

The timers are defined as follows:

ip sla monitor 1
type echo protocol ipIcmpEcho xxx.xxx.xxx.xxx source-interface FastEthernet0/0
timeout 1000
threshold 40
frequency 3
ip sla monitor schedule 1 life forever start-time now
ip sla monitor 2
type echo protocol ipIcmpEcho yyy.yyy.yyy.yyy source-interface FastEthernet0/1
timeout 1000
threshold 40
frequency 3
ip sla monitor schedule 2 life forever start-time now


I figured since there are 2 possible exit interfaces, I wiould need to configure two PAT statements. I did those as follows:

ip nat inside source route-map COMCAST interface FastEthernet0/0 overload
ip nat inside source route-map VERIZON interface FastEthernet0/1 overload


I will also create the static nat translations that need to be done to allow services to be reached via either interface.

The route-maps for these are here:

route-map COMCAST permit 10
match ip address 101
match interface FastEthernet0/0
!
route-map VERIZON permit 10
match ip address 101
match interface FastEthernet0/1


If there is an easier way to do this, by all means, let a brother know.

Now, the final piece to my solution is the policy applied to the interface going to our SonicWALL. I was having all my issues due the fact I was trying to apply policy on the outgoing FastEthernet interfaces. Welp, I learned that's a no-no. My policy will simply match the ip addresses that need to sit on the yyy and have the next-hop pointing there.

route-map policy_1 permit 10
match ip address 5
set ip next-hop yyy.yyy.yyy.yyy
!
route-map policy_1 permit 20


I was overthinking this, I believe. I had a policy for all traffic except the access-list 5 hosts being next-hopped to xxx.xxx.xxx.xxx. But, I realized, the route that matters will be in the routing table so this shouldn't matter.

While I'm not certain this is optimal, I am highly certain it meets our needs. It provides failover, while ensuring traffic is using the higher speed cable connection, while also allowing resources to be reached via a different ISP. Well, hopefully. Works in GNS3, but we shall see...

Like I said, I have CCNA + beginning BSCI knowledge so alot of this is brand new. If any more experienced types see holes/issues, let me know!

Thanks a ton.

dtlokee

The only thing I would add to the solution you have is to make sure the echo sla operation can't be routed through the other provider to the destination, that would sort of defeat the purpose.

jezg76

Sounds good, dt. Thanks for your input. I always enjoy reading your posts. Seems like lots of valuable info in that head of yours.