故障处理巧用debug

泗水县广播电视台 张红 山东广电网络有限公司济宁分公司 何钰

故障的现象总是千变万化，令网络运维人员防不胜防。在日常的网络运维过程中除了要保障网络的安全稳定，还要具有随机应变的能力。

近日笔者单位DHCP 出现故障，通过查看设备配置和MAC 地址学习，均没有发现问题，最后通过debug 查看DHCP 的过程，将故障定位在接入层OLT 设备上，最终完成了网络故障的解决。

故障描述及排查

近日接到运维人员报修，某点播用户获取IP 地址出现故障。得知故障现象后，我们立即开始排查，排查思路是按照故障的区域进行划分的。比如只有个别用户故障，排查故障的重点要靠近接入层；如果一部分用户出现故障，那就要把排查重点放在汇聚层设备；如果是大面积故障，那就要排查核心层设备诸如BRAS 或核心路由器。

此次故障的报修范围很小，是个别用户，那么按照上述思路首先排查接入层，无外乎物理链路、设备状态、ONU 的配置等。将物理层排查后，再按照顺藤摸瓜自下而上排查，那就是汇聚层。接入层ONU 上联是OLT，在OLT 上主要查看的是PON 口和上联口的配置。然后使用MAC 地址学习的命令“show mac-address l2-switch”，查看到故障设备的MAC 地址可以从PON 口上学习到，而且OLT 的上联口也可以学习到故障设备所在VLAN 的MAC地址。这样既然该VLAN 在PON 口和上联口都可以学习到MAC 地址，说明网络通讯是正常的。那么为什么点播用户获取不到IP 地址呢？

这时故障的排查陷入了僵局，不知道该如何继续排查下去。重新梳理下故障的现象进行尝试。

所谓的尝试还是按照网络结构，先从接入层开始，尝试更换点播终端设备、ONU 设备，然后再进一步往上排查。所有的尝试都无效后，接下来就需要排查OLT 上游设备BRAS 了。

这时读者或许会说，不是就个别用户有故障吗？怎么还排查起核心设备了呢？这里需要说明的是DHCP 的地址池就在BRAS 上，也就说点播终端设备的IP 地址是BRAS 给分配的。那么我们可以在BRAS 上查看下点播终端和BRAS 交互DHCP 报文的过程。

接下来就可根据报文交互的过程看下故障到底出在什么地方。那么如何在BRAS上查看点播终端设备和BRAS交互DHCP 报文的过程呢？

这里需要使用到debug命令。Debug 即调试命令，在日常网络维护中使用该命令可以有效的帮助我们诊断和定位和排除在使用网络设备的各种问题。

在使用该命令前，需要开启路由器对终端界面的日志记录功能。具体配置命令即：

完成日志记录功能的开启后，接下来通过点播终端设备的MAC 地址对其DHCP报文进行调试排查，具体的配置命令即：

通过在BRAS 上执行上述debug 命令，可以得到以下报文即：

通过使用debug 命令得到的DHCP 通讯的报文，我们可以清晰地看到DHCP 通讯的前两步。也就是说DHCP通讯的过程从第2 步就中断了，即DHCP 服务器已经提供给客户端IP 地址、子网掩码、网关、DNS 和租约等其他内容，但是DHCP 客户端没有发起DHCP REQUEST 广播消息来响应服务器端。这就说明BRAS 作为服务器端已经将地址和租约信息提供给客户端，但是客户端没有回应，这样就可以将问题定位在BRAS以下。

那么接下来就排查BRAS以下的问题，BRAS 以下有OLT 和ONU 设备，这就需要在OLT 上进行现场抓包，通过使用抓包工具发现OLT 上故障点播设备所在PON 口有大量广播包，当然也可以使用show 命令查看。对广播包的处理，可以找到发送广播包的源，还可以使用广播包抑制功能来解决。既然找到故障原因，通过对广播包源MAC 地址的排查，很容易找到非法的广播包发送源设备，将其关闭或者处理后故障恢复。

故障解决

上面我们从知悉故障，首先按照网络层次进行排查，然后再使用debug 命令查看DHCP 通讯的过程，将故障点进一步锁定在OLT 上，在OLT上揪出了罪魁祸首——非法广播包，最后将故障得到了解决。

正是网络中存在大量广播包，导致正常DHCP 通讯中断或不正常，才会出现文章开头的那一幕，点播终端设备获取不到IP 地址。通过该故障的排查，一个貌似很平常的故障，使用了许多处理手段才得以解决，所以说，每一次故障的处理都是一次经验的积累，一次和设备增加熟知度的亲密接触。