如何看待Cisco交换机与路由器多CPU

Cisco交换机与路由器多CPU的特点
Cisco交换机和路由器到底有几个CPU，都分布在哪个模块上？这些是否能通过命令查出，查出来是否有问题
分析依据
要查Cisco交换机和路由器上的多CPU，必须有CISCO-PROCESS MIB，从该MIB中表cpmCPUTotalTable 查找到对象cpmCPUTotal5minRev（即5分钟CPU收到的占有率），通过通过这个表的CPU索引 cpmCPUTotalPhysicalIndex 找到CPU所在位置；最好后通过索引，从entPhysicalName 对象找到CPU分布在那些模块，cpmCPUTotal5minRev的值需要确认IOS版本，再确认不同的对象。综上，分三步查找：
1、cpmCPUTotal5minRev (1361419910911115) （以IOS在120(3)T-122(35) 之间为例），查找该设备有几个CPU，同时每个CPU占有率多少。
2、cpmCPUTotalPhysicalIndex (1361419910911112) 查找CPU在cpmCPUTotalTable 中的索引。
3、entPhysicalName (1361214711117) 通过引用索引，定位CPU在哪个板卡上。
实例分析（Cisco catalyst 6509）
1、查找CPU的个数，及5分钟占有率。
C: >snmpwalk 10102 1361419910911115
ciscociscoMgmt109111151 : Unsigned32: 6
ciscociscoMgmt109111152 : Unsigned32: 7
ciscociscoMgmt109111153 : Unsigned32: 91
ciscociscoMgmt109111154 : Unsigned32: 91
该Cisco交换机有4个CPU，分别占用为 6% 、7%、91%、91%。
2、查找CPU的索引。
C: >snmpwalk 10102 1361419910911112
ciscociscoMgmt109111121 : INTEGER: 4017
ciscociscoMgmt109111122 : INTEGER: 4001
ciscociscoMgmt109111123 : INTEGER: 1007
ciscociscoMgmt109111124 : INTEGER: 5007
3、通过索引，定位CPU在哪些板卡上。
C: >snmpget 10102 13612147111174017
47111174017 : OCTET STRING- (ascii): CPU of Routing Processor 5
C: >snmpget 10102 13612147111174001
47111174001 : OCTET STRING- (ascii): CPU of Switching Processor 5
C: >snmpget 10102 13612147111175007
47111175007 : OCTET STRING- (ascii): CPU of Sub-Module 1 DFC Card
C:>snmpget 10102 13612147111171007
47111171007 : OCTET STRING- (ascii): CPU of Sub-Module 2 DFC Card
通过参看Cisco交换机的板卡，定位对应关系，从上面的分析上看，可以看出6509 配置的5个模块，CPU的分布如下：板卡号 模块名 子模块名 Cpu个数 CPU占用率。
1 16口SFM 1000MB模块 DFC 卡 1 91%。
2 16口SFM 1000MB模块 DFC 卡 1 91%。
3 8口1000 MB 模块 - 0。
4 48口100 MB 模块 - 0。
5 SUP 720 引擎 PFC和MSFC2 2 PFC 6%， MSFC2 7%。
为什么DFC卡 CPU 占有率如此高？
DFC中有一个进程为 lcp schedular ，这个进程在系统初始化的时候，占用CPU时间为100% ，之后其他的进程需要CPU时间时，分配给其他的进程，也就是说lcp scheduler 占用的都是没有用的CPU时间， lcp scheduler 进程是接管所有没有用的CPU时间来动态分配CPU。某些网管软件和命令 show process cpu 不关心DFC的cpu ，所以查不到。

你的路由可能被攻击了，最好把路由器恢复到出厂设置，在重新设置下，另外就是检查下端口，对端口进行监控，观察一段时间看下
你看下show processes cpu | exclude 000%
然后看看那个线程CPU usage会比较高
不知道有没有loop
检测下有没有环路
再就是用排除法来分析了
把端口逐个断开，观察cpu利用率，很快就能找出故障的端口。或者进一步用排除发找出网络分支上的故障点。
1、判断故障原因
原理上，是在路由器上创建一个permit ip any any的access-list（访问列表），然后，把这个acl应用到故障端口上，打开ip包的debug，分析故障原因。例子如下：
11创建一个access-list ，允许ip包通过
route（config）# access-list 120 permit ip any any
12把此acl应用的故障端口上
route（（config-if）#ip access-group 120 in
这样做的目的是因为，下面要打开debug，就是要根据这个acl，来抓通过这个端口的包。
13打开debug进行抓包
route#debug ip packet 120
debug应该在console上进行
14停止debug
route#no debug all
注意debug可能会把路由器冲死，所以应该尽快停止。
15分析抓到的包
抓到的包，可以分析出原地址，目的地址，源端口，目的端口，用于判断故障的根源。
当然，有时遇到攻击软件，会用IP欺骗的方式进行攻击，例如下面看到的抓包信息
2:54:56: IP:
s=18093127229 (FastEthernet0/0), d=1931517376 (FastEthernet0
1), g=2111387497, len 40, forward
2:54:56: TCP src=1232, dst=80, seq=1632305152, ack=0, win=16384 SYN
2:54:56: IP: s=18093128205 (FastEthernet0/0), d=1931517376 (FastEthernet0
1), g=2111387497, len 40, forward
2:54:56: TCP src=1839, dst=80, seq=1144193024, ack=0, win=16384 SYN
2:54:56: IP: s=18093129212 (FastEthernet0/0), d=1931517376 (FastEthernet0
1), g=2111387497, len 40, forward
2:54:56: TCP src=1116, dst=80, seq=1918435328, ack=0, win=16384 SYN
2:54:56: IP: s=18093130223 (FastEthernet0/0), d=1931517376 (FastEthernet0
1), g=2111387497, len 40, forward
2:54:56: TCP src=1302, dst=80, seq=1559429120, ack=0, win=16384 SYN
上面这个例子可以看出，攻击行为用虚拟源地址180xxx想目的地址1921517376发包，这些包都被发到了网关，也就是路由器的FastEthernet0/0。
2、解决方法
首先，当然应该先找到罪魁祸首，如果在路由器上debug不是很清晰能找出故障源，就用sniffer或者ethereal这样的抓包工具找出那台机器。
另外，在路由器上，也可以针对攻击的特性，做访问列表，关闭相关的端口。
下面是在路由器上一个典型的acl
! --- 禁止ICMP协议
access-list 115 deny icmp any any echo
access-list 115 deny icmp any any echo-reply
! --- 禁止冲击波135端口的数据包
access-list 115 deny tcp any any eq 135
access-list 115 deny udp any any eq 135
access-list 115 deny udp any any eq 4444
! --- 禁止TFTP应用的端口的数据包
access-list 115 deny udp any any eq 69
! --- 禁止其他微软的有漏洞的协议端口
access-list 115 deny udp any any eq 137
access-list115denyudpanyanyeq138
access-list115denytcpanyanyeq139
access-list115denyudpanyanyeq139
access-list115denytcpanyanyeq445
access-list115denytcpanyanyeq593
! --- 允许其他的IP包通过路由器端口
access-list 115 permit ip any any
! --- 把以上的访问列表应用的端口上
interface
ip access-group 115 in
ip access-group 115 out
另外还有和你一样有故障的人的结局方法：你可以参考下
1 IP
NAT导致路由器cpu利用率高的情况比较常见，查了nat表 发现我的静态映射条目只有5个不算多 这个应该不需要考虑
2
在inside、outside端口增加no ip redirect和no ip
direct-broadcast等语句以减少cpu处理的数据包，这个是非常重要的一步，很多时候，路由器死机就是因为没有做这一步防范
3
启用了service tcp-keepalive-in功能和scheduler process-watchdog
terminat功能，开启了看门狗进程，检查已经建立的tcp连接，如果发生不激活或者长时间挂起的情况，立刻中断这个连接。个人认为只对路由器自身发
起的链接有效，
4 使用no ip source-route命令关于对于源ip地址的路由检查，这个避免了不必要的资源占用
5
关闭一些不需要的服务 比如 no ip finger ，no service tcp-small-servers，no service
udp-small-servers等等
6 关闭对直接广播的转发 no ip direct-broadcast
这样可以防治路由器对一些大量的广播包进行应答
7 关闭了路由器的>