网络故障排除思路

上月时，一时心血来潮，想将自己所知，自己所了解这几年来的服务器维护经验做下小结。
是以答应培训发展部，给部门成员进行几次培训。
主要内容有：服务器故障的应急处理及网络故障分析
　　　　　　Dns架构与常识
            技术人员效率提升之简单办法
分三次培训，每次１小时。
原以为这些都是些经验之谈，写起培训档来，应该没什么问题。
没想到真正动手的时候，才发现。自己还未达到高屋建瓴的高度。并不是如自己所想的那样可以做到随手拎来～
　　　
　　　大致写完培训档后才发现，很多平时常用的指令，我们并不深解其原理。如traceroute～
　　　
　　　其实关于培训，受益最大的应该是培训师，在每一次对别人进行培训时，其收益远大于受训者～
　　
　　　培训在我看来是一种经验之谈。其实每个人都有可当培训师的潜质。可惜因种种原因，很多人浪费了。
　
　　　培训别人是一种沟通过程，是一种学习过程，一种交流与成长的过程。有好的东西能拿出来分享，是体现自己我价值，提高认知的很好途径。

　　　例如今天准备的服务器故障应急处理与网络故障分析。其重点就是一种思路。一种对网络问题的判断思路。
　　　服务器维护工具不重要，意识与责任才是重要的。通过这次的培训文档的准备，让我对traceroute的原理、基本表现、及侦听的数据有一个较深入的了解。
　　　对之前认为怪异的路由信息，变得不再怪异了。
　　　很多时候，问题能够解决。但我们却不知道是因为什么而解决了～
　　　要写培训档时～这原因或许就可以解决了。道理很简单，你总不至于想被别人问得下不了台吧～

部分内容介绍：
　　对网络故障及服务器故障的准确判断是作为一个合格的网管的必备技能。只有知道问题才能解决问题，如何在最短的时间确定故障点或问题点，如何使用网络故障诊断工具是本次培训的主要内容。
   1.故障处理流程与思路
　 2.网络故障诊断
　 3.服务器故障诊断
　 4.故障重演与演示


故障出现后，理出一个判断流程与思路至关重要。特别的网络故障，若没有一个很好的思路，则会越测试得到越多的结果就越乱，对问题越不能确定。是以在故障出现后，对每个测试，我们都必需有一个确定的目标。这与做事是一致的。有目标，制定行动骤，再用一个个的测试来核实。以确定问题点。很多时候，这些行动都是在我们脑里一晃而过，这些是经验。但归纳后，你的效率就会更高。对问题的了解就越彻底～具体对思路的了解我会结合网络故障诊断来分析。但一个基本思路是：结论是什么？依据是什么？360方位的测试结果是什么？

1.1故障描述。问题发生时，对故障的描述信息收集的越详细越好。（网站域名不能访问？服务器ip能不能正常ping通，或哪些地方能通哪些地方不能通？服务器所在同网段内网能不能正常ping通，服务器有没有到达正常的登陆界面？）
1.2依据故障的描述，分析大概的几种可能情况，制定测试方案（一般是在大脑中确认。有经验与没有经验在这一点上很能体现问题）。再据测试结果分析。
1.3一般常见故障与沟通技巧。测试点的选择，路由测试到哪一跳，这一跳对的物理方位。在沟通时，需要对方帮你确认的信息与内容是什么？具体要对方帮我们什么？

360测试方式：

如我们最常见的服务器当机情况。发现服务器监控机报警了，服务器连不上了。我们先用ping测试，看服务器是否可达？－》无返回数据包－》做路由测试（确认是公司内部问题或是网络哪个节点问题，若是最后一跳是到idc的路由ip，则确定是idc方面问题。－》再到同一机房同网段内的机器上进行ping测试。确认内网是否是正常的。）这就是所谓的我认为的360测试方式。逻辑原则是：外－》外－》内－》内
利用cacti流量监控/ipmonitor监控等。
提供给idc的资料内容：路由测试、路由比对测试、内网测试结果，丢包率，测试点。

技术描述禁忌与建议：
故障描述。问题发生时，对故障的描述信息收集的越详细越好。（网站域名不能访问？服务器ip能不能正常ping通，或哪些地方能通哪些地方不能通？服务器所在同网段内网能不能正常ping通，服务器有没有到达正常的登陆界面？）
依据故障的描述，分析大概的几种可能情况，制定测试方案（一般是在大脑中确认。有经验与没有经验在这一点上很能体现问题）。再据测试结果分析。
一般常见故障与沟通技巧。测试点的选择，路由测试到哪一跳，这一跳对的物理方位。在沟通时，需要对方帮你确认的信息与内容是什么？具体要对方帮我们什么？

常见工具的使用：ping,　netstat,　tracert/traceroute,　route add，nmap,lsof命令行的使用
常见故障的表现：arp攻击、国际出口故障、idc故障、dns故障、指向故障、公司内部出口故障的常见表征
3.Arp攻击表征：ping 丢包，整段网络问题或单台问题，同网段可ping，在相邻机器上查得arp –a时发现网关mac不一致。解决办法：tcpdump –nnnv arp 应该可以监听到arp攻击信息包。再通过nmap -sP 192.168.1.0/32  查整段的服务器mac来确认攻击源的真实ip地址。

Netstat –s查看具体机器上的数据包统计情况。
Tcpdump 常用侦听语法：
tcpdump -nnnv arp 查找ARP攻击时确定攻击原MAC地址时常用。
tcpdump -nnnv udp port 53  DNS服务器53端口受ARP攻击时查看攻击源时用。
tcpdump -nnnv udp and not port 53  可以确定是否有非53端口的大流量UDP攻击
tcpdump -nnnv port 80 and host 192.168.0.1 找出从192.168.0.1的80端口收到或发送的IP包。
tcpdump -nnnv host ! 192.168.15.129 and ! 192.168.15.130 and dst port 80
捕获除了主机192.168.15.129与192.168.15.130 且到本机目标80端口的数据包。
tcpdump -nnnv src 192.168.15.129 and port 53 捕获由192.168.15.129到本机53端口的数据包。不管是UDP还是TCP


服务器故障：
这里说的服务器故障指：路由的最后一跳节点在idc网关处理的所有故障。包括：硬件故障、启动故障、软件设置故障等。一般需要IDC帮忙进行处理的所有故障判断。此部分故障目前大部分由系统集成部来承担。这里只介绍几点基本的处理方法。
2.常见的硬件故障有：RAID故障，磁盘故障，电源故障。一般在启动过程需要人工干预。
3.常见的软件故障主要有：重启或掉电引发的文件系统故障。
4.系统日志是解决软件故障的重要依据。无论是什么系统，在出现异常后，首先要查看的就是日志。