BEIGRP故障诊断
现象描述:无法与其他运行BEIGRP动态路由的路由器建立邻居关系;没有将所需的路由信息正确的通知邻居。
下表描述了产生这些问题的可能原因以及相应的解决办法。
可能原因 |
判断方法和解决方案 |
没有配置network命令或错误的配置了network命令 |
步骤1 使用 show ip beigrp neighbors命令输出当前所有邻居的信息,确认所有直连的BEIGRP路由器均在此输出中出现。 步骤2 如果某一台或几台直连的路由器没有在输出的邻居表中出现,使用show running-config命令查看那些未出现在邻居表中的路由器以及本地路由器的当前运行配置。 步骤3 确认每一个需要运行BEIGRP动态路由的接口都有相应的network命令将其包含在内。比如:如果ethernet1/0接口配置的IP地址为192.168.20.1,则需要键入下列命令在此接口上激活BEIGRP动态路由。 router_config# |
路由器指定了不相同的自治系统号 |
步骤1 使用show ip beigrp protocol命令显示此自治系统中所有的路由器当前运行配置。 步骤2 检查每台路由器的router beigrp全局配置,确认需要进行BEIGRP通信的路由器使用了相同的自治系统号,只有处于相同的自治系统中的BEIGRP路由器才会建立邻居关系,并交互彼此的路由信息。 |
复合距离计算系数不符 |
步骤1 使用show ip beigrp protocol命令显示此自治系统中所有的路由器的BEIGRP当前运行配置。 步骤2 检查每台路由器的router beigrp全局配置,确认需要进行BEIGRP通信的路由器“BEIGRP metric weight”的K值完全一致,只有处于相同复合距离计算系数的BEIGRP路由器才会建立邻居关系,并交互彼此的路由信息。
|
是否错误的配置了access-list命令 |
步骤1 使用debug ip packets 和debug ip beigrp packets hello命令激活ip和BEIGRP的报文诊断信息。前一条命令的输出信息可以告诉我们IP报文是否被正确的发送和接收,以及是否存在封装错误;后一条命令的输出信息则可以说明BEIGRP的hello报文是否被正确的发送和接收。 注意:打开这些输出信息后将占用大量的CPU时间,所以当网络比较繁忙时不要使用这些命令,以免造成网络拥塞。 步骤2 如果输出信息显示当前路由器IP及BEIGRP报文均能正确发送,但是相连的路由器没有收到这些报文,那么检查当前运行配置中的access-list单元,它们是否将BEIGRP报文过滤并丢弃。 步骤3 使用no ip access-group access-list-number in删除所有当前接口上激活的access-list配置。 步骤4 现在再次查看IP和BEIGRP的debug输出信息,相连的路由器是否已经可以正确的接收到报文。 步骤5 如果现在可以正确接收报文,那么就是access-list中的某条规则进行了错误的过滤操作。现在逐条恢复原来配置的access-list命令,直到报文再一次被过滤,我们就找到了配置错误的access-list。 . 步骤6 检查access list是否对源路由器的发送报文进行了过滤。如果是,调整access list允许发送相应的报文。可以使用permit命令完成这个操作。 步骤7 使用调整后的access list,观察它是否能正确的控制报文的接收和发送。 步骤8 如果新的access list工作正常,则按照上面的步骤调整自治系统中的其他路由器,直到故障被彻底排除。 |
现象描述:运行BEIGRP的路由器上,路由表中没有出现期望的路由。位于不同网段的主机无法进行通信,此问题可能出现在只运行BEIGRP动态路由的网络中,有时也出现在同时运行BEIGRP和其他类型动态路由的网络中。
下表介绍了造成这种问题的可能原因以及解决办法
可能原因 |
判断方法和解决方案 |
路由器间未建立邻居关系 |
参见上一部分的描述 |
没有在不同的自治系统之间进行BEIGRP路由的再分配(redistribute) |
步骤1 使用show running-config查看处于BEIGRP自治系统边界交叉点上的路由器。 步骤2 如果此台路由器上配置了多个BEIGRP的自治系统(显示多个router beigrp配置条目),确认配置了redistribute命令在不同的自治系统间进行路由的再分配。例如,如果一台路由器同时属于自治系统100以及自治系统200,使用下列命令在不同的自治系统间再分配BEIGRP路由。 router_config# 步骤3如果你希望本地配置的静态路由也进行再分配, 你需要增加 redistribute static命令
|
路由在不同的动态路由协议之间没有进行再分配或重新分布 |
步骤1 使用show running-config命令查看位于运行不同动态路由区域边界的路由器当前运行配置。 步骤2 查看其中的redistribute命令,确认在不同的路由协议之间进行了必要的路由信息再分配。例如,要在ospf 500与beigrp 200之间进行路由信息的在分配需要键入如下命令: router_config# 步骤3 如果希望得到当前配置的静态路由,需要使用redistribute static命令
|
路由器间hello-interval或hold-time值不匹配 |
步骤1 使用show running-config查看网络上所有路由器的当前运行配置。 步骤2 查找其中的 ip beigrp hello-interval和 ip beigrp hold-time接口配置命令,这两条命令配置的值在整个网络中都应该是一致的,或者至少在骨干网上应该配置相同的值。 步骤3 将那些hello-interval和hold-time配置错误的路由器进行修正。你可以使用下面两条接口下的配置命令恢复这两个参数的缺省配置:no ip beigrp hello-interval、no ip beigrp hold-time
|
缺省的路由向量距离配置错误 |
步骤1 在怀疑配置错误的路由器上使用show running-config命令显示当前运行的配置,查找default-metric命令条目,此条命令会改变再分配路由的缺省向量距离。 步骤2 如果配置中存在default-metric条目,检查它定义的向量距离值。确认这些取值是可靠的,并且可以正确的完成其他路由协议的metric值到BEIGRP向量距离的转化工作。
步骤3 如果配置中不存在default-metric条目,则检查redistribute的配置,如果需要转发非直连和非静态的路由,则需要保证配置default-metric条目。
|
现象描述:在BEIGRP路由器上,当使用show ip beigrp topology命令输出BEIGRP的tpb信息时,发现某条路由长时间处于Active状态。当这种现象只是偶尔发生时,BEIGRP路由器可以通过active-timer修正错误,将在规定的时间内没有发送reply应答的邻居标志为死亡,这可能是由于线路的暂时拥塞引起的。但是当这种现象频繁发生时,就应该引起我们的重视了,需要查找原因所在。
下表说明了造成这种现象的可能原因以及解决办法:
可能原因 |
判断方法和解决方案 |
Active-timer定时器的配置不当 |
步骤1 使用命令show running-config检查每一个BEIGRP路由器的当前运行配置。 步骤2在router beigrp命令层次下找到timers active-time命令。这条命令配置的参数值决定了一条路由处于active状态的最长时间,也就是等待所有邻居对query报文以reply进行回应的时间。如果这个时间设置的太短,某些邻居可能不能在此时间范围内完成必要的处理,然后发送reply报文进行回应。 步骤3 确认命令timers active-time 设置的参数值在相同的自治系统内是保持一致的。一般情况下,我们使用系统的缺省配置(3分钟),以保证邻居有充足的时间处理query报文,并发送reply进行回答。 |
接口或硬件问题 |
步骤1 使用命令show ip beigrp neighbors多次输出邻居的状态信息,检查Uptime 和Q Cnt (queue count) 部分的输出内容。 如果uptime的统计值不断被重置,或者Q Cnt域的输出值始终很大,这时就很有可能存在硬件问题。 步骤2 打开BEIGRP的debug信息输出,查看其中的Stack_in_Active条目,这些输出信息将告诉我们那些可能存在问题的路由器。 步骤3 首先确认那些被怀疑的路由器是否还在正常运行,然后检查那些运行BEIGRP动态路由的接口,找出其中可能存在的硬件问题。有关硬件排错的详细内容请参阅相关章节。
|
线路负载过大 |
步骤1 如果进行BEIGRP报文交互的线路流量很大或线路质量不佳,query或者reply报文就不会很可靠的传输到目的地,query或reply报文可能被丢掉,也可能会延迟很长时间到达,这样就会造成active-timer定时器超时。 步骤2 提高线路带宽或改善线路质量,具体方法请参阅有关章节。 |
一条BEIGRP的路由可能处于Passive或Active状态。当拥有到达目的网段稳定的BEIGRP路由时,我们就说此路由处于Passive状态。
如果一台BEIGRP路由器丢失了到达某个网络的连接(比如说,网络A),那么原来到达此网络的BEIGRP路由将进入Active状态。这台路由器发送query报文给它所有的邻居,希望能从它们的回答中找到新的到达网络A的路由。这台路由器将一直保持在Active状态,直到收到所有邻居的reply回应报文为止,或者active-timer定时器超时。
如果路由器在active-timer超时之前收到了所有邻居的reply报文,它将根据这些信息计算出新的到达网络A的最佳路径,这条路由随之回到Passive状态。否则,路由器将把超时仍未对query报文进行回应的邻居从邻居表中删除,输出“Stuck-in-Active”的debug信息,将没有发送reply的邻居以回答了目的网段不可达来处理,计算新的最佳路由,路由回到Passive状态。