[c-nsp] Policy-routing with object tracking

Tue Mar 27 03:37:52 EST 2007

Hello Bob. 

I am using a mix of set ip next-hop verify availability + sla monitor . 
PBR is active if the ip next-hop is up and running otherwise you use your 
backup path .
I think you need to use code 12.4 to have access to the set ip next hop 
verify availability .
Example here : 
CE1 "push" a  certain type of traffic towrds CE2 only if CE2 lan ip 
address is up and running .

PBR setup
CE1#
interface <type/number>
ip policy route-map <map name>
!
route-map <map name>
Match ip address <access-list name>
set ip next-hop verify-availability [next-hop-address sequence track 
object] 
!
ip access-list standard <access-list name>
permit <interesting traffic><wildcard>

        CE1 --- Ebgp ---------- PE1 
        |
        |Lan 
        |
        CE2 --- Ebgp ----------PE2

Sla monitor to "keep an eye" on CE2 lan (it is just an icmp echo towrds 
the ip address)

CE3(config)# rtr 1 
OR 
CE3(config)# ip sla monitor 1 
type echo protocol protocol-type target [source-ipaddr ip-address] 

rtr schedule operation-number [life {forever | seconds}] [start-time 
{hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss}] 
[ageout seconds] 
Example: 
Router(config)# rtr schedule 1 life forever start-time now 

Hope this helps 
Rgds
David

Internet
bob at tink.com

Sent by: cisco-nsp-bounces at puck.nether.net
26/03/2007 22:55

To
cisco-nsp
cc

Subject
[c-nsp] Policy-routing with object tracking

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

This message and any attachments (the "message") is 
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified. 

**********************************************************************************************

BNP Paribas Private Bank London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in
the United Kingdom.

BNP Paribas Securities Services London Branch is authorised 
by CECEI & AMF and is regulated by the Financial Services 
Authority for the conduct of its investment business in 
the United Kingdom.

BNP Paribas Fund Services UK Limited is authorised and 
regulated by the Financial Services Authority