最近工作小結

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 時，過程如下：

所以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進行修改，然後傳送出去，這樣三層路由就走完了。其實不難。