|
Has anyone had a chance to look at this problem (I mailed this last
week, and have spent all weekend on it to no avail)? If this isn't a
LVS issue and instead an heartbeat issue, please let me know so I can
ask for help in the right group ;)
> try as I might, I can't figgure out what's going wrong.
>
> LVS forwards http without a problem on my direct route setup (using
the
> ipchains redirect approach with vlans on cisco switch).
> I'm using ldirectord + heartbeat from the linux-ha cvs to do the
> configuration stuff for me; I used a mouse copy-paste, and changed the
> proper ports and added the persistence for https (on port 443),
ipvsadm
> output on the director looks like this:
> (replace EXT-IP with some routable ip address, done that way to
protect
> the innocent ;)
>
> IP Virtual Server version 1.0.0 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> TCP EXT-IP:https lc persistent 600
> -> 10.23.3.101:https Route 1 0 0
> TCP EXT-IP:www lc
> -> 10.23.3.101:www Route 1 6 0
>
> This is a kernel I compiled today, 2.2.17. my setup is a bit funny,
> here's what ifconfig looks like (snipped for brevity's sake):
> eth0 Link encap:Ethernet HWaddr 00:D0:B7:BD:5C:5F
> inet addr:10.23.2.2 Bcast:10.23.2.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>
> eth0:0 Link encap:Ethernet HWaddr 00:D0:B7:BD:5C:5F
> inet addr:EXT-IP Bcast:EXT-BCAST Mask:255.255.255.248
>
> eth1 Link encap:Ethernet HWaddr 00:D0:B7:C7:1D:32
> inet addr:10.23.3.2 Bcast:10.23.3.255 Mask:255.255.255.0
>
> lo blah blah blah..
>
> eth1 goes into my internal network (seperate vlan on a cisco switch,
> made this really "neat" setup with the vlans and we bypass arp
problems
> and have completely minimized collisions.. but that's another story),
to
> where my real web servers are.
>
> I ran
> /usr/sbin/tcpdump -l -i eth0 tcp port 443
> and
> /usr/sbin/tcpdump -l -i eth1 tcp port 443
>
> As soon as I point my browser (located outside this network, of
course)
> to the https://, tcpdump output on the director shows up on eth0, but
> NOT on eth1.. which makes me believe this things ain't forwarding
> traffic on 443 like it should. There is NOTHING weird in the
ldirectord
> logs; in fact, it even tells me that it found 10.23.3.101:443 and that
> it's removing the fallback server. Imagine that. Putting a temp
> web-server on the director listening on 443 didn't work, either. my
> ipchains does allow 443 access, too.
>
> Well, in reading through the list, I found someone was having a
similar
> problem, but with http (guy was running some cobalt stuff, if i
remember
> correctly) instead of https and his director would actually pick up
the
> tab. No resolution was posted, and I'm stuck in the baffled state. I
> read through that HOWTO about a dozen times, concentrating on the
https
> section; but that only talks about the real server issues and not the
> director issues (if there are any?).
>
> Any ideas? I bet it's something really stupid, some uber obvious
> oversight. Sheesh. Please let me know!
> Thanks,
> John "Jano" Lukac
>
>
>
>
>
|
