運用ガイド
本装置を使用しているIPv4ネットワーク上で,通信トラブルが発生する要因として考えられるのは,次の3種類があります。
- IP通信に関係するコンフィグレーションの変更
- ネットワークの構成変更
- ネットワークを構成する機器の障害
上記1.および2.については,コンフィグレーションおよびネットワーク構成の変更前と変更後の差分を調べていただき,通信ができなくなるような原因がないか確認してください。
ここでは,3.に示すように「コンフィグレーションおよびネットワーク構成は正しいのにIP通信ができない」,「これまで正常に動いていたのにIP通信ができなくなった」というケースを中心に,障害部位および原因の切り分け手順を説明いたします。
障害部位および原因の切り分け方法は,次のフローに従ってください。
- <この項の構成>
- (1) ログの確認
- (2) インタフェース状態の確認
- (3) 障害範囲の特定(本装置から実施する場合)
- (4) 障害範囲の特定(お客様の端末装置から実施する場合)
- (5) 隣接装置とのARP解決情報の確認
- (6) ユニキャストルーティング情報の確認
- (7) フィルタリング/QoS設定情報の確認
- (8) Nullインタフェース設定情報の確認
- (9) ポリシールーティング設定情報の確認
- (10) Tag-VLAN連携設定情報の確認
(1) ログの確認
通信ができなくなる原因の一つには,ハードウェア(PRU/NIF/Line)の障害(または壊れ)が考えられます。本装置が表示するログで,ハードウェアの障害を示すメッセージの表示手順を示します。
なお,ログの内容については,「メッセージ・ログレファレンス 3. 装置関連の障害およびイベント情報」を参照してください。
- 本装置にログインします。
- show loggingコマンドを使ってログを表示させます。
- ログには各々発生した日時が表示されます。通信ができなくなった日時にログが表示されていないか確認してください。
- 通信ができなくなった日時に表示されているログの障害の内容および障害への対応は「メッセージ・ログレファレンス」に記載しています。その指示に従ってください。
- 通信ができなくなった日時にログの表示がないときは,「(2) インタフェース状態の確認」に進んでください。
(2) インタフェース状態の確認
本装置のハードウェアは正常に動作している場合でも,本装置と接続している隣接の装置のハードウェアに障害が発生していることも考えられます。
本装置と隣接の装置間の,インタフェースの状態を確認する手順を次に示します。
- 本装置にログインします。
- show ip interfaceコマンドを使って該当装置間のインタフェースのUp/Down状態を確認してください。
- 該当インタフェースが”Down”状態のときは,「8.4 ネットワークインタフェースの通信障害」を参照してください。
- 該当インタフェースとの間のインタフェースが”Up”状態のときは,「(3) 障害範囲の特定(本装置から実施する場合)」に進んでください。
(3) 障害範囲の特定(本装置から実施する場合)
本装置に障害がない場合は,通信を行っていた相手との間のどこかに障害が発生している可能性があります。通信相手とのどこの部分で障害が発生しているか,障害範囲を特定する手順を次に示します。
- 本装置にログインします。
- pingコマンドを使って通信できない両方の相手との疎通を確認してください。pingコマンドの操作例および実行結果の見方は,「6.3.1 当該宛先アドレスとの通信可否を確認する」を参照してください。
- pingコマンドで通信相手との疎通が確認できなかったときは,さらにpingコマンドを使って本装置に近い装置から順に通信相手に向けて疎通を確認してください。
- pingコマンド実行の結果,障害範囲が隣接装置の場合は「(5) 隣接装置とのARP解決情報の確認」に,リモート先の装置の場合は「(6) ユニキャストルーティング情報の確認」に進んでください。
(4) 障害範囲の特定(お客様の端末装置から実施する場合)
本装置にログインできない環境にある場合に,お客様の端末装置から通信相手とのどこの部分で障害が発生しているか障害範囲を特定する手順を次に示します。
- お客様の端末装置にping機能があることを確認してください。
- ping機能をお使いになり,お客様の端末装置と通信相手との疎通ができるか確認してください。
- ping機能で通信相手との疎通が確認できなかったときは,さらにpingコマンドを使ってお客様の端末装置に近い装置から順に通信相手に向けて疎通を確認してください。
- ping機能による障害範囲が特定できましたら,障害と考えられる装置が本装置である場合は本装置にログインしていただき,障害解析フローに従って障害原因の調査を行ってください。
(5) 隣接装置とのARP解決情報の確認
pingコマンドの実行結果によって隣接装置との疎通が不可の場合は,ARPによるアドレスが解決していないことが考えられます。本装置と隣接装置間のアドレス解決状態を確認する手順を次に示します。
- 本装置にログインします。
- show ip arpコマンドを使って隣接装置間とのアドレス解決状態(ARPエントリ情報の有無)を確認してください。
- 隣接装置間とのアドレスが解決している(ARPエントリ情報あり)場合は,「(6) ユニキャストルーティング情報の確認」に進んでください。
- 隣接装置間とのアドレスが解決していない(ARPエントリ情報なし)場合は,隣接装置と本装置のIPネットワーク設定が一致しているかを確認してください。
(6) ユニキャストルーティング情報の確認
隣接装置とのアドレスが解決しているにもかかわらず通信ができない場合や,IPv4ユニキャスト通信で通信相手との途中の経路で疎通が不可となる,または通信相手までの経路がおかしいなどの場合は,本装置が取得した経路情報を確認する必要があります。確認手順を次に示します。
- 本装置にログインします。
- show ip routeコマンドを実行して,本装置が取得した経路情報を確認してください。
- 本装置が取得した経路情報の中に,通信障害となっているインタフェースの経路情報がない場合やネクストホップアドレスが不正の場合は「8.6 IPv4ユニキャストルーティングの通信障害」に進んでください。
- 本装置が取得した経路情報の中に,通信障害となっているインタフェースの経路情報がある場合は,通信不可のインタフェースに設定している次の機能に問題があると考えられます。該当する機能の調査を行ってください。
- フィルタリング/QoS機能
「(7) フィルタリング/QoS設定情報の確認」に進んでください。
- ポリシールーティング機能
「(9) ポリシールーティング設定情報の確認」に進んでください。
(7) フィルタリング/QoS設定情報の確認
本装置において,インタフェースがup状態で,かつ経路情報も正しく設定されているにもかかわらず通信ができない場合は,フィルタリング機能により特定のパケットが廃棄されているか,あるいはQoS機能の帯域制御,出力優先制御,または廃棄制御によりパケットが廃棄されている可能性があります。
したがって,スタートアップコンフィグレーションファイルのフィルタリング機能およびQoS機能の設定条件が正しいか,システム構築において帯域制御ならびに優先・廃棄制御がシステム運用において適切であるか見直してください。また,フィルタリング機能およびQoS機能によって本装置内でパケットが廃棄されている場合の,廃棄個所の特定方法の手順を次に示します。
(a) フィルタリング機能によるパケット廃棄の確認方法
- 本装置にログインします。
- show filter-flowコマンドを使って入出力インタフェースでパケットが廃棄されていないか確認してください。
- [確認例]
- 通信できないパケットの入力インタフェース名称がtokyo1,送信元IPアドレスが170.10.11.10の場合,フィルタリング機能で廃棄されているかどうかを確認します。
- 本装置にログインします。
- 「show filter-flow interface tokyo1 detail」と入力します。
> show filter-flow interface tokyo1 detail <Filter IP List No.>: 1 Using Interface:tokyo1/in ip source: 170.10.11.21 - 170.10.11.30 ip destination: any protocol:6(tcp) port source:80 ack check off syn check off forward packets : 461 <Filter IP List No.>: 2 Using Interface:tokyo1/in ip source: any ip destination: any protocol:ip drop packets : 50121 >- 入力インタフェース名称がtokyo1の<Filter IP List No>を確認します。
上記例では,<Filter IP List No.>:1,2が該当します。
- 3.で確認したフロー条件と通信できないパケットの内容を比較して,一致する<Filter IP List No.>の動作が廃棄になっていないか確認します。
本例ではパケットの送信元IPアドレスが170.10.11.10なので<Filter IP List No.>:2と一致します。<Filter IP List No.>:2の動作は廃棄なので,入力インタフェースのフィルタリング機能で廃棄されている可能性があります。
(b) QoS機能の帯域制御によるパケット廃棄の確認方法
- 本装置にログインします。
- show qos ip-flowコマンドを使って入出力インタフェースでパケットがQoS機能の帯域制御によって廃棄されていないか確認してください。
- [確認例]
- 通信できないパケットの入力インタフェース名称がtokyo1,送信元IPアドレスが170.10.11.21の場合,QoS機能の帯域制御によって廃棄されているかどうかを確認します。
- 本装置にログインします。
- 「show qos ip-flow interface tokyo1 detail」と入力します。
>show qos ip-flow interface tokyo1 detail <QoS IP List No.>: 1 max rate normal Using Interface:tokyo1/in ip source: 170.10.11.21 - 170.10.11.30 ip destination: any protocol:ip burst size:3000Byte packets of 100000kbps and under(priority3 discard4) : 7021 packets of 100000kbps over (drop) : 729 <QoS IP List No.>: 2 Using Interface: tokyo1/out ip source: any ip destination: any protocol:6(tcp) port destination:20 - 21 ack check off syn check off hit packets (priority8 discard4) : 11568793 >- 入力インタフェース名称がtokyo1の<QoS IP List No.>を確認します。
上記例では<QoS IP List No.>:1が該当します。
- 3.で確認したフロー条件と通信できないパケットの内容を比較して,一致する<QoS IP List No.>の動作が廃棄になっていないか確認します。
本例ではパケットの送信元IPアドレスが170.10.11.21なので,<QoS IP List No.>:1と一致します。<QoS IP List No.>:1の契約帯域違反時(packets of 1000000bps over (drop))の動作は廃棄なので,入力インタフェースのQoS機能の帯域制御で廃棄されている可能性があります。
(c) QoS機能のキュー制御によるパケット廃棄の確認方法
- 本装置にログインします。
- show qos queueingコマンドを使って出力インタフェースでパケットがQoS機能のキュー制御によって廃棄されていないか確認してください。
- [確認例]
- QoS機能のキュー制御によって廃棄されているかどうかを確認します。通信できないパケットの出力インタフェースがNIF番号0,Line番号1,使用するキュー番号が4(Priority 4)の場合での確認方法を以下に示します。
- 本装置にログインします。
- 「show qos queueing nif 0 line 1」と入力します。
> show qos queueing nif 0 line 1 NIF0/Line1 (outbound), Rate_limit=1000kbps, Qmode=Priority Max_Queue=8 : : Priority(Queue)=4, Qlen=1, Maximum_Qlen=2, Limit_Qlen=127 Discard send_pkt discard_pkt send_byte discard_byte 1 6533 19 533.0k 10.0k 2 2564 1581 125.5M 20.0k 3 2256877 1235 5433.2M 10.0k 4 568788 2548 255.0k 20.0k total 2834762 5383 5559.6M 60.0k : : >- Priority 4での廃棄したパケット数(discard_pkt)のtotal値が1以上の場合,キュー制御によってパケットが廃棄されています。本例では5383なので,キュー制御によってパケットが廃棄されています。
(8) Nullインタフェース設定情報の確認
特定のネットワーク宛または特定の端末宛の通信をNullインタフェースに向けて制限しているにもかかわらず,パケットが廃棄されない場合は,Nullインタフェースの設定内容に誤りがある可能性があります。次の手順でNullインタフェースの設定内容が正しいか確認してください。
- show ip interface ipv4-unicastコマンドを使いNullインタフェースの状態を確認します。NullインタフェースがUPしているか確認してください。
- スタートアップコンフィグレーションファイルでNullインタフェースが定義されているか確認します。
- show ip routeコマンドで経路情報を確認します。
コンフィグレーションコマンドstaticで定義した経路情報の設定内容が正しいかどうかを確認してください。
- パケットが廃棄されているか確認します。
show ip interfaceコマンドを使ってNullインタフェースでパケットが廃棄されているか確認してください。
(9) ポリシールーティング設定情報の確認
本装置において物理的障害は発生してなく,経路情報も正しく設定されているにもかかわらず通信ができない場合は,ポリシールーティング機能の出力先インタフェースに障害が発生しているためにパケットが廃棄されている可能性が考えられます。
したがって,次の手順でポリシールーティングの現在使用されている出力先インタフェースの状態を確認してください。
(a) ポリシールーティング機能による出力先インタフェースの確認方法
- 本装置にログインします。
- show ip policyコマンドを使って入力インタフェースのポリシールーティング設定内容と,現在使用されている出力先インタフェースの状態を確認します。
- [確認例]
- 通信できないパケットの入力インタフェースがtokyo,送信元IPアドレスが200.1.4.5の場合,ポリシールーティング機能で使用されている出力先を確認します。
- 本装置にログインします。
- 「show ip policy interface tokyo」と入力します。
> show ip policy interface tokyo <Interface Name> <Filter List No> tokyo 1,2 >- 入力インタフェースtokyoで使用されている条件番号を確認します。
上記例では,<Filter List No.>:1,2が該当します。
- 3.で確認した条件の詳細を表示します。「show ip local policy interface tokyo 1 2」と入力します。
> show ip local policy interface tokyo 1 2 <Interface Name>: tokyo <Filter List No.> 1 forward packets protocol : ip ip_source : 200.1.4.0 - 200.1.4.255 ip_destination : 200.1.7.0 - 200.1.8.255 current policy route Policy Group Name route1 Output Interface tokyo3 Next Hop IP address 200.1.10.1 <Interface Name>: tokyo <Filter List No.> 2 forward packets protocol : ip ip_source : 200.1.5.0 - 200.1.5.255 ip_destination : 200.1.19.0 - 200.1.20.255 current policy route Policy Group Name route2 Output Interface yokohama Next Hop IP address 200.1.50.2 >- 各条件の内容と条件とその際の出力先を確認します。
通信できないパケットの内容を比較して,一致する条件のポリシールーティンググループ名称を確認します。
- 採用されているポリシーグループの状態を確認します。「show ip cache policy route1」と入力します。
> show ip cache policy route1 <Policy Group Name>: route1 priority Interface Name status Nexthop 1 tokyo1 Down 200. 1. 1. 2 2 tokyo1 Down 200. 1. 2. 2 3 tokyo2 Down 200. 1. 8. 3 *> 4 tokyo3 Down 200. 1. 10. 1 default >- 出力先インタフェースが障害により出力できないためパケットが廃棄されています。スタートアップコンフィグレーションファイルのポリシー情報の設定を見直すと共に,「8.4 ネットワークインタフェースの通信障害」に従ってください。
なお,show ip cache policyコマンド実行時,使用中の経路がない(経路の先頭に*>の表示がない)場合も,出力先インタフェースの障害によりパケットが廃棄されていることを表します。
(10) Tag-VLAN連携設定情報の確認
本装置に,IPインタフェース情報,経路情報が正しく設定されているにもかかわらず通信ができない場合は,Tag-VLAN連携情報の設定が誤っている(またはされていない)ために,パケットが廃棄されている可能性が考えられます。本装置のTag-VLAN連携設定情報を確認する手順を次に示します。
- 本装置にログインします。
- show interfacesコマンドを使用してTag-VLAN連携設定情報(Tag-VLAN連携機能の使用の有無,Tag-VLAN連携回線情報およびVLAN ID)を確認してください。
上記コマンドでTag-VLAN連携の設定が正しいと確認できた場合は,本装置に関するTag-VLAN連携の設定に問題はありません。接続装置(LAN Switchなど)の設定に問題(VLAN設定をしていない,VLAN IDが一致していない)がある可能性があります。接続装置の設定情報を確認してください。
Copyright (c) 2005, 2011, ALAXALA Networks Corporation. All rights reserved.