【SRX】RE与PFE策略不一样步，致使Commit失败-----案例分析

         了解Juniper产品的都知道，无论是防火墙、交换机仍是路由器，Junos操做系统上RE（路由引擎)和PFE（数据转发引擎）是分离的。策略不一样步主要是对于低中高端防火墙来讲的，像SRX100-SRX300、到最近才出来的SRX1500，及SRX4K，以及史上顶级一二的防火墙SRX5800都有可能出现策略不一样步的状况（Note：Chassis-cluster-双机环境中，防火墙几乎都是双机部署，特殊状况除外）。RE经过由单独的SCB或SFB去承载，而PFE则是在单独的业务接口板卡上（不一样的型号须要单独对待）。

         根据最近半年的Case处理，发如今SRX1500、SRX4K平面出现策略不一样步的状况比较频繁，虽然这事吧，不算大，但在客户方也是蛮重要的，对于大客户来讲，基本都是经过Netconf下发配置的，一下发出现提交报错，这很容易影响运维操做。但RE和PFE配置同步失败，最终的Root-Case仍是要再等等……并非什么问题都有解决方案的，大部分都是Workaround来处理的。

      

 案例日志以下：

      

edit security]

'policies'

Policy is out of sync between RE and PFE <SPU-name(s)>.

Please resync before commit.

error: configuration check-out failed

Note：这个问题能够在低端和高端防火墙单机和双机上看到。错误日志千千万，不变的是须要处理的进程-NSD；

出现策略不一样步的缘由有如下几点：

1. 从RE到PFE的policy消息丢失

2. RE上出现问题，例如：使用重复的策略ID；

排查的基本细路以下：

1. 若是同步异常的话，先对比RE和PFE的checksum值，经过如下命令：

RE上使用命令“show security policies checksum ” (Note:隐藏命令，需输入彻底)

示例：

root@vsrx-a> show security policies checksum

Logical system: root-logical-system

From zone                To zone                  Checksum

trust                    untrust                  0x66b85abb-ca868ed9-a025220e-ca14f609

每一个PFE上（Branch防火墙是FWDD, HE防火墙是XLR）

root@vsrx-a% vty fwdd

BSD platform (VMWare virtual processor, 428MB memory, 8192KB flash)

FLOWD_VSRX(vsrx-a vty)# show usp policy checksum

Logical system: root-logical-system

From zone                       To zone                         checksum

trust                           untrust                         0x66b85abb-ca868ed9-a025220e-ca14f609

Note:  RE和PFE的Checksum值必须一致。

执行如下步骤解决问题：

1. 执行命令 > request security policies resync (隐藏命令）后，查看Commit是能够正常同步。

root@vsrx-a> request security policies resync

node0:

--------------------------------------------------------------------------

Start sending policies ...

Succeeds.

Total sent 2 policies.

{primary:node0}

2. 若是步骤1还未恢复，尝试执行#commit synchronize  【隐藏命令】，若是commit synchronize 从执行失败，则使用commit synchronize  force 命令

3. 若是步骤2仍是没有恢复Commit问题，重启nsd进程

。

root@vsrx-a# run restart network-security

Network security daemon started, pid 1293

4. 若是操做完步骤3还未恢复，则重启设备（若是是Chassis-cluster则重启两台，若是是生产环境中，则根据评估进行相关操做，不要作重启动做）

后话：不少时候，都是重启NSD进程恢复的，由于在客户生产环境不太可能由于重启设备，这毕竟是大动做，涉及到业务，又是一级变动，备件、现场工程师都要到场。