[c-nsp] Policy-routing with object tracking

[Joe Maimon]

Bob Tinkelman wrote:

> We offer customers at the T1 level, or multiple T1 level,
> a fall-back path via another service, such as cable-modem,
> dsl or fios.   We configure a tunnel over the lower-cost
> service back to one of our routers, assign the customer a
> private 65xxx asn, and run bgp over the multiple paths.
> 

We offer this as well. Its something I have always suggested customers 
request their ISP's to do for them (with very limited luck) to perform 
inbound redundancy for the small players of the network world.

> That's our standard config, and it's working fine.
> 
> One customer has a fairly high-speed cable connection,
> and I'd like to configure things so his outbound web-
> requests go out that path, nat'd, so long as that path
> is functioning.
> 
> My idea was to use object tracking, but I don't seem to
> have it quite right.  Or maybe I'm going about it in a
> totally wrong way.
> 
> 
> This was my idea:
> 
>   | version 12.4
> 
>   | ! Monitor reachability of some system through the cable-modem connection
>   | ip sla monitor 1
>   |  type echo protocol ipIcmpEcho 66.185.139.149
>   |  timeout 1000
>   |  threshold 50
>   |  frequency 3
>   | ip sla monitor schedule 1 life forever start-time now
> 
>   | track 1 rtr 1 reachability
> 
>   | interface FastEthernet0/0
>   |  description Customer LAN
>   |  ip address bbb.bbb.bbb.1 255.255.255.0
>   |  ip nat inside
>   |  ip policy route-map WEB-VIA-CABLE	! Not in running config (yet)
> 
>   | interface FastEthernet0/1
>   |  description Cable-modem via point-to-point Ethernet
>   |  ip address aaa.aaa.aaa.6 255.255.255.252
>   |  ip nat outside
> 
>   | ip local policy route-map LOCAL-SLA-VIA-CABLE
> 
>   | ip nat inside source list NAT-INSIDE-ADDRS interface FastEthernet0/1 overload

You may want to use a route-map with a match interface statement (which 
I have seen completely not working in post 12.4-2T) instead of this.

> 
>   | ip access-list standard NAT-INSIDE-ADDRS
>   |  permit bbb.bbb.bbb.0 0.0.0.255
> 
>   | ip access-list extended PING-TO-SLA-TARGET
>   |  permit icmp any host 66.185.139.149 echo
> 
>   | ip access-list extended WEB-ACCESS
>   |  permit tcp any any eq www
> 
>   | route-map LOCAL-SLA-VIA-CABLE permit 10
>   |  match ip address PING-TO-SLA-TARGET
>   |  set ip next-hop aaa.aaa.aaa.5

You may get burnt by implicit deny, for best practice never finish an 
acl, prefix-list or route-map with implicits

route-map LOCAL-SLA-VIA-CABLE permit 100
route-map WEB-VIA-CABLE permit 100

> 
>   | route-map WEB-VIA-CABLE permit 10
>   |  match ip address WEB-ACCESS
>   |  set ip next-hop verify-availability aaa.aaa.aaa.5 1 track 1

Looks fairly standard, I am doing this and have done this.

What version of IOS are you running -- I suspect the T train and post 
12412 to have some possible bugs with policy routing.

(Aside from the deficiencies in policy routing ipsec/gre tunnels that 
have been present for quite some time)

> 
> 
> 
> The first thing I ran into was that my "local policy" doesn't work.
> Even when I changed it to just match on the destination, independent
> of protocol type, traceroutes would just timeout with asterisks at
> the first hop.
> 
> Inserting a route:
>   | ip route 66.185.139.149 255.255.255.255 Fa0/1 aaa.aaa.aaa.5
> seemed to get around that.  
> 
> It's clearly cleaner to have a local policy, but we can probably live
> with the above.
> 
> 
> At least that brought the tracked item up:
> 
>   | router#sho track
>   | Track 1
>   |   Response Time Reporter 1 reachability
>   |   Reachability is Up
>   |     7 changes, last change 01:55:46
>   |   Latest operation return code: OK
>   |   Latest RTT (millisecs) 8
>   |   Tracked by:
>   |     ROUTE-MAP 0
> 
> 
> 
> At one point, while investigating the "ip local policy" issues,
> I added:
> 
>   | route-map LOCAL-SLA-VIA-CABLE permit 50
>   |  match ip address prefix-list VICTIMS
>   |  set ip next-hop aaa.aaa.aaa.5 
> 
>   | ip prefix-list VICTIMS seq 5 permit www.www.www.www/32
> 
> But even here, with no dependency on tracking, traceroute to the
> designated victim syste, still went out over the T1.
> 
> 
> 
> 
> OK.  Obviously I'm confused.  I'm not sure if I've gone about this
> in totally the wrong way, or if I've must missed some minor points.

Bugs and/or minor points.

Try turning on and off cef/route-cache features and see if you get 
differing results.

> 
> Any feedback would be appreciated.
> --
> Bob Tinkelman          <bob at tink.com>
> ISPnet, Inc.  http://www.ispnetinc.net
> 
> +1 (718) 464-4747  office
> +1 (800) 806-NETS  toll free
> +1 (718) 217-9407  fax
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
>