Mailing List Archive

On Wed, 17 Jan 2001, Paul Lussier wrote:

>
> Hi all,
>
> I have the following configuration:
>
> lvs1:/# ipvsadm
> IP Virtual Server version 1.0.2 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> TCP ssifarm.lowell.mclinux.com:https rr
> -> ssifarm1.lowell.mclinux.com:https Route 1 0 0
> TCP ssifarm.lowell.mclinux.com:telnet rr
> -> ssifarm1.lowell.mclinux.com:telnet Route 1 0 0
>
> I can telnet to ssifarm, but not to ssifarm:443, in other words, lvs is
> working for telnet, but it appears that it's not working for https.

SSL needs to be persistant connections

-Matt
>
> Any ideas what could be wrong or what to look at?
>
> Thanks,
>
>

--
----------------------------------------------------------------------
Matthew S. Crocker
Vice President / Internet Division Email: matthew@crocker.com
Crocker Communications Phone: (413) 587-3350
PO BOX 710 Fax: (413) 587-3352
Greenfield, MA 01302-0710 http://www.crocker.com
----------------------------------------------------------------------

In a message dated: Wed, 17 Jan 2001 16:14:41 EST
"Matthew S. Crocker" said:

>SSL needs to be persistant connections

Is that a requirement for LVS? It won't forward the packed otherwise?

Thanks,
--

Seeya,
Paul
----
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.

If you're not having fun, you're not doing it right!

In a message dated: Thu, 18 Jan 2001 00:05:51 GMT
Julian Anastasov said:

> Hello,
>
> It is not obvious from the provided ipvsadm output. Can you
>tcpdump one session? Many things can go wrong in test environments?

If I run tcpdump on the LVS server, I see the connections coming in to it.
If I run tcpdump on the readl server, I see nothing.

> Stop all real servers and leave only one where you will start
>tcpdump -len host client

That's exactly what I was doing.

> How do you detect that it is not working, only by looking in
>the browser window? The ipvsadm table is empty which can mean that
>you hit directly the real server (ARP problem) but you don't mention
>when this output is generated, before or after the failed SSL test.

I detect that it is not working by:

telnet <vip> 443

This does work from a client, yet does if I:

telnet <real server> 443

Thanks,
--

Seeya,
Paul
----
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.

If you're not having fun, you're not doing it right!

Hello,

On Wed, 17 Jan 2001, Paul Lussier wrote:

> Hi all,
>
> I have the following configuration:
>
> lvs1:/# ipvsadm
> IP Virtual Server version 1.0.2 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> TCP ssifarm.lowell.mclinux.com:https rr
> -> ssifarm1.lowell.mclinux.com:https Route 1 0 0
> TCP ssifarm.lowell.mclinux.com:telnet rr
> -> ssifarm1.lowell.mclinux.com:telnet Route 1 0 0
>
> I can telnet to ssifarm, but not to ssifarm:443, in other words, lvs is
> working for telnet, but it appears that it's not working for https.

It is not obvious from the provided ipvsadm output. Can you
tcpdump one session? Many things can go wrong in test environments?
If you are just asking if there is a known problem with SSL, the short
answer is NO, there is no.

> Any ideas what could be wrong or what to look at?

Stop all real servers and leave only one where you will start

tcpdump -len host client

this will show the ICMP and the TCP packets to/from the client.

You can do the same in the director and in the client.

How do you detect that it is not working, only by looking in
the browser window? The ipvsadm table is empty which can mean that
you hit directly the real server (ARP problem) but you don't mention
when this output is generated, before or after the failed SSL test.

>
> Thanks,


Regards

--
Julian Anastasov <ja@ssi.bg>

Hello,

On Wed, 17 Jan 2001, Paul Lussier wrote:

> If I run tcpdump on the LVS server, I see the connections coming in to it.

can you analyze/provide the LVS debug output:

echo 20 > /proc/sys/net/ipv4/vs/debug_level


Regards

--
Julian Anastasov <ja@ssi.bg>

On Wed, 17 Jan 2001, Paul Lussier wrote:

> I can telnet to ssifarm, but not to ssifarm:443, in other words, lvs is
> working for telnet, but it appears that it's not working for https.
>
> Any ideas what could be wrong or what to look at?

can you telnet to 443 on the real-server?

AFAIK telnet is not a client for 443 as cryptograph exchange has occur to
even connect to the socket.

If this is the problem, try curl as the client.

Joe

--
Joseph Mack mack@ncifcrf.gov

In a message dated: Wed, 17 Jan 2001 19:30:50 EST
Joseph Mack said:

>can you telnet to 443 on the real-server?

Ayup. I don't get anything other than:

Connected to foo.bar.com
Escape character is '^]'.

but I can't even get that when I try to connect through the LVS server.
I get instead:

telnet: Unable to connect to remote host: Connection refused

I think the problem might have something to do with the client I'm trying to
connect to, so I need to speak to the developers of said app (it's not an
SSL webserver, but similar).

As soon as we all get unconfused about what we're doing, I'll report back.

Thanks.


>AFAIK telnet is not a client for 443 as cryptograph exchange has occur to
>even connect to the socket.
>
>If this is the problem, try curl as the client.
>
>Joe
>
>--
>Joseph Mack mack@ncifcrf.gov
>

--

Seeya,
Paul
----
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.

If you're not having fun, you're not doing it right!

Paul Lussier wrote:
>
> In a message dated: Wed, 17 Jan 2001 19:30:50 EST
> Joseph Mack said:
>
> >can you telnet to 443 on the real-server?
>
> Ayup. I don't get anything other than:
>
> Connected to foo.bar.com
> Escape character is '^]'.

same result here. that's news to me. I thought it didn't connect.


> but I can't even get that when I try to connect through the LVS server.
> I get instead:
>
> telnet: Unable to connect to remote host: Connection refused

(long shot)
did you read the bit in the HOWTO about https where you have to get the
certificate correct. The IP for the certificate has to be for the VIP
not the RIP. If your real-server has a certificate and you're connecting to
the real-server at it's RIP, you should set up the real-server with the VIP
on a real pingable eth0 type device for a proper test (and remove all
machines with IP=VIP from the network).

>
> I think the problem might have something to do with the client I'm trying to
> connect to, so I need to speak to the developers of said app (it's not an
> SSL webserver, but similar).

if your client can connect directly to the real-server with your client, then
you
should be able to connect to the real-server via the director with the same
client. The director is just shuffling packets.

Joe

--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@epa.gov ph# 919-541-0007, RTP, NC, USA

In a message dated: Thu, 18 Jan 2001 11:08:38 EST
Joseph Mack said:

>if your client can connect directly to the real-server with your client, then
>you should be able to connect to the real-server via the director with the
>same client. The director is just shuffling packets.

I was getting connection refused when going from the director to the
real-server as well. I think there might have been some confusion between
myself and the other people trying to implement this environment where they
were binding to one IP and I was re-directing to a different one. They've
just finished moving all the network around, so now I have to go and see if I
can't make some sense of the re-achitecting they've done :)

Thanks,
--

Seeya,
Paul
----
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.

If you're not having fun, you're not doing it right!

Paul Lussier wrote:
>
> In a message dated: Thu, 18 Jan 2001 11:08:38 EST
> Joseph Mack said:
>
> >if your client can connect directly to the real-server with your client, then
> >you should be able to connect to the real-server via the director with the
> >same client. The director is just shuffling packets.
>
> I was getting connection refused when going from the director to the
> real-server as well.

you won't be able to do this if the director is configured to forward that port.
You can't access LVS'ed services from any of the machines in the LVS.

I think there might have been some confusion between
> myself and the other people trying to implement this environment where they
> were binding to one IP and I was re-directing to a different one. They've
> just finished moving all the network around, so now I have to go and see if I
> can't make some sense of the re-achitecting they've done :)

the left hand and the right hand...

Joe

--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@epa.gov ph# 919-541-0007, RTP, NC, USA

In a message dated: Thu, 18 Jan 2001 12:05:37 EST
Joseph Mack said:

>> I think there might have been some confusion between
>> myself and the other people trying to implement this environment where they
>> were binding to one IP and I was re-directing to a different one. They've
>> just finished moving all the network around, so now I have to go and see if
>> I can't make some sense of the re-achitecting they've done :)
>
>the left hand and the right hand...

Ayup! That's what it was. It turns out the guys writing the application were
starting up a logical interface with one ip, and the LVS scripts I wrote were
doing the same, but with a different alias/ip.

In addition, they had told me to send <ip 1>:443 to RS1-4, and <ip 2>:443
to RS1a-4a where these were different IPs, but really also just logical
interfaces on the real-servers. When I looked at the ifconfig output of the
realservers, I had eth0, eth0:1-4 defined, but I was redirecting to one set of
aliases, but their app was listening on a different set up ip/alias pairs.

Now that I know what's going on, things seem to make a whole lot more sense.
And this stuff's working to boot :)

Thanks alot for all the input!
--

Seeya,
Paul
----
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.

If you're not having fun, you're not doing it right!

On Thu, 18 Jan 2001, Paul Lussier wrote:

> I was redirecting to one set of
> aliases, but their app was listening on a different set up ip/alias pairs.

does it everytime.

> And this stuff's working to boot :)

can't beat that

Joe

--
Joseph Mack mack@ncifcrf.gov