[c-nsp] Policy-routing with object tracking

Mon Mar 26 16:55:16 EST 2007

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.

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/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

  | 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

  | 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

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.

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