OSPF Adjacency Issues

Showing results for 
Show  only  | Search instead for 
Did you mean: 

OSPF Adjacency Issues

Not applicable

We've got a Cisco 7301 routers that forms OSPF adjacencies with an HA pair of 5020 firewalls.  Recently I swapped this router out with a different router with the same IPs but different configs to test a new WAN connection.  OSPF forms up just fine with the new router.  After testing concluded and swapping back to the old router OSPF freaks out.  The adjacencies get stuck in EXSTART.  Cisco also says that this is an MTU mismatch condition, not true in my case.

Failing the firewalls over did not clear this up, tried twice.  Rebooting them did the trick.  After the reboot and a failover the adjacency was just fine.

Aug 11 00:15:14: %OSPF-5-ADJCHG: Process 200, Nbr on GigabitEthernet0/0.200 from EXSTART to DOWN, Neighbor Down: Too many retransmissions

Aug 11 00:16:04: %OSPF-5-ADJCHG: Process 200, Nbr on GigabitEthernet0/0.200 from DOWN to DOWN, Neighbor Down: Ignore timer expired

Aug 11 00:17:14: %OSPF-5-ADJCHG: Process 200, Nbr on GigabitEthernet0/0.200 from EXSTART to DOWN, Neighbor Down: Too many retransmissions

Wondering if anyone else has seen this type of issue, or at least has any suggestions on how to get the adjacency to form without having to reboot.


L5 Sessionator

what software version are you on

L5 Sessionator

Do you have jumbo frames enabled. There was an issue which was seen on release 4.1.3 which got fixed in 4.1.7.

Bug 40409: Palo Alto Networks firewall not able to setup an OSPF link when using P2P to a Cisco router with jumbo-frames enabled, but broadcast mode does work. Issue with to P2P mode only, which has been fixed.

Another issue was seen in release 4.1.7 which has been fixed in 4.1.13 and 5.0.4

Bug 45687:  When HA fails over from the active device to the passive device, it took more than a couple of minutes to re-establish the OSPF adjacency when the OSPF database was large. This occurred in rare situations and was due to the new active device sending redundant Database Description (DD) packets. If the neighbor OSPF router cannot handle the duplicate OSPF DD packets, the OSPF database exchange can be aborted multiple times. This issue has been resolved with this release such that the redundant DD packets are not sent.

I am not sure if you are running into any of the above issue.


Not applicable

Running 4.1.7-h2...should have included that.

Just verify what the link types were configured on the cisco and the firewall. Its recommended that if using the Ethernet cables to connect to the cisco router, select the link type as "broadcast", and not "p2p" or "p2mp"

Plus, its always recommended to use graceful restart when deploying OSPF in a cluster. The feature, “graceful-restart” for OSPF is currently not supported by the PAN-FW.  Since “graceful-restart” is not supported for OSPF, the routes will not be retained in the FIB once an OSPF neighbor goes down. Moreover, since the routes have been purged, traffic  reliant upon these routes will be incorrectly forward out the default route or dropped.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!