Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

OSPF state loading to full.

Hi ,

My router is configured with OSPF with service provider.

Once in a while  I recieve the error ' Process 10, Nbr x.x.x.x on GigabitEthernet0/0 from LOADING to FULL, Loading Done '.

At this time we loose the connectivity to this router.

This happens quite frequently nowadays. Can any one suggest possible reason and resolution to this issue.

Router we use is 3845.




Re: OSPF state loading to full.

In OSPF terms, some event in triggering SPF process and OSPF neighborship has been reestablished at the end of SPF processs. Log message you posted is conveying this.

There could be multiple reasons which is trigerring this event

- check for flapping log message for gi0/0 interface to check if link between two neighbors is stable

- debug the osopf process(adj , events) to drill down to OSPF specific reason

** debug can have significant impact on performance (just take care in case its production enviornment)



Re: OSPF state loading to full.

Raja's suggestions are very good ones...

One thing I have experienced in the past wehen peering with an SP router is that the SP oversubscribes their connections with customers to get the most bang for their buck. Sometimes this causes the router to have its processor loaded down momentarily -- long enough to lose a few Hello times.

Or I have seen the case in which the SP's engineers log into the router, make configuration changes on a config that is so long that the proc pegs while saving the config -- maybe theyre even backing it up at the same time to make it worse.

Just a few thoughts...


Re: OSPF state loading to full.

There might be many possible causes for this condition as already stated by others. In an environment where say 2 routers are connected through a switch and interface flaps in one of them, this message might be the only one observed on the other router (because the physical link is not so direct as it seems). If the interruption is short, the peer who didn't lose physical connectivity might report just a resynchronization of the OSPF database (because dead timer didn't expire and neighbor was not lost on this side of the link). You can actually shut/no shut interface, replace a router or perform other maintenance procedures in one router and the peer might just see the OSPF neighbor state going from loading to full (that is, if you do it in less than 30-40 seconds). The bottom line is that, because there might be many possible reasons for this message (e.g. an attack situation), you need to check with your SP what's going on. And make sure that this is the only message/issue reported on your side of the link.