OSPF adjacencies flapping caused by minor changes in Virtual Router.

[VMAntonenko]

Hello.

There is a question about OSPF adjacency flapping caused by minor changes in OSPF process.

I planned data-center deployment of PA-5060 HA-cluster. In this plan PA-5060 needs to be attached to OSPF AREA 0, and multiple NSSA areas in different security  zones. Number of multiple areas non constant and in will be increasing in the future with deploying new DMZs.

When i configured this, i noticed that some changes in OSPF causes adjacancy reestablishing with peers when configuration is commiting.

For example: 

Creating new interface/subinterface and attacing it to existent OSPF area commits without interruption.

Creating new area, even without interfaces belongs to it, commits with reestablishing all existent OSPF adjacancies and service interruption.

Precisely OSPF peers receives one-way hello from PA (hello packet with empty neighbors list) and goes to Init state.

In this scenario deploying of any new DMZ will cause service interruption in whole data-center segment.

Is this a normal behaviour of PA? 

Are there any workarounds? GR or something.

I found an article in community.

https://live.paloaltonetworks.com/t5/Management-Articles/Commit-Causes-OSPF-Adjacencies-to-go-Down/t...

But it dated 2012. Is this fixed now?

Thanks in advance.

[pulukas]

If this is still an issue, try testing with using eBGP and private ASN for your DMZ segments instead.

[nextgenhappines]

I believe that issue is already resolved back in 6.0 or 6.1.    I am running on 7.1.9, I don't think I see any OSPF adjacencies flapping when we add or delete interface|subnet..

E

[VAntonenko]

nextgenhappines,

As I described, creating int/subint not cause flapping, but creating/deletting area, even without interfaces, leads to flapping.

My design assumes creating a new area for new DMZ.

I tested this case on PA-500 with software from 5.0.0 to 7.1.17, issue still exists.

So sad, it seems we'll have to make new design.