В чем проблема с ospf?

Question

[Иван]

Всем привет! Между цисками поднят GRE over IPsec, пинг между сетями стабильный и ровный, но каждые пару минут пропадают несколько пакетов подряд. Выявил закономерность, в логе в этот момент появляется:

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

Помогите расшифровать это сообщение, и предположить, что нужно поменять в настройках роутеров?

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 mtu 1440 state EXSTART
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 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

Comments

[Алексей]

www.certification.ru/cgi-bin/forum.cgi?action=thre...

Answer 1

[Иван]

ip ospf network point-to-multipoint non-broadcast

Answer 2

[Клёвый Админ]

Причин такому поведению существует более одной. Покажите весь конфиг.

Comments

[Иван]

В интернете пишут что вроде проблемы с MTU...

[Клёвый Админ]

Иван: а со второй стороны конфиг какой? (с той которая отваливается)

[Иван]

Евгений Быченко: Зеркальный должен быть..

[Иван]

Отваливаются они обе получается, маршрут OSPF пропадает в это время

[Иван]

Я думаю может на той стороне не разрешён мультикаст 224.0.0.5 на туннель.

[Клёвый Админ]

Иван: если бы дело было в мультикасте OSPF бы пробился либо OSPF протоколом, либо вообще UDP. В вашем же случае тип линка вообще ptp и ospf об этом знает, он не, по идее, не изает в этом случае широковещалку или мультикаст. Нужен конфиг второй стороны, чтобы точно всё сверить