[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netfilter
Subject:    Re: Policy NAT, pools etc. Is netfilter for me?
From:       "George B." <georgeb () gmail ! com>
Date:       2009-05-26 7:21:45
Message-ID: b65cae940905260021w25a242bcmf0b8f8a63ff6669 () mail ! gmail ! com
[Download RAW message or body]

Ok, just found this in a recent list reply to a similar question:

> ip route add local <address>/<mask> table local dev <interface>

> This way <address>/<mask> will be considered local by the system which will reply \
> to ARP requests for it, actually usable by any local process, but won't appear \
> assigned to <interface> so >chances are that no local process will use it unless \
> told explicitly.

So, it looks like this is a project worth spending lab time on.  I
tested the above on a Debian box under my desk at work and that worked
as far as responding to ARP.


See, here is the "thing" ... the NAT function is the most expensive
operation in my network.  I have one site where I have spent in excess
of $100K for hardware to simply perform outbound NAT functionality.
In most cases I have to buy hardware with a bazillion features I don't
use in order to get the NAT throughput that I do need.  When we got to
the point where we ran out of CPU on Cisco ASA 5550 units, I decided
there had to be a better (and less expensive) way. Even if I have to
spread things over several boxes, it would still come out cheaper than
a $80,000 load balancer or full featured firewall being used for
nothing but NAT. In that segment of the network a fully featured
firewall is overkill as the rule is very simple; NAT all connections
outbound, deny all connections inbound. In dollars per packet, NAT is
more expensive than firewalling, routing, or anything else in the
network.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[prev in list] [next in list] [prev in thread] [next in thread]