先放出拓扑说明一下结构。
分支有两条线路，一条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，这样的问题。
再奇葩的问题，最后都会有答案，耐心耐心，不放过任何一个细节。