***排错是个很头疼的问题，juniper原先的ssg系列登录到web就会有看到设计很好的日志记录界面，一眼就能看出问题所在。相对而言，srx上进行traceoption比较麻烦，很多错误都不明显。
这篇文章不是什么正儿八经的文档，只是我自己实验和工作心得。上个月在处理一次juniper srx和Cisco as防火墙建立***的case时候遇到了问题(下面会讲到)。于是我打算反推过来，看看srx上使用traceoption进行***排错会有哪些好玩的地方。
1.实验拓扑：
2.实验过程：
拓扑很简单，分别用两台srx340模拟local和remote，先进行正常的***配置：
现在我们开始搞破坏，然后通过traceoption来查看相关的日志记录。
第一步，修改域分享密码，把原先的Juniper换成Cisco，发现隧道down掉了：
我们开始查看debub文件，搜索关键字设置为error：
[Feb 1 10:14:24]
[Feb 1 10:14:24]
[Feb 1 10:14:24]
[Feb 1 10:14:24]
[Feb 1 10:14:24]
[Feb 1 10:14:24]
[Feb 1 10:14:24]
红色的字体很清晰的显示：不正确的域分享密码。
第二步，继续搞破坏，之前的实验为了偷懒，我都是用的预设的加密和认证。现在使用自定义的proposals，我在两段的authentication-algorithm做个小手脚：
然后***自然就down掉了：
继续看debug文件（***排错对于菜鸟真是头疼，现在做实验知道了结果反推回去真是神清气爽啊）：
仍然搜索关键字error：
[Feb 1 10:31:34]ike_st_i_private: Start
[Feb 1 10:31:34]ike_send_notify: Connected, SA = { b5683f91 580f05d7 - 3780e055 cd8cc990}, nego = 0
[Feb 1 10:31:34]1.1.1.2:500 (Initiator) <-> 2.2.2.2:500 { b5683f91 580f05d7 - 3780e055 cd8cc990 [-1] / 0x00000000 } IP; Connection got error = 14, calling callback
[Feb 1 10:31:34]ikev2_fb_v1_encr_id_to_v2_id: Unknown IKE encryption identifier -1
[Feb 1 10:31:34]ikev2_fb_v1_hash_id_to_v2_prf_id: Unknown IKE hash alg identifier -1
[Feb 1 10:31:34]ikev2_fb_v1_hash_id_to_v2_integ_id: Unknown IKE hash alg identifier -1
[Feb 1 10:31:34]IKE negotiation fail for local:1.1.1.2, remote:2.2.2.2 IKEv1 with status: No proposal chosen
[Feb 1 10:31:34] IKEv1 Error : No proposal chosen
[Feb 1 10:31:34]IPSec Rekey for SPI 0x0 failed
[Feb 1 10:31:34]IPSec SA done callback called for sa-cfg P1 local:1.1.1.2, remote:2.2.2.2 IKEv1 with status No proposal chosen
出现了多个error，failed。我们可以断定是在IKEV1阶段出现了问题，缩小了排错的范围（修改：IKE V1的意思是使用的IKE 版本1 ，不是阶段1，现在已经有了IKE V2，可以更快的协商并且防止dos***，从而提供安全性）。
第三步，我们开始对第二阶段搞破坏，正常情况下，***建立成功的日志会显示：
翻译过来就是：阶段二连接成功。
搞破坏之前先讲一讲我肤浅的理解，二阶段的参数不匹配，应该不影响一阶段的隧道的建立。但是这次和思科对接的case里面，第一阶段一直无法建立，而对端的思科工程师说他的debug文件显示是我二阶段的感兴趣流没有匹配：
但是这个我和思科的兄弟确认了好几遍没有问题。最后发现问题是出在二阶段的参数上面。
回到Juniper srx和srx对接的环境中来模拟，我们修改二阶段的Diffie-Hellman Group:
区别于juniper和cisco对接第一阶段都无法建立，SRX和SRX对接的话，第一阶段是ok的，第二阶段down了：
继续查看traceoption日志：
[Feb 1 10:58:00]IPSec negotiation failed for SA-CFG P1 for local:1.1.1.2, remote:2.2.2.2 IKEv1. status: No proposal chosen
[Feb 1 10:58:00] P2 ed info: flags 0x8082, P2 error: Error ok
[Feb 1 10:58:00] IKEv1 Error : No proposal chosen
出现的代码和上面步骤二的一致，都是 IKEv1 Error : No proposal chosen
这说明IKEv1 Error : No proposal chosen并不是仅仅针对于第一阶段而言的（修改：v1的意思不是阶段1）。
我并不知道为什么和思科的设备第一阶段都无法建立。回过头来看，双方的debug文件似乎都无法准确定位问题的所在？这里就需要老司机们答疑解惑了，我参考了Juniper的kb文档并且和对端的思科设备配置文件对比了一下，似乎没有找到思科的配置上定义了这个参数，需要思科的老司机们解释下下。后来用户的网络已经联通，管理权限交还给了用户，我也没有继续深究下去。
这些就是我做的简单的实验，JUNIPER SRX系列支持基于路由和基于策略的IPSEC ×××，也支持dynamic ***和ssl ***。去年遇到过一个HA模式下dynamic ***问题，下次就机会模拟下HA环境dynamic ***做些好玩的实验。