这场大战真是惊天动地，上回说到整个拓扑结构很简单，总部采用H3C防火墙使用模板方式，分支使用天融信设备，采用野蛮模式对接。两边设备都是直接接在公网上，前面没有NAT设备。之前已经有部分分支是使用的H3C设备对接成功了。

       第298回，天融信防火墙参照其他分支配置了参数，对接失败。首先比对两边的各种算法，确认没有错误；接着查看日志，天融信设备上日志简单，并且是分支，还是要去总部的设备上查看。在总部防火墙上开启DEBUG，发现在IKE第一阶段就协商失败，查看发现协商的时候报用户名不对，查看了天融信的配置，天融信在选择野蛮模式的情况下，必须配置总部和分支的用户名，而对应华三这边，只配置了分支的用户名，这里就可以看到不同厂家在同样的标准协议上的不同理解了。在总部添加了本地用户名后，隧道建立正常，测试完成。

       第299回，不到数日，又说隧道不通，到现场查看，原来这次换了对手，上次是防火墙，这次是上网行为管理，参数配置和防火墙一模一样。开始和上次一样，打开总部DEBUG，发现这次用户名是正确了，但是类型不一样了总部是fqdn，分支是user fqdn。而且分支还没法改，这下可就难办，总部已经接入了大量分支，修改总部参数的话就需要同步修改所有正在使用的分支配置。思考之后，决定分支改为使用IP地址协商，总部在模板里新建一个策略，用于和采用IP地址方式的分支对接。测试正常。

       第300回，仅仅第二天，问题又来了。这回现象是一次只能通一条数据流。这就很奇怪了，总部是不会对这个做限制的，随后天融信的后台技术说上网行为管理是采用在一个隧道里跑多条数据流的方式。这我就真的是第一次听到了，之前都是一个隧道跑一条数据流，多个数据流就建多个隧道。我想到的唯一办法就是把地址段扩大，把几个数据流都包括进来，但是一分析不行，会出现冲突。没有办法求助厂家工程师。还真有这样一条命令，可以实现一个隧道内跑多条数据流。security  acl   XXXX  aggregation 

        经历了300回合，总算是彻底解决了对接中的各种问题。从这个案例可以看出来，各个厂家都宣称支持标准协议，可以和第三方对接，但是实际对接中，产品研发不同的理解就会导致对接失败，特别是对协议进行的内部优化。遇到这种情况，只能是对报错逐条分析，将各项参数恢复为各大厂家都通行的方式进行测试，少见的参数要求，则必须要求助厂家工程师的支持才能解决了