Sometimes a routing protocol such as OSPF or BGP is not available with your next hop and you need to be able reroute traffic based on conditions.  There are different ways to do this, but my favorite is via track tables and IP SLA.

What is nice about this method is that it allows routing by reachability or other methods to determine if the route is useable.  At home I have two internet providers but cannot count internet access just because their equipment has power.  I use this to change my default route and insert a static route or delete it based on that same reachability.

sample:

Read more: IP SLA

One of the complaints I had for the longest time about access lists was the lack of a good way to 'group' access lists.  Some of the newer IOS releases have allowed you to insert or delete rules, but placing them still has to be thought out.  If the access list is long, this can be a challenge.

It took me a while to wrap my head around the zone based firewalls in IOS but the big selling point for me was the ability to group access list rules by policy.  It takes a little bit more planning to start, but in the long run it is a much safer way to configure access lists.

For example, I can create a policy that refers ( via class-map ) to protocols or IP blocks I always want to allow.  To add another block ( a  new BGP peer perhaps ), I simply append a new rule into the access list 'BGPAlwaysAllow' without care of order.

The pitfall for me was in three parts; first the zone-pair names can be anything, but I found names like 'inside', 'outside', and 'vpn' are useful.  I thought the name had a function, but it's just a label to bind the interfaces (pairs) to the policy maps.  The second part is that traffic transiting between interfaces will fail if only one interface has been assigned to the zone.

Finally, I needed to think about all pairs.  For example in->out but also the pair out->in.  Multiple interfaces can be assigned to the same zone.  Traffic within the same zone is explicitly allowed.  Assigning multiple pairs can be very powerful ( i.e. inside1<-> isp1 and inside2<-> isp2 ) but can quickly add complexity that is hard to follow.

It definitely is not as easy as just assigning an ACL that is in or out, once it is set up, it is infinitely safer to edit and follow.  The caveat here is the free naming which if not thought out a bit could make it impossible to read.  The names work best if they are assigned a purpose such as 'peer2peer' , 'dropNoLogging', or 'evilWormPorts'.

Here is a very basic config for out-> in.  There are three access-lists that are referred to by the policy-map/zone-pair, alwaysallowedports, trustednetworks, and dropnolog that I do not list.  Note this is as if you could assign three ( or more ) access lists to the same interface, but in a paticular traffic flow ( pair ).

!

zone security outside

zone security inside

!

class-map type inspect match-any permitted

 match access-group name alwaysallowedports

 match access-group name trustednetworks

class-map type inspect match-any dropnolog-cmap

 match access-group name dropnolog

!

policy-map type inspect outside-inside-pmap

 class type inspect permitted

  pass

 class type inspect dropnolog-cmap

  drop

 class class-default

  drop log

!

Zone-pair security out-in source outside destination inside

 service-policy type inspect outside-inside-pmap

!

interface serial 0/0

 zone-member security outside

interface fastethernet 0/0

 zone-member security inside