[c-nsp] Policy-routing with object tracking
Bob Tinkelman
bob at tink.com
Sun Apr 1 13:40:44 EDT 2007
A belated thanks to those who answered my original
question, both privately and to the list.
In answer the the "version question", we're running
c2600-advipservicesk9-mz.124-13
I spent some time over a couple of days, and eventually
gave up on using "local ip policy" to control the path
taken by the SLA ping traffic, and used an old fashioned
static route instead.
It turns out that was the only thing I needed to change
to make things work.
I was being stubborn about wanting to use "local ip
policy" both because it's clearly cleaner, and also
because it seemed to give me the ability to do more
testing without "someone on site with a browser".
Again, thanks for everyone's time.
--
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
> 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 system, 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/
More information about the cisco-nsp
mailing list