RTシリーズのログに関するFAQ
回線障害を報告するログ
| 新規作成日 | 2000/Jan/25 |
| 最終変更日 | 2010/Jul/21 |
| 文書サイズ | 16KB |
「HDLC Error」というログの意味を教えてください。
[ 役割 ]
PP[XX] HDLC Error: CRC
PP[XX] HDLC Error: FRAME
PP[XX] HDLC Error: ABORT FRAME
PP[XX] HDLC Error: FRAME CRC
「受信したデータが壊れている」という意図を表していて、 回線の障害などの可能性を表しています。
debugレベルで、ログが記録されます。
debugレベルの16進数ダンプの部分は取扱注意！
電話番号などの個人情報も含まれていることがあります。
RT100iで専用線の場合の「HDLC Error」発生例 ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ┃# pp select leased ┃leased# show status pp ┃LEASED: ┃Current line status is Online. ┃Call is outgoing side, ┃3 hours 45 minutes 3 seconds connection. ┃Received: 128634 packets [107298501 octets] Load: 0.1% ┃Transmitted: 128063 packets [19404922 octets] Load: 1.2% ┃Abort error: 146 times. ┃Frame error: 6406 times. ┃CRC error: 3019 times. ┃PPP Cofigure Options ┃ LCP Local: Magic-Number MRU, Remote: Magic-Number ┃ IPCP Local:, Remote: IP-Address ┃ PP IP Address Local: Unnumbered, Remote: Unnumbered ┃ CCP: None ┃# ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ 発生要因 ]
宅内配線 宅外配線 宅外配線 宅内配線
[ISDN端末]〜〜[DSU]〜〜〜〜[回線接続業者]〜〜〜〜[DSU]〜〜[ISDN端末]
↑ ↑
├───────────────────────┤
＜回線障害の発生している可能性のある範囲＞
回線障害の発生している可能性のあるそれぞれの部分で、 正常に動作する機器などで置き換えながら、症状の変化を 調べることにより、障害の発生している個所を特定して ゆきます。このような調査方法を「切り分け」などと言います。
DSUが故障している可能性がある場合、DSUを交換して様子を見ます。
回線が周囲からのノイズを受けたために
発生している可能性があります。
→回線接続業者に回線状態を検査してもらう必要があります。
機器の仕様なのか、不具合なのか、定かではありません。
例) 接続中に「HDLC Error」が発生することがある接続相手
関連情報：rt100i-users 21366
7.2.4と8.0.2でfixされたAscend MAX (Lucent MAX)の不具合の可能性があるようです。
必要であれば、Ascend MAX (Lucent MAX)のリリースノートの調査やファームウェアの更新を検討してください。
[ 回線障害の調査依頼のコツ ]
DSUまでの折り返し試験は、通常、短時間の調査で エラーが検出されるかどうかで判別されます。
短時間の障害調査だと障害を発見できないことも多く、 その時(その場で)は、「障害は無い」と判定されることもあります。 十二分な障害調査を依頼しておかないと、何度も、 回線障害調査を依頼しなければならなくなるかもしれません。
予めログの「HDLC Erorr」や障害の発生状況を観測しておき、 時間の間隔や時間帯などを予測して(指定して)、 一定時間連続して測定して貰うようにすると良いでしょう。
[ 創作サポート日記 ]
WAN接続時のスループット低下の原因は、ネ ットワークのトラフィックが急速に増えるとか、 不要な通信が増えるとか、ということもあるの ですが、ISDNルータや回線のトラブルでもスル ープットの低下などの障害が発生します。
電話サポート担当のＹ嬢は、いつものように サポート電話を取りました。「専用線にRTを繋 いでWAN接続をしているが、ルータ設定を変え てないのに、突然、通信が遅くなってきたよう です。ルータが壊れちゃったんだと思うので、 急いで修理をしてください。」と、依頼されま した。ISDNルータの故障としても、他の要因の 障害にしても、障害の原因究明が先決ですので、 ひとまず、障害発生時のデバッグ・ログとshow status lanやshow status ppの結果を収集して 頂くように依頼しました。
後日、お客さまから障害時のデバッグ・ログ が送られてきました。ログを解析すると、
PP[XX] HDLC Error: CRC PP[XX] HDLC Error: FRAME PP[XX] HDLC Error: ABORT FRAME PP[XX] HDLC Error: FRAME CRCのようなログが多数出ていました。show status ppの結果でも、多くの回線エラーが集計されて いました。これらの情報により、トラフィック が増えたのではなく、専用線や機器の故障の可 能性があることがわかりました。そこで、ルー タが故障しているかどうかの切り分け作業をお 願いすることにしました。お客さまに、両方の ルータの設定にデバッグ・ログを出力するよう に設定していただいた上で、「どちらかのルー タの専用線側のコネクタをブスッと抜き、カチ ッと挿す」という作業をしてもらいました。も し、可能なら、DSUやISDNルータ、回線、ケー ブル、場所などを変更して同様に試してもらう ようにお願いしました。
後日、お客さまから試験結果のデバッグ・ロ グが送られてきました。ログを解析すると、 DSUやISDNルータを交換しても障害が回復して いない(ログに変化が無い)ことがわかりました。 この状況では、回線関係の障害である可能性が 高く、DSUやISDNルータの障害である可能性が 低いと思われます。お客さまには、ISDNルータ の故障ではない旨を伝え、回線業者に回線の障 害を報告して、調査を依頼していただくように お願いすると共に、障害を発見した時期に行な われたネットワークに関係するかもしれない作 業を調査して頂くようにお願いいたしました。
その後、お客さまから調査結果の報告がありま した。結局、回線業者に調査を依頼することで 回復したということでした。これで本件のサポ ートを終了することができました。
一般的な調査方法は、ネットワーク機器の利 用状況を参考にしながら、LANアナライザやWAN アナライザといった専用機器を利用しながら、 ネットワークを利用した通信内容を分析するこ とになります。回線トラブルの可能性があると いうことですと、WANアナライザが活躍します。 回線の信号レベルの不具合からプロトコルの不 具合などを解析することができます。
しかし、ユーザによる障害の切り分け作業に WANアナライザが使えるとは限りませんので、 RTシリーズによる切り分けテクニックを紹介し ましょう。
DSUや回線に障害がある場合、電話に利用し ているISDN回線だと、「通話の音声にノイズが 乗る」のような形で障害が表面化してきますの で、感覚的にわかりやすいものになります。し かし、専用線やデータ通信に利用しているISDN 回線の障害になると通信内容がデジタルデータ になりますので、デジタルデータの中身のエラ ー状態を確認しなければ、正確に判別すること ができません。ISDNルータを専用線に接続して いる場合ですと、時々データが壊れるとか、不 通になるとか、反応が遅い時があるというよう な症状で表面化してしまいます。
データ通信の回線に障害が発生していると、 PPPを利用した接続をしているISDNルータでは、 PPPレベルでの通信が不安定になります。PPPレ ベルが安定していない訳ですから、TCP/IPの通 信は、より不安定になってしまいます。結局、 「通信が遅くなった」という症状となり、スル ープット低下と勘違いしてしまう場合もあるよ うです。
つまり、回線の障害が発生していると、ping コマンドなどによる簡単な通信の可/不可の確 認は、あまり効果がありません。
「専用線のコネクタを抜いてから挿す」とい う動作を伝えるのにわざわざ擬音で表現する必 要はありません。電話でのサポートで擬音を上 手に使うことで「専用線のコネクタを抜いてか ら挿す」という動作を伝えるばかりではなく、 接触不良を起こさないようにしていただく配慮 でした。もちろん、回線コネクタの接触不良も トラブル原因になりますから、確実にコネクタ を挿し直すことで解決する場合もあります。
RTのログ機能でdebugレベルのログを残すよ うに指定しておくとPPPの接続時の接続相手と のネゴシエーションの通信内容もログされます。 双方のISDNルータでこのPPPのネゴシエーショ ン内容のログを取り、送ったデータが届いてい るのかなどを比較することにより低レベルな障 害の確認をすることができます。つまり、ping コマンドなどが利用できない回線の障害発生時 にも、データが届いているのか、化けているの かという確認が行なえます。
ISDN回線を利用している環境でこのPPPのネ ゴシエーション時のログを見るには、syslog debug onしておき、通常の切断と接続を行いま す。しかし、常時接続である専用線接続では、 ルータの電源を入れ直すか、「専用線のコネク タを抜いてから挿す」という措置をすることで PPPのネゴシエーションが再開されます。
つまり、専用線においては「コネクタを抜い てから挿す」という作業により、接続と切断の 状態をログを採取しながら手際良く観察するこ とができるのです。ちなみに、ISDN回線で同様 の障害が発生している時には、切断する目的で 「コネクタを抜いてから挿す」という作業はや らないで、通常の「接続と切断」を行なうよう にします。
回線の障害は、新規導入、変更、移転などの 時に発生する可能性が高いのですが、一度発生 してしまうと、地道な切り分け作業を繰り返さ なければ、確実な究明は難しいでしょう。いく つかの具体的な回線まわりの障害事例の項目を 上げておきます。
ケーブルを自作してみるとその難しさが納得 できるかもしれませんね。
DSUを交換して切り分け作業をします
終端抵抗付きローゼットなどを使ったりします。
運用中には不要なので通常カットされる。
LANケーブルとISDN S/T点ケーブルが似ています。 ケーブルの色分けやラベル付けをします。
+-------------+
| IPホスト#A | (ホスト)
+------+------+
| 133.176.200.51 133.176.200.0/24
-------+-----------------------------------
| 133.176.200.67
+------+------+
| RT(A) | (ダイヤルアップ・サーバ)
+-------------+
: 10/Celery
: ISDN擬似交換機またはISDN回線
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
:
: 20/Tomato
+-------------+ (ipcp/133.176.200.68)
| RT(B) | (端末型ダイヤルアップ) ↑ IPマスカレード
+------+------+ 192.168.0.1-192.168.0.254
| 192.168.0.1 192.168.0.0/24
-------+-----------------------------------
| 192.168.0.2
+------+------+
| IPホスト#B | (Windows98)
+-------------+
isdn local address 10/Celery ip lan address 133.176.200.67/24 ip lan proxyarp on pp select anonymous ip pp remote address pool 133.176.200.68 133.176.200.69 pp auth request chap-pap pp auth username test-user test-password ppp ipcp msext on pp enable anonymous
isdn local address 20/Tomato ip lan address 192.168.0.1/24 pp select 1 isdn remote address call 01/Celery ip pp route add net default 1 pp auth accept chap pap pp auth myname test-user test-password nat use on nat masquerade on ppp ipcp ipaddress on ppp ipcp msext on pp enable 1
1999/06/23 09:30:32: PP[01] IP Commencing: ICMP 192.168.0.2 > 133.176.200.51 : echo request 1999/06/23 09:30:32: PP[01] Calling 10 with 1B mode 1999/06/23 09:30:32: PP[01] PPP/IPCP up ... 1999/06/23 09:31:35: PP[01] Disconnect complete 1999/06/23 09:31:35: PP[01] Disconnected cause [No error.] 1999/06/23 09:31:35: PP[01] Disconnected by [User] 1999/06/23 09:31:35: PP[01] Charge is 10 yen
1999/06/23 09:30:32: PP[01] IP Commencing: ICMP 192.168.0.2 > 133.176.200.51 : echo request 1999/06/23 09:30:32: PP[01] Calling 10 with 1B mode 1999/06/23 09:30:32: ISDN[1/80] SEND [SETUP] 1999/06/23 09:30:32: ISDN[1/80] RECV [CALL PROC] 1999/06/23 09:30:32: ISDN[1/80] RECV [CONN] 1999/06/23 09:30:32: PP[01] HDLC Opening, ch = A 1999/06/23 09:30:32: PP[01] ISDN connect, going PPP phase 1999/06/23 09:30:32: PP[01] SEND LCP ConfReq in STARTING 1999/06/23 09:30:32: PP[01] RECV LCP ConfReq in REQSENT 1999/06/23 09:30:32: PP[01] SEND LCP ConfAck in REQSENT 1999/06/23 09:30:32: PP[01] RECV LCP ConfAck in ACKSENT 1999/06/23 09:30:32: PP[01] SEND CCP ConfReq in STARTING 1999/06/23 09:30:32: PP[01] SEND IPCP ConfReq in STARTING 1999/06/23 09:30:32: PP[01] RECV CCP ConfReq in REQSENT 1999/06/23 09:30:32: PP[01] SEND CCP ConfAck in REQSENT 1999/06/23 09:30:32: PP[01] RECV IPCP ConfReq in REQSENT 1999/06/23 09:30:32: PP[01] SEND IPCP ConfNak in REQSENT 1999/06/23 09:30:32: PP[01] RECV CCP ConfAck in ACKSENT 1999/06/23 09:30:32: PP[01] RECV IPCP ConfNak in REQSENT 1999/06/23 09:30:32: PP[01] SEND IPCP ConfReq in REQSENT 1999/06/23 09:30:32: PP[01] RECV IPCP ConfReq in REQSENT 1999/06/23 09:30:32: PP[01] SEND IPCP ConfAck in REQSENT 1999/06/23 09:30:32: PP[01] RECV IPCP ConfAck in ACKSENT 1999/06/23 09:30:32: PP[01] PPP/IPCP up 1999/06/23 09:30:32: PP[01] Local PP IP address 133.176.200.68 1999/06/23 09:30:32: PP[01] Remote PP IP address 133.176.200.67 ... 1999/06/23 09:31:34: ISDN[1/80] RECV [DISC] 1999/06/23 09:31:34: ISDN[1/80] SEND [REL] 1999/06/23 09:31:35: ISDN[1/80] RECV [REL COMP] 1999/06/23 09:31:35: PP[01] Disconnect complete 1999/06/23 09:31:35: PP[01] Disconnected cause [No error.] 1999/06/23 09:31:35: PP[01] Disconnected by [User] 1999/06/23 09:31:35: PP[01] Charge is 10 yen
[ FAQ for RT-Series ]
[ FAQ for Syslog / files / Intro / Install / Config ]