前些天我們數據中心燒了一台Cisco 3745（簡直就是餐具啊），在等備件維修期間，臨時換了一台Cisco 3725頂替它的位置。
恢復了配置之後，跟它連接的兩個SPOKE路由器就出了異常情況。
這是一個基於動態IP的點到多點L2L環境，兩台SPOKE路由在每次IPSec SA更新的時候都提示下列錯誤：
Jun 17 07:22:13.387: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at 76.68.xx.xx
Jun 17 08:20:37.183: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at 76.68.xx.xx
Jun 17 09:19:39.225: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at 76.68.xx.xx
就是提示與HUB路由器協商快速模式失敗（ISAKMP階段二），但是VPN卻又沒有任何問題。
總這樣蹦錯誤提示不是辦法，於是開始DEBUG，在DEBUG中定位到一些錯誤，大意是說Peer addr is stale/IPSec Peer Not Found。
在Google上搜索了數十頁的結果，也沒有與我的情況相似的。而後我又查閱了Cisco的VPN排障指南，結合debug信息，所指定的三種錯誤（transform-set不匹配、crypto acl不匹配、identity不匹配）沒有一種是我的情況。
因為HUB端的IP地址也是動態的，所以在SPOKE端用DNS名稱來動態解析HUB端的IP地址。因為上面兩個debug消息是一起出現的，因此我懷疑是spoke端的dns解析有問題。
我又做了一些嘗試，將SPOKE端Crypto Map中的peer改為HUB端的IP而不是DNS名稱，結果發現IPSec SA更新的時候，就不會再出現這種問題了。更令人匪夷所思的就是我前面所述，報錯後幾秒鐘，IPSec SA仍然可以成功更新。（雖然我通過debug可以看到是再次發起請求後才成功的，可是……）
這個問題排障了兩天，卻得出這樣的結果。
真不知道是我的配置問題還是Cisco IOS的bug……
SP1：其实这个问题不会影响到VPN的连通性。
从这个问题出现到SA重新协商成功，一般是需要30秒左右的时间。而Cisco路由器默认开始重新协商SA，是在SA到期前的两分钟左右。新的SA没有协商成功，旧的SA仍然起作用。
据测试，VoIP等应用在出现此问题时不受任何影响。
SP2：可以確定是IOS的BUG。IOS更換為12.4（15）T13之後，此現象消失。原有BUG的IOS版本為12.4（25）C。