主题：【原创】寻找小强 -- 数据传输故障调查实例 一 -- 萨苏

有点邪门。

或者交换机上的mac映射不正常，比如路由器的ip给重用了

虽然小强还没抓到，宝倒是先来一个了。

先临时建个通路，然后把路由还有交换器都重起一遍就好了。如果是有问的机器，肯定就起不来了。

这种问题以前遇见过，查了半天查不出来。

原来是一个路由器坏掉了，但是还不是全坏，时断时续的。

还有Cisco的全双工自适应太滥了。害得得把公司所有pc还有ip 电话全都改成100 full。

自从去年日本修改了金融法，在日本的高利贷公司就不好做了吧！特别是跨国的企业。

听说这种高利贷公司把收不回来的贷款打包以低价卖给别的公司，通常都是有黑社会背景的。至于人家公司怎么收债就不关心了。

看来天下财主都是一样黑啊！

对于日本用户，在问题查清之前，想通过重启之类方法来排错，一个字，难，两个字，很难，呵呵。

原因:本地或对端内部服务器的task负荷过大(被哪位大拿加了几个同时定时启动的辅助软件),或者更大的大拿对task进行了源码改善(确实是达到了改善目标，不过改得恰到好处,正好带来task启动时内存临界leak状态)。

对策:1.服务器加内存

2.......

3.......

结果:(IT向业务发行的事故处理报告书中记载)我们没有做什么特别的啊。好像可能也许一定是ISP那边出了问题。不过经过我们24xN小时的连续监测,已经没有类似问题再次发生。以上。

(瞎猜的,谁也别当真。呵呵。)

在美国大把的, 貌似GAAP和FASAB都有专门的地方说明怎么记录这些帐

Just spend time enjoying your article.... Truly relaxed:)

我党现在的处理办法根本不会影响包转发性能。所有的包在转发的同时会一份拷贝送到某些节点做离线分析。如果有问题才会cut off这个flow或者封IP什么的。

不会的，如果是这个问题会一直ping不通