這是一篇經歷分享。
Aruba Central誕生到現在已經有一段時間了，Central跟地端最大差異之處，在於一個透過Central網頁設定，另一個透過熟悉的設備管理網頁或是Console介面調整。
最近遇到一個狀況，操作DB時會不定時出現卡頓，經過TCP封包抓取比對，我給出這狀況發生原因「Session不正常關閉」。
在事件一開始，立刻指示開立Case，然後便提醒小夥要特別留意TCP交握與Session存活機制，一方認爲Session已經結束，另外一方認爲Session存活，再加上Stateful Firewall的機制，就有可能發生Session不正常關閉的狀況。
關鍵轉折在收集到DB的TCP DUMP，才讓我確認狀況發生時並非當下有問題，而是稍早先發生狀況才導致後續發生卡頓。
我還懷疑到雙線上行鏈路的Cisco vPC，因爲去來機制不同，藉此更多學習深思在雙活Gateway的運作。實際抓包中或是先前經歷Mirror，Cisco vPC還是Aruba VSX要下Mirror很難做到全收錄，至於在這樣架構流量怎麽走或是Mirror設計，我覺得對於sflow收集分析流量的網管來說，也要多做點構思。
剛從專案滿檔的地獄回歸，積累十幾件事情，也就沒有特別有動力去做LAB。
Case支援工程師提到他做了LAB，實測能復現，是因爲Aruba有項功能「enforce-tcp-handshake」開啓所導致。
DB的運作有時候會用(不完整)快速TCP封包重新繼續操作，前後可以間隔長到幾十分鐘以上。但若是在Aruba Gateway上session已經關閉，又開啓enforce-tcp-handshake的功能，就會因爲這不完整過程的TCP機制，導致封包被丟棄，觸發重新傳遞，最後逾時又重新進行TCP交握建立新Session。
不可思議的地方就是「enforce-tcp-handshake」是預設關閉的，在Central上也是顯示未啓用，然而透過CLI連入Gateway下指令卻是啓用的。最後是在Central上先啓用，再關閉，Gateway就正常了。
之前有玩過Aruba Controller的Firewall設定，要是開啓某些功能會導致網路在某些條件下會產生狀況，不過我檢查過Central網頁上設定，如果當初是正常顯示，也就是Central與Device顯示的設定是相同的話，或許就不會花那麼久的。
在使用Central設定時，我都說只能靠Central去操作，盡量不要用Console操作，因爲Central設定的優先度比較高，Console操作可能是無用的。此外關於Central的教學，也沒有提倡使用CLI操作。
最後，我思考爲什麼這個「enforce-tcp-handshake」會啓用。預設沒開，我也把設定部分都放在Central上操作，然而，這功能看似從一開始就已經開啓了，我覺得這蠻像設備本身就啓用，而Central沒有設定就不會產生對此的檢查機制，所以才會出現差異吧。