What's the problem with ospf?

Hello! Raised between the Cisco GRE over IPsec, ping between networks stable and smooth, but every few minutes, lost several packages in a row. Revealed a pattern in the log this appears:

000087: *Oct 23 14:34:09.695 PCTime: %OSPF-5-ADJCHG: Process 111, Nbr 10.60.0.1
on Tunnel from LOADING to FULL, Loading Done

Help to decrypt this message and to suggest what needs to be changed in the settings of the routers?

Debug:

000140: *Oct 23 14:41:20.135 PCTime: OSPF: Rcv hello from 10.60.0.1 area 101 fro
m Tunnel111 10.60.0.1
000141: *Oct 23 14:41:20.135 PCTime: OSPF: Cannot see ourself in hello from 10.6
0.0.1 on Tunnel111, state INIT

000142: *Oct 23 14:41:20.135 PCTime: OSPF: Send immediate hello to nbr 10.60.0.1
, src address 10.60.0.1, on Tunnel111
000143: *Oct 23 14:41:20.135 PCTime: OSPF: Send hello to 10.60.0.1 area 101 on T
unnel111 from 10.60.0.2
000144: *Oct 23 14:41:20.135 PCTime: OSPF: End of hello processing
000145: *Oct 23 14:41:20.171 PCTime: OSPF: Rcv hello from 10.60.0.1 area 101 fro
m Tunnel111 10.60.0.1
000146: *Oct 23 14:41:20.171 PCTime: OSPF: 2 Way Communication to 10.60.0.1 on T
unnel111, state 2WAY
000147: *Oct 23 14:41:20.171 PCTime: OSPF: Send DBD to 10.60.0.1 on Tunnel111 se
q 0x2153 opt 0x52 flag 0x7 len 32
000148: *Oct 23 14:41:20.171 PCTime: OSPF: End of hello processing
000149: *Oct 23 14:41:20.171 PCTime: OSPF: Rcv DBD from 10.60.0.1 on Tunnel111 s
eq 0xC6E opt 0x52 flag 0x7 len 32 state EXSTART mtu 1440
000150: *Oct 23 14:41:20.171 PCTime: OSPF: First DBD and we are not SLAVE
000151: *Oct 23 14:41:20.203 PCTime: OSPF: Rcv DBD from 10.60.0.1 on Tunnel111 s
eq 0x2153 opt 0x52 flag 0x2 len 112 mtu 1440 state EXSTART
000152: *Oct 23 14:41:20.203 PCTime: OSPF: NBR Negotiation Done. We are the MAST
ER
000153: *Oct 23 14:41:20.203 PCTime: OSPF: Send DBD to 10.60.0.1 on Tunnel111 se
q 0x2154 opt 0x52 flag 0x3 len 112
000154: *Oct 23 14:41:20.239 PCTime: OSPF: Rcv DBD from 10.60.0.1 on Tu
it-cap#nnel111 seq 0x2154 opt 0x52 flag 0x0 len 32 mtu 1440 state EXCHANGE
000155: *Oct 23 14:41:20.239 PCTime: OSPF: Send DBD to 10.60.0.1 on Tunnel111 se
q 0x2155 opt 0x52 flag 0x1 len 32
000156: *Oct 23 14:41:20.239 PCTime: OSPF: Send LS REQ to 10.60.0.1 length 12 LS
A count of 1
000157: *Oct 23 14:41:20.271 PCTime: OSPF: Rcv DBD from 10.60.0.1 on Tunnel111 s
eq 0x2155 opt 0x52 flag 0x0 len 32 mtu 1440 state EXCHANGE
000158: *Oct 23 14:41:20.271 PCTime: OSPF: Exchange Done with 10.60.0.1 on Tunne
l111
000159: *Oct 23 14:41:20.275 PCTime: OSPF: Rcv LS UPD from 10.60.0.1 on Tunnel11
1 length 64 LSA count 1
000160: *Oct 23 14:41:20.275 PCTime: OSPF: Synchronized with 10.60.0.1 on Tunnel
111, state FULL
000161: *Oct 23 14:41:20.275 PCTime: %OSPF-5-ADJCHG: Process 111, Nbr 10.60.0.1
on Tunnel111 from LOADING to FULL, Loading Done
it#
000162: *Oct 23 14:41:20.771 PCTime: OSPF: Rcv LS UPD from 10.60.0.1 on Tunnel11
1 length 76 LSA count 1
it#
000163: *Oct 23 14:41:24.815 PCTime: OSPF: Send hello to 224.0.0.5 area 101 on T
unnel111 from 10.60.0.2
it#
000164: *Oct 23 14:41:50.075 PCTime: OSPF: Rcv hello from 10.60.0.1 area 101 fro
m Tunnel111 10.60.0.1
000165: *Oct 23 14:41:50.079 PCTime: OSPF: End of hello processing
it#
000166: *Oct 23 14:41:54.815 PCTime: OSPF: Send hello to 224.0.0.5 area 101 on T
unnel111 from 10.60.0.2
July 8th 19 at 11:27
2 answers
July 8th 19 at 11:29
Solution
ip ospf network point-to-multipoint non-broadcast
July 8th 19 at 11:31
The reasons for such behavior there is more than one. Show the whole config.
On the Internet write that kind of problem with MTU... - jorge_Emmerich65 commented on July 8th 19 at 11:34
: and on the second side configuration of what? (the one that falls off) - wilfrid11 commented on July 8th 19 at 11:37
Mirror should be.. - jorge_Emmerich65 commented on July 8th 19 at 11:40
Off they both work, the OSPF route is lost at this time - jorge_Emmerich65 commented on July 8th 19 at 11:43
I think maybe on the other side is not allowed multicast 224.0.0.5 on tunnel. - jorge_Emmerich65 commented on July 8th 19 at 11:46
if it was in multicase'd get OSPF or OSPF Protocol, either UDP. In your case, the type of link in General and ptp ospf knows about it, he's not, in theory, not isaet in this case, shirokolashka or multicast. The desired configuration of the second party to accurately to check - wilfrid11 commented on July 8th 19 at 11:49

Find more questions by tags CiscoNetwork administrationComputer networksFreeBSD