最近工作小结

1、由于上次加了报文上CPU的功能后，本以为该功能是能够正常工作，报文上CPU是没 问题的，但是经过测试发现，唉，怎么什么报文都能够上CPU了。

根据这个 现象，就想到了会不会是下发的ACL有异常啊，然后去看SDK代码，然后一直以为这个CPU端口是已经从管理VLAN中剔除的。最后也是在同事的建议下，去确认下到底CPU有没有从管理VLAN中剔除掉。

 一下确认后惊呆了，确实没有被 剔除掉，然后自己郁闷了，自己 原先的测试难道没有遍历到 这个用例吗，真的有点怀疑自己当初是 怎么测试的。

2、由于报文上CPU后，我们软件处理这边会根据报文的源MAC地址进行记录， 记录到一张全局mac表中。

     原先实现是使用完毕后，就直接将 对应的mac表项进行删除，但是经过测试发现，如果 不断修改报文的源mac地址，一下子这个全局mac表 使用就被 占满了，导致设备出现异常。

     根据这个现象，直接将mac表象操作进行修改，改为覆盖式index的方式，每次 index进行加1， 当加到max时，重新回到0，进行覆盖原先配置，这样子就不用考虑使用完毕后进行释放资源了。

这个问题其实自己当时考虑到会出现的，但是对mac表的修改方案未进行确定，就一直没有修改。

如果这个问题一直没有修改，版本提供给现场设备 使用，肯定是会出现问题的。幸好及时 发现。

3、根据以上的 问题现象以及自己处理问题的方式，总结如下

3.1: 测试 用例需要遍历完善，及时记录问题

3.2：发现问题后，根据问题显现 提示可能引发问题的几种原因， 进行逐一排查。

 

4、由于使用的是UIP的开源代码，所以对上CPU后报文处理都是可见的，这边引申一下3层报文转发流程

    由于 报文使用ACL上CPU，而我们现在 关心的就是报文的目的mac是设备的报文是能够 上CPU的。

当pc1 192.168.1.100  ping 192.168.10.100 时，过程如下：

 

由于两个ip地址不在同一 网段，然后pc查找自己的路由表，发现有到10网段的路由，下一跳是1.101

所以pc1 192.168.1.100 ,进行发送目的ip是1.101的arp请求，用来获取1.101所在设备的mac地址。

pc1获取到地址后，进行icmp组包，源mac+ 192.168.1.100 + 192.168.10.100 + 目的mac，当然报文格式不是这样的，

所以当设备收到这个报文后，发现目的ip地址不是自己，同理，会去广播请求目的ip所对应的设备mac地址，获取到后，将原先的icmp报文的源mac和目的mac进行修改，然后发送出去，这样三层路由就走完了。其实不难。

总结：当设备命令对应ACL上CPU后，目的mac地址是自己，然后查看目的ip是不是给自己的，如果给自己的话，则自己处理，如果不是给自己的，则进行路由转发了。所以这就是上三层了。