先放出拓撲說明一下結構。
分支有兩條線路，一條IPsec ***訪問分部的內部資源，一條MSTP專線訪問總部資源。如果MSTP線路斷了，也可以從***訪問總部資源。原本的配置已經完成，使用正常，此次客戶重新規劃地址段，要改一下分支的地址段，所以IPsec這塊就需要重新配置了。同樣的，MSTP那邊也要改配置。
按照客戶要求，完成了配置修改，首先測試去訪問總部資源，沒有問題，正常的。然後測試從IPsec訪問分部的資源，也沒問題。最後一步，斷開MSTP線路訪問總部資源，發現不行了，然後此時，訪問分部資源也不行了。這裏就出現了奇怪的現場，斷開MSTP怎麼會影響到***線路。
之後再次測試，插回MSTP線路，業務訪問就都恢復正常了。反覆幾次都是這樣，心裏就懷疑是不是出BUG了，那就這樣，把MSTP專線的配置全刪了，只插線，這樣測試，這時候還是不通，然後把接口地址配上，這時候居然就通了，指數據走MSTP的路由這時候都還沒配。
這下更確認是產品問題了，聯繫了客服看配置，又抓包，啥也沒看出來，說配置沒問題。我看了一下分部抓包的信息，PING包的來回，好像有規律，收到的請求是迴應的1/2，再一看，分部迴應一次發2個報文，而且這2個報文的MAC都不一樣。雖然不知道爲什麼會這樣，感覺既然不正常，那就查查MAC到底是哪的。覈對了設備上的接口MAC，發現其中一個是分部設備去往總部的接口MAC，這就有點感覺了。馬上看了路由，發現問題了，分部有一條大段的路由指向總部專線的路由器，而分支新的地址段就被包括在裏面。解決辦法也簡單，寫一條明細的路由指向公網出口就行了。
最後說一下故障現象是怎麼回事，分支是從***到了分部，分部回包到達出口設備時，匹配了一條大段路由，指到了去往總部的路由器了，接着又從MSTP線路回來了。這時候，即使分支的設備沒寫MSTP路由，但是有接口地址就可以收到報文。而且分支設備不是安全設備，不檢測來回報文路徑問題，不記錄會話狀態，只轉發。這幾個因素加一起，就出現了上面的現象。
總結一下這次的經驗，IPsec ***這個東西，很煩人，需要注意的東西很多，但是隻要規範的做，其實也不會出問題。出現這個問題的首要原因就是忽視了路由問題，以爲默認的路由肯定是可以的，沒去檢查；第二就是廠家400，真的不要迷信他們，這和他們沒法瞭解現場情況有關係，找他們最好是確認一些明確的小問題，比如這個功能設備有沒有，這個特別的現象，是不是BUG，這樣的問題。
再奇葩的問題，最後都會有答案，耐心耐心，不放過任何一個細節。