No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

OSPF Is Initialized Although the GE Interface of the NE40 Is Up

Publication Date:  2012-07-27 Views:  53 Downloads:  0
Issue Description
The networking diagram is as follows:
NE40(1)------(GE)-------OSN------OSN------(GE)------NE40(2)
Version of NE40: NE40NE80-VRP5.30-0238.03
Symptom of the fault: The 3G services provided by the subnet under the NE40 were interrupted upon flash alarms. Viewing the log of NE40 (1), the engineer found that the neighbor of OSPF between NE40 (1) and the peer NE40 (2) was initialized. However, the GE interfaces on the two NE40 routers did not turn Up or Down. 
 
Alarm Information
The alarms on the NE40 (1) and the OSPF initialization information are as follows:
%Jun 9 20:00:34 2008 SmartVillage_ne40 FIB/4/LOG:
[After pretreat RT_Request]:The product function PdtPreOperRoute return VOS_ERR.
%Jun 9 20:00:34 2008 SmartVillage_ne40 FIB/4/LOG:
[After pretreat RT_Request]:The product function PdtPreOperRoute return VOS_ERR.
%Jun 9 20:00:34 2008 SmartVillage_ne40 FIB/4/LOG:
[After pretreat RT_Request]:The product function PdtPreOperRoute return VOS_ERR.
%Jun 9 20:00:34 2008 SmartVillage_ne40 RM/4/RMLOG:OSPF 1 223: Nbr 10.161.1.4 event InactivityTimer State Full -> Down.
%Jun 9 20:00:05 2008 SmartVillage_ne40 RM/4/RMLOG:OSPF 1 223: Nbr 10.161.1.4 event LoadingDone State Loading -> Full.
%Jun 9 20:00:05 2008 SmartVillage_ne40 RM/4/RMLOG:OSPF 1 223: Nbr 10.161.1.4 event ExchangeDone State Exchange -> Loading.
%Jun 9 20:00:05 2008 SmartVillage_ne40 RM/4/RMLOG:OSPF 1 223: Nbr 10.161.1.4 event NegotiationDone State ExStart -> Exchange.
%Jun 9 20:00:05 2008 SmartVillage_ne40 RM/4/RMLOG:OSPF 1 223: Nbr 10.161.1.4 event 2WayReceived State Init -> ExStart.
%Jun 9 20:00:05 2008 SmartVillage_ne40 RM/4/RMLOG:OSPF 1 223: Nbr 10.161.1.4 event HelloReceived State Down -> Init.
%Jun 9 20:00:02 2008 SmartVillage_ne40 FIB/4/LOG:
[After pretreat RT_Request]:The product function PdtPreOperRoute return VOS_ERR.
%Jun 9 20:00:02 2008 SmartVillage_ne40 FIB/4/LOG:
[After pretreat RT_Request]:The product function PdtPreOperRoute return VOS_ERR.
%Jun 9 20:00:02 2008 SmartVillage_ne40 FIB/4/LOG:
After pretreat RT_Request]:The product function PdtPreOperRoute return VOS_ERR.
%Jun 9 20:00:02 2008 SmartVillage_ne40 FIB/4/LOG:
[After pretreat RT_Request]:The product function PdtPreOperRoute return VOS_ERR.
%Jun 9 20:00:02 2008 SmartVillage_ne40 FIB/4/LOG:
[After pretreat RT_Request]:The product function PdtPreOperRoute return VOS_ERR.
%Jun 9 20:00:02 2008 SmartVillage_ne40 FIB/4/LOG:
[After pretreat RT_Request]:The product function PdtPreOperRoute return VOS_ERR.
%Jun 9 20:00:02 2008 SmartVillage_ne40 FIB/4/LOG:
[After pretreat RT_Request]:The product function PdtPreOperRoute return VOS_ERR. 

 
Handling Process
1. The following alarms were believed not to affect the services:
%Jun 9 20:00:34 2008 SmartVillage_ne40 FIB/4/LOG:
[After pretreat RT_Request]:The product function PdtPreOperRoute return VOS_ERR.
Meaning of alarms:
FIB deletion alarm: indicates that the FIB with VLANIF as the outbound interface is being deleted.
Trigger cause:
When deleting a route with VLANIF as the outbound interface, the system prints this alarm as a prompt. The problem with the print function causes the normal alarm to end with "return VOS_ERR".
Impact:
This is a normal alarm that does not affect the system. However, during route flapping, the alarm is printed once and again, making it a bit hard to view the log clearly.
Workaround:
If the network can be stabilized, the problem is avoided. If the customer’s network keeps flapping and the customer feels it useless to have the alarm, the alarm can be deleted with a patch loaded. The R&D personnel intend to delete the alarm in the later versions.
There is no special command to disable the alarm. Although the inforcenter command can be used to disable the alarm, the alarms of the same precedence or the same module will be all disabled.
2. That the GE interfaces of the NE40 routers are not Up or Down indicates that optical packets can be transmitted normally between the NE40 routers and OSNs and the GE links between them are normal.
3. The initialization of the OSPF neighbor indicates that the hello packets of OSPF between the NE40 routers go wrong. In the case of normal links between the NE40 routers and OSNs, probably the links between OSNs break down. 
 
Root Cause
Null
Suggestions
The transmission engineers should confirm whether there is something wrong with the links between OSNs during the flash alarming on the interruption of the 3G services. 

END