[c-nsp] Policy-routing with object tracking
david.ponsdesserre at uk.bnpparibas.com
david.ponsdesserre at uk.bnpparibas.com
Tue Mar 27 05:57:47 EST 2007
How about stefull NAT ? Seems to be a good idea if you have NAT involved
in your design .
Stateful NAT (SNAT) is a Cisco IOS Software feature allowing two or more
network address translators to function as a translation group. A backup
NAT provides translation services in the event of failure to the active
translator. The result is a more resilient IP network.
More details can bve found here :
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_white_paper09186a0080118b04.shtml
Rgds
David
Internet
jmaimon at ttec.com
Sent by: cisco-nsp-bounces at puck.nether.net
27/03/2007 11:30
To
bob
cc
cisco-nsp
Subject
Re: [c-nsp] Policy-routing with object tracking
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/
>
>
_______________________________________________
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
More information about the cisco-nsp
mailing list