一：网络layout简化如下：
二：异常现象：
测试网络中做了两个SERVER，一个Primary server (192.168.10.4.1),一个Standby server(192.168.104.2), 某天发现Standby server做备份的时候有丢包，丢包率在5%，出现丢包异常。好在异常是Standby server，有足够的时间去Troubleshooting。
三：此次Troubleshooting过程折腾了好多天，网路课同仁从网络角度去查找原因，系统课同仁从系统平台去查找原因，登入交换机，查看log，发现连接Standby server 端口有大量的UP,DOWN的信息，刚开始交换机并没导入时间，没记录到Log和time的对于关系，怀疑丢包异常是网线或者网卡有问题导致UP,DOWN，那就换网线，换网卡测试，发现异常并没有解除，但是还是想最终确认，按照如下命令导入：
在enable模式下使用clock set 设定
在config模式下使用以下3条指令
clock timezone GMT 8 设定时区
service timestamps debug datetime localtime 设定debug产生的时间格式
service timestamps log datetime localtime show-timezone 设定log产生的时间格式
奇怪，一丢包，TTL值从64变成128，讲到这里，大家可能网卡或者协议栈出了问题，但是这次的问题，可不是如此：
常识：大家都知道系统平台不同，PING的TTL也是不样的。
LINUX TTL=64
WIN2K/NT TTL=128
WINDOWS 系列 TTL=32
UNIX 系列 TTL=255
WIN2K/NT TTL=128
WINDOWS 系列 TTL=32
UNIX 系列 TTL=255
知道了以上的常识的话，解决问题思路就更加开阔。
ping 192.168.104.2 TTL=64的话，证明现在刚好在和Standby server （系统平台为linux)通讯,突然通讯中断,出现TTL=128 那么可以想象到现在已不在和Standby server 通讯而是和同网络中另外一台test station。
机会难得，赶紧CMD ---> arp -a ; nbtstat -a 192.168.104.2 发现此对应的MAC是另外一个，哈哈，总算找到原因。
到这里，我们也只能得出，同网络中有台PC中了ARP病毒，劫持了Standby server 或者某网卡绑定了Standby server 的MAC,最后mail通知到工程部门去确认，发现是某网卡绑定Standby server 的MAC，；异常根源解除，再重新测试数据备份已OK。
