基于CEF的MLS排错三部曲

　　在多层交换机中都会利用高速内存表来创建路由选择表。这个路有表的生成方式有很多，CEF就是其中典型的一种。简单的说，CEF是一种基于拓扑 的转发模型。通过CEF可以将预先所有路由选择信息加入到转发信息库(FIB)中，并且将动态更新邻接表中的第二层重写信息。通过这种机制，可以提高数据 交换的性能。不过有时候CEF转发模型也会“生病”。作为网络管理员，学会对症下药。笔者根据自己的经验，将基于CEF的MLS排错总结为三部曲。希 望能够对大家的网络排错提供一点指导意义。

　　第一步：查看第三层引擎的CEF表

　　由于第三层引擎的CEF表决定了硬件交换的CEF表。所以如果CEF出现问题，网络管理员应该第一个想到的就是是否是这张第三层引擎的CEF表 出现了问题。这是一个资深网络管理员应该具有的职业习惯。总之，在对CEF问题进行排错的时候，首先就需要查看交换机的CEF表。要查看这个表的内容也很 简单，只需要使用show ip cef (detail)命令即可。不带detail其显示的比较简单的信息。而带上的话，显示的内容就比较完整。通常情况下，我们是先用不带参数的命令 试试看。如果信息不够的话，再加入参数。

　　另外这里需要注意的是，这个命令显示的内容并不是硬件交换组件中的FIB表。这是什么意思呢?硬件交换组件中的FIB表会有一个副本。通常情况 下，两者是同步更新的。为了安全起见，使用show ip cef命令显示的是这个副本中的内容，而不是真正的FIB表。故两者可能有时间差。不过这个时间差很小，一般情况下不会对我们的排错产生负面影响。

　　第二步：查看第三层引擎的邻接表

　　如果通过第一步还不能够得到问题的原因，那么接下去要查看的就是第三层引擎的邻接表。邻接表与CEF表是CEF转发模型的两个基本组件。通常情 况下CEF出问题的话，就是这两个表在作怪。当多层交换机通过ARP过程获得MAC地址之后，CEF转发模型将利用这些信息填充邻接关系表。在填充的过程 中，系统会利用邻接节点的MAC地址重新信息与目标接口。CEF表中的所有IP路有选择条目都会对应于一个下一跳地址。

　　要查看这个表的信息，需要使用命令show adjacency。同理在这个命令中也可以使用参数detail。使用这个参数之后，系统会显示详细的邻接关系表信息，如会包括第二层的信息等等。不过 这里需要注意的是，这个表并不是实时更新的。默认情况下，这个表的更新频率为一分钟。也就是说每60秒更新一次。为此网络管理员有时候可能需要运行这个命 令两次(中间隔一分钟)，才能够得到自己想要的结果。

　　在查看这张表的时候，需要注意前缀的问题。在CEF表中，前缀可以分为子网前缀与主机前缀。系统设计的时候，如果直接连接了多台主机的话，则这 个路由器中的邻接表采用的是子网的前缀，而不是各台主机的前缀。子网前缀会指向一个探查邻接关系条目。当需要将数据报转发给特定主机的时候，系统将在邻接 关系数据库中查找具体的前缀。在查看这张表中，首先需要对这些前缀搞清楚。看看其对应的子网前缀是否有问题。或者说，本来应该是子网前缀的，但是系统中采 用的却是主机前缀。

　　其次需要注意的是，在某些特殊的业务中，需要对IP前缀或者地址进行一些特殊的处理。如用户所采用的硬件交换不支持对数据帧进行路有选择，或者 第三层引擎要求对数据包进行处理时。在遇到这些情况的时候，交换机就需要对数据包进行特殊的处理。也就是说，可能需要改变IP的前缀。这种案例在实际的工 作中还是比较常见的。如NAT(网络地址转换)等等。故如果网络管理员发现NAT运作异常，而企业使用的刚好是基于CEF的MLS环境时，就要条件反射的 想到是否是这个邻接表出现了问题。这种反射非常的重要。如果网络管理员有这种技能，那么就可以在最短时间内帮助用户解决网络问题。不过这需要管理员工作经 验的积累。

　　第三步：调试第三层引擎的CEF

　　通过以上两个步骤，基本上可以分析出问题可能发生的原因。然后就需要使用debug ip cef命令调试第三层引擎的CEF。这个命令主要是从第三层引擎的角度显示相关的CEF信息，并进行相关的调试工作。在使用这个命令的时候，难点就是这个 命令的参数比较多。要查看不同的信息、进行不同的调试动作往往需要使用不同的命令参数。

　　如参数drops是让网络管理员查看记录丢弃的数据包;而参数recive是记录没有根据FIB邻接表中的信息对其进行交换，而将其发送到下一 个交换层的数据包。通常情况下，这些命令显示的信息都是文本形式。对阅读或者导入到数据库中进行进一步分析会带来一定的阻碍。故在这些情况下网络管理员可 能希望系统以表格的形式来显示相关的内容，此时管理员就需要使用参数table。这个参数就是告知系统以表格的形式显示与FIB邻接表相关的事件。不过采 用这个参数的时候，需要注意其不会显示全部的内容，而只是显示相关的事件。这些事件包括刷新FIB表、填充FIB表的路由选择更新、添加或者删除FIB表 条目、重新加载FIB表等等事件。故Table参数主要有两个作用，一是规范数据显示的格式，以表格的形式显示;二是对数据进行过滤，只显示跟FIB邻接 表相关的事件。

　　与Table参数类似的还有一个ipc参数。这个参数也是起到一个信息过滤的作用。使用了这个参数后，系统记录CEF中与进程间通信相关的信 息。具体来说，就是显示如下这些内容：被重新排序的消息的状态、顺序到达的IPC消息、IPC消息的传输状态、用于IPC消息的缓存空间使用状态、线路卡 发送给路有处理器的抑制请求等等。

　　在第二点“查看第三层引擎邻接表”的时候笔者说道过需要关注IP前缀的相关信息。当企业采用了NAT等需要对这些前缀进行特殊处理的业务时，就 很容易在这个地方出现问题。要查看这些前缀的信息，系统还提供了一个专门的参数prefix-ipc。这个参数主要记录与IP前缀信息相关的更新。如与 FIB邻接表前缀相关的控制信息、线路卡中IP路由选择更新的调试信息等等。这些信息对于排除IP地址前缀导致的网络故障非常的有用。

　　在调试第三层引擎的CEF时，需要注意，debug命令其会占用网络设备的CPU资源，而且占用的还会比较多。为了保证正常的应用不受影响，在 使用这个命令的时候要谨慎。最好能够在网络比较空闲的使用进行调试。另外就是需要注意，这个debug ip cef命令显示的内容比较多，作为网络管理员要学会在命令后面带参数，以过滤一些不必要的信息。虽然这个命令的参数比较多，但是只要多使用几次就可以掌握 参数的要点。特别需要提醒的是，这个命令显示内容都比较专业。必须要真正了解显示结果的含义之后，才能够做后续的操作。而不能够在一知半解的情况下，就对 其进行维护。否则的话，就可能会把故障搞的越来越大。

　　以上的三部曲只是对CEF排错的一个基本的思路。如果读者需要了解具体排错的过程，在后续的文章中笔者可以通过案例来具体的讲解。