Description

This article provides information on how to troubleshoot OSPF peering, which is between a SRX device and another device, when it is stuck in the loading state.

Symptoms

  • A SRX device and another device is trying to establish OSPF peering. Loading is one of the states of the several OSPF states, which the SRX device traverses through, before establishing complete neighborship with its peers.
  • Loading in OSPF can be characterized as follows - If the local router needs to receive complete LSA information from its neighbor, it enters this state and starts sending Link State Request packets to its neighbor.
  • Ideally the SRX device (which is the local router), after receiving complete Link-State database information of its peer, must form fully functional OSPF adjacency and reach the Full state. Instead, the SRX device gets stuck in the Loading state itself.

Solution

Methodologically, in the loading state, the SRX device sends Link State Requests to its peer. The peer should reply with a Link State Update. As per design, the SRX device should acknowledge this with a Link State Acknowledgement.

The current scenario reveals that the SRX device does not send the Link State Acknowledgement to its peer. A potential reason for this is that when the peer sends Link State Update fragments to the SRX, As per design, it should not drop the fragments. But one setting in the screen options hierarchy is capable of dropping the fragmented packets.

The comand below highlights it:

user@host# set security screen ids-option <untrust-screen> ip block-frag

You can disable it by using the following command:
user@host# deactivate security screen ids-option <untrust-screen> ip block-frag
When disabled, it ensures that the Link State Update fragments are accepted and acknowledged by the SRX device. So, full OSPF adjacency will be established between the SRX device and its peer.
 

Modification History

2020-06-08: Article reviewed for accuracy. No changes made. Article is correct and complete.