[期待解决]远程登入到solaris系统奇慢无比！！！Windows系统 电脑资料

期待解决远程登入到solaris系统奇慢无比！Windows系统 电脑资料 公司的几台 服务器 是放在数据中心的，和本地通过专线连接， 公司的几台服务器是放在数据中心的，和本地通过专线连接。因为是在局域网里，远程连接使用secureCRT的ssh协议。 最近发现连到应用服务器上输入密码后，要等很长时间才能登入，用的是solaris系统，装了三快网卡，一快是接到外网，两快接内网，无论是用两快内网网卡的哪一快连接，速度都是奇慢。但是同样连接到数据中心的Web服务器，速度就很快。而且最奇怪的是我们本地也有一台solaris系统，如果先登入这台服务器，然后通过te.或者ssh连接应用服务器，都不会发生延迟的现象，但用办公室的pc上连就是要等上个老半天。 不知道哪位碰到过类似的情况，有待高人解答，万谢. diag 回复于：xx-09-11 09:46:44如果SSH 慢 我遇到过。（你用HOSTNAME 还是 IP ？） TELNET 就不明白了。 yiyu_66 回复于：xx-09-11 13:33:25我用的是ip地址，用ip和hostname连接有什么区别吗？ duxf 回复于：xx-09-11 13:41:04dns有问题的时候，比较慢，检查一下你得Dns设置 siyeclover 回复于：xx-09-11 13:50:26color=gray:f668ff68a5cloud猜测是域名逆向解析的问题。 修改一下应用服务器的hosts文件，把本地的机器的名字写进去。 不知禁止域名逆向解析是否可以，cloud没做过。 以下文字抄录自OpenBSD的FAQ，对solaris或许也有借鉴之处，希望可以帮助到您：/color:f668ff68a5 quote:f668ff68a58.22 - Reverse DNS - or - Why is it taking so long for me to log in? Many new users to OpenBSD experience a two minute login delay when using services such as ssh, ftp, or tel. This can also be experienced when using a proxy, such as ftp-proxy, or when sending mail out from a workstation through sendmail. This isalmost always due to a reverse-DNS problem. DNS is Domain Name Services, the system the Inter uses to convert a name, such as .openbsd into a numeric IP address. Another task of DNS is the ability to take a numeric address and convert it back to a name, this is Reverse DNS. In order to provide better logging, OpenBSD performs a reverse-DNS lookup on any machine that attaches to it in many different ways, including ssh, ftp, tel, sendmail or ftp-proxy. Unfortunately, in some cases, the machine that is making the connection does not have a proper reverse DNS entry. An example of this situation: A user sets up an OpenBSD box as a firewall and gateway to their internal home work, mapping all their internal puters to one external IP using NAT. They may also use it as an outbound mail relay. They follow the installation guidelines, and are very happy with the results, except for one thing - every time they try to attach to the box in any way, they end up with a two minute delay before things happen. What is going on: From a workstation behind the NAT of the gateway with an unregistered IP address of 5, the user uses ssh to aclearcase/ target=_blank ess the gateway system. The ssh client prompts for username and password, and sends them to the gateway box. The gateway then tries to figure out who is trying to log in by performing a reverse DNS lookup of 5. The problem is addresses are for private use, so a properly configured DNS server outside your work knows it should have no information about those addresses. Some will quickly return an error message, in these cases, OpenBSD will assume there is no more information to be gained, and it will quickly give up and just admit the user. Other DNS servers will not return ANY response. In this case you will find yourself waiting for the OpenBSD name resolver to time out, which takes about two minutes before the login will be permitted to continue. In the case of ftp-proxy, some ftp clients will timeout before the reverse DNS query times out, leading to the impression that ftp-proxy isnt working. This can be quite annoying. Fortunately, it is an easy thing to fix. Fix, using /etc/hosts: The simplest fix is to populate your /etc/hosts file with all the workstations you have in your internal work, and ensure that your /etc/resolv.conf file contains the line lookup file bind which ensures that the resolver knows to start with the /etc/hosts file, and failing that, to use the DNS servers specified by the nameserver lines in your /etc/resolv.conf file. Your /etc/hosts file will look something like this: :1 localhost.in.example localhost localhost.in.example localhost gw.in.example gw 0 scrappy.in.example scrappy 5 shadow.in.example shadow Your resolv.conf file will look something like this: search in.example nameserver 3 nameserver 4 lookup file bind A mon objection to this is But, I use DHCP for my internal work! How can I configure my /etc/hosts? Rather easily, actually. Just enter lines for all the addresses your DHCP server is going to give out, plus any static devices: :1 localhost.in.example localhost localhost.in.example localhost gw.in.example gw 0 scrappy.in.example scrappy 5 shadow.in.example shadow 00 d100.in.example d100 01 d101.in.example d101 02 d102.in.example d102 . snip . 98 d198.in.example d198 99 d199.in.example d199 In this case, I am assuming you have the DHCP range set to 00 through 99, plus the three static definitions as listed at the top of the file. If your gateway must use DHCP for configuration, you may well find you have a problem - dhclient will overwrite your /etc/resolv.conf every time the lease is renewed, which will remove the lookup file bind line. This can be solved by putting the line lookup file bind in the file /etc/resolv.conf.tail. Fix, using a local DNS server Details on this are somewhat beyond the scope of this document, but the basic trick is to setup your favorite DNS server, and make sure it knows it is authoritative for both forward and reverse DNS resolution for all nodes in your work, and make sure your puters (including your gateway) know to use it as a DNS server. /quote:f668ff68a5 color=gray:f668ff68a5 以上 喜欢新田由加的siyeclover /colo