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

OSPF(Open Shortest Path First)プロトコルでは、隣接するルータ(ネイバー)がMTU(Maximum Transmission Unit)値の不一致により、ネイバー関係を確立できない場合があります。本記事では、OSPFにおけるMTUの役割、MTU不一致時の挙動、さらにMTUのチェックを無視する設定方法について詳しく解説します。

スポンサーリンク

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

OSPFはネイバー関係を確立する際、まずHelloパケットの交換を行い、2Way状態へ移行します。その後、DD(Database Description)パケットが交換されます。このDDパケットには、各ルータのインターフェースMTU値が含まれています。もしルータ間でMTU値が異なると、OSPFは隣接関係を「Full」ステートに到達させず、ネイバー関係は確立されません。

OSPFがMTUの不一致を検出する仕組みは以下の通りです:

  • DDパケットの交換時に、自身のMTU値をネイバーに通知します。
  • 受信側ルータが送信側ルータのMTUが一致しないと判断すると、Exchangeステートで停止します。

このように、OSPFはMTUの一致をネイバー関係の重要な条件の1つとしています。

スポンサーリンク

MTUが異なる場合のOSPF動作

次に、具体例を用いてMTUが異なる場合の動作を解説します。

例:R2とR3の間でMTU不一致をシミュレート

  • R3のインターフェースMTUをデフォルトの1500から1400に変更し、R2との不一致を発生させます。
  • R2でdebug ip ospf adjコマンドを実行し、OSPFのネイバー確立時の挙動を確認します。
R2#debug ip ospf adj

 続いて、R3のインターフェース設定を変更します。R3のMTU値を変更し、一旦、隣接関係を切断します。

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

 R3のMTU値変更後のR2のdebug ip ospf adjの出力です。

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

 R3のMTUが1400である場合、R2から見たOSPFのネイバーは以下のように「Exchange」状態で止まり、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

MTUの不一致により、しばらくするとネイバー関係がダウンし、以下のようなログが表示されます。

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

 これでMTU値がルータ間で一致しました。しばらくすると、 Ignore timer expiredにより、再度、ルータは、ネイバー確立を試みます。

*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

これにより、OSPFはMTUの不一致がある限り、ネイバー関係を維持できないことが確認できます。

スポンサーリンク

MTU不一致を無視する設定方法(mtu-ignore)

OSPFでは、通常、隣接関係の確立にはMTU値の一致が必要ですが、MTUの不一致を無視してネイバー関係を確立させることができます。これを実現するために、ip ospf mtu-ignoreコマンドを用います。

この設定を有効にすると、ルータ間でのMTUチェックをスキップし、MTU値が異なっていてもネイバー関係が「Full」状態に到達するようになります。

この機能は特定のネットワーク環境では非常に有効ですが、以下のような場合にのみ使用することが推奨されます。

  • MTU不一致によるOSPFネイバーの切断が許容できない場合
  • ネットワーク設計の都合上、MTUを統一できないが、OSPFネイバー関係の確立が必要な場合
  • ネットワーク内のトラフィックパターンが特定のMTUに依存していない場合

設定例
以下に、MTU不一致を無視する設定の具体的な手順を示します。ここでは、先ほどのR2とR3のインターフェースに対して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

 R2側でdebug ip ospf adjを実行し、MTU値を無視した際の挙動を確認します。

R2#debug ip ospf adj 
OSPF adjacency debugging is on

 R3のMTUを再度1400に変更し、一旦、隣接関係を切断し、再度ネイバー接続を試みます。

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とR3が正常に隣接関係を確立していることがわかります。

 R2のdebug ip ospf adjの出力です。

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は1400と認識していますが、Exchangeステートが完了し、Full状態に遷移していることがわかります。これにより、R2とR3のMTUが異なっていても、隣接関係が正常に確立されたことが確認できます

スポンサーリンク

mtu-ignore使用時の注意点

mtu-ignoreは便利な設定ですが、使用には注意が必要です。以下のようなリスクや制限があります。

パケットフラグメンテーションのリスク
MTUが異なる場合、トラフィックがフラグメントされる可能性が高まります。これにより、パフォーマンスが低下することがあります。特に、TCPベースのアプリケーションでは遅延や再送が増えることがあるため、慎重に検討する必要があります。

トラブルシューティングの難易度増加
MTU不一致を無視することで、一時的にOSPFのネイバー関係は確立されますが、他のプロトコルやアプリケーションでのMTU依存の問題が発生する可能性があります。トラブルシューティング時にMTUの不一致が見逃される可能性があるため、事前に十分なテストと監視が必要です。

ネットワークの信頼性の低下
長期的な運用では、MTUの統一が推奨されます。mtu-ignoreはあくまで一時的な回避策として用いるべきであり、恒久的な解決策にはなりません。

スポンサーリンク

まとめ

OSPFでは、MTUの不一致がネイバー確立に大きな影響を与えます。特に、大規模ネットワークでのトラブルシューティング時に、MTUの問題を見逃すと、原因の特定に時間がかかることがあります。ip ospf mtu-ignoreの設定は便利ですが、ネットワーク設計における正確なMTU管理を心がけ、無駄なトラフィックの再送を避けることが重要です。

コメント