故障描述：
上周末，一个市场的托管机房例行电路设备清洗升级，中间有些单电源设备发生重启，其中有一台服务器重启后死活无法通信；
解决·思路：
起初以为是重启死机，让机房协助放电重启，仍然无法通信，设备硬件状态灯一切正常，显示器显示用户登录界面，且鼠键正常使用，服务器是一台linux操作系统。
然后怀疑是否网络配置有问题，因为服务器配置了双网卡绑定，自知可能性不大，死马当活马医，让机房协助进入到系统单用户模式，查看网卡状态都是正常的，于是注销掉网卡配置，并在其它网卡em4上配置一个新的ip，把em1的线插到em4上，依然无法通信。
最后怀疑是网线问题，给em1换了根网线依然无法通信。注意这里有个失误，没有测试em2网口的线，也没有用em2网口的线插到em4上尝试。
没办法今天博主亲自上阵，又折腾了不少时间，依然没招，最后登录到链接这台服务器em1口的汇聚交换机上，才发现这个口的status是up的，但protocol状态是down的。
第一时间想到的是，不会生成环路了吧，因为服务器配置有双网卡，但是马上杜绝了这个念头，其一双网卡配置没毛病，其二查看交换机这个接口信息，并没有error disable状态，其三查看生成树并没有发现alternate BLK的阻塞状态。
是么原因造成的这个接口的protocoldown状态呢？没招开始查看交换机配置文件，一点点过目。
发现了monitor的配置，其中Destination port 指向的正是这个接口，到此才恍然大悟。
事实上，交换机的镜像端口的目标端口，其protocol状态是关闭的，以前真的没有注意这个梗。
而为什么重启之前没事呢，这就和双网卡绑定有关系了，恰巧之前服务器流量跑在了em2上，配置monitor端口时，没有及时发现，而重启系统后，em1优先级较高接管了流量通信。而monitor的目标端口是protocol down，物理上的status确实up的，这也就导致了bond无法检测认为em1是正常的，流量自然还是走em1，自然也就无法通信。
说到底还是经验不够，迟了亏，其实当时换根线用em2口的线单独测试，兴许就会及时发现这个问题，想到交换配置的问题，也就不用到现场折腾小半天。
好在客户损伤不大，业务上及时迁移到其它主机上，没有造成损失。
下次碰到此问题，网络设备，硬件、系统，等所有的原因还是都要考虑到位，才能搞高效快速的定位并解决问题，以此为戒了。
（今天的分享就到这里，如果您有高见或好的分享，记得留言哦！）
祝福我们的祖国繁荣昌盛
