经验分享：基于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排错的一个基本的思路。如果读者需要了解具体排错的过程，在后续的文章中笔者可以通过案例来具体的讲解。