Cisco Catalyst のTDR試験コマンドでポート故障を遠隔診断する
忙しい人向けサマリ
- リンク障害は現地での物理切り分けしかできずとてもつらい
- test cable-diagnostics tdr コマンドの結果が Fail もしくは Not completed になったら自装置のポート故障と判断できることを発見
- 判定率50%、誤検知率0%。範囲は狭いが信頼性が高く大変有用で障害対応時間が大幅短縮
こんにちは。とある通信会社の委託で壊れたルーターを取り替えるだけの簡単なお仕事をしている夜勤作業員です（エンジニアじゃないよ）。ふと思い出したので、私が新入社員のときに初め取り組んだ業務改善のお話をしたいと思います。
地味に面倒なリンク障害の切り分け
%LINK-3-CHANGED: Interface GigabitEthernet0/1 changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down
ネットワークを監視していると日常的に起きるリンク障害(リンクダウン・ポートダウン)。両装置がいまも稼働しているならば、その故障被疑箇所は主に装置Aのポート・装置Bのポート・それらをつなぐケーブルの3つが挙げられます。オプティカルなSFPであれば show interfaces transceiver などのコマンドで光を出してる・受けてるが遠隔で確認できますし、SONET/SDHとかだったら show controllers sonnet とやればアラートや統計値が確認でき、ある程度の推測が可能です。しかしUTPを使ったナイーブなEthernet (1000BASE-T等) ではこれといった有用な方法がありません。
となると現地でケーブルを差し替えてみたり筐体を交換してみたりして物理的に切り分けるしかないのですが、両装置で保守部門が異なったりしていて最初にどちらかが対応してダメだったらバトンタッチするやら、故障箇所が分かってからベンダに代替品を手配するやらで、緊急対応なのに直るまで8時間と平気でかかかったりします。しかも 1000BASE-T などの細いリンクはネットワークの末端、すなわちエンドユーザーの入り口であることが多く、それは大抵シングル構成でリンクダウンがサービス中断に直結するため速やかに復旧させなくてはなりません。余談ですがこのような場所には Catalyst 2960 や 3560 といったチープな機器が使われておりオンライン診断機能が貧弱・無い(POSTだけとか)のも痛いところです。
ケーブル試験コマンド？
なんかいい方法ないかな〜といろいろ調べていた矢先、ふと test cable-diagnostics tdr というコマンドを見つけました。TDR (Time Domain Reflectometry) とは試験用のパルス信号を送り、反射して帰ってきた信号とその時間を分析することで伝送路の特性を測る手法です。ネットワークの世界ではどちらかというと光ファイバの減衰率を測定するOTDR (Optical TDR) のほうが有名だと思います。よく「パルス試験器」と呼んでいました。レイリー散乱とかフレネル反射とか懐かしい人いませんか？
さて、では実際に使ってみましょう。まず対象ですが Cisco の最も安価なスイッチである Catalyst 2960 シリーズの IOS 12.2 系でも動くので大抵のCiscoスイッチなら対応していると思います(ただし 100BASE-TX ポートを持つ一部機種(旧機種？)は非対応だったようなおぼろげな記憶があります)。次に実行方法ですが、 test cable-diagnostics tdr interface <インターフェース名> というコマンドを実行してください。コマンドは何事も無く終了するので、試験が終わるまで5秒ほど待ってから結果を show cable-diagnostics tdr interface <インターフェース名> コマンドで確認します。なお試験時はリンクダウンし通信が途切れるでご注意ください。
#test cable-diagnostics tdr interface GigabitEthernet0/24
#show cable-diagnostics tdr interface GigabitEthernet0/24
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/24 1000M Pair A 2 +/- 4 meters N/A Normal
Pair C 2 +/- 4 meters N/A Normal
Pair C 2 +/- 4 meters N/A Normal
Pair D 2 +/- 4 meters N/A Normal
とこのようにUTP各ペアのケーブル長・ペアの組み合わせ(ストレート/クロス)・状態が確認できます。つまり名前の通りケーブルの状態を診断するコマンドなのですが、壊れた Catalyst 2960 でこのコマンドを実行してみたところ、おもしろい結果が出てきました。
#show cable-diagnostics tdr interface G0/24
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/24 1000M Pair A N/A N/A Fail
Pair B N/A N/A Fail
Pair C N/A N/A Fail
Pair D N/A N/A Fail
Fail とでています。これはCiscoのコマンドリファレンスにも載っていない結果です。これは使えそうと直感し統計を取ってみることにしました。
データを取ったら傾向性が見えてきた
本施策ではポート集約に使っている約1万台の Catalyst 2960 / 3560 と対向の光アクセス装置間における約200件のリンクダウン障害(リンクダウン起きすぎィ!!)に対しケーブル試験コマンドを実行しデータを取ってみました。特に Fail と Normal が目立ちますね。
またペアステータスと原因箇所の関係を見てみると、ステータスごとに原因の割合が大きく異なっています。これは有意っぽい。
Fail と Not completed は無条件で自装置故障と判断
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/24 1000M Pair A 9 +/- 4 meters N/A Fail
Pair B 65535 +/- 4 meters N/A Normal
Pair C 30 +/- 4 meters N/A Fail
Pair D 6 +/- 4 meters N/A Fail
まず Fail になった案件は109件中109件(100%)が自装置のポート不良でした。Cisco に問い合わせてみたのですが「わからん。てかケーブルを診断するコマンドなのでそれ以外の意味はないよ」という塩回答しか返ってこなかったので断言はできませんが、おそらく試験を行う低レイヤーのパーツ(PHYチップ？)が故障しており試験そのものが正常に行えなかったことを示すものだと思います。件数的にも意味的にもこれは即自装置の故障と断定してよいでしょう。
また Not completed も4件中4件(100%)が自装置のポート不良でした。これはいつまで経ってもケーブル試験が終わらないパターンで、試験機能が正常に動作しないことから件数は少ないものの意味的に考えて自装置の故障と断定してよいでしょう。
Open / Short は長さを使って判断できるかも？
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/24 1000M Pair A 0 +/- 2 meters N/A Open
Pair B 0 +/- 2 meters N/A Open
Pair C 0 +/- 2 meters N/A Open
Pair D 0 +/- 2 meters N/A Open
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/24 1000M Pair A 2 +/- 4 meters N/A Normal
Pair B 0 +/- 4 meters N/A Short
Pair C 2 +/- 4 meters N/A Normal
Pair D 2 +/- 4 meters N/A Normal
次に Open と Short ですが、Pair Length に着目してみると 0m 地点(つまり自身のポート)で断線・短絡が起きている場合は自装置が故障していることが多いことが分かりました。件数が少なくデータが不十分なのと、1件ですが0mなのに対向装置を交換したら治ったという事例もあり(対応者の勘違いの可能性もアリ)断定はできないと思います。
Normal / ImpedanceMis はそっ閉じ
最後に Normal と ImpedanceMis ですが、こちらも Pair Length が 0m や 規格外(65536メートルとか)だったりする場合は自装置の故障が多く、正常に値を測定できる場合は対向装置の故障が多いという傾向はありますが天気予報レベルの精度です。これで判断はできないと思います。
結論: 50%は遠隔切り分けできる！
というわけで安全側に倒して、Fail または Not completed になった場合は自装置のポート不良と判断するのがひとまずよさそうです。このとき特定率は50%、誤検知率は0%です。なかなかいい成績ではないでしょうか。もし両装置がどちらもCatalystならば7割くらいは判定できるかもしれません。
おまけ: ハードウェアアーキテクチャから推測できる故障
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/5 1000M Pair A N/A N/A N/A
Pair B N/A N/A N/A
Pair C N/A N/A N/A
Pair D N/A N/A N/A
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/6 1000M Pair A N/A N/A N/A
Pair B N/A N/A N/A
Pair C N/A N/A N/A
Pair D N/A N/A N/A
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/7 1000M Pair A N/A N/A N/A
Pair B N/A N/A N/A
Pair C N/A N/A N/A
Pair D N/A N/A N/A
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/8 1000M Pair A N/A N/A N/A
Pair B N/A N/A N/A
Pair C N/A N/A N/A
Pair D N/A N/A N/A
余談ですがこのように複数のポートがまとめてダウンすることがあります。
#show platform pm if-numbers interface gid gpn lpn port slot unit slun port-type lpn-idb gpn-idb ---------------------------------------------------------------------- Gi0/1 1 1 1 6/3 1 1 1 local Yes Yes Gi0/2 2 2 2 6/0 1 2 2 local Yes Yes Gi0/3 3 3 3 6/1 1 3 3 local Yes Yes Gi0/4 4 4 4 6/2 1 4 4 local Yes Yes Gi0/5 5 5 5 5/2 1 5 5 local Yes Yes Gi0/6 6 6 6 5/3 1 6 6 local Yes Yes Gi0/7 7 7 7 5/0 1 7 7 local Yes Yes Gi0/8 8 8 8 5/1 1 8 8 local Yes Yes Gi0/9 9 9 9 8/3 1 9 9 local Yes Yes Gi0/10 10 10 10 8/0 1 10 10 local Yes Yes
実はこのスイッチでは5〜8番ポートが同一の Port ASIC (ASIC#5) に接続されています。このようにハードウェアの構成を思い浮かべて「ああ、あのパーツが壊れたんだな」と故障モードと実際の事象を紐付けて被疑箇所を推測するのも大変有用です。
ポートダウン自動判定ツールの開発
前途の通りこの試験コマンドは通信断を伴うため、オペレーターが誤ったポートを指定したり正常なのに試験をしてしまったりしてアウテージが起きないようツールによる自動実行・自動判定の仕組みを作りました。
こんな感じでWeb上からポート試験が実行できます。このとき使用中のポート(MACアドレスエントリの有無で判断)を選択すると実行を拒否します。ツールはケーブル試験のほかに、shutdown/no shutdown や、speed と duplex の変更等のショックを与えてリセット回復も狙っています。そしてしばらくするとレポートが表示され、何をすべきかをオペレーターにレコメンドします。
ちなみに speed や duplex を固定してみたり自動にしてみたりというショック療法は TAC から提案を受けてやってみたのですが、まったく効果がなくのちに廃止しています。
はじめたばかりの PHP と MySQL でヒーヒー言いながら作っていました。いやはや懐かしい。
セピア色の業務改善
新卒入社後NOCに初期配属され、そのときの課長は「いいんじゃない？やってみてごらん」と自由奔放で、主査(主任)は「それがお客様のためになるならやろう！」と本質を大切にする方だったためサポートをやアドバイスを頂きながらトントン拍子でここまで形にすることができました。遠隔切り分けにより障害対応時間を1/3に短縮することができ、その年の優良事例として表彰もされました。最低評価以外の査定をいただいた最初で最後の年でもあります。
そして上司が変わり、職場が変わり、それがこの会社ではかなり特殊で貴重なものだったということを知りました。そのような恵まれた環境に居たから自分はソリティアおじさんの道に進まずに済んだのです。ちなみにその職場は今では「え？マニュアルに書いてあるコマンド以外打たないでよ。怖いから」という組織になっており、それを思うとなんとも黄昏れてしまう中堅おじさんなのでした。
