Question9:你认为一个售后工程突然接到客户电话说 XXX 业务上不了外网了，你如何排错，【 （华三）、华为、锐捷、深信服、安恒、天融信、山石网科、奇安信、绿盟、思科】。围绕这个问题你是如何思考的？
1.
- 通用排错
a. 报告故障
b. 主动沟通确认故障【故障报告人、故障报告人、用户操作记录】
c. 确认故障
d. 故障四要素、故障主体（哪个网络故障）、故障表现（故障现象）、用户发现故障时间是几点、故障位置（哪个网络组件故障）
e. 收集信息
f. 收集信息四要素、需要收集哪些信息、如何收集这些信息、获取授权、收集的信息进行系统评估
g. 判断分析
h. 判断分析阶段是对收集的信息进行信息分析整理、通过故障信息、维护信息、变更信息、团队经验-得到可能故障的原因列表。
i. 原因列表
j. 原因猜想、可能是1、可能是2、可能是3、可能是4
k. 故障评估需要逐一排错前面进行的故障评估工作、逐一排错逐一排错三元素（逐一排错、回退准备、应急方案）、故障是否解决或者恢复、否(恢复网络)是(解决故障、通过逐一排查找到故障的根本原因）
l. 收尾工作（文档的移交、信息点通告）
1.
- 网络排错思想
-
-
- 以业务流量的路径为核心故障排查
-
通常情况下，网络中业务流量的路径是在网络规划阶段就已经设计好的，只需要知道受到网络故障影响的业务的流量往返路径，跟踪此路径，逐步排除即可。
1.
1.
1. 分层排除法
分层法很简单，所有模型都遵循相同的基本前提：当模型的所有低层结构工作正常时，它的高层结构才能正常工作。一般建议在处理故障时，从参考模型自底向上进行故障排查。
1.
1.
1. 对比配置法
对比配置法是指对比正常状态与故障状态下的配置、软件版本、硬件型号等内容，检查两者之间的差异。
经验较少的网络故障排除人员在实践中会更多的使用到这种方法。
1.
1.
1. 分块处理方案
管理部分（路由器名称、口令、服务、日志等）
端口部分（地址、封装、cost、认证等）
路由协议部分（静态路由、RIP、OSPF、BGP、路由引入等）
策略部分（路由策略、策略路由、安全配置等）
接入部分（Console登录、Telnet登录、拨号等）
其他应用部分（DNS、DHCP、VPN配置等）
1.
1.
1. 分段故障处理法
数据包转发过程中可能经过多台路由器和物理链路，每段物理连接都有可能发生故障，因此分段处理的方法是有效的。
1.
- 主网络排错
-
-
- 现实问题
-
当我们从用户那里接到一个故障时，工程师根据现象要求客户收集一堆信息，然后一线、二线用服、研发产品、研发平台一级一级反复咨询与确认，几乎每个故障都要经过多个层级的人进行处理，信息交流占据了每个人大部分的时间，反复收集信息与确认问题现象也会让用户不胜其烦。那么该如何减少这些环节无谓的损耗，提升问题的处理效率？接下来就带大家一同探讨下。
1.
1.
1. 什么是业务问题？
在网络设备上承载的业务是多种多样的，而并不是所有用户均可以根据业务部门反馈的故障准确描述是什么类型的网络问题。这就需要详细询问客户遇到的问题，来推测可能和网络设备的哪些应用有关。网络设备只不过是一个管道，并不关心承载的业务是搜索，还是云盘，网上商城等，网络设备只关心是什么网络协议出了问题。比如说是浏览网页（http协议）不可以，还是FTP下载不行，是PORTAL认证有问题，还是路由没生效？我们需要通过一系列的咨询，迅速掌握用户的业务和网络设备的什么功能有关系。
1.
1.
1. 故障现象是什么？
知道了是什么业务有问题，就基本知道和网络哪部分有关。比如最常见的就是某些网络链路不通。由于网络链路不通，导致了客户业务系统出现了各种各样的异常表现。我们需要再了解，是延迟大，还是丢包；是丢包还是彻底不通；是部分地址不通，还是全网不通；具体是从哪个地址到哪个地址网络互访有问题。
1.
1.
1. 与哪个设备有关？
数据中心里的网络设备成千上万，当明确了故障现象后，接下来需要迅速找到故障设备。这时"流量统计，镜像，抓包"三大招就派上用场了。通过这些日常手段，结合业务测试或PING测试，就可以找到故障设备，这个过程决不能省，而且还要确保统计的结果准确无误。
1.
1.
1. 用户是否操作过设备？
有人做过统计，发现数据中心里出现的故障， 70％是人为操作故障。每年运营商封网，或者节假日放假，大家会发现网上问题一下子少了很多，即使出现的也多是硬件故障。由于每个人对各个设备，网络协议的理解程度不同，在做网络变更或者部署新的应用时，往往是故障的高发期，所以不要放过用户操作的任何细节，尤其很多时候用户认为自己的操作与故障毫无关系，就不去提。请仔细检查设备的log， history Command信息。
1.
1.
1. 做过哪些排查检测？
当遇到PING不通时，试着将ARP/MAC静态绑定下，看是什么结果；当遇到PBR不生效时，试着调整下PBR的配置，看是什么结果；当遇到下载速度慢时，试着换台PC测试下，看是什么结果... ...，我们可以通过各种排查测试将故障现象进一步细化。平时可以多翻翻操作手册、命令手册以及维护手册，这样遇到问题时才能得心应手。
1.
1.
1. 对网络的操作记录是否可以查找？
人会记错，但设备不会记错。任何时候操作设备时，都要留下操作记录，留日后自己分析，或者作为说明问题的证据。空口无凭，很难说服任何人，所以不仅要自己养成记录的好习惯，也要让用户养成记录操作记录的好习惯。
1.
1.
1. 故障诊断的信息是如何？
很多时候客户急于恢复业务，要求重启设备或不再配合测试，这样留给我们定位的时间很少，此时一定要采集故障时的DIAG信息。 DIAG信息里包含了这台设备运行状态的各种参数，是产品经历过多年网上问题洗礼总结出的关键信息，所以通过DIAG往往能准确定位出80％网上问题。除了DIAG，还有" LOGFILE， DIAG-FILE" 都要收集，而且DIAG信息最好有故障时和正常时两份。
#导出并反馈以下信息
<H3C>logfile save、<H3C>diagnostic-logfile save、<H3C>display diagnostic-information。。。最后将上诉文件通过ftp或more方式回显导出。
1.
1.
1. H3C官网、知了社区是否有看过？标杆是否锤了？ iserviceCT网上问题智能诊断系统是否诊断了？
如果问题不是那么着急，可以看看官网对硬件安装、适配关系、协议使用场景等是否有相关限制；知了社区是否有类似故障问题；此外，标杆和iservice中接口错包、设备运行异常等信息也是极有帮助的。如果还是无法定位，需要将故障时间点、详细故障现象、 DIAG、 LOGFILE、 DIAG-FILE、流统、操作记录等信息收集并反馈，有了这些详细信息，问题也许很快能找到答案，否则就要花费大量的时间去交流，影响问题处理效率
1.
- 交换机丢包问题排查
开始 故障现象-交换机丢包
1.
1.
1. 明确故障时间
故障是否规律、一直异常、某个时间异常？
1.
1.
1. 确认交换机丢包位置
1、分段测试； 2、流量统计； 3、镜像抓包； 4、 debug
1.
1.
1. 检查logbuffer
检查接口Down/UP； 检查设备运行的动态路由协议邻居等状态是否存在变更； 检查设备是否收到大量刷新转发表项的TC报文
1.
1.
1. 检查接口
display interface查看接口错包（input errors）计数是否增长 display transceiver diagnosis interface xxx查看光口收发光 确认接口是否存在超带宽、拥塞丢包： display counters rate inbound interface display interface xxx（看Peak input rate、 Peak output rate） display qos queue-statistics interface+端口+outbound
1.
1.
1. 查看转发表项
三层转发： display ip routing-table 、 display fib 、 display arp 二层转发： display mac-address
1.
1.
1. 查看二层是否环路
<H3C>display mac-address mac-move [H3C-probe]debug l2 slot 1 chip 0 mac/move_rec/show
1.
1.
1. STP是否正常
display stp brief查看接口转发状态 display stp abnormal-port确定接口是否被阻塞 display stp tc确认收到的tc报文是否在不停增加
1.
1.
1. 路由是否正常
display ip routing-table查看路由是否正确，是否稳定； [spine-probe]debug rxtx softcar show slot x检查是 否有路由环路（IPV4_TTL数值是否在不停增长）
1.
1.
1. ARP是否正常
H3C-probe]debug rxtx softcar show slot X检查ARP是否超 限速（正常流量or现网攻击？）； [S6800-probe]debug ipv4-drv show config slot x确认设备的 ARP表项是否超规格； <S6800>debugging arp packet 确认ARP学习过程；
1.
1.
1. 其他原因
框式设备确认内联口是否存在异常； 入方向报文封装是否正常； 是否存在Parity-Error告警； 检查交换机版本说明书是否存在已知问题