Ok. Here's a layout of basically how it setup
220.127.116.11 (network providers router)
real server 1 lvs machine real server 2
RIP (10.100.50.247) RIP (18.104.22.168) RIP (10.100.50.246)
lo:0 (22.214.171.124) VIP (126.96.36.199) lo:0 (188.8.131.52)
default gw 184.108.40.206 default gw 220.127.116.11
static arp entry static arp entry
for the router, for the router,
real server 3 (which is not to be load balanced)
The problem is real server 1,2,3 cannot get to the internet which is a
requirement. Basically because these machines don't really have a real ip
address at all, so for them to get out, they need to be NAT's at some
What I thought you be possible is to set up a route or some type of rule
that says if traffic originates from 10.100.50.0/24, instead of using the
default gw, 18.104.22.168, go through 22.214.171.124 and be masqeraded, but
at thew same time if traffic originates from elsewhere and gets passed
from the LVS machine's VIP, then use the default gw and use DR instead.
So I could masq and use DR for important traffic all at the same time.
I hope this clears things up. My original email was pretty misleading.
On Fri, 22 Sep 2000, Joseph Mack wrote:
> On Fri, 22 Sep 2000, Jeremy Hansen wrote:
> > I have a situation where I'm using DR, but I need to NAT *some*
> > traffic.
> > I have the lvs server setup with real ip's, but all the real servers are
> > using internal addresses. I'm using DR, so the real servers are actually
> > using the real ip of my upstream providers router, I'm statically
> > assigning the mac address of the router to the real servers.
> I don't understand the last two sentences. (I assume the router is the box
> connecting your public network to the ISP). But lets put that aside for
> the moment.
> The VIP is a routable IP, so clients on the internet can send packets to
> the LVS. The real-servers will also have the VIP on them, so they can send
> replies to the client. The RIPs on the real-servers and the network
> connecting the director to the real-servers can be anything you like,
> including non-routable IPs (ie 192.168.x.x).
> Can you explain your problem again saying why this framework won't work
> in your case.
> Joseph Mack mack@xxxxxxxxxxx
eholes.org * jeremy@xxxxxxxxxx
eholes have feelings too...