[c-nsp] Handling "junk traffic" with a secondary ISP using NAT

Robert Johnson fasterfourier at gmail.com
Mon Aug 31 20:48:54 EDT 2009


I will take a look at OER shortly. But in the mean time, yes, each host on
the internal network has a public address and no NAT is being performed at
all currently.

On Mon, Aug 31, 2009 at 5:37 PM, Ryan West <rwest at zyedge.com> wrote:

> 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: cisco-nsp-bounces at puck.nether.net [mailto:
> cisco-nsp-bounces at puck.nether.net] On Behalf Of Robert Johnson
> Sent: Monday, August 31, 2009 5:05 PM
> To: cisco-nsp at puck.nether.net
> 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  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