一大早，公司砸开了锅，纷纷说公司所有的服务器都出现登录出现延迟。我连忙远程了一下，用ssh -v debug了一下，发现远程连接并未出现什么问题。但登录不到几秒钟，鼠标就不动了。这还了得，根本无法干活嘛！我陆续查了防火墙的负载，日志，cpu,session等都未发现什么异常。公司的远程工具也设置了反空闲。

我继续用ping,tracert工具发现到联通的节点就无法访问。很显然tracert没到公司的防火墙地址就不行了。我初步判断是机房的网络有问题。与机房协调沟通，并无半点收获。人家说他们网络正常，其他客户都没出现问题。从机房的流量监控看也没发现流量异常。

我不得已亲自去一趟机房，登上服务器一看，未出现任何问题，访问外网也正常。ssh配置文件没有问题。用机房的内网远程访问我们的服务器，依旧是时断时续。用了tcpdump抓包工具，发现一台服务器的发出的udp包过多，我开启了udp flood防护功能，但并未出现改观。

在机房用机房的内网远程我们的服务器也是时段时续。在机房tracert我们的服务器和在公司一样，机房这才答应和机房的网络提供商联通联系。事后机房也未承认是机房的网络问题。隔几天远程竟然奇迹般的恢复正常。

到底是哪里出现了问题呢，真是一个诡异的故障经历。虽然没有搞清楚问题出在哪里，记录下来，以作参考，也希望高人们能提出意见，不甚感激。

事后两个月，这篇文章有了下文。

诡异的情况再次出现，从cacti监控图可以看见一台服务器的网卡流量较高，登上这台服务器，用iftop -n查看网卡流量发现有很多udp包，用lsof -i udp,发现发包的罪魁祸首是webservice,这是开发人员部署的一种分布式服务，把服务的部署人员协商，停止了这个服务，几分钟以后，ssh卡顿现象瞬间消失。上次已经发现了udp包过多的问题，只是做了一些策略，并未停止服务。至于这个服务为什么会有那么大的破坏力，我也不得而知。事情总算过去了，至此ssh诡异事件也划上了句点。