On Fri, 12 Jul 2019 at 15:24, Brian Haley <haleyb.dev@gmail.com> wrote:
On 7/12/19 9:57 AM, Giuseppe Sannino wrote:
Hi community, I need your help ,tips, advices.
*> Environment <* I have deployed Openstack "Stein" using the latest kolla-ansible on the following deployment topology:
1) OS Controller running as VM on a "cloud" location 2) OS Compute running on a baremetal server remotely (wrt OS Controller) location 3) Network node running on the Compute host
As per the above info, Controller and compute run on two different networks.
Kolla-Ansible is not really designed for such scenario but after manipulating the globals.yml and the inventory files (basically I had to move node specific network settings from the globals to the inventory file), eventually the deployment works fine.
*> Problem <* I have no specific issue working with this deployment except the following:
"SSH connection to the VM is quite slow".
It takes around 20 seconds for me to log into the VM (Ubuntu, CentOS, whatever).
But once logged-in things are OK? For example, an scp stalls the same way, but the transfer is fast?
*> Observations <*
* Except for the slowness during the SSH login, I don't have any further specific issue working with this envirorment * With the Network on the Compute I can turn the OS controller off with no impact on the VM. Still the connection is slow * I tried different type of images (Ubuntu, CentOS, Windows) always with the same result. * SSH connection is slow even if I try to login into the VM within the IP Namespace
From the ssh -vvv, I can see that the authentication gets stuck here:
debug1: Authentication succeeded (publickey). Authenticated to ***** debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug3: send packet: type 90 debug1: Requesting no-more-sessions@openssh.com <mailto:no-more-sessions@openssh.com> debug3: send packet: type 80 debug1: Entering interactive session. debug1: pledge: network
> 10 to 15 seconds later
What is sshd doing at this time? Have you tried enabling debug or running tcpdump when a new connection is attempted? At first glance I'd say it's a DNS issue since it eventually succeeds, the logs would help to point in a direction.
+1 - ~30s timeout on SSH login is normally a DNS issue.
-Brian
debug3: receive packet: type 80 debug1: client_input_global_request: rtype hostkeys-00@openssh.com <mailto:hostkeys-00@openssh.com> want_reply 0 debug3: receive packet: type 91 debug2: callback start debug2: fd 3 setting TCP_NODELAY debug3: ssh_packet_set_tos: set IP_TOS 0x10 debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1
Have you ever experienced such issue ? Any suggestion?
Many thanks
/Giuseppe