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>Search


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


Interface flapping result in the OSPF neighbor of S9300 can’t rebuild after it down

Publication Date:  2012-09-18 Views:  126 Downloads:  0

Issue Description

Because of the problem of optical power, the interface UP/DOWN time after time, result in the flapping of the ospf peer, the number of OSPF message soared, the OSPF neighbor of S9300 can’t rebuild after it down.

Alarm Information


Handling Process

Too many OSPF peer, the value of ospf cpcar as default in main control board and interface board is too small.  When the network flapping, route OSPF will republishing and relearning or route flapping, the OSPF messages increased sharply; result in the complete leaky bucket of OSPF, a part of OSPF peer can’t build, so this part of OSPF peer will continue to send the DD and increase the number of messages, result in more OSPF be discarded, more peer down, bring the “snowball” effect.

1. Increase the OSPF cpcar of  main control board and interface board, adjust the   cpcar in interface board base on the number of ospf peer and LSA.
2. Configure the sham-hello enable (peer will keep alive when it receive any OSPF message) for the OSPF process.
3. Interface up/down, we can check the link, make sure the link is connect credibility, such as increase the ical attenuator , make sure the optical power in a reasonable bound, make sure the port can work correctly, to relieve the influence of this problem.

Root Cause

1. Check the log of equipment, OSPF hello messages send failed.
Jan 13 2012 08:40:27 S9300%%01OSPF/6/NBR_DOWN_REASON(l): Neighbor state leaves full or changed to Down. (ProcessId=100, NeighborRouterId=, NeighborAreaId=0, NeighborInterface=Vlanif864,NeighborDownImmediate reason=Neighbor Down Due to Inactivity, NeighborDownPrimeReason=Hello Not Seen, NeighborChangeTime=[2012/01/13] 08:40:27)

2. A lot of Cpcar discard packages in the log
Jan 13 2012 08:48:06  S9300%%01QOSE/4/CPCAR_DROP_LPU(l): Some packets are dropped by cpcar on the LPU in slot 4. (Protocol=ospf, Drop-Count=01245633)
Jan 13 2012 08:58:06  S9300 %%01QOSE/4/CPCAR_DROP_LPU(l): Some packets are dropped by cpcar on the LPU in slot 4. (Protocol=ospf, Drop-Count=01254750)
Many notes of socket send failed packages
Jan 13 2012 10:27:24  S9300%%01OSPF/6/RM_SOCK(l): Invoking the RM SOCK failed. (FID=0x70178025, LN=5225, ReturnValue=0xffffffff)

3. Check the ospf peer and the number of router, the number of ospf peer of S9300 approach to 100, and the number of LSA approach to 9000. In this case, once the route flapping or the router is re-learning, the cpcar as default of ospf will have a large number of packages discarded and result in the peer unable build.


When we configure the Cpcar, suggest the number of main control board is twice of interface board.