|
----- Original Message -----
From: "Joseph Mack" <mack.joseph@xxxxxxx>
To: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, October 31, 2001 11:40 AM
Subject: Re: Geographically Distributed LVS
> Kip Iles wrote:
>
> > Since I brought up the tunl0:1 interface on dir_B for the second
service,
>
> hmm, what is a "second service"?
I had refrained from telling you about the second service previously since
it only complicates matters but it is just another RS. I only brought it up
because the tunnel to it killed my connection to dir_B. We can forget it now
and only talk about a single RS behind dir_B.
> > I see nothing. It is dead to the world. Unfortunately it is also 250
miles
> > away with no terminal server and no other route to the inside reserved
ip
> > addresses.
>
> I see. You could go mad trying to debug this, especially with filter rules
> running on LVS_B. Can you get some machines
> locally to test it out. Convert one of your realservers to simulate dir_B?
Yeah! I was pushed into moving this to the remote site before it was ready
but had hoped I could be careful enough not to lock myself out. Apparently
that did not happen. I do have linux 2.4 running on a laptop, here ay my
home office. A few tweaks on my home router and I could expose it for
testing. I will be putting a spare HP Secure Web Console at the remote site
and connecting it to dir_B serial. This might save me next time. I am going
mad!
> > I had them reboot dir_B at the remote site but it never
> > reestablished communications, probably because
> > /etc/sysconfig/network-scripts/ifcfg-tunl0:1 brought the tunnel back up
on a
> > reboot.
> >
> > The primary tunnel tunl0 did not cause this problem but did not work,
> > either. Tcpdump showed the return packet trying to go through the
tunnel.
>
> your route is set incorrectly on dir_B I expect.
I assumed that the default route for this box would be to the border router,
since it worked before I established the tunnel interface.
> > IPTABLES conf on dir_B
> > iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>
> you have iptables, so I assume you're running 2.4. If you have
> 2.4 LVS-NAT you can't have external masq rules for ipvs, they're built
into
> the ipvs code.
Yes, I decribed all this in a previous thread answered by Julian. The thread
was:IPVS/FreeSwan - Freeswan broke IPVS. I stopped this tread since I
brought down FreeSWAN to degug the LVS issues.
> Redhat Linux 7.1 with Kernel Patch 2.4.13
> FreeSWan 1.91, IPVS Version 0.9.5, ipvsadm 1.20-2
> > I thought this was going to be easy!
>
> to quote a recent posting "no-one has ever setup an LVS in a hurry"
Yeah! But I thought I was over the major learning curve after setting up
dir_A. It has really performed well running VS-TUN to a whole slew of
realservers and multiple VIPs. I'm definately sold on LVS. Being an HP, SUN,
IBM, IRIX, CLIX, APOLLO admin for the last 20 years, I am amazed at the
versatility of Linux. I believe we can do anything we want with these boxes,
given enough time and effort. I replaced my Cisco LocalDirector with LVS on
Linux.
Anyway, Thanks so much for listening and responding.
Kip Iles
Director of Information Systems
NO Boundaries Network, Inc.
|
