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管理を心がけ、無駄なトラフィックの再送を避けることが重要です。
コメント