殆ど自分への備忘録となりますが、マルチキャストの検証を行う際に私が利用するデバッグコマンドを紹介します。
マルチキャストは問題切り分けが難しい
慣れるとどこで止まっているか、なぜ問題が発生しているかもロジカルに切り分けできるのですが、マルチキャストを学び始めた時点では、要素が色々あって難しいことがあります。
例えば、私の場合は以下を確認したりします。
- 各マルチキャストルーターでip multicast-routingが有効になってるか？
- 各インターフェースでPIMが有効になってるか？
- IGMPはLast hop routerで有効になってるか？
- Last hotp routerでもPIMを有効にしてるか？
- PIM Sparse-Modeの場合はみんな同じRPを指してるか？
- RPFチェックは想定通りのパスを指してるか？
もちろん、sh ip mrouteを理解することも必要ですが、上記のようにマルチキャストはうまく動作しない要素が沢山あるので、初めは戸惑うと思います。
私はラボ環境を構築するときは上記4つ目を忘れることがありました。
私が多用しているデバッグコマンド
マルチキャストの切り分けはsh ip mrouteから切り分けていくことが定石だと思いますが、ラボ環境であれば以下のデバッグコマンドをお勧めします。
- debug ip mfib pak
これで、受け取ったマルチキャストパケットを、そのルーターがどのように処理したかがわかります。また、メッセージ自体も人間にかなり分かりやすいものなので非常に重宝します。
そのパケットをドロップしたのか、転送したのであればどのインターフェースに向けて転送したのかも簡単に分かります。
例1:正常に転送しているケース
実際に例を挙げてみますね。以下は正常なケースです。
R4# MFIBv4(0x0): Pkt (155.1.146.6,224.10.10.10) from GigabitEthernet1/0.146 (TS) accepted for forwarding MFIBv4(0x0): Pkt (155.1.146.6,224.10.10.10) from GigabitEthernet1/0.146 (TS) sent on GigabitEthernet1/0.45 R4#
R4がG1/0.45へ正常に転送したことを示しています。
例2:ダメなケース
以下は、パケットの転送が失敗しているケースです。
R5# MFIBv4(0x0): Pkt (155.1.146.6,224.10.10.10) from GigabitEthernet1/0.45 (TS) Acceptance check failed - dropping R5#
上記はわざとR5の設定として155.1.146.6（マルチキャストパケットのセンダー）のベストパスをマルチキャストパケットを受信したインターフェースと違う設定にしたケースです。つまり、RPFチェックに失敗するように仕向けました。非常に分かりやすいメッセージですね。
ip mrouteコマンドで無理矢理RPFチェックに成功するように設定してみました。
ip mroute 155.1.146.0 255.255.255.0 155.1.45.4
再度テストしてみた結果のメッセージが以下です。正常に下流に転送が再開されたことがわかります。
MFIBv4(0x0): Pkt (155.1.146.6,224.10.10.10) from GigabitEthernet1/0.45 (TS) accepted for forwarding MFIBv4(0x0): Pkt (155.1.146.6,224.10.10.10) from GigabitEthernet1/0.45 (TS) sent on GigabitEthernet1/0.58
実際の本番環境では中々デバッグコマンドの設定は難しいと思いますが、ラボ環境などで障害を再現させた時の切り分けには非常に有効です。極端な話、経路上のすべてのルータに上記デバッグコマンドを設定すれば、すぐに「どこでマルチキャストパケットがドロップされているか？」が一目瞭然なので。
マルチキャストのデバッグコマンドは機種やIOSによってかなり変わるので、上記コマンドを利用する場合は事前にコンテキストヘルプを確認してくださいね。
コメント