【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進程恢復的，由於在客戶生產環境不太可能由於重啓設備，這畢竟是大動做，涉及到業務，又是一級變動，備件、現場工程師都要到場。