网管判断路由器丢包的原因
一般情况下，如果路由表中有匹配的表项的话，则会进行后续的工作，路由器接口能接收到报文是其工作的基础。
如果报文丢失的话，那么将极大的影响到路由交换功能，最终导致数据的丢失，造成报文丢失的原因有很多，不过最主要的可能是路由器内存不足或者CPU过载所造成的。
要解决这个问题，首先需要判断问题的原因。
一、内存碎片是指路由器内存被划分了许多不连续的块。他将导致内存利用率降低，严重时可能会产生内存错误，影响路由器的性能。它也会导致路由器报文丢失的问题。
其实不仅路由器的内存存在碎片问题，普通的硬盘也存在这种问题。如微软操作系统中就自带一个碎片整理工具，可以保障用户来整理硬盘中的碎片，以提高硬盘的存储容量以及存储性能。这里指的内存碎片其实跟硬盘碎片是类似的。
二、那该如何判断路由器的内存是否存在碎片呢?这里主要借助的是灵科路由器自带的SHOW MEMORY命令。这个命令会显示当前内存的相关信息。如执行这条命令后，会显示当前可用内存(Free)与最大可用快(Largest)的数值。
网络管理员把这两个值进行比较，就可以判断碎片对路由器性能的影响。这主要是把路由器的可用内存与最大可用快的大小进行比较。
如果路由器的可用内存与最大的可用快大小比较接近时，表示虽然路由器存在碎片但是影响不大。但是若最大可用的块很小，如只有最大可以用内存的几十分之一，那么就说明路由器内存碎片问题比较严重了。
三、如路由器的可用内存为20M， 而最大可用块的大小为15M的话，则表示路由器内存中是有一定的碎块，但是这点碎块不影响路由器的正常运行。如果可用内存为20M，而最大可用块为0.8M的话，则说明路由器内存中存在比较多的碎块。
连续连续内存中没有足够大的可用快，这有可能导致严重的内存分配问题，如导致一个或者多个接口间歇性的丢失报文。在路由器内存中，允许存在一定的内存碎片。
到现在为止，还没有哪一种内存管理技术说可以完全避免产生内存碎片。只是这个碎片要保证一个合理的值。
具体这个值是多少，也没有人可以给出一个具体的标准。不过根据笔者的经验，最好能够保证可用块的大小在可用内存的二分之一到三分之一之间。
当然可用块大小跟可用内存越接近越好。
四、其实这个可用块与可用内存之间的关系我们可以利用柜子中的抽屉来表示。如一个柜子可用容量虽然比较大，但是里面划分了大小不等的1000多个格子。每个格子的空间容量有限。
当有大的数据需要存储时，整的容量是够的，但是小格子的容量不够。此时，就会发生报文丢失的问题。
此时看起来内存足够用，可是此时内存中已经没有连续的空间用来存储数据。所以这些看起来比较大的可用内存，其实保存不了多少数据。
五、如果确定路由器内存中没有过多的碎片，则网络管理员就要考虑是否是因为CPU过载所导致报文丢失的。要查看CPU的使用率，可以利用SHOW PROCESS命令来查看路由器的CPU使用情况，通过这条命令，可以显示出路由器CPU最近5秒、最近1分钟、以及最近5分钟的CPU使用率。由于 CPU的使用率一直在变化，故网络管理员主要关系的是5分钟之内的CPU平均使用率。
通常情况下，如果5分钟之内的CPU使用率能够保持在60%以下，最多不能够超过70%，则说明路由器的CPU工作还是正常的。但是如果其CPU使用率达到了70%以上，则说明路由器的CPU使用过度了。
此时可以说明路由器接口报文丢失很可能是CPU过载所造成的。
六、如果确认路由器CPU过载，那么网络管员需要确认到底是哪一个进程占用了大量的内存。只有把这个罪魁祸首找出来，网络管理员才能够对症下药，解决问题。如网络管理员经过查询发现是SRB BACKGROUND进程占用了大量的CPU，则就说明发生了网桥风暴。故要解决CPU过载问题，要达到这个目的，网络管理员可以通过SHOW PROCESS MEMORY命令查询路由器的内存分配信息。
通过执行这个命令，系统会反馈当前路由器内存的可用量、以使用量等信息。还会反映每个进程所占用的内存空间。如果某个进程所占用的内存与上面显示的所占用的CPU都很大的话，则说明这个进程很有问题。网络管理员要逐一排查这些可以的进程。
七、如有时候网络管理员可以强制把某些耗用CPU资源大的进程关闭掉，然后测试一下报文丢失的情况是否有所改善。如果有明显改善的话，那么就找到问题的原因了。
此时网络管理员就可以对症下药，分析一下到底这个进程多对应的服务是什么，为什么会占用这么多的CPU资源与内存资源。
如果可以的话，可以先把这个服务关闭掉，以减少报文丢失现象，保障其他服务的正常运作。等到查明问题的原因，修复好后再重新启动。
在灵科路由器中采用了很多交换技术，如过程交换、快速交换、自治交换、硅交换等等，但是他们都依赖于报文。如果报文丢失的话，再怎么高级的交换技术都将不起作用，如何防止报文丢失就至关重要。
当网络管理员发现有报文丢失的情况，马上要采取以上等措施找到报文丢失发生的原因，并积极采取措施尽早恢复故障。