Shulou(Shulou.com)06/01 Report--

Anyone who is familiar with Juniper products knows that RE (routing engine) and PFE (data forwarding engine) are separate on Junos operating systems, whether they are firewalls, switches, or routers. Policy non-synchronization is mainly for low -, middle-and high-end firewalls, such as SRX100-SRX300, SRX1500, and SRX4K, and SRX5800, the top firewall in history. (in Note:Chassis-cluster- dual-machine environment, firewalls are almost always deployed on dual computers, except in special cases). The RE is carried by a separate SCB or SFB, while the PFE is on a separate business interface card (different models need to be treated separately).

According to the Case processing in the past six months, it is found that the policy is out of sync frequently in the SRX1500 and SRX4K plane. Although this is not a big deal, it is also quite important in the customer side. For major customers, they are basically configured through Netconf, and an error is reported as soon as they are sent, which can easily affect the operation and maintenance operation. But RE and PFE configuration synchronization failed, the final Root-Case will have to wait. There is not always a solution to every problem, most of which are handled by Workaround.

The case log is as follows:

Edit security]

'policies'

Policy is out of sync between RE and PFE.

Please resync before commit.

Error: configuration check-out failed

Note: this problem can be seen on both low-end and high-end firewalls on stand-alone and dual machines. There are tens of thousands of error logs, but what remains unchanged is the process that needs to be handled-NSD

There are several reasons why policies are out of sync:

1. Missing policy messages from RE to PFE

2. There is a problem on RE, such as using duplicate policy ID.

The basic details of the investigation are as follows:

1. If synchronization is abnormal, first compare the checksum values of RE and PFE, using the following command:

Use the command "show security policies checksum" on RE (Note: hide the command, you need to enter it completely)

Example:

Root@vsrx-a > show security policies checksum

Logical system: root-logical-system

From zone To zone Checksum

Trust untrust 0x66b85abb-ca868ed9-a025220e-ca14f609

On every PFE (Branch firewall is FWDD, HE firewall is 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: the Checksum values of RE and PFE must be the same.

Perform the following steps to resolve the problem:

1. After executing the command > request security policies resync (Hidden Command), check that Commit can be synchronized normally.

Root@vsrx-a > request security policies resync

Node0:

Start sending policies...

Succeeds.

Total sent 2 policies.

{primary:node0}

two。 If step 1 has not been restored, try to execute # commit synchronize [hide command], and if commit synchronize slave execution fails, use the commit synchronize force command

3. If step 2 still does not restore the Commit problem, restart the nsd process

.

Root@vsrx-a# run restart network-security

Network security daemon started, pid 1293

4. If you have not recovered from step 3, restart the device (if it is a Chassis-cluster, restart two devices, if it is a production environment, then perform relevant operations according to the evaluation, do not restart)

Later: most of the time, the NSD process is restarted, because it is unlikely to restart the equipment in the customer's production environment. After all, this is a big move, involving business and a first-level change, and spare parts and field engineers have to be present.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.