Policy Based Routing (two gateways of last resort)?

[zcamero]

Looking for examples or any other form of help.  I am looking at setting up two gateways of last resort one for one class C subnet and one gateway for the rest of the traffic.  Is there a way to use Policy Based Route to force only certain subnets to a second gateway of last resort without effecting the current gateway of last resort for the rest of the network?

[Paul L]

without knowing your environment its hard to say.
I have done something similar, I think you should be able to accomplish this with static routes of varying weights and cost.

[zcamero]

For example I have 10.2.0.0/16 for my network.

Right now I have a static route
ip static-route create 0.0.0.0/0.0.0.0 next-hop 10.2.2.2 cost 1 preference 5

I would like only 10.2.5.0/24 out of my network to use 10.2.7.2 as the last resort rather than 10.2.2.2

[Paul L]

this is now the second time in 48hrs someone asked me this same question.

are you in Canada by chance?

[zcamero]

Nope in the states.

[Paul L]

its a really good question. A colleague told me that you can do it on 5500/5600s so its safe to say that you can do it on a 8600/8800. I would have to test something out in my lab as I have never done it before. Only ever screwed around with indirect static routes with varying weights and costs to make some goofy routing work.

[zcamero]

Definitely some goofy routing in my situation.

[imorris]

We have 88xx with RS modules running 7.1.5.3 (at the moment).  We use the following method to redirect an Exchange connector server thru a specific internet router, rather than have it follow the standard default route.  In essence it matches the source address and replaces the next-hop if the destination address is not equal to our internal networks ... works a treat.  Note that the network declarations are in ranges, not netmasks.  You have to apply the filter to the incoming port(s).

filter acl 221 create inPort act 4092 name "ExgCmb301"
filter acl 221 port add 7/24
filter acl 221 ace 21 create name "Cmb301-nh"
filter acl 221 ace 21 action permit redirect-next-hop 10.2.2.10 stop-on-match true
filter acl 221 ace 21 debug count enable
filter acl 221 ace 21 ip src-ip eq 10.1.2.221
filter acl 221 ace 21 ip dst-ip ne 10.0.0.0-10.255.255.255,172.16.0.0-172.31.255.255,192.168.0.0-192.168.255.255
filter acl 221 ace 21 enable

This is only relevant for the enhanced filters available in the R and RS modules.  Unfortunately the older modules don't support network ranges in their filter declarations.  Hope this helps tho.

Cheers

Ian

[Dave]

What imorris posted is the solution to your problem. Its basically an ACL that changes the next hop instead of dropping (or allowing) the package.

I use it in a rather large installation to realize a certain routing constellation with firewalls (checkpoint). Works amazingly well and does not impact performance in a way we could measure.

I did not find the documentation very easy to understand though...

[zcamero]

Thanks alot. I will work with this and see where I get.  Just so I have this all straight. 

10.2.2.10 is the last resort where you point your traffic to?
10.1.2.221 is your Exchange connector server?
10.0.0.0-10.255.255.255,172.16.0.0-172.31.255.255,192.168.0.0-192.168.255.255
is all the possible outside networks you might need to reach?

[Dave]

his example means the following:

The police is named exCmb301 and applied to the inbound traffic on Interface 7/24.

The ACE is named Cmb301-nh.

When an IP-Packet has the source-IP 10.1.2.221 (eq = equals) and is not destined to the IP ranges 10.0.0.0-10.255.255.255,172.16.0.0-172.31.255.255,192.168.0.0-192.168.255.255 (ne = not equals) then the next hop for the packet will be 10.2.2.10.

The stop-on-match means that the action will be taken regardless of whats listed in lower items of the ACL.

A counter will be increased every time the rule is used (for debug purposes).

[zcamero]

Thanks again.  That clears things up. I'll give this a shot. 

[imorris]

Sorry for the "dump and run" yesterday, I was a bit under the pump.  Thanks for expanding on the explanation Dave and yes I agree the documentation is not very clear. Once you "click" to what it is doing though it is very powerful and, as Dave also points out, negligible impact on throughput or CPU.

To re-construct with zcamero net parameters and some random ports to illustrate the flexibility I get ...

filter acl 222 create inPort act 4092 name "Special-NH"
filter acl 222 port add 3/1,4/4-4/12
filter acl 222 ace 22 create name "Ten2Five"
filter acl 222 ace 22 action permit redirect-next-hop 10.2.7.2 stop-on-match true
filter acl 222 ace 22 debug count enable
filter acl 222 ace 22 ip src-ip eq 10.2.5.1-10.2.5.254
filter acl 222 ace 22 ip dst-ip ne 10.2.0.0-10.2.255.255
filter acl 222 ace 22 enable

When you play around with this, probably the most important bit is making sure the correct template is selected.  In the first line when the ACL is initially declared, a template is specified.  In the above I use "act 4092".  The template specifies which "fields" of the frame will be presented to the filter for processing.  There are a number of these templates out-of-the-box with combinations that suit most requirements ... src-ip, dst-ip, src-mac etc ... or you can make your own. 

Just make sure that the template you specify has all the fields your filter requires.  Template 4092 only gives the filter src and dst ip, no point in setting an ACE entry to look at, say, DSCP because it won't see it.  Would have to change the template to one that includes srcIp/dstIp/dscp ... I have embarassed myself more than once with this. 

Cheers

Ian