OSPFネイバーが確立されない理由はMTU？対処法を徹底解説

OSPF では、隣接するルータ（ネイバー）同士でインターフェースの MTU（Maximum Transmission Unit）が合っていないと、ネイバーが FULL にならないことがあります。この記事では、OSPF が MTU を確かめる仕組みと、MTU が合わないときの動き、MTU のチェックを無視する ip ospf mtu-ignore の設定と注意点を確かめます。

この記事でわかること

DBD（Database Description）パケットで MTU が通知されること
MTU が合わないとき、MTU が小さい側は EXSTART、大きい側は EXCHANGE で止まること
ip ospf mtu-ignore の設定と、使うときの注意点

検証構成
ネイバー確立時の MTU の通知
MTU が合わない場合の動き
MTU の不一致を無視する（mtu-ignore）
1. mtu-ignore を設定する
2. MTU を変えてネイバーを作り直す
mtu-ignore を使うときの注意点
まとめ

検証構成

R2 と R3 を 192.168.23.0/24 でつなぎ、エリア0で OSPF のネイバーにします。インターフェースの MTU は、どちらも既定の 1500 です。検証では R3 の MTU を 1400 に変えて、MTU が合わない状態を作ります。

図1　検証構成

ネイバー確立時の MTU の通知

OSPF のネイバーは、Hello を交換して 2-Way になったあと、EXSTART と EXCHANGE で DBD パケットを交換し、お互いの LSDB の中身（LSA のヘッダ）を伝え合います。この DBD パケットには、送ったルータのインターフェースの MTU（Interface MTU）が入っています。

画面イメージについて

この記事の画面は、実際の画面ではなく、検証時の画面から見るポイントを抜き出して描いたイメージです。バージョンによって、項目の並びや表記は変わります。

パケットキャプチャ（Wireshark）：R2 から R3 への DB Description画面イメージ

▸ Frame 12: 82 bytes on wire (656 bits), 82 bytes captured (656 bits)▸ Ethernet II▸ 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 23▸ Internet Protocol Version 4, Src: 192.168.23.2, Dst: 192.168.23.3▾ Open Shortest Path First  ▸ OSPF Header  ▾ OSPF DB Description1      Interface MTU: 1500    ▸ Options: 0x52, O, (L) LLS Data block, (E) External Routing    ▸ DB Description: 0x07, (I) Init, (M) More, (MS) Master      DD Sequence: 8685  ▸ OSPF LLS Data Block

図2　DBD パケットの Interface MTU（実際の画面ではなく、表示内容のポイントを示したイメージです）

No.	表示	意味
1	`Interface MTU: 1500`	DBD を送ったインターフェース（R2）の MTU。受け取った側は、この値を自分のインターフェースの MTU と比べる

受け取った DBD の Interface MTU が、自分のインターフェースで受け取れる大きさ（自分の MTU）より大きいと、その DBD を捨てます。つまり、DBD を捨てるのは MTU が小さい側です。

MTU が小さい側（ここでは R3）は、相手の DBD を捨てるので EXSTART から進めず、DBD を再送し続けます。
MTU が大きい側（ここでは R2）は、相手の DBD を受け付けて EXCHANGE に進みますが、相手から応答が来ないので EXCHANGE で止まります。

図3　MTU が合わないときの DBD のやり取り

MTU が合わない場合の動き

R3 の MTU を 1400 にする

R2 で debug ip ospf adj を有効にし、ネイバーができるときの動きを見ます。

R2#debug ip ospf adj

R3 のインターフェースの MTU を 1400 に変え、インターフェースを shutdown／no shutdown して、ネイバーを作り直します。

R3(config)#int fa0/0.23
R3(config-subif)#ip mtu ?
  <68-1500>  MTU (bytes)

R3(config-subif)#ip mtu 1400
R3(config-subif)#shutdown
R3(config-subif)#no shutdown

R2 の debug を見ると、R3 から mtu 1400 の DBD を受け取り、「ネイバーの MTU のほうが小さい」と表示しています。R2 は R3 の DBD を受け付けて、EXCHANGE に進んでいます。

R2#
*Jun 16 12:37:31.111: OSPF-1 ADJ   Fa0/0.23: Rcv DBD from 
3.3.3.3 seq 0x2277 opt 0x52 flag 0x7 len 32  mtu 1400 state EXCHANGE
*Jun 16 12:37:31.111: OSPF-1 ADJ   Fa0/0.23: Nbr 3.3.3.3 has smaller interface MTU
*Jun 16 12:37:31.111: OSPF-1 ADJ   Fa0/0.23: Send DBD to 3.3.3.3 seq 0x2277 opt 0x52 flag 0x2 len 92

ネイバーの状態を確認する

R2 から見た R3 は EXCHANGE、R3 から見た R2 は EXSTART で止まり、どちらも FULL になりません。

R2#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           1   EXCHANGE/BDR    00:00:37    192.168.23.3    FastEthernet0/0.23

R3#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   EXSTART/DR      00:00:37    192.168.23.2    FastEthernet0/0.23

しばらくすると、R3 では DBD の再送が上限に達し、ネイバーがダウンします。

R3#
*Jun 16 12:39:15.251: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0.23 
from EXSTART to DOWN, Neighbor Down: Too many retransmissions

R3 の MTU を元に戻す

R3(config)#int fastEthernet 0/0.23
R3(config-subif)#no ip mtu

再送の上限でダウンしたネイバーは、しばらくのあいだ無視されます。このログでは、約60秒後に Ignore timer expired が出て、もう一度ネイバーを作り始め、MTU がそろったので FULL になっています。

*Jun 16 12:40:15.251: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0.23 
from DOWN to DOWN, Neighbor Down: Ignore timer expired
*Jun 16 12:40:19.955: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0.23 
from LOADING to FULL, Loading Done

MTU の不一致を無視する（mtu-ignore）

ip ospf mtu-ignore をインターフェースに設定すると、受け取った DBD の MTU のチェックをしなくなり、MTU が違っていてもネイバーが FULL になります。チェックで DBD を捨てるのは MTU が小さい側ですが、両側に設定しておけば、どちらの MTU が小さくなっても対応できます。

mtu-ignore を設定する

R2(config)#int fa0/0.23
R2(config-subif)#ip ospf mtu-ignore

R3(config)#int fa0/0.23
R3(config-subif)#ip ospf mtu-ignore

MTU を変えてネイバーを作り直す

R2#debug ip ospf adj 
OSPF adjacency debugging is on

R3 の MTU をもう一度 1400 にして、shutdown／no shutdown でネイバーを作り直します。今度は FULL になります。

R3(config)#int fa0/0.23
R3(config-subif)#ip mtu 1400
R3(config-subif)#shutdown

*Jun 16 12:49:11.175: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0.23 
from FULL to DOWN, Neighbor Down: Interface down or detached

R3(config-subif)#no shutdown

*Jun 16 12:50:02.963: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/0.23 
from LOADING to FULL, Loading Done

R2 の debug では、R3 の MTU を 1400 と認識したうえで EXCHANGE を終え（Exchange Done）、FULL になっています。

R2#
*Jun 16 12:50:03.519: OSPF-1 ADJ   Fa0/0.23: Rcv DBD from 3.3.3.3 seq 0xA09 opt 0x52 flag 
0x1 len 72  mtu 1400 state EXCHANGE
*Jun 16 12:50:03.519: OSPF-1 ADJ   Fa0/0.23: Exchange Done with 3.3.3.3
*Jun 16 12:50:03.523: OSPF-1 ADJ   Fa0/0.23: Send LS REQ to 3.3.3.3 length 36 LSA count 1
*Jun 16 12:50:03.523: OSPF-1 ADJ   Fa0/0.23: Send DBD to 3.3.3.3 seq 0xA09 opt 0x52 flag 0x0 len 32
*Jun 16 12:50:03.539: OSPF-1 ADJ   Fa0/0.23: Rcv LS UPD from 3.3.3.3 length 76 LSA count 1
*Jun 16 12:50:03.543: OSPF-1 ADJ   Fa0/0.23: Synchronized with 3.3.3.3, state FULL
*Jun 16 12:50:03.543: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/0.23 
from LOADING to FULL, Loading Done

mtu-ignore を使うときの注意点

ip ospf mtu-ignore は、MTU のチェックをやめるだけで、リンクの MTU の違いがなくなるわけではありません。

注意点	内容
大きな OSPF パケット	MTU が大きい側は、自分の MTU（1500）までの大きさで LSU などを送ります。MTU が小さい側（1400）は、それより大きなパケットを受け取れずに捨てることがあります。LSA が増えると、LSDB の同期が終わらなくなるおそれがある
通常の通信	OSPF 以外の通信でも、MTU が小さい側が大きなパケットを受け取れない問題は残る。ネイバーが FULL になっているので、原因として気づきにくくなる
使いどころ	機器の仕様で MTU をそろえられないときなどに限って使い、できるだけリンクの両側で MTU をそろえる

まとめ

項目	内容
MTU の通知	DBD パケットの Interface MTU
MTU が合わないとき	MTU が小さい側が相手の DBD を捨てる。小さい側は EXSTART、大きい側は EXCHANGE で止まり、やがて Too many retransmissions でダウン
debug の表示	`Nbr ... has smaller interface MTU`
回避	`ip ospf mtu-ignore` で MTU のチェックをやめる（根本的には MTU をそろえる）

ネイバーが EXSTART や EXCHANGE で止まっているときは、まずリンクの両側の MTU を確かめます。