Robert, You might want to look into OER with NAT and leverage application mapping for your outbound selection. OER can be a bit of a beast, but you might consider. In a SOHO design, the configuration is a lot less complex.
http://www.cisco.com/en/US/docs/ios/12_4t/oer/configuration/guide/h_oerstr.html#wp1059322 Another choice would application aware PBR, which can also be used with OER or just with source based routing like you listed below. I was a little confused by what the /24 statement. Are you saying that each user has a publicly routed address? Is your firewall doing NAT? -ryan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Johnson Sent: Monday, August 31, 2009 5:05 PM To: [email protected] Subject: [c-nsp] Handling "junk traffic" with a secondary ISP using NAT Hello Cisco experts, I have an interesting configuration here. I have an organization with some /24s of IP space assigned to their internal hosts. The IGP is OSPF and connectivity to the outside world is via a single ISP with multiple links using BGP (private ASN). In an effort to cut costs, we would like to use an additional cheaper consumer-level ISP to handle some of the "junk traffic" such as streaming radio, MySpace CDN, etc. Traffic that is not mission critical. The idea is to add an additional router to the main OSPF area, redistribute static routes to the "junk traffic" IP blocks into OSPF, and run NAT on the new router to get all this traffic flowing over the "cheap consumer level FTTP ISP" connection which is attached to the new router. The configuration to retract these static routes from the OSPF area upon a failure of the cheap ISP is straightforward. However, this scheme breaks some functionality. An incoming connection from a host in one of the "junk destination" IP blocks to a host in our internal network will flow in through the normal primary ISP. Responses to this connection, however, will be routed out through the secondary ISP and NATted, causing the reply packets to come from a different IP address. A potential solution would be to have the new router inspect all flows originating from the internal network and NAT only TCP sessions that originate from the inside network. The idea was to create a reflexive ACL containing any TCP flows originating from the inside network that are not established. Then use PBR to NAT any flows defined in this reflexive ACL, and send the rest of the traffic out without performing any NAT. Unfortunately, it doesn't appear to be possible to do this using standard Cisco reflexive ACLs, since the entries in the reflexive ACL have the source and destination reversed. Any ideas to implement this properly? Thanks, Robert _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
