sidetech

(元)インフラエンジニアの寄り道メモ。

ゴースト・プロトコル・ハント

いんやぁ・・・参りました。久々に重度のドドドハマりです。
結果的に出張して現地対応を余儀なくされることになってしまいました。無念。

 Rtv700ghost_2

某遠隔拠点のRTV700が不安定で内線が不通になるという事で、SNMPでのグラフを見る限りでも、CPUの上昇の一定とメモリ増加から特定プロセスのメモリリークかなという事で、社内LANでループでもあったのかなとルーターを見て回ってもデュプリケート無し。
次第に症状はメモリリークする前にRTV700のインターフェースのIPがドロップするだけになってしまい、ろくにグラフが取れなくなっていく始末。
遠隔地にコンソールにダイレクトにRTV700を見る為の環境を作って入ってみるも、RTV700自体はハングしておらず。でもローカルIPしか見えない。

RTV700は親機と子機があるのだけど、親機だけが死ぬという症状。SIPアタックか?ということで、SIPの制限を試みるもダメ。上位VPNルーターSIP-NATを切ってもダメ。RTV700親機のIPを変更しても効果なし。なんじゃこりは・・・。
TCPUDPも可能な限りの制限を掛けても落ちてしまう。でもそれ以外のVPNルーターから社内LANはいたって普通に通信が出来ている。変なARPも見当たらない。

RTV700には・・・というかYAMAHAルーターにはDUMPを取る機能が付いているのだけど、原因と思われるパケットが見えない。気になるのは「未サポートパケットの受信」が多いような気がするというぐらい。

そのうちに1時間持たずに落ちる様になってきた。周期としては35分程度で落ちる。機器交換しても、ファームを変えてもダメで、どうにもウィスパーレベルのパケットに殺されている状態。

現地に行けば対策手段は格段に広がる(深夜対応含む)が、遠隔ではここまでが限界か。
問題は、SIPを苦しめている相手が正常の範囲での通信だった場合、EOLなRTV700では改善しようもない。TCP/UDPで見えないからそんな筈はないと思いたいが。。。

そして、結局ゴーストハントへ西方面に出張。

開始時刻は23時から。最悪でも5時までには原因究明して解決したい。6時間の勝負。

症状が発生するのに約35分必要とするので、絞り込み方法を何パターンか検討しながら様子を見るという方法なので、とにかく大胆に的確に切り分けなければならないのだが、時間だけが経過し、全てのセオリーが通じない。

結局、社内LANに悪者は居なく、SIPルーターとなっていたRTX1200からも外してRTV700だけのネット接続にしても落ちる。グローバルIPも変えたんで外部からのアタックも考えにくい。

35分のインターバルでの格闘は結局4時過ぎても原因が掴めず。
ももう外す配線は限られていた。

ネットワーク側ではなくて・・・となると、もう残っているのはPBXからの接続線。アナログチャンネル(TEL)ポートとBRIチャンネル(PBX)ポート。そしてISDNクロック同期用のISDN S/Tポート。

復帰後は内線が使えていることを踏まえて、ここにきて初めてクロック同期のS/Tポートを外して35分を待つ。

そして40分が経過したとき・・・RTV700は落ちなかった。。。

Dsu_isdn

電話周りの事は詳しくないので憶測になってしまうが、このDSU(写真のシロモノ)からの異常クロック同期通信によってRTV700が悲鳴をあげていた・・・?!

今までにDSUは極まれーに壊れる事は確かにあった。でもRTV700をハングアップさせる様な事は今迄無く、完全にターゲットから外れていた…。

こりゃ何をやってもたどり着けない訳だ。。。
SNMP統計では異常の初動確認が出来たけど、さすがにDSUの部分までは見れない。

ただ、回復前と回復後で、出なくなったRTV700のログはあるにはある。

2015/05/27 00:57:52: [CA] Probe packet timer expired. GW [tgw.00a0dexxxxxx] is Deleted.

このログの意味が分からなかったんだけど、ググったりRTV700のマニュアル読んだりしたけど出てこない。けど、expiredとDeletedというメッセージが気にはなっていた。ただこのログは不定期にしか出てこなかったのと、MACアドレスを表示しているので、このログでネットワーク内をずっと警戒していた。これはバグ的関連性かなぁ・・・。それとももっと違ったメッセージだったんだろうか。

ちなみにDSUの代用品なんてノーマークだったんで持ち合わせがないw
仕方ないので、dipSwitchと接続の組み合わせの変更で様子を見ることにした。最悪、クロック同期をしない手段も考えた。その場合は不具合がまた別の意味で出てしまうので、同期していない場合の対処方法も一応検討したんだけど…

もうかれこれ12時間安定している。
一応、領域でいえば電話屋の領域なので、あとは電話屋に任せる[E:coldsweats01]

久々に悩ましすぎたトラブルでした。どおりでお化けな訳よねぇ…。

今後廃れる内線の仕組みを未だに使っているだけなので、正直解決しても肥しになったかは分からないけど・・・ほんまにまいった!でも予定通りの時間に終わったんで、繰り越しにならんでよかった[E:happy02]

【追記の反省】
障害中には感じ取れなかった事や思いつかなかった事、思い込みでヒラメキを阻害していたことなどが多々あるので、改めてログとにらめっこしたら・・・気になるログ・・・ちゃんとありましたね。

2015/05/27 01:16:15: Dch-Link: Timer to wait link establishing is expired
2015/05/27 01:16:15: [VPM] Reset, GW:1, table:-1

このログの「Dch-Link」に注目しておけばもっと原因究明が早かったかもしれない。
しばらくISDNなんてシロモノと遠ざかっていて思いつかなかった。

ISDNには通信データ用のBチャネルと、制御用のDチャネルってのがあるっすね。
で、Dチャネルは制御用でして、クロック同期もこれで行われているんじゃないかなと。

そして、ログを見る限りでは・・・その事を伝えるログとして出ていましたね~[E:coldsweats01]
Dチャネルなんてのは日頃意識する事がないんだってば・・・[E:weep]

チックショー