|
Hello,
On Fri, 17 Nov 2000, John Lukac wrote:
>
> Hi,
>
> 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
What means this? ^^^ ^^^
Why the requests don't reach LVS?
> 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.
Detect the packets from the browser with ipchains logging
in the director:
ipchains -I input -s CIP -d 0.0.0.0/0 443 -l
Try with another browser, "curl https://VIP";, for example.
If you run virtual service on port 443 and it shadows the
local socket we don't expect LVS to deliver the requests to the local
socket. If you use ipvsadm -C and then start this temp ssl server,
are the clients served?
> 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
Hm, what problem?
> 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!
Debug why the packets are not scheduled, LVS does not show
any scheduled packets, so we don't expect they to be forwarded. You
must find the reason: echo 2 > /proc/sys/net/ipv4/vs/debug_level
after adding #define CONFIG_IP_VS_DEBUG to include/linux/config.h
and kernel recompile. There are no specifics for the https port in
LVS.
> Thanks,
> John "Jano" Lukac
Regards
--
Julian Anastasov <ja@xxxxxx>
|
