概要设计
4. 典型问题分析
4.1 Console口不响应
设备使用和测试过程中经常遇到系统console口不响应的问题，这有可能是多种原因造成的，首先要排除使用不当的因素。
有可能是之前做了telnet、ssh等远程登录操作登录到其它系统，然后因为某些原因远端系统不响应，这时候在console口按任何键都不会看到回显。这时候可以试图通过“终端切换键”切回设备控制台，方法是：先按住CTRL+SHIFT+6三个键，然后松手再按x键，中间不要插入其它任何键。如果属于这种情况，输入“终端切换键”后应该能够回到设备控制台，并且用where命令可以看到刚才登出的线路，使用disconnect命令可以断开外出连接（注意按键的顺序，大部分人都不能熟练掌握终端切换键，建议先找一台正常的机器体验一下这个组合，避免误判）。
分布式系统或堆叠系统中，有可能是从主控设备通过through-pass命令登录到线卡/成员设备等情况，这时候可以通过CTRL+X能够退回设备控制台。
不属于上述两种情况的，则有可能属于软件故障。这时应该先试图telnet设备，看看能否telnet上去。如果能，则可能是出现了死锁的情况，导致tty0无法运行。这时获得tty0（注意大小写敏感！）任务的调用栈并分析，如果tty0停在正常等待用户输入的位置，那有可能是console口驱动的问题，需要请驱动开发人员继续定位。如果tty0在等待互斥量或event，那就需要查看本应发出事件或可能占有互斥量的任务的调用栈，依次检查这些任务停在什么位置，判断是否存在任务间互相等待的情况，如果存在那么就属于死锁，否则属于互斥量泄漏或漏发了event，这时候都可以请相关模块的维护人员继续定位。如果不能telnet，那就只能呼出系统热键，然后采用与telnet类似的方法依次查看tty0以及其它有关任务的调用栈并分析。假设当前tty0任务在等待A模块的互斥量，那么就需要查看A模块有关的任务，找到当前持有互斥量的任务a并查看它阻塞的原因，这样得到的最终结果有几种可能：任何任务都不可能持有该互斥量，这时可能是互斥量泄漏；持有互斥量的任务又在等待另外的互斥量，这可能是死锁。判断哪个任务持有一个给定的互斥量，有两种方法：1、vx系统互斥量结构semaphore中有一个域owner（目前除vx6.5外的vxworks中owner都位于互斥量id偏移0x18字节）表示持有该互斥量的任务，找到owner值就可以；2、根据任务调用栈当前调用的函数判断当前可能进入了哪个互斥量，这主要是基于对相关业务的经验作出判断（例如看到当前任务停在routing的函数中，那么它可能已经持有了路由的信号量rt_semaphore）。
另外一种可能造成console口不响应的可能是CPU忙，这可以从热键信息中分辨：热键中包含CPU占用率信息，如果看到CPU占用率为100%，那么就有可能导致console口不响应。这时应该查看两个信息：分任务CPU占用率（show taks信息）中，某任务CPU占用率较高并且与当前环境中正在运行相关业务，那么该任务有较高嫌疑造成CPU100%；在分任务CPU占用率最后会显示\，这里的任务名称具有较高嫌疑。
这里介绍的定位死锁等方法也适用于其它类似的情况。
综上，遇到console口不响应的问题，先排除telnet出去、登录到线卡等误操作，然后尝试telnet查看tty0等任务的调用栈，或直接通过热键查看所有任务调用栈信息；考虑到出现console口不响应的情况时，系统可能已经处于高度不稳定状态，在非用户现场情况下优先考虑热键。
4.2 CPU占用率高
先clear task，然后再show task查看CPU占用率和分任务占用率。看看哪个任务CPU占用率比
273935858.doc Version1.4T (错误！未指定书签。) Page 16 of 27
概要设计
较高，忽略IDLE任务。这种情况下一般来说某个任务占用率超过10%就应该关注了，超过50%就说明该任务很忙了。
CPU一列是每个任务的CPU占用率，后缀为E的表示该任务的占用率为“估计值”。 invoked一列是每个任务的调用次数。
分任务的CPU和invoked值，均为从系统启动（或者上次clear task）至今的统计值。
如果CPU比较忙的时候console口仍然有响应，可以直接查看忙任务的调用栈，并分析；一般需要多看几次。如果任务调用栈比较长（例如超过5行），就说明这个任务可能在处理自己的业务。这时候可以通过异常解析工具（bsa或winbsa）等解析调用栈，然后分析该任务忙的原因（也可以将调用栈以及解析结果提交给对应模块的维护人员处理）。
几个典型的可能忙的任务有：
INTR，这不是一个任务，而是模糊统计中断占用的时间，一般INTR占用比较高，说明可能有较多的报文收发操作，因为报文接收是系统中断最主要的来源。
L2Tx、bcmR、INTR三个任务忙，系统肯定是忙于接收报文。报文多有几种可能，即ipv4报文、ipv6报文、二层报文。这时候可以通过间隔5秒连续查看命令show ip traffic两次的方式得知是否是ipv4报文过多，该命令输出如下： Switch#show ip traffic IP statistics:
Rcvd: 31158449 total, 2550455 local destination, 2432184 delivered 主要关注两次执行中Rcvd值是否增长得比较快，如果平均每秒钟有几k个报文的增量，那么就可以认为是ip报文比较多，这时候请参考《三层转发引起CPU占用率高》中描述的方法来定位。类似的可以使用show ipv6 traffic来判断是否属于ipv6报文太多引起的CPU忙。
如果排除ipv4、ipv6报文，那么就只可能是普通二层报文过忙。这时候可以通过在console口上输入debug l2 rx raw octets 64来获取有关调试信息，看看是哪种二层报文比较多，并找到相应模块维护人员继续定位。
RPCS，此任务是RPC服务端。一般线卡上可能会出现RPCS比较高的情况，原因是主控向线卡发送了大量的RPC请求。比较常见的情况是主控hal下发了大量的调用，线卡收到后忙于处理并向交换芯片下发表项，也有其它可能，这里提供几种手段来排查：
1、show task 0x
2、如果show task显示当时RPCS任务不忙，那么可以通过debug rpc event来看看哪些服务号的rpc比较频繁，需要注意这个调试输出中既有发出的RPC请求也有收到的，而这里我们只需要关注那些收到的。典型的收到RPC的输出如下：
[RPC] EVENT REQ received ([type]) from slot [dig1], service code [hex1] seq [dig2], call user's rountine [hex2] to handle
其中type可能是SYNC或ASYNC，分别表示同步或异步调用；dig1是发起调用的槽位号，线卡上看到通常是0，主控上看到是线卡槽位号；hex1是16进制的服务号；dig2是调用序列号，hex2是用于处理此调用的处理函数。
假设某个调用号的RPC收到得特别频繁，那么可以结合现场业务分析为何会有大量调用。通常根据服务号的值来查找相对困难，可以在map中查找对应的处理函数（hex2）来获知rpc服务的信息。
注意：debug rpc event可能信息比较多，需要随时做好关闭调试的准备。
3、debug rpc event也找不到有用的信息，可以进入诊断模式，间隔一段时间执行命令show rpc
273935858.doc Version1.4T (错误！未指定书签。) Page 17 of 27
概要设计
service两次，检查两次之间哪些rpc服务调用次数或者消耗时间（ticks）增长较多。
ARPT，此任务是arp定时器处理。这个任务主要的工作是分时检查系统每个arp对应的mac地址是否发生了老化或迁移，如果发生了就需要更新相关的转发表项。ARPT任务忙的概率并不大，但是如果出现忙，其主要原因可能有两个：
1、检查mac地址是否迁移本身消耗了过多的时间，这有可能是交换芯片sdk的原因，以前在盛科的芯片上出现过这样的问题。
2、Mac地址频繁的出现迁移的情况，这时候arp会将迁移事件通知给相关模块并更新邻接表，这时会占用大量时间。可以打开debug arp packet、debug arp adj-table查看是否有大量调试输出，尤其有大量[ADJ]开头的调试信息，或者有大量下面的调试信息“IP ARP: Physical port of [addr] changed to [ifindex], notify routing”，则可能出现了频繁更新的情况。
Arp频繁更新，一般是因为生成树震荡的原因导致了mac地址老化，以后我们会专门描述如何定位生成树震荡问题。
MYIP，此任务主要用于ip有关的各种处理，最可能引起任务忙的几类操作有：单播cache操作、多播cache操作、路由操作等，这三种操作分别对应于调试开关debug ip flow、debug ip mroute-cache、debug ip exf，可以依次试着打开这几个调试开关看一下，看看哪种调试开关中的输出信息最多，那么就有可能是相应的功能繁忙。
如果是单播cache操作繁忙，建议参考文档《三层转发引起CPU占用率高》。 其它两种情况则需要ip/路由模块的维护人员继续定位。
EGRP，此任务用于邻接表流水线处理ipv4的cache、路由、egress等表项加入硬件表的操作。最可能引起任务忙的可能是路由压力测试时，大量路由灌入，将这些路由加入硬件表时引起CPU忙，这是正常的。其它情况需要ip模块的维护人员继续处理。
DHSN、DH6S，此任务用于dhcp snooping和dhcpv6 snooping业务。这里存在一些情况需要操作交换芯片的FP表，而频繁的FP表项操作可能引起任务繁忙。需要此模块维护人员继续处理。 IG-S，此任务是igmp-snooping的主任务。这个任务忙，有可能是因为设备收到了大量的igmp报文引起处理繁忙，可以debug ip igmp-snooping packet看看，如果出现大量收到报文的调试信息，建议先排查一下收到igmp报文的原因；如果不属于这种情况就需要此模块维护人员处理。 SNMP，此任务忙可能是收到了大量的SNMP请求，建议检查网络中是否存在网管软件在访问该设备。
其它任务忙，建议结合《交换机系统任务不完全列表》找到相关模块的维护人员定位问题。
4.3 三层转发引起CPU忙
首先clear task、show task，查看show task中CPU一列，看看哪个任务偏高。如果是L2Tx、INTR、bcmR等任务忙，则说明可能是收到了过多的报文导致的，首先通过show ip traffic命令看一下其中的Rcvd统计（命令输出第一行）是否增长较快，如果每秒钟增长小于一千，那么应该不属于这种情况；否则需要通过调试命令查看哪些报文较多。
如果使用console口连接到设备上，直接使用debug ip packet打开调试命令；如果使用telnet方式连接，则必须在debug的时候配置访问列表，去掉从PC到设备的ip报文，比如我的PC机地址是192.168.25.24而telnet的设备地址是192.168.25.254，那么我们需要配置这样一个扩展访问列表： !
ip access-list extended mydebug
deny ip 192.168.25.254 255.255.255.255 192.168.25.24 255.255.255.255 deny ip 192.168.25.24 255.255.255.255 192.168.25.254 255.255.255.255 permit ip any any
273935858.doc Version1.4T (错误！未指定书签。) Page 18 of 27
概要设计
!
然后telnet到设备上之后使用debug ip packet access-group mydebug，后面这个access-group mydebug特别重要，不加这个会导致debug信息非常多。在telnet线路上查看debug信息，需要先打开terminal monitor命令。
查看debug信息中哪些ip报文比较多，因为设备在跑业务可能流量较大，随时做好准备输入no debug all以免过多调试影响业务。
几种典型的调试信息如下：
IP:
说明系统从接口sintf收到源地址sip、目的地址dip的报文，从接口dintf发出，下一跳网关是gateway-addr。
这样调试说明系统在三层转发报文，通常三层转发都是硬件完成的，软件转发仅限于硬件表还没生成的时候。如果这种报文出现得非常多说明系统出现了软件转发的情况，这时候请检查： 1.gateway-addr与dip是否一致，
1.1如果一致则说明该转发命中了直接路由，这时候应该为dip加硬件cache。现在出现很多打印输出说明硬件cache可能没加成功，这有两种可能，arp没学到或cache表满。先检查一下dip的arp是否学到。
1.1.1 show arp时dip的arp已经存在，其interface包含物理端口信息，例如v20(g2/1)，说明arp学习已经完成，这时候请检查sintf与dintf是否相同：
1.1.1.1 sintf与dintf相同，这说明三层转发的报文从相同的接口进出，首先结合网络情况判断这种报文是否合理，如果合理请show running interface
1.1.1.2 show ip cache查看当前有多少条ip cache，是否超出了硬件表的规模。如果超出硬件表规模，则说明此设备不满足现网需求，需要通过优化网络或配置等方案解决现网问题。
1.1.2 show arp时dip的arp已经存在，但interface只有vlan，例如VLAN20则不能成功加入硬件表，这种情况一般是因为用户配置了静态arp，但是arp的mac地址不正确或者主机不存在，而这时候却有其他主机（sip）向该主机发送报文，导致CPU占用率升高。这时建议取消静态arp配置，或者排查网络确定流量的合法性。
1.1.3 show arp时dip的arp是未完全项，这时候调试信息中应该会伴有大量的encapsulation failed：
1.1.3.1 dip不存在但有主机向它发送报文，这与1.1.2的情况有些类似，请排查网络确定流量的合法性。
1.1.3.2 dip存在但因为其他原因导致arp刚刚学到就被老化，导致ip cache会不停地被加入硬件表然后从硬件表中删除。这时候可以debug ip flow看看是否有大量相同地址的ip cache反反复复的在硬件表中添加和删除，例如有非常频繁的\to software cache\、\to hardware cache\和\from hardware\的字样，这种情况最大可能是生成树震荡导致mac地址不停老化最终引起arp和cache删除，建议通过debug span topo等手段检查生成树的有关情况。
1.2 gateway-addr与dip不一致，这时候这些流应该是命中exf的，但这些报文全都被送到软件转发，说明硬件exf表没有添加成功，这也有两大类原因，gateway-addr没学到或这exf表满，可以参考上述方法检查gateway-addr的arp为什么没学到。
4.4 Ping不通
Ping不通大致有几类原因：
1、ping出端icmp echo request报文没能正常发出去，这可能是因为没有路由、没有arp或硬件
273935858.doc Version1.4T (错误！未指定书签。) Page 19 of 27
概要设计
故障导致没发出去；
2、被ping端没收到报文，这可能是交换芯片表项设置不正确，例如defip表不正确，导致直连路由没送到CPU，fp表不正确，导致报文被重定向，vlan设置不正确，导致报文被vlan过滤，生成树状态不正确，导致报文被丢掉，等等；
3、被ping端icmp echo reply（下文称为ping请求）未能正确发出，原因一般与1相同； 4、Ping出端icmp echo reply未能收到，原因一般与2相同；
5、Ping出端收到icmp echo reply（下文称为ping应答）时超时。
出现ping不通时，需要打开一些调试命令来判断ping不通的原因，建议在console口使用全部调试命令，如果需要在telnet线路上使用ip调试命令，需要使用访问列表过滤掉无关报文，不能在telnet线路上使用l2、hal的调试命令。下列所有ip调试信息中A表示ping出设备的ip地址，B表示被ping设备的ip地址，G表示报文发出的网关，可能与A/B之一相同。 建议依次进行下列调试步骤： 1、检查ping出设备是否将ping请求报文发出：在ping出端打开debug ip packet，然后开始ping，并检查日志：
类似“IP: 0,src=A (local), dst=B (VLAN2), len=84, gate=G, sending”的日志，并且后面没有跟着其它日志（如下面的封装失败），说明ip层面已经正确的将报文发出；
类似“IP: 0,src=0.0.0.0 (local), dst=B, len=84, route failed”的日志，说明没找到路由，这时应该通过show ip route查看被ping的地址是否有路由；
类似“IP: 0,s=A (local), d=B (VLAN2), g=G, len 84, encapsulation failed”的日志，说明没有学到下一跳地址的arp，这时建议检查g=后面的ip地址对应的arp是否存在，这里需要说明只有连续ping出至少两个报文的情况下才可能看到“封装失败”的输出，对每个封装失败的报文会依次报告“sending”、“encapsulation failed”。
如果调试信息显示ip层面已经正确的将报文发出，那么可以使用debug ip tx multi-tx raw error查看l2层面的发送结果，查看是否有失败信息（注意检查失败信息是否对应着发出的ping报文）；如果l2层未输出失败日志，可以使用debug hal send查看hal的输出。
2、如果上述调试信息都未报告失败，那么我们应该认为报文正确的从ping出端发出了，需要检查被ping设备软件层面是否收到ping请求报文。这时候我们应该查看被ping端的有关日志信息，需要说明的是如果被ping的设备是85、95等分布式交换机，所有下面这些调试信息都需要在与ping出设备相连的线卡上查看（例如被ping设备通过G2/1端口连接ping出设备，那么应该在slot 2上查看调试信息）：
在被ping端打开debug ip packet，保持ping出端的ping操作，并检查日志：
类似“IP: 0,src=A (VLAN2), dst=B (VLAN2), len=84, rcvd”说明收到了ip报文，这时可以通过检查源、目的ip地址、报文长度等方式确认是否是ping请求报文；也可以通过debug ip raw使系统详细输出报文格式来确认。 如果被ping端未输出上述日志，需要在诊断模式下使用debug l2 rx raw error命令查看l2层收到报文的情况，并根据输出的报文内容判断是否收到了ping请求报文。如果l2调试信息显示l2也未收到ping请求报文，那么建议检查vlan配置、生成树状态、交换芯片上路由表项等信息，确认未收到报文的原因；或者先确认ping出设备是否正确的将报文发出来。 如果被ping端日志显示它收到了ping请求报文，那么应该继续检查是否将ping应答报文发出，这里的调试方法与“检查ping出设备是否将ping请求报文发出”相同。
3、如果上述调试信息说明被ping设备收到了ping请求报文，需要检查被ping设备是否发出了ping应答报文。
首先使用debug ip icmp命令，检查是否有类似“ICMP: rcvd echo from A, len 40”的调试信息，如果有则说明被ping设备的icmp层面收到了ping请求报文，这时继续检查是否有类似“ICMP:
273935858.doc Version1.4T (错误！未指定书签。) Page 20 of 27