网管员利用debug命令排错及应注意事项

  在实际工作中,为了确定事件、数据包是否工作正常或者某个策略是否有效,往往可以通过这个debug命令来查看交换器等网络设备的进程运转情况。不过这个命令跟ping等其他排错命令不同,其会带来很多的负面作用。所以在使用的时候,网络管理员需要特别的注意。具体的来说,需要注意一下几点。

  注意事项一:不要在网络比较繁忙的时候使用这个命令

  通常情况下,使用debug命令是可以帮助网络管理员收集到很多有用的信息。但是需要注意的是,与此同时,这个命令也会产生大量的对于解决问题没有多少帮助的垃圾数据。也就是说,这个命令本身并没有过滤的功能,其只是简单的收集相关的信息。这不仅会增加设备与网络的负担,而且分析这些信息的时候,也会有不少的障碍。当信息比较多的时候,只有比较专业的人员才可以从繁杂的信息中整理出有用的信息。

  其次在debug命令使用的过程中,也会使得CPU出现比较大的开销。这会对网络的性能产生很大的负面影响。有时候甚至导致网络的堵塞。从而使得网络故障雪上加霜,破坏网络设备的正常运转。

  基于如上原因,笔者建议,最好能够在网络流量或者用户比较少的时候使用这个debug命令,从而在最大程度上降低这个命令对于其他用户的负面影响。如果正的有必要马上解决问题,等不到网络空闲的时候,那么必须要遵守如下这个原则。即应当在已经了解故障的特定类型流量或者解决方案,并且已经将故障限定在某个局部范围内之后,才使用这个debug命令进一步收集相关信息。如此的话,可以在这个命令后面加上相关的参数,来降低设备CPU的开销,提高信息的使用价值。

  注意事项二:需要注意输出结果的不同

  在不同的情况下,debug输出结果的格式是不同的。网络管理员掌握这些输出结果的差异,对于他们进行排错具有很大的使用价值。如上所述,debug命令产生的信息量是比较多的。如果管理员能够了解不同情况下的不同输出格式,那么就可以在最短时间内找到自己所需要的信息。也就是说,可以帮助管理员提高信息过滤的效率。

  那么具体有哪些不同呢?笔者对此做了一些总结,供大家参考。一是需要注意,在使用这个命令进行排错的时候,输出的格式会随着协议的不同而变化。如某些协议只是为每个数据包产生单行输出,而有些协议则为会数据包产生多行输出。当网络管理员掌握这个规则之后,可以不看内容,而只看输出的格式,就了解这些输出结果可能是对应哪些协议的。这对于网络管理员从海量的信息中定位所需要的内容,是非常有帮组的。

  二是需要注意这个命令所带的参数不同,其输出的结果的数量也是不同的。有些debug命令会产生大量的输出结果,而有些命令输出的结果数量少的可怜。对于网络排错来说,并不是信息越多越好,也不是说越少越好。而是要看输出的结果是否对口,是否切重要点。这就对网络管理员提出了比较要的要求。要求管理员必须掌握尽可能多的debug命令,并在恰当的时候使用恰当的debug命令。也就是说,最后输出的结果能够满足管理员的需要。太多的话,是一种呢浪费,同时也会增加交换机等设备的CPU负担。笔者的建议是,在使用这个命令的时候,最好能够从小到大。只有在当前命令收集的结果不够满足当前需要的情况下,才使用更大范围的命令。这可以有效的降低设备的CPU负荷。

  最后的一个变化就是根据错误的情形、协议的不同、采用命令的不同,其返回结果的格式也会有差异。如有些情况下其产生的结果是文本行的格式。而有时则是以字段格式的方式提供。这也有助于网络管理员过滤信息。另外需要注意的是,有些管理员可能会把debug命令收集起来的信息存入到数据库中进行更加复杂的分析。此时就需要这个字段与文本行格式的差异。在某些情况下,需要对文本行格式的数据进行整理,才能够满足管理员的需要。

  注意事项三、对于debug命令收集到的信息要及时分析

  记得有位哲人说过,人不能够两次站在同一条河上。利用这句话来形容事物是时刻在变化的。其实这个道理在网络中也是有效的。连续使用两次debug命令来收集相关的信息,其结果就可能有所差异。为此作为网络管理员,应该学会及时的从debug命令中获取信息。并且还应该学会在调试完毕之后即使的关闭 debug命令,甚至可以禁用它。从而让网络设备在最短时间内恢复到工作状态。然后接下去的工作就是对收集到的信息进行分析,查找故障或者性能下降的原因。

  简单的说,就是不要边使用debug命令收集信息,边对数据进行分析。这主要还是由于debug命令会大量占用CPU的资源。在实际工作中,为了最大程度的降低debug命令的负面影响,笔者建议,最好相关的debug命令创建比较好的目标行动计划。如每个星期一次,让debug命令在网络比较空闲的时候运行一次,以收集网络管理员所关心的信息。这能够帮助网络管理员防范于未然,同时也不会对用户网络的正常使用产生很大的负面影响。

  注意事项四:学会在debug命令后面加入相关的参数

  在思科的产品中,所有的debug命令必须都在exec模式下运行,并且大部分的debug命令在运行的时候都没有强制参数的要求。但是笔者还是建议,在绝大部分情况下,使用debug命令的时候要带上相关的参数。特别是在将调试信息隔离到特定接口或者特性的时候,带参数的debug命令会非常的有用。

  归根究底,这还是因为debug命令产生的大量结果已经对CPU资源的消耗所决定的。如果不带参数的话,不仅难以将信息与接口或者特性一一对应,而且还会占用CPU等资源。这会扩大debug命令的负面影响。为此笔者的建议是在使用debug命令的时候,最好先使用带参数的debug命令。只有在其收集的信息不够用时,再考虑不带参数。

  不过值得注意的是,有一个参数需要慎用,即all参数,如debug all命令。如果采用这个命令的话,会产生压倒多数的被调试的进程。情况严重的话,会导致系统与网络崩溃。故这个all参数往往只是在非生产领域使用。或者是在网络刚组建的使用采用。等到网络正式投入使用过,这个参数就需要谨慎使用的。通常情况下,是禁用。

  可见,debug命令虽然只是思科产品中很小一部分的功能。但是在排错与性能优化中,其作用不可忽视。在使用的时候,也是大有讲究。以上的一些提醒,相信对各位网络管理员正确使用debug命令会有很大的帮助。

Your email is never shared.
Required fields are marked *