Cisco ASR 9000 シリーズ アグリゲーション サービス ルータ 機能トラブルシューティング モジュール

アクセス コントロール リスト（ACL）

Access Control List（ACL; アクセス コントロール リスト）は、パケットのフィルタリング、分析または転送の対象となるトラフィック タイプの選択、または何らかの方法で影響を受けるトラフィック タイプの選択に使用されます。Access Control Entry（ACE; アクセス コントロール エントリ）は、ACL に含まれる個々の permit（許可）文または deny（拒否）文です。各 ACE には、アクション要素（「許可」または「拒否）と、送信元アドレス、宛先アドレス、プロトコル、プロトコル固有のパラメータなどの基準に基づくフィルタ要素が含まれます。このセクションの内容は次のとおりです。

• 「show および debug コマンドの使用方法」

• 「ACL メッセージが表示されない」

• 「フラグメント パケットが受け入れられる」

• 「出力カウンタが正しくない、または機能しない」

• 「ACL のインターフェイスへのバインドが拒否される」

• 「単一の ACE で多数の TCAM を使用する」

• 「ACL で可変の TCAM スペースを使用する」

• 「L3 インターフェイスのイーサネット サービスが機能しない」

• 「イーサネット サービスに関する ACL ログが機能しない」

• 「イーサネット サービス ACL のインターフェイスへのバインドが拒否される」

• 「ACL の変更時に TCAM が枯渇する」

• 「ACL を削除できない」

• 「DF ビットがサポートされていない」

• 「最大 ACL 数の制限に達した」

• 「ACL 内のサポートされていない組み合わせ」

• 「統計情報カウンタがない」

• 「TCAM のリソースが枯渇した」

show および debug コマンドの使用方法

手順概要

1. show access-lists ipv4 [rp-access [hardware {ingress | egress} {sequence-number | location node-id | summary [rp-access] | maximum [detail] [usage { pfilter location node-id }]

2. debug feature-ea-dll {all | error | info | resmgr | vmr}

詳細手順

ACL メッセージが表示されない

ステップ 1 ACL の ACE を表示します。

RP/0/RSP0/CPU0:router# show access-lists ipv4

ステップ 2 ACL の TCAM エントリを表示します。

RP/0/RSP0/CPU0:router# show access-lists ipv4 hardware {ingress | egress} detail ...

ステップ 3 ACL の TCAM エントリを表示します。

ステップ 4 ACL でログを設定します。

RP/0/RSP0/CPU0:router# ipv4 access-lists log-update threshold

回避策

fragment フラグを持つエントリが存在しない場合は、すべてのインターフェイスからアクセスリストを削除し、fragment フラグを持つエントリを再適用します。

（注） フラグメント パケットは、fragment キーワードのない拒否 ACE とは一致しません。フラグメント パケットを拒否する ACE には、fragment キーワードを明示的に追加してください。

フラグメント パケットが受け入れられる

ステップ 1 ACL の ACE を表示します。

RP/0/RSP0/CPU0:router# show access-list ipv4

ステップ 2 IPv4 カウンタ（フラグメントなど）を表示します。

RP/0/RSP0/CPU0:router# show ipv4 traffic

ステップ 3 ACL の TCAM エントリを表示します。

ステップ 4 RP/0/RSP0/CPU0:router# show access-list ipv4 hardware {ingress | egress} location

ステップ 5 ACE に fragment キーワードが含まれるようにします。

RP/0/RSP0/CPU0:router# deny ipv4 any any fragments

ステップ 6 デバイスで受信されたフラグメント パケット数をチェックします。

ステップ 7 TCAM エントリを表示します。

回避策

フラグメント パケットは、fragment キーワードのない拒否 ACE とは一致しません。fragment フラグを持つエントリが存在しない場合は、次の手順を実行します。

ステップ 1 すべてのインターフェイスから ACL を削除します。

ステップ 2 フラグメント パケットを拒否する ACE に fragment キーワードを明示的に追加します。

ステップ 3 この ACL をすべてのインターフェイスに再適用します。

出力カウンタが正しくない、または機能しない

ステップ 1 既知のルートを表示します。

RP/0/RSP0/CPU0:router# show route ipv4

ステップ 2 ARP テーブルのエントリを表示します。ネクストホップを探します。

RP/0/RSP0/CPU0:router# show arp

ステップ 3 ACL の TCAM エントリを表示します。

RP/0/RSP0/CPU0:router# show access-list ipv4 hardware

回避策

ステップ 1 ルートが欠落している場合、または ARP が不完全な場合は、 no shut コマンドを使用して回復します。

ステップ 2 UIDB テーブルまたは TCAM エントリが正しくない場合は、すべてのインターフェイスから ACL を削除して再適用します。

ACL のインターフェイスへのバインドが拒否される

設定が適用されたときに発生したエラーを表示します。

RP/0/RSP0/CPU0:router# show configuration failed

回避策

エラーが TCAM スペースに関連する場合は、ACL から ACE を削除します。TCAM エントリの数は ACL あたり 64 個に制限されています。

単一の ACE で多数の TCAM を使用する

ステップ 1 ACL の ACE を表示します。

RP/0/RSP0/CPU0:router# show access-list ipv4

ステップ 2 ACE に含まれる範囲の数をチェックします。

ACL で可変の TCAM スペースを使用する

Pre-Internal Forwarding Information Base（Pre-IFIB; プレ内部転送情報ベース）ハードウェア統計情報エントリを表示します。

RP/0/RSP0/CPU0:router# show lpts pifib brief

L3 インターフェイスのイーサネット サービスが機能しない

イーサネット サービスは、L3 インターフェイスではサポートされていません。

イーサネット サービスに関する ACL ログが機能しない

イーサネット サービスのロギングはサポートされていません。

イーサネット サービス ACL のインターフェイスへのバインドが拒否される

ステップ 1 設定が適用されたときに発生したエラーを表示します。

RP/0/RSP0/CPU0:router# show configuration failed

ステップ 2 ACL の ACE を表示します。

RP/0/RSP0/CPU0:router# show access-list ipv4

ステップ 3 pfilter_ea のトレース ログを表示します。

回避策

ステップ 1 ACL のフィールドがサポートされていない場合は、そのフィールドを ACE から削除します。

ステップ 2 TCAM スペースが枯渇した場合は、その ACL の ACE を削除します。

ステップ 3 ACL に含まれる範囲を減らします。

ACL の変更時に TCAM が枯渇する

該当する ACL に対して設定された ACE を表示します。

RP/0/RSP0/CPU0:router# show access-list {ethernet-service/ipv4}

回避策

新しい ACL を適用する前に、古い ACL を削除します。

ACL を削除できない

ステップ 2 該当する ACL を使用しているインターフェイスを表示します。

RP/0/RSP0/CPU0:router# show access-list {ethernet-services | ipv4} usage pfilter

ステップ 3 IPv4 トレース情報を表示します。

RP/0/RSP0/CPU0:router# show access-list ipv4 trace

ステップ 4 イーサネット サービスのトレースを表示します。

RP/0/RSP0/CPU0:router# show access-list ethernet-services trace

DF ビットがサポートされていない

現在のリリースでは、Do not Fragment（DF）ビットは一致基準としてサポートされていません。

最大 ACL 数の制限に達した

ACL ID の最大数は、NP あたり 2048 です。ACL の名前と方向に関する TCAM エントリは、インターフェイス間で共有されます。

ACL 内のサポートされていない組み合わせ

アクセスリストにサポートされていないフィールドの組み合わせが指定されている場合があります。アクセスリストに指定されている組み合わせが現在サポートされていることを確認してください。現在のリリースでサポートされている組み合わせは次のとおりです。

• VLAN OUT + L2 PROTO + MAC SA + MAC DA

• VLAN OUT + VLAN IN + MAC SA + MAC DA

• VLAN OUT + VLAN IN + L2 PROTO + MAC DA

統計情報カウンタがない

統計情報カウンタは、現在のリリースではサポートされていません。

TCAM のリソースが枯渇した

「TCAMs Out of Resources」メッセージは、使用可能な数を超える TCAM エントリをプロビジョニングしようとしたことを意味します。

Quality of Service（QoS）

システムでは、次の種類の QoS が提供されます。

• ジッタ、遅延、およびパケット損失を最小限に抑える、音声およびビデオ アプリケーションのマルチレベル プライオリティ スケジューリング

• トラフィック負荷の最も高い時間帯でもすべての階層レイヤ全体にわたって音声とビデオのサービス完全性を確保する、プライオリティ伝達

• Differentiated Service Code Point（DSCP; DiffServ コード ポイント）、MPLS EXP ビット、および IEEE 802.1p IP precedence ビットを使用した、マーキング、ポリシング、スケジューリング、入力/出力による分類

このセクションの内容は次のとおりです。

• 「show および debug コマンドの使用方法」

• 「サービスポリシー設定が拒否される」

• 「パケットが不適切に分類される」

• 「パケットが間違ったキューに格納される」

• 「パケットが不適切にマークされる」

• 「パケットが不適切にポリシングされる」

• 「シェーピングが正しくない」

• 「Weighted Random Early Detection（WRED）が正しくない」

• 「帯域幅が保証されない」

• 「帯域幅比が機能しない」

• 「ポリシーマップまたはクラスマップを変更または削除できない」

• 「クラスマップ ACL を変更または削除できない」

• 「サービスポリシーを削除できない」

• 「QoS EA が再起動した後、show policy-map interface が失敗する」

• 「QoS EA が再起動した後、service-policy config が失敗する」

• 「show policy-map interface で出力エラーが発生する」

• 「サービスポリシーでバンドル メンバが設定されない」

show および debug コマンドの使用方法

手順概要

1. show run policy-map

2. show run classmap

3. show run interface

4. show policy-map interface type interface-name [output | input]

5. show qos interface type interface-name [output | input]

6. show qos-ea interface type interface-name [output | input]

7. show qos-ea km

8. debug qos-ea ?

詳細手順

サービスポリシー設定が拒否される

ステップ 1 サービスポリシー設定が拒否される、またはコミットできない場合は、show configuration failed コマンドを使用してエラー メッセージをチェックします。

ステップ 2 リソースの使用状況が設定値を超えている場合は、チェックポイントの回数を確認します。

RP/0/RSP0/CPU0:router# show qos-ea ha chkpt all info location node-id

ステップ 3 OOR をチェックします。

ステップ 4 使用されているリソースを確認します。

ステップ 5 概要情報を確認します。

RP/0/RSP0/CPU0:router# show qos summary {queue | police | policy}

パケットが不適切に分類される

ステップ 1 パケットが正しいインターフェイスに到着していることを確認します。

ステップ 2 パケットのフィールドが予想したとおりであることを確認します。

ステップ 3 パケット タイプを確認します。

ステップ 4 KM ポリシー情報が UIDB 設定と一致することを確認します。

RP/0/RSP0/CPU0:router# show qos-ea km policy policy info location filename

RP/0/RSP0/CPU0:router# show qos-ea km policy policy vmr interface filename hw detail

ステップ 5 各クラスの VMR エントリを確認します。

RP/0/RSP0/CPU0:router# show qos-ea km policy policy vmr interface filename hw detail

ステップ 6 パケットが実際にどのクラスと一致しているかを確認します。パケットのフィールドが異なるクラスに一致している場合は、NP マイクロコードによってこれをさらにデバッグする必要があります。

RP/0/RSP0/CPU0:router# show policy-map interface filename {output | input} [member filename]

ステップ 7 入力時に L2 入力書き換えの前に QoS ルックアップが実行されているかどうか、および出力時に QoS ルックアップの前に L2 書き換えが実行されていることを確認します。

RP/0/RSP0/CPU0:router# show qos type interface {input | output} location node-id

ステップ 8 RP/0/RSP0/CPU0:router# show run interface type node-id

ステップ 9 RP/0/RSP0/CPU0:router# show run policy-map policy

ステップ 10 RP/0/RSP0/CPU0:router# show run class-map classmap

パケットが間違ったキューに格納される

ステップ 1 RP/0/RSP0/CPU0:router# show qos-ea type interface {input | output} location node-id

ステップ 2 パケットが正しく分類されていることを確認します。

ステップ 3 ハッシュ構造を確認します。

RP/0/RSP0/CPU0:router# show qos-ea type interface {input | output} location node-id

ステップ 4 クラスのハッシュ キーと、クラスのハッシュ結果が正しいキュー ID を持つことを確認します。

パケットが不適切にマークされる

ステップ 1 パケットが正しく分類されていることを確認します。

RP/0/RSP0/CPU0:router# show qos type interface {input | output} location node-id

ステップ 2 RP/0/RSP0/CPU0:router# show qos-ea km policy policy vmr interface filename hw

ステップ 3 RP/0/RSP0/CPU0:router# show qos-ea km policy policy vmr interface filename sw

ステップ 4 RP/0/RSP0/CPU0:router# show policy-map interface filename {input | output} [member filename]

ステップ 5 マーキング値を確認します。

RP/0/RSP0/CPU0:router# show qos type interface {input | output} location node-id

パケットが不適切にポリシングされる

ステップ 1 パケットが正しく分類されていることを確認します。

ステップ 2 ポリサーの CIR/CBS/PIR/PBS が、設定されたサービスポリシーに従って正しく設定されていることを確認します。また、トラフィックがどの程度のレートで到着しているかも確認し、ポリシング レートと照合します。

RP/0/RSP0/CPU0:router# show qos type interface {input | output} location node-id

ステップ 3 クラスのトークン バケットとポリシング ノード インデックスを取得します。

RP/0/RSP0/CPU0:router# show qos-ea type interface {input | output} location node-id

ステップ 4 RP/0/RSP0/CPU0:router# show policy-map interface filename {input | output} [member filename]

シェーピングが正しくない

ステップ 1 パケットが正しく分類されていることを確認します。

RP/0/RSP0/CPU0:router# show qos type interface {input | output} location node-id

ステップ 2 シェーパーの CIR/CBS/PIR/PBS が、設定されたサービスポリシーに従って正しく設定されていることを確認します。シェイプ プロファイル ID とエンティティ ハンドル情報（np、tm、レベル、インデックス、オフセット）を取得します。

RP/0/RSP0/CPU0:router# show qos-ea type interface {input | output} location node-id

ステップ 3 これらが正しく設定されている場合は、ハードウェア内のシェーパー プロファイルを確認します。

ステップ 4 RP/0/RSP0/CPU0:router# show policy-map interface filename {input | output} [member filename]

Weighted Random Early Detection（WRED）が正しくない

ステップ 1 パケットが正しく分類されていることを確認します。

ステップ 2 WRED カーブが正しく設定されていて、各カーブの最小および最大のしきい値が、設定されたサービスポリシーに従った適切な値であるかどうかを確認します。

RP/0/RSP0/CPU0:router# show qos type interface {input | output} location node-id

ステップ 3 WRED プロファイル ID とエンティティ ハンドル情報（np、tm、レベル、インデックス、オフセット）を取得します。

RP/0/RSP0/CPU0:router# show qos-ea type interface {input | output} location node-id

ステップ 4 RP/0/RSP0/CPU0:router# show policy-map interface filename {input | output} [member filename]

帯域幅が保証されない

ステップ 1 パケットが正しく分類されていることを確認します。

ステップ 2 各クラスの重みが、クラス間の帯域幅比に従って正しく設定されているかどうかを確認します。

RP/0/RSP0/CPU0:router# show qos type interface {input | output} location node-id

ステップ 3 RP/0/RSP0/CPU0:router# show run policy-map policy

ステップ 4 正しく設定されている場合は、クラスの WFQ プロファイル ID とエンティティ ハンドル情報（np、tm、レベル、インデックス、オフセット）を取得します。

RP/0/RSP0/CPU0:router# show qos-ea type interface {input | output} location node-id

ステップ 5 RP/0/RSP0/CPU0:router# show policy-map interface filename {input | output} [member filename]

帯域幅比が機能しない

ステップ 1 パケットが正しく分類されていることを確認します。

ステップ 2 RP/0/RSP0/CPU0:router# show run policy-map policy

ステップ 3 各クラスのコミット重みが、クラス間の帯域幅比に従って正しく設定されているかどうかを確認します。また、超過重みが、帯域幅の残りの比率の設定に従って設定されていることも確認します（超過重みの割り当てが超過重みの比率に収まっている必要があります）。

RP/0/RSP0/CPU0:router# show qos type interface {input | output} location node-id

ステップ 4 RP/0/RSP0/CPU0:router# show qos-ea type interface {input | output} location node-id

ステップ 5 RP/0/RSP0/CPU0:router# show policy-map interface filename {input | output} [member filename]

ステップ 6 クラスの WFQ プロファイル ID とエンティティ ハンドル情報（np、tm、レベル、インデックス、オフセット）を取得します。

RP/0/RSP0/CPU0:router# show qos-ea type interface {input | output} location node-id

ステップ 7 コミット重みと超過重みが正しい場合は、次の手順を実行します。

a. 各クラスのキュー サイズをチェックします。

b. キュー サイズを増やします。

ポリシーマップまたはクラスマップを変更または削除できない

ステップ 1 ポリシーがインターフェイスに適用されていることを確認します。

RP/0/RSP0/CPU0:router# show running-config

ステップ 2 インターフェイス上のサービスポリシーを削除します。

ステップ 3 ポリシーマップを変更します。

クラスマップ ACL を変更または削除できない

• show config failed

• show running-config

ステップ 1 該当する ACL がクラスマップの match 文の一部であることを確認します。

ステップ 2 そのクラスマップが、インターフェイスに適用されているポリシーマップの一部であることを確認します。

ステップ 3 ポリシーマップがインターフェイスに適用されている場合、ACL の変更または削除は許可されません。

ステップ 4 このポリシーマップのサービスポリシー設定をすべて削除してから、ACL を変更します。

サービスポリシーを削除できない

ステップ 1 RP/0/RSP0/CPU0:router# show config failed

ステップ 2 qos_ma_ea プロセスを再起動します。

QoS EA が再起動した後、show policy-map interface が失敗する

• show running-config

• show qos-ea ha chkpt all info location node-id

• show qos-ea ha chkpt if-qos all location node-id

ステップ 1 QoS EA の状態が in_sync（state = 2）であるかどうかを確認します。

RP/0/RSP0/CPU0:router# show qos-ea ha state location node-id

ステップ 2 エラーがない場合は、次の手順を実行します。

a. RP/0/RSP0/CPU0:router# debug generic

b. 失敗するコマンドを実行して、デバッグを収集します。

QoS EA が再起動した後、service-policy config が失敗する

ステップ 1 QoS EA の状態が in_sync（state = 2）であるかどうかを確認します。

RP/0/RSP0/CPU0:router# show qos-ea ha state location node-id

ステップ 2 エラーがない場合は、次の手順を実行します。

a. RP/0/RSP0/CPU0:router# debug generic

b. 失敗するコマンドを実行して、デバッグを収集します。

show policy-map interface で出力エラーが発生する

バンドルの場合は、メンバ インターフェイスを指定します。バンドルインターフェイスのポリシー情報は、現在のリリースでは使用できません。

• show policy-map interface {output | input} member

• show {qos | qos-ea} interface {output | input} location node-id

サービスポリシーでバンドル メンバが設定されない

バンドルの場合は、メンバ インターフェイスを指定します。バンドルインターフェイスのポリシー情報は、現在のリリースでは使用できません。

• show policy-map interface {output | input} member

• show {qos | qos-ea} interface {output | input} location node-id

双方向フォワーディング検出（BFD）

Bidirectional Forwarding Detection（BFD; 双方向フォワーディング検出）は、すべてのメディア タイプ、カプセル化、トポロジ、およびルーティング プロトコルにおいてフォワーディング パスの障害検出を迅速化するために設計された検出プロトコルです。このセクションの内容は次のとおりです。

• 「show および debug コマンドの使用方法」

• 「BFD セッションがダウン状態になる」

• 「BFD セッションのフラップが起こる」

• 「隣接ルータで BFD セッションがダウンしている」

• 「BFD セッションが LC で作成されない」

show および debug コマンドの使用方法

手順概要

1. show bfd [ipv4 | all] [location node-id]

2. show bfd client [detail]

3. show bfd [ipv4 | all] session [detail | interface ifname [ destination address ]] [[agent] location node-id]]

4. show bfd counters packet [ interface ifname ] location node-id

5. show bfd trace {adjacency | error | fsm | packet} [filter {destination <address> | interface ifname}] [location node-id]

6. show tech-support routing bfd {terminal [page] | file send-to [background] [compressed | uncompressed]}

詳細手順

BFD セッションがダウン状態になる

ステップ 1 IP の接続性を確認します。IP パケットの損失がないことを確認します。

RP/0/RSP0/CPU0:router# ping local-remote-address

ステップ 2 ルータとリモート デバイスに次のパラメータが設定されていることを確認します。

a. それぞれがサポートできる BFD セッションの数

b. ポリシング レートをサポートするためのタイマー

BFD セッションのフラップが起こる

次の手順に従って、各種 BFD パラメータをチェックします。次のセクションも参照してください。

• 「隣接ルータで BFD セッションがダウンしている」

• 「BFD セッションが LC で作成されない」

ステップ 1 IP の接続性を確認します。

RP/0/RSP0/CPU0:router# ping local-IP-address

ステップ 2 入力カウンタと出力カウンタを確認します。

RP/0/RSP0/CPU0:router# show interface

ステップ 3 セッションの詳細情報を表示します。

RP/0/RSP0/CPU0:router# show bfd session detail

ステップ 4 セッションのパケット カウンタを表示します。

RP/0/RSP0/CPU0:router# show bfd counter

ステップ 5 SPP カウンタを表示します。

RP/0/RSP0/CPU0:router# show spp node

ステップ 6 リソースの使用状況を表示します。

RP/0/RSP0/CPU0:router# monitor process

ステップ 7 IP の接続性を表示します。IP パケットの損失がないことを確認します。

RP/0/RSP0/CPU0:router# ping local remote address

次のメッセージが表示された場合、BFD フラップの原因はアプリケーション フラップです。

ステップ 8 SPP でパケットが失われていないことを確認します。

RP/0/RSP0/CPU0:router# show spp node location

ステップ 9 LC の CPU とメモリの使用状況をチェックします。

RP/0/RSP0/CPU0:router# monitor processes location

ステップ 10 ローカル インターフェイスのカウンタをチェックします。

RP/0/RSP0/CPU0:router# show interfaces type interface-name

ステップ 11 インターフェイスに適用されている QoS ポリシーをチェックします。

RP/0/RSP0/CPU0:router# show policy-map interface

ステップ 12 リモート側でステップ 1 ～ 11 を繰り返します。

ローカル エコーの障害が原因で BFD セッションのフラップが起こる

BFD セッションのフラップは、ルータがエコー障害を検出したためにローカルで起こる場合があります。

LC の CPU 使用率を調べます。
RP/0/RSP0/CPU0:router# monitor process location

LC CPU の SPP プロセスを調べて、BFD エコー パケットで生じた遅延を確認します。
RP/0/RSP0/CPU0:router# show bfd trace performance reverse location

BFD エコー パケットの損失を除外します。 show bfd counters packet location

SPP プロセスの再起動が原因で BFD セッションのフラップが起こる

BFD 障害検出が 1 秒以内に設定されている場合、LC で SPP プロセスが再起動すると、BFD セッションのフラップが起こります。

隣接ルータで BFD セッションがダウンしている

隣接ルータは、BFD がダウンしていることを知らせるために、次のメッセージを送信します。

BFD セッションが LC で作成されない

1 つの LC で許可される BFD セッションの数は 1024 です。1024 を超える BFD セッションを設定すると、ランダムな BFD セッションが作成されなくなる場合があります。

接続障害管理（CFM）

Connectivity Fault Management（CFM; 接続障害管理）は、リモート ネットワークの障害をネットワーク越しにエンドツーエンドで監視、検出し、診断します。これには、キープアライブと MAC ベースの ping およびトレースルートが使用されます。このセクションの内容は次のとおりです。

• 「show および debug コマンドの使用方法」

• 「MEP に CCM がない」

• 「上位レベルのパケットが下位レベルの MEP に送信される」

• 「上位レベルのパケットが下位レベルの MEP に送信されたときにデバッグ メッセージが生成されない」

• 「MEP で CCM がディセーブルになっており、リモート/ピア MEP がその影響を受ける」

• 「CFM の ping およびトレースルートの結果が「not found」になる」

• 「ドロップされた CFM PDU」

• 「CFM の ping でシーケンス エラーが表示される」

• 「CFM の ping でシーケンス エラーが表示される」

show および debug コマンドの使用方法

手順概要

1. debug ethernet cfm platform

2. debug ethernet oam platform

3. show spp node

4. show spp client

詳細手順

MEP に CCM がない

ステップ 1 設定された MEP と MIP を表示します。

RP/0/RSP0/CPU0:router# show ethernet cfm local main

ステップ 2 MEP ローカル ノードに関する情報と CCM 統計情報を表示します。

RP/0/RSP0/CPU0:router# show ethernet cfm location mep
RP/0/RSP0/CPU0:router# show ethernet cfm peer mep

ステップ 3 特定の LC CFM インスタンスによって示されるリモート MEP を表示します。CCM が受信されていない場合、ピアは表示されません。

ステップ 4 SPP によって認識された CFM SID 統計情報を表示します。

RP/0/RSP0/CPU0:router# show spp sid stats

ステップ 5 CFM PI によって認識されたパケットを表示します。すべてのオプションをイネーブルにします。パケットがドロップ、転送、または処理された場合、出力が表示されます。

RP/0/RSP0/CPU0:router# debug ethernet cfm packet pack ccm

ステップ 6 SPP ドロップを表示します。

RP/0/RSP0/CPU0:router# show spp client location 0/2/cpu0

上位レベルのパケットが下位レベルの MEP に送信される

設定されたしきい値を超える上位レベルの CFM パケットは、NP によって転送されます。show interface コマンドで表示されるパケット数の値は、通常は受信パケットに一致します。

• show interface ：インターフェイスの統計情報を表示します。

上位レベルのパケットが下位レベルの MEP に送信されたときにデバッグ メッセージが生成されない

ステップ 1 設定された MEP と MIP を表示します。

RP/0/RSP0/CPU0:router# show ethernet cfm local main

ステップ 2 MEP ローカル ノードに関する情報と CCM 統計情報を表示します。

RP/0/RSP0/CPU0:router# show ethernet cfm location mep

ステップ 3 特定の LC CFM インスタンスによって示されるリモート MEP を表示します。CCM が受信されていない場合、ピアは表示されません。

RP/0/RSP0/CPU0:router# show ethernet cfm peer mep

ステップ 4 SPP によって認識された CFM SID 統計情報を表示します。

RP/0/RSP0/CPU0:router# show spp sid stats

ステップ 5 CFM PI によって認識されたパケットを表示します。すべてのオプションをイネーブルにします。パケットがドロップ、転送、または処理された場合、出力が表示されます。

RP/0/RSP0/CPU0:router# debug ethernet cfm packet pack ccm

ステップ 6 SPP ドロップを表示します。

RP/0/RSP0/CPU0:router# show spp client location 0/2/cpu0

MEP で CCM がディセーブルになっており、リモート/ピア MEP がその影響を受ける

ステップ 1 設定された MEP と MIP を表示します。

RP/0/RSP0/CPU0:router# show ethernet cfm local main

ステップ 2 MEP ローカル ノードに関する情報と CCM 統計情報を表示します。

RP/0/RSP0/CPU0:router# show ethernet cfm location mep

ステップ 3 特定の LC CFM インスタンスによって示されるリモート MEP を表示します。CCM が受信されていない場合、ピアは表示されません。

RP/0/RSP0/CPU0:router# show ethernet cfm peer mep

ステップ 4 SPP によって認識された CFM SID 統計情報を表示します。

RP/0/RSP0/CPU0:router# show spp sid stats

ステップ 5 CFM PI によって認識されたパケットを表示します。すべてのオプションをイネーブルにします。パケットがドロップ、転送、または処理された場合、出力が表示されます。

RP/0/RSP0/CPU0:router# debug ethernet cfm packet pack ccm

CFM の ping およびトレースルートの結果が「not found」になる

ステップ 1 すべての CFM グローバル設定を表示します。

RP/0/RSP0/CPU0:router# show run ethernet cfm

ステップ 2 ローカルの MEP とその CCM 統計情報を表示します。

RP/0/RSP0/CPU0:router# show ethernet cfm location main

ステップ 3 ピア MEP から受信された CFM CCM を表示します。

RP/0/RSP0/CPU0:router# show ethernet cfm peer meps

ステップ 4 CFM の接続性を確認します。

RP/0/RSP0/CPU0:router# ping ethernet cfm

ステップ 5 CFM のトレースを開始します。

RP/0/RSP0/CPU0:router# trace ethernet cfm

ドロップされた CFM PDU

ステップ 1 インターフェイスあたりの CFM PDU の統計情報を表示します。

RP/0/RSP0/CPU0:router# show ethernet cfm interfaces statistics

ステップ 2 MST ステータスを表示します。

RP/0/RSP0/CPU0:router# show spanning-tree mst mstp

ステップ 3 すべてのローカル MEP によって認識されたピア MEP を表示します。

RP/0/RSP0/CPU0:router# show ethernet cfm peer meps

ステップ 4 MEP または MIP が設定されたインターフェイス上での STP ステータスをチェックします。STP ブロック ポート上の MEP から発信された CFM PDU は転送されますが、MIP で転送される PDU は STP ポートの状態に従います。これは、STP がブロックされているポートで MIP が設定されている場合、CFM PDU はその MIP でドロップされることを意味します。

ステップ 5 STP 状態と CFM ピアの MEP ステータスを表示します。

RP/0/RSP0/CPU0:router# show spanning-tree mst mstp

ステップ 6 パケットのデバッグを有効にして、転送されたパケットが MIP でドロップされることを確認します。

RP/0/RSP0/CPU0:router# debug ethernet cfm pack rec dropped int gig

CFM の ping でシーケンス エラーが表示される

ステップ 1 CFM の接続性を表示します。

RP/0/RSP0/CPU0:router# ping ethernet cfm

Dynamic Host Configuration Protocol（DHCP）スヌーピング

DHCP スヌーピングは DHCP のセキュリティ機能で、信頼されない DHCP メッセージをフィルタリングし、DHCP スヌーピングのバインディング テーブルを構築、維持することによってセキュリティを提供します。信頼されないメッセージとは、ネットワークまたはファイアウォールの外部から受信され、ネットワーク内でトラフィック攻撃を引き起こす可能性のあるメッセージのことです。ここでは、次のコマンドについて説明します。

• 「show コマンド」

• 「trace コマンド」

• 「syslog コマンド」

• 「tech-support コマンド」

• 「アクション コマンド」

• 「L2VPN コマンド」

• 「L2Snoop コマンド」

• 「L2Snoop コマンド」

• 「インターフェイス コントローラ コマンド」

show コマンド

DHCP アプリケーションは RSP で実行されます。DHCP アプリケーションには、アプリケーションの設定状態、DHCP クライアントの状態、および DHCP パケットの統計情報を表示する EXEC モード CLI show コマンドがいくつかあります。

• show dhcp ipv4 snoop binding ：DHCP クライアントの状態を表形式で表示します。

• show dhcp ipv4 snoop binding mac-address macaddress ：指定した MAC アドレスを持つ DHCP クライアントの詳細な状態を表示します。

• show dhcp ipv4 snoop binding summary ：DHCP クライアントの総数を表示します。

• show dhcp ipv4 snoop profile ：DHCP スヌープ プロファイルの一覧を表示します。

• show dhcp ipv4 snoop profile name name ：特定の DHCP スヌープ プロファイルの詳細を表示します。

• show dhcp ipv4 snoop statistics ：DHCP スヌープの Rx パケット、Tx パケット、およびドロップ パケットの総計をブリッジ ドメインごとに表示します。

• show dhcp ipv4 snoop statistics bridge-domain name ：特定のブリッジ ドメインにおける DHCP スヌープの Rx パケット、Tx パケット、およびドロップ パケットの詳細をメッセージ タイプごとに表示します。

trace コマンド

DHCP アプリケーションには 1200 以上のトレース ログがあります。トレース ログには、DHCP アプリケーションで発生した重要なイベントが記録されます。特定の DHCP クライアントに関連付けられたトレース ログには、そのクライアントの MAC アドレスが含まれます。

• show dhcp ipv4 trace errors ：エラー トレースを表示します。

• show dhcp ipv4 trace events ：イベント トレースを表示します。

• show dhcp ipv4 trace packets ：パケット処理トレースを表示します。

• show dhcp ipv4 trace snoop errors ：DHCP スヌープ機能のエラー トレースを表示します。

• show dhcp ipv4 trace snoop events ：DHCP スヌープ機能のイベント トレースを表示します。

• show dhcp ipv4 trace snoop internal ：DHCP スヌープ機能の内部デバッグ トレースを表示します。

syslog コマンド

DHCP アプリケーションには 1600 以上の syslog ログがあります。これらのログには、DHCP アプリケーションで発生したイベントが記録されます。

• debug dhcp ipv4 errors ：エラー ログを表示します。

• debug dhcp ipv4 events ：イベント ログを表示します。

• debug dhcp ipv4 packets ：パケット処理ログを表示します。

• debug dhcp ipv4 snoop errors ：DHCP スヌープ機能のエラー ログを表示します。

• debug dhcp ipv4 snoop events ：DHCP スヌープ機能のイベント ログを表示します。

• debug dhcp ipv4 snoop internal ：DHCP スヌープ機能の内部デバッグ ログを表示します。

tech-support コマンド

DHCP アプリケーションには、DHCP CLI コマンドのグループを呼び出す tech-support コマンドが 4 つ用意されています。tech-support コマンドは、デバッグの際に DHCP アプリケーションの情報を得るために使用します。

• show tech-support dhcp ipv4 snoop file filename

• show tech-support dhcp ipv4 snoop bridge-domain-name bridgedomainname file filename ：指定したブリッジ ドメインの情報を表示します。

• show tech-support dhcp ipv4 snoop profile-name profilename file filename ：指定したプロファイルの情報を表示します。

アクション コマンド

次の CLI コマンドは、DHCP スヌープのバインディング状態をクリアする場合に使用します。

• clear dhcp ipv4 snoop binding ：すべての DHCP スヌープ クライアントのバインディングをクリアします。

• clear dhcp ipv4 snoop binding bridge-domain bridgedomainname ：指定したブリッジ ドメイン内のすべての DHCP スヌープ クライアントのバインディングをクリアします。

• clear dhcp ipv4 snoop binding mac-address macaddress ：指定した MAC アドレスを持つ DHCP スヌープ クライアントのバインディングをクリアします。

L2VPN コマンド

L2VPN AC で DHCP スヌープをイネーブルにするには、DHCP スヌープ プロファイルをブリッジ ドメインまたは AC に関連付けます。DHCP スヌープの trusted 属性は、DHCP スヌープ プロファイル内の trusted 属性の値に従って AC に設定されます。L2VPN CLI コマンドを使用すると、L2VPN ブリッジ ドメインおよび AC の DHCP スヌープ属性の状態が表示されます。

• show l2vpn bridge-domain bd-name bridgename detail ：指定したブリッジ ドメインの L2VPN DHCP スヌープ設定を表示します。

• show l2vpn forwarding interface interface detail location location ：特定のインターフェイスの L2VPN DHCP スヌープ設定を表示します。

L2Snoop コマンド

L2Snoop は、NETIO と RSP 上の DHCP スヌープ アプリケーションとの間で DHCP スヌープ パケットを送受信します。

show l2snoop statistics pcb all ：RSP 上の DHCP スヌープ アプリケーションとの間で送受信された L2SNOOP DHCP パケットの Rx/Tx 統計情報を表示します。

インターフェイス コントローラ コマンド

インターフェイス コントローラは、回線とネットワーク プロセッサとの間で DHCP スヌープ パケットを送受信します。

show controllers interface stats ：回線との間で送受信された DHCP パケットを含むインターフェイス コントローラの統計情報を表示します。

イーサネット フィルタリング（L2PT）

イーサネット フィルタリングは、既存の 2 つのトンネリング プロトコル、シスコの Layer 2 Forwarding（L2F; レイヤ 2 フォワーディング）と Microsoft の Point-to-Point Tunneling Protocol（PPTP）の優れた機能を集約したものです。このセクションの内容は次のとおりです。

パケットがフィルタに基づいて不適切にドロップまたは転送される

ドロップまたは転送されるはずの宛先 MAC を持つパケットが適切にフィルタリングされません。

ステップ 1 RP/0/RSP0/CPU0:router# show version

ステップ 2 L2 ブリッジ/xconnect がアップしていることを確認します。

RP/0/RSP0/CPU0:router# show running-configuration

アップしていない場合は、VPLS/EoMPLS デバッグ ガイドを参照してください。

回避策

ステップ 1 フィルタリング設定をいったん削除し、実行コンフィギュレーションに再度追加してみます。

ステップ 2 ラインカードを再起動します。

イーサネット運用管理および保守（EOAM）管理性

このセクションの内容は次のとおりです。

• 「検出運用ステータスがローカル/リモートで「Reject」になっている」

• 「リンク モニタ イベントが設定どおりにトリガーされない」

• 「CCM が MEP で受信されない」

• 「MEP で CCM がディセーブルになっている」

• 「「not found」エラーが受信される」

• 「ドロップされたパケット」

検出運用ステータスがローカル/リモートで「Reject」になっている

次のコマンドを使用して、require remote パラメータが一方のポートでイネーブルであり、他方ではディセーブルであることを確認します。

• show ethernet oam discovery ：ネイバー検出ステータスを表示します。

• show ethernet oam configuration ：設定を表示します。

require remote loopback support パラメータが一方のポートでイネーブルであり、remote loopback が他方のポートでディセーブルであることを確認します。

リンク モニタ イベントが設定どおりにトリガーされない

次のコマンドを使用して、リンク モニタリング設定を確認し、関連するエラーを表示します。

• show ether-ctrl trace configuration ：イーサネット コントローラのリンク モニタリング設定を表示し、ウィンドウ サイズとしきい値が正しいことを確認します。

CCM が MEP で受信されない

次のコマンドを使用して、MEP 設定を確認します。

• show ethernet cfm local meps ：ローカルの MEP とその CCM 統計情報を表示します。

• show ethernet cfm peer mep ：CCM が受信されていない場合、ピアは表示されません。

• show spp sid stats ：SPP SID 統計情報をチェックし、CFM トラフィックが注入およびパントされていることを確認します。

• show spp client ：RSP から SPP ドロップを探します。

• debug ethernet cfm packets ：すべてのパケット タイプについてデバッグをイネーブルにします。

MEP で CCM がディセーブルになっている

CFM 継続性チェック メッセージは単方向です。ある MEP で CCM がディセーブルになっている場合、ピア MEP では CCM は受信されず、送信元 MEP のエントリがタイムアウトします。

RP/0/RSP0/CPU0:router# show ethernet cfm peer meps

「not found」エラーが受信される

次のコマンドを使用して、CFM 設定の確認、統計情報の表示、および接続性のチェックを行います。

• show run ethernet cfm ：すべての CFM グローバル設定を表示します。

• show ethernet cfm local meps：ローカルの MEP とその CCM 統計情報を表示します。

• show ethernet cfm peer meps ：ピア MEP から受信された CFM CCM を表示します。

• show ethernet cfm ccm-learning-database：CCM データベースのエントリを表示します。

• ping ethernet cfm ：CFM の ping を実行します。

ドロップされたパケット

次のコマンドを使用して、ドロップされたパケットに関する情報を表示します。

• show ethernet cfm interfaces statistics ：CFM PDU のインターフェイスごとのドロップ統計情報を表示します。

• show spanning-tree mst ：STP ステータスをチェックします。

• show ethernet cfm peer meps ：MEP または MIP が設定されたインターフェイス上での CFM ピア MEP ステータスをチェックします。

IGMP スヌーピング（L2 マルチキャスト）

show コマンドの使用

手順概要

1. 正しいトポロジと設定を確認します。

a. show l2vpn bridge-domain summary

b. show igmp snooping bridge-domain

c. show l2vpn bridge-domain bd-name bd-name

d. show l2vpn bridge-domain bd-name bd-name detail

e. show igmp snooping bridge-domain bd-name detail

f. show igmp snooping port bridge-domain bd-name

2. IGMP スヌーピングの制御トラフィックが送受信されていることを確認します。

a. show igmp snooping summary statistics

b. show igmp snooping bridge-domain bd-name detail statistics

c. show igmp snooping port [ if-type if-name] detail statistics

3. IGMP スヌーピングのグループ状態が想定したとおりに作成されていることを確認します。

a. show igmp snooping group

b. show igmp snooping group bridge-domain bd-name

c. show igmp snooping port if-type if-name group [detail]

4. フォワーディング状態が IGMP スヌーピング状態と一致していることを確認します。

a. show l2vpn forwarding bridge-domain [bd-name] mroute ipv4 location lc-name

b. show l2vpn forwarding bridge-domain [bd-name] mroute ipv4 hardware [ingress | egress] location lc-name

詳細手順

デバッグ コマンド

IGMP スヌーピングのデバッグに役立つコマンドを次に示します。

• debug l2snoop {call | error | events | init | packet}

– call： L2snoop 関数呼び出しに関連するデバッグ

– error： L2snoop エラーのデバッグ

– events： L2snoop イベントのデバッグ

– init： L2snoop 初期化のデバッグ

– packet： L2snoop パケット送受信のデコード

トレース コマンド

その他にデバッグに役立つコマンドとして、トレース コマンドがあります。

• show igmp snooping trace

– all： IGMP スヌープ トレースをすべて表示します。

– error： IGMP スヌーピング トレースのエラーを表示します。

– file： 特定のファイル。

– hexdump： トレースを 16 進数で表示します。

– last： 最後の <n> 個のエントリを表示します。

– location： カードの位置。

– packet-error： IGMP スヌーピング トレースのパケット エラーを表示します。

– reverse： 最新のトレースから順に表示します。

– stats： 統計情報を表示します。

– tailf： 新しいトレースが追加されるたびにその内容を表示します。

– unique： 重複したエントリを集約してカウントとともに表示します。

– verbose： 内部デバッグ情報を表示します。

– wrapping： ラッピング エントリを表示します。

リンク バンドル

リンク バンドルは、1 つに束ねて単一のリンクとするポートのグループです。リンク バンドルには次のような利点があります。

• 複数の LC にまたがる複数のリンクによって単一のインターフェイスを構成できます。そのため、単一のリンクで障害が発生しても接続性は失われません。

• バンドルされたインターフェイスでは、バンドルの使用可能なすべてのメンバにわたってトラフィックが転送されるため、帯域幅の可用性が向上します。そのため、バンドル内のリンクの 1 つで障害が発生した場合、トラフィックを別のリンクに移動できます。帯域幅を増減する際、パケット フローが中断することはありません。

このセクションの内容は次のとおりです。

• 「バンドルが起動しない」

• 「バンドル メンバにトラフィックが分散しない」

• 「バンドルでバックプレーンからの MAC アドレスが使用されない」

• 「L3 データ トラフィックが流れない」

• 「バンドル上での ping が失敗する」

• 「L3 パケットがバンドル上で同期しない」

• 「L2 トラフィックが流れない」

• 「バンドル上でのロード バランシング」

• 「バンドルの統計情報」

バンドルが起動しない

ステップ 1 バンドルがアップしていることを確認します。

RP/0/RSP0/CPU0:router# show interface bundle-ether bundle-id

ステップ 2 メンバ ポートが「shutdown」でないことを確認します。ポートの MAC アドレス（BIA）が有効であることを確認します。

RP/0/RSP0/CPU0:router# show interface

ステップ 3 LACP を実行している場合は、LACP パケットを相応に送受信できることを確認します。LACP パケットを相応に送受信できない場合は、インターフェイス カウンタをチェックして、どの段階のパケットがドロップされているかを特定します。

RP/0/RSP0/CPU0:router# show lacp counters

ステップ 4 LACP 統計情報を表示します。

RP/0/RSP0/CPU0:router# show lacp

ステップ 5 リンクの相手側がアップしていることを確認します（バンドルおよびメンバ）。

RP/0/RSP0/CPU0:router# show bundle

バンドル メンバにトラフィックが分散しない

ステップ 1 メンバがアップしていることを確認します。

RP/0/RSP0/CPU0:router# show interface node-id

ステップ 2 リモート側がアップしていることを確認します。

ステップ 3 LACP パラメータが両側で同じであることを確認します。

a. LACP がイネーブルの場合は、LACP の状態をチェックします。

RP/0/RSP0/CPU0:router# show lacp bundle

b. バンドル メンバが同じ特性を持つことを確認します。

RP/0/RSP0/CPU0:router# show running interface interface-name

c. バンドル メンバが異なる特性を持っている場合は、すべてのバンドル メンバの特性を同じにします。

d. LACP パケットが送受信されていることを確認します。

RP/0/RSP0/CPU0:router# debug bundlemgr local packets port node-id

回避策

LACP によるバンドルが起動しない場合は、バンドルの一方の側をパッシブ モードにし、もう一方の側をアクティブ モードにします。少なくとも一方の側がアクティブである必要があります。

バンドルでバックプレーンからの MAC アドレスが使用されない

ステップ 1 バックプレーン MAC がプログラムされていることを確認します。

RP/0/RSP0/CPU0:router(admin)# show diag chassis eeprom-info

このコマンドは管理モードで実行する必要があります。

ステップ 2 RP/0/RSP0/CPU0:router# show controllers backplane bpe-trace

L3 データ トラフィックが流れない

通常インターフェイス（サブインターフェイスなし）

ステップ 1 Address Resolution Protocol（ARP; アドレス解決プロトコル）を表示します。

RP/0/RSP0/CPU0:router# show arp

ステップ 2 LAG テーブルがハードウェアに適切にプログラムされていることを確認します。

RP/0/RSP0/CPU0:router# show interface bundle-ether bundle-id

ステップ 3 実行コンフィギュレーション情報を確認します。

RP/0/RSP0/CPU0:router# show running-config

ステップ 4 Cisco Express Forwarding（CEF; シスコ エクスプレス フォワーディング）によって転送されたパケットに関する情報を表示します。

RP/0/RSP0/CPU0:router# show cef

ステップ 5 RP/0/RSP0/CPU0:router# show cef hardware ingress location node-id

ステップ 6 RP/0/RSP0/CPU0:router# show cef hardware egress location node-id

サブインターフェイス

ステップ 1 L3 IPv4 トラフィックのトラブルシューティングを行います。

ステップ 2 VLAN 着信トラフィックが受信インターフェイス上の VLAN トラフィックと一致することを確認します。

バンドル上での ping が失敗する

ステップ 1 ARP を表示します。

RP/0/RSP0/CPU0:router# show arp

ステップ 2 特定の LC または RSP での ARP 情報を表示します。

RP/0/RSP0/CPU0:router# show arp location node-id

ステップ 3 RP/0/RSP0/CPU0:router# show cef hardware detail location node-id ingress

ステップ 4 RP/0/RSP0/CPU0:router# show interface

ステップ 5 ハッシュ計算機能を使用して、テストするバンドル メンバ（インターフェイス）を特定します。

ステップ 6 該当インターフェイスをバンドルから削除します。

ステップ 7 該当インターフェイスに IP アドレスを割り当てます。

ステップ 8 該当インターフェイスに対して ping を実行します。

ステップ 9 ルータと ping 先のノードとの間で ARP が解決されていることを確認します。

ステップ 10 相手側の ARP テーブル内の MAC アドレスがルータ上の MAC アドレスに対応していることを確認します。

ステップ 11 バンドルの MAC アドレスが有効であることを確認します。

ステップ 12 ルーティングおよびハードウェア ルーティング テーブルにネクストホップへのエントリがあることを確認します。

ステップ 13 インターフェイス カウンタをチェックし、ping パケットが送信され、バンドルのルータ メンバ ポートで受信されているかどうかを確認します。

ステップ 14 ucode カウンタをチェックし、パケットがバンドルの受信メンバまたは送信メンバ上でドロップされている箇所を確認します。

回避策

別のポートで試してみます。

L3 パケットがバンドル上で同期しない

ステップ 1 RP/0/RSP0/CPU0:router# show interface

ステップ 2 そのプロトコルのデバッグを有効にするか、プロトコル カウンタをチェックして、プロトコル パケットが送受信されているかどうかを確認します。

ステップ 3 プロトコル パケットが送受信されていない場合は、インターフェイス カウンタをチェックして、インターフェイスでパケットの入出力が示されているかどうかを確認します。

ステップ 4 インターフェイス レベルではパケットの受信と送信が示されているにもかかわらず、プロトコルにパケットが到達していない場合は、ucode カウンタをチェックして、ドロップが起こっているかどうかを確認します。

L2 トラフィックが流れない

VPLS

ステップ 1 AC がアップしていることを確認します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain

ステップ 2 ブリッジ ドメインがアップしていることを確認します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain

ステップ 3 MTU の不一致を探します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain detail

VPWS

ステップ 1 設定されている相互接続に関する簡潔な情報を表示します。

RP/0/RSP0/CPU0:router# show l2vpn xconnect summary

ステップ 2 RP/0/RSP0/CPU0:router# show l2vpn xconnect state

ステップ 3 RP/0/RSP0/CPU0:router# show controllers bundle bundle-ether bundle-id location node-id

バンドル上でのロード バランシング

L2 トラフィックがロード バランシングされない

ステップ 1 RP/0/RSP0/CPU0:router# show running-config

ステップ 2 RP/0/RSP0/CPU0:router# show bundle

ステップ 3 RP/0/RSP0/CPU0:router# show interface bundle-ether bundle-id

ステップ 4 RP/0/RSP0/CPU0:router# show arm router-ids

ステップ 5 RP/0/RSP0/CPU0:router# show controllers bundle bundle-ether bundle-id location node-id

L3 トラフィックがロード バランシングされない

ステップ 1 RP/0/RSP0/CPU0:router# show arm router-id

ステップ 2 RP/0/RSP0/CPU0:router# show bundle

ステップ 3 RP/0/RSP0/CPU0:router# show interface bundle-ether bundle-id

ステップ 4 RP/0/RSP0/CPU0:router# show controllers bundle bundle-ether bundle-id location node-id

ステップ 5 RP/0/RSP0/CPU0:router# show running-config

ステップ 6 RP/0/RSP0/CPU0:router# show arm router-ids

ステップ 7 トラフィックを送出するのが望ましいメンバを特定します。

RP/0/RSP0/CPU0:router# bundle-hash bundle-ether bundle-id

ステップ 8 バンドルの各メンバを表示し、実際にトラフィックを送出しているメンバを確認します。

RP/0/RSP0/CPU0:router# show interface

バンドルの統計情報

現在のリリースでは、バンドル インターフェイスに対する show interface accounting コマンドで L2 統計情報はサポートされていません。

多重スパニング ツリー（MST）

Multiple Spanning Tree（MST; 多重スパニング ツリー）は、シスコ独自の Multiple Instances Spanning Tree Protocol（MISTP）の実装を参考にして IEEE で策定された標準規格です。このセクションの内容は次のとおりです。

• 「show および debug コマンドの使用方法」

• 「MSTP の構成が不適切または一貫していない」

• 「MSTP は適切に構成されているが、トラフィックのフラッディングが発生する」

• 「MSTP で間違ったポート状態が示される」

• 「パケット フォワーディングが MSTP 状態と一致していない」

• 「RL2GP アクセス ネットワークが RL2GP ノードをルートとして認識しない」

• 「トラフィックが RL2GP ノードを通じてスイッチングされない」

show および debug コマンドの使用方法

手順概要

1. show spanning-tree mst

2. show spanning-tree ring-termination

3. show l2vpn bridge-domain [bd-name bridge-domain name | brief | detail | group bridge-domain group name | interface { type interface-id } | neighbor IP address [pw-id value ] | summary]

4. debug spanning-tree mst controller

5. debug spanning-tree mst io

6. debug spanning-tree mst packet

7. debug spanning-tree mst protocol-state

詳細手順

MSTP の構成が不適切または一貫していない

スパニング ツリーが適切に構成されない場合、その原因の多くは設定ミスか、BPDU の損失です。これは通常、複数のノードが自身をルートとして提示する現象として現れますが、結果的にどのノードがルートであるかについて不一致が見られる場合もあります。

MSTP の構成が不適切または一貫していない：設定ミス

各ノードで次が一致していることを確認します。

• 設定名

• ブリッジのリビジョン

• プロバイダーブリッジ モード

• インスタンスと VLAN のマッピング

RP/0/RSP0/CPU0:router# show run spanning-tree mst protocol instance name

MSTP の構成が不適切または一貫していない：BPDU の損失

ノード A が ノード B に BPDU を送信しているかどうかを確認します。それらのノードを接続しているインターフェイスごとに次のコマンドを数回実行します。

RP/0/RSP0/CPU0:router# show spanning-tree mst protocol instance name internal io interfaces interface-name

定期的に BPDU を送信するのは指定ポートだけです。非指定ポートは、トポロジの変更時または起動時にアップデートを送信します。送受信された BPDU が適宜上位に送られていることを確認します。

MSTP は適切に構成されているが、トラフィックのフラッディングが発生する

BPDU の断続的な損失は、show コマンドでスパニングツリーが不適切に見えないにもかかわらず、トポロジ変更通知が送出されることを意味する場合があります。これらの通知は MAC のフラッシュを引き起こし、その結果、MAC アドレスが再学習されるまで強制的にトラフィックのフラッディングが起こります。

トポロジ変更通知を探します。次のコマンドを実行して、TC 1 を探します。

（注） このオプションは冗長です。

MSTP で間違ったポート状態が示される

STP は、ポート状態を変更しようとするときに L2VPN を使用します。「Sent Update」の値をチェックします。この値が Yes の場合、STP は L2VPN からのアップデートを待っています。

RP/0/RSP0/CPU0:router# show spanning-tree mst name internal l2vpn

パケット フォワーディングが MSTP 状態と一致していない

ステップ 1 冗長リンクをシャットダウンし、MSTP 設定を削除して、基本的なブリッジ処理が動作することを確認します。

RP/0/RSP0/CPU0:router# show spanning-tree mst name

RP/0/RSP0/CPU0:router# show interface interface-name

ステップ 2 MSTP によって計算された各ポートの状態をチェックし、それを MSTP によって制御されているポートおよび EFP 上でのパケット送受信数と比較します。通常のデータ パケットは、フォワーディング（FWD）状態のポートだけで送受信されます。BPDU は、MSTP によって制御されているすべてのポートで送受信されます。

ステップ 3 BPDU が流れていて、ルート ブリッジの選択が正しいことを確認します。これらの関連するシナリオを最初にチェックします。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain [detail]

このコマンドは、ブリッジ ドメインのメンバのステータスを表示します。関連するブリッジ ドメインのメンバがアップしていることを確認します。

ステップ 4 ハードウェアにプログラムされたフォワーディング状態をチェックします。

RL2GP アクセス ネットワークが RL2GP ノードをルートとして認識しない

RL2GP を設定する方法には次の 2 通りがあります。

• あたかも両方のノードが別々であるかのようにアドバタイズする。この方法では、各ノードが一意のブリッジ ID を持ち、設定が互いを補完する必要があります。

• あたかも各ノードが同じノード上の異なるポートであるかのようにアドバタイズする。この方法では、ポート ID 以外の設定は同一です。

RL2GP のコマンドは、基本インターフェイスではなく、タグ付けされていない EFP を対象とする必要があります。

ステップ 1 RP/0/RSP0/CPU0:router# show running-config spanning-tree ring-termination name

ステップ 2 両方のノードをデバッグし、出力を含めます。

RP/0/RSP0/CPU0:router# debug spanning-tree mst packet full sent interface interface-name

トラフィックが RL2GP ノードを通じてスイッチングされない

ステップ 1 l2vpn と UIDB のデータを収集し、データパスが正しいことを確認します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain [detail]

ステップ 2 フォワーディング状態がハードウェアにプログラムされたとおりに設定されていることを確認します。

Virtual Private Local Area Network Service（VPLS）

Virtual Private Local Area Network Service（VPLS）を使用すると、サイトを地理的に分離し、各サイトを疑似回線で接続することによってイーサネット ブロードキャスト ドメインを共有できます。このセクションの内容は次のとおりです。

• 「show および debug コマンドの使用方法」

• 「AC がダウンしている」

• 「疑似回線がダウンしている」

• 「VPLS がフラッディング トラフィックを転送しない」

• 「VPLS が AC から疑似回線にフラッディング トラフィックを転送しない」

• 「VPLS が疑似回線から AC にフラッディング トラフィックを転送しない」

• 「VPLS が AC から AC にユニキャスト トラフィックを転送しない」

• 「VPLS が AC から疑似回線にユニキャスト トラフィックを転送しない」

• 「VPLS が疑似回線から AC にフラッディング トラフィックを転送しない」

• 「疑似回線はアップしているのに ping が失敗する」

• 「トラフィックが失われる」

• 「疑似回線のフラップが原因でトラフィックが失われる」

• 「RSP フェールオーバー中にトラフィックが失われる」

• 「優先パスが機能しない」

show および debug コマンドの使用方法

手順概要

1. show l2vpn bridge-domain [bd-name bridge-domain name | brief | detail | group bridge-domain group name | interface { type interface-id} | neighbor IP address [pw-id value ] | summary]

2. show l2vpn forwarding bridge-domain [ bridge-domain-name ] {detail | hardware {egress | ingress}} {location node-id}

詳細手順

AC がダウンしている

ステップ 1 RP/0/RSP0/CPU0:router# show interface

ステップ 2 RP/0/RSP0/CPU0:router# show l2vpn bridge interface detail

ステップ 3 AC インターフェイスで l2transport が設定されていることを確認します。

ステップ 4 AC インターフェイスがアップしていることを確認します。

ステップ 5 MTU が一致していることを確認します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain interface type interface-name detail

疑似回線がダウンしている

ステップ 1 OSPF ネイバー情報を表示します。

RP/0/RSP0/CPU0:router# show ospf neighbor

ステップ 2 MPLS LDP ネイバー情報を表示します。

RP/0/RSP0/CPU0:router# show mpls ldp neighbor neighbor

ステップ 3 ブリッジの疑似回線の状態を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain neighbor

ステップ 4 両方の PE で疑似回線が適切に設定されていることを確認します。

ステップ 5 MPLS パッケージがインストールされていることを確認します。

ステップ 6 コア インターフェイスがアップしていることを確認します。

ステップ 7 ルーティング プロトコルが OSPF であることを確認します。

ステップ 8 PE ピアとの LDP セッションが確立されていることを確認します。

ステップ 9 MTU が一致していることを確認します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain detail

VPLS がフラッディング トラフィックを転送しない

ステップ 1 OSPF ネイバー情報を表示します。

RP/0/RSP0/CPU0:router# show ospf neighbor

ステップ 2 MPLS LDP ネイバー情報を表示します。

RP/0/RSP0/CPU0:router# show mpls ldp neighbor neighbor

ステップ 3 両方の PE で疑似回線が適切に設定されていることを確認します。

ステップ 4 MPLS パッケージがインストールされていることを確認します。

ステップ 5 コア インターフェイスがアップしていることを確認します。

ステップ 6 ルーティング プロトコルが OSPF であることを確認します。

ステップ 7 PE ピアとの LDP セッションが確立されていることを確認します。

ステップ 8 MTU が一致していることを確認します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain detail

VPLS が AC から疑似回線にフラッディング トラフィックを転送しない

ステップ 1 セグメントの入力 UIDB および XID を表示します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding interface hardware ingress detail location

ステップ 2 疑似回線のハードウェア情報を表示します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding neighbor 192.12.12.5 pw-id 100 hardware egress location node-id0

ステップ 3 MPLS リーフ情報を表示します。

RP/0/RSP0/CPU0:router# show mpls forwarding labels hardware egress detail location

ステップ 4 ブロードキャスト、マルチキャスト、および未知のユニキャストに関するブリッジ情報を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain bd-name 1 det

ステップ 5 MAC 制限を超えていないことを確認します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding bridge-domain 1:1 detail location

ステップ 6 PI イベント トレースを表示します。

RP/0/RSP0/CPU0:router# show l2vpn trace location

ステップ 7 疑似回線と AC がアップしていることを確認します。

ステップ 8 両方の AC に対してハードウェアがプログラムされていることを確認します。

ステップ 9 RP/0/RSP0/CPU0:router# show l2vpn forwarding interface GigabitEtherne0/5/0/2 hardware ingress detail location node-id

ステップ 10 疑似回線に対してハードウェアがプログラムされていることを確認します。

VPLS が疑似回線から AC にフラッディング トラフィックを転送しない

ステップ 1 セグメントの入力 UIDB および XID を表示します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding interface hardware ingress detail location

ステップ 2 MPLS リーフ情報を表示します。

RP/0/RSP0/CPU0:router# show mpls forwarding labels hardware egress detail location

ステップ 3 ブロードキャスト、マルチキャスト、および未知のユニキャストに関するブリッジ情報を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain bd-name 1 det

ステップ 4 MAC 制限を超えていないことを確認します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding bridge-domain 1:1 detail location

ステップ 5

ステップ 6 PI イベント トレースを表示します。

RP/0/RSP0/CPU0:router# show l2vpn trace location

ステップ 7 疑似回線と AC がアップしていることを確認します。

ステップ 8 両方の AC に対してハードウェアがプログラムされていることを確認します。

ステップ 9 RP/0/RSP0/CPU0:router# show l2vpn forwarding interface GigabitEtherne0/5/0/2 hardware ingress detail location node-id

ステップ 10 疑似回線に対してハードウェアがプログラムされていることを確認します。

VPLS が AC から AC にユニキャスト トラフィックを転送しない

ステップ 1 ブリッジ ドメインの状態を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain bd-name node-id detail

ステップ 2 MAC 情報を表示します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding bridge-domain mac-address location

ステップ 3 両方の AC に対してハードウェアがプログラムされていることを確認します。

ステップ 4 LC の宛先インターフェイスに対して宛先 MAC エントリがプログラムされていることを確認します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding bridge-domain mac-address location node-id0

VPLS が AC から疑似回線にユニキャスト トラフィックを転送しない

ステップ 1 ブリッジ ドメインの状態を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain bd-name node-id detail

ステップ 2 MAC 情報を表示します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding bridge-domain mac-address location

ステップ 3 AC と疑似回線の両方に対してハードウェアがプログラムされていることを確認します。

ステップ 4 LC の宛先インターフェイスに対して宛先 MAC エントリがプログラムされていることを確認します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding bridge-domain mac-address location node-id0

VPLS が疑似回線から AC にフラッディング トラフィックを転送しない

ステップ 1 ブリッジ ドメインの状態を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain bd-name node-id detail

ステップ 2 AC と疑似回線の両方に対してハードウェアがプログラムされていることを確認します。

疑似回線はアップしているのに ping が失敗する

ステップ 1 ブリッジ ドメインの状態を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain bd-name node-id detail

ステップ 2 両方の CE が同じサブネット上にあることを確認します。

ステップ 3 MTU が一致していることを確認します。

ステップ 4 エンドツーエンドのカプセル化が一致していることを確認します。

トラフィックが失われる

ステップ 1 ブリッジ ドメインの状態を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain bd-name node-id detail

ステップ 2 セグメント カウンタを表示し、交換されたパケットおよびバイト数が増えているかどうかを確認します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding interface GigabitEthernet node-id detail location node-id

ステップ 3 帯域幅レートが CE 間で一致していることを確認します。

疑似回線のフラップが原因でトラフィックが失われる

ステップ 1 ブリッジ ドメインの状態を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain bd-name node-id detail

ステップ 2 セグメント カウンタを表示し、交換されたパケットおよびバイト数が増えているかどうかを確認します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding interface GigabitEthernet node-id detail location node-id

ステップ 3 PI イベント トレースを表示します。

RP/0/RSP0/CPU0:router# show l2vpn trace location

RSP フェールオーバー中にトラフィックが失われる

ステップ 2 セグメントのカウンタを表示します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding interface GigabitEthernet node-id detail location node-id

ステップ 3 ブリッジ ドメインの状態を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain bd-name detail

ステップ 4 入力 UIDB を表示します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding interface interface hardware ingress detail location node-id

ステップ 5 MPLS パス内のすべてのルータをチェックし、次が設定されていることを確認します。

a. MPLS LDP グレースフル リスタート

b. OSPF NSF

ステップ 6 セグメント カウンタを表示し、交換されたパケットおよびバイト数が増えているかどうかを確認します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding interface GigabitEthernet node-id detail location node-id

優先パスが機能しない

ステップ 1 ブリッジ ドメインの状態を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain bd-name detail

ステップ 2 入力 UIDB を表示します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding interface interface hardware ingress detail location node-id

Virtual Private Wire Services（VPWS）

Virtual Private Wire Services（VPWS）は、基盤となる MPLS トンネルを使用して地理的に離れたサイト間の回線セットをエミュレートすることにより、これらのサイトを接続します。このセクションの内容は次のとおりです。

• 「show および debug コマンドの使用方法」

• 「AC がダウンしている」

• 「疑似回線がダウンしている」

• 「VPWS が AC から疑似回線にトラフィックを転送しない」

• 「VPWS が疑似回線から AC にトラフィックを転送しない」

• 「疑似回線はアップしているのに ping が失敗する」

• 「トラフィックが失われる」

• 「RSP フェールオーバー中にトラフィックが失われる」

• 「優先パスが機能しない」

show および debug コマンドの使用方法

手順概要

1. show l2vpn xconnect [detail | group | interface | neighbor | state | summary | type | state unresolved]

2. show l2vpn forwarding {detail | hardware | interface | location | message | resource | summary | unresolved} location node-id

3. show mpls forwarding [detail | {label label number} | interface interface-id | labels value | location | prefix [network/mask | length] | summary | tunnels tunnel-id]

詳細手順

AC がダウンしている

ステップ 1 インターフェイスの状態を表示します。

RP/0/RSP0/CPU0:router# show interface

ステップ 2 xconnect の状態を表示します。

RP/0/RSP0/CPU0:router# show l2vpn xconnect detail

ステップ 3 AC インターフェイスで l2transport が設定されていることを確認します。

ステップ 4 AC インターフェイスがアップしていることを確認します。

ステップ 5 MTU が一致していることを確認します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain interface type interface-name detail

疑似回線がダウンしている

ステップ 1 OSPF ネイバー情報を表示します。

RP/0/RSP0/CPU0:router# show ospf neighbor

ステップ 2 MPLS LDP ネイバー情報を表示します。

RP/0/RSP0/CPU0:router# show mpls ldp neighbor neighbor

ステップ 3 ブリッジの疑似回線の状態を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain neighbor

ステップ 4 両方の PE で疑似回線が適切に設定されていることを確認します。

ステップ 5 MPLS パッケージがインストールされていることを確認します。

ステップ 6 コア インターフェイスがアップしていることを確認します。

ステップ 7 ルーティング プロトコルが OSPF であることを確認します。

ステップ 8 PE ピアとの LDP セッションが確立されていることを確認します。

ステップ 9 MTU が一致していることを確認します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain detail

VPWS が AC から疑似回線にトラフィックを転送しない

ステップ 1 疑似回線のハードウェア情報を表示します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding neighbor 192.12.12.5 pw-id 100 hardware egress location node-id0

ステップ 2 ブロードキャスト、マルチキャスト、および未知のユニキャストに関するブリッジ情報を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain bd-name 1 det

ステップ 3 MAC 制限を超えていないことを確認します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding bridge-domain 1:1 detail location

ステップ 4 疑似回線と AC がアップしていることを確認します。

ステップ 5 両方の AC に対してハードウェアがプログラムされていることを確認します。

ステップ 6 RP/0/RSP0/CPU0:router# show l2vpn forwarding interface GigabitEtherne0/5/0/2 hardware ingress detail location node-id

ステップ 7 疑似回線に対してハードウェアがプログラムされていることを確認します。

VPWS が疑似回線から AC にトラフィックを転送しない

ステップ 1 入力 UIDB を表示します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding interface interface hardware ingress detail location node-id

ステップ 2 疑似回線と AC がアップしていることを確認します。

ステップ 3 この疑似回線に関連付けられたローカル ラベルを探します。

RP/0/RSP0/CPU0:router# show l2vpn xconnect detail

ステップ 4 AC に関連付けられた XID を探します。

RP/0/RSP0/CPU0:router# show l2vpn xconnect detail

ステップ 5 RP/0/RSP0/CPU0:router# show l2vpn forwarding interface GigabitEthernet 0/4/0/2 hardware ingress detail location 0/4/CPU0

疑似回線はアップしているのに ping が失敗する

ステップ 1 ブリッジ ドメインの状態を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain bd-name node-id detail

ステップ 2 両方の CE が同じサブネット上にあることを確認します。

ステップ 3 MTU が一致していることを確認します。

ステップ 4 エンドツーエンドのカプセル化が一致していることを確認します。

トラフィックが失われる

ステップ 1 ブリッジ ドメインの状態を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain bd-name node-id detail

ステップ 2 セグメント カウンタを表示し、交換されたパケットおよびバイト数が増えているかどうかを確認します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding interface GigabitEthernet node-id detail location node-id

ステップ 3 帯域幅レートが CE 間で一致していることを確認します。

RSP フェールオーバー中にトラフィックが失われる

RSP フェールオーバーが実行されるときにトラフィックが失われることがあります。これは、プレフィクスの学習に使用される IGP がダウンすることに起因する可能性があります。次の説明は、IGP として OSPF を使用していることを前提とします。

• show process failover ：フェールオーバー中のプロセスの詳細を表示します。

• debug ospf ha ：OSPF HA 関連のデバッグをイネーブルにします。

• debug ospf instance nsf ：フェールオーバーの前に実行し、デバッグ ログを収集します。

• show process failover ：フェールオーバーの後に実行します。

ステップ 1 すぐにチェックすべきこととして、ネクストホップ ルータでも（このルータと同様に）フェールオーバー メカニズムが作動したかどうかが挙げられます。ネクストホップ ルータでもフェールオーバー メカニズムが作動した場合は、OSPF がダウンしている可能性があります。

ステップ 2 ネクストホップ ルータでフェールオーバー メカニズムが作動していない場合は、OSPF で「nsf cisco」が設定されていることを確認します。「nsf cisco」が設定されている場合は、フェールオーバー中にネクストホップに到達可能かどうかを確認します。到達不能な場合は、リンクのダウンやネゴシエーションの問題など、到達可能性に関する問題がある可能性があります。

優先パスが機能しない

ステップ 1 ブリッジ ドメインの状態を表示します。

RP/0/RSP0/CPU0:router# show l2vpn bridge-domain bd-name detail

ステップ 2 入力 UIDB を表示します。

RP/0/RSP0/CPU0:router# show l2vpn forwarding interface interface hardware ingress detail location node-id

インターネット プロトコル（IP）

このセクションの内容は次のとおりです。

• 「show および debug コマンドの使用方法」

• 「トラフィックが失われる」

• 「トレースルートが失敗する」

• 「ルートの追加が失敗する」

• 「継続的なトレースバック」

• 「fib_mgr が起動しない」

• 「CEF エントリが同期しない」

• 「fib_mgr がクラッシュする」

• 「トレースバックが表示される」

• 「サブインターフェイスでのカプセル化の変更が原因でトラフィックが失われる」

• 「RSP フェールオーバー中にトラフィックが失われる」

show および debug コマンドの使用方法

手順概要

1. show cef location node-id

2. show cef ipv4 { prefix/mask } location node-id

3. show bgp summary

4. show bgp [{ipv4 | all} {unicast | multicast | all}] dampened-paths

5. show bgp [{ipv4 | all} {unicast | multicast | all}] flap-statistics [regexp regular-expression | filter-list access-list | cidr-only | { ip-address [{ mask | / prefix-length } [ longer-prefixes ]] [detail]}]

6. show arp [vrf vrf-name ] [ ip-address [location node-id ] | hardware-address [location node-id] | traffic [location node-id | interface-name]

7. show interface accounting

8. show cef ipv4 {prefix/mask } hardware {ingress | egress} location node-id

9. show cef platform trace common [all | errors | events | info] [location node-id]

詳細手順

トラフィックが失われる

show interface accounting コマンドを使用するか、宛先での Rx パケットを調べて、パケットの損失を確認します。

• show cef {ipv4} (destination-ip)/(mask) hardware egress detail location node-id：プレフィクス (destination-ip)/(mask) に関連するハードウェア データ構造を表示します。

• show arp location node-id：特定の LC または RSP での ARP 情報を表示します。

• show cef trace errors all reverse location node-id：記録された PI コード ltrace エラーを表示します。

• show cef platform trace {ipv4} errors all reverse location node-id：プロトコル IPv4 でのプラットフォーム コード ltrace エラーを表示します。

パケットが入力から出力に正常に転送されたことを示す ucode のカウンタは次のとおりです。

• PARSE_ENET_RECEIVE_CNT：入力インターフェイスに到着したパケットを表示します。

• MODIFY_FABRIC_TRANSMIT_CNT：出力 LC に送信されたパケットを表示します。

• PARSE_FABRIC_RECEIVE_CNT：出力 LC 上のファブリックから受信されたパケットを表示します。

• MODIFY_ENET_TRANSMIT_CNT：出力インターフェイスの外部に送信されたパケットを表示します。

ドロップのないトラフィックでは、これらのカウンタの値はすべて一致します。いずれかのカウンタが一致しない場合は、状況に応じて調査を続けます。たとえば、PARSE_FABRIC_RECEIVE_CNT が MODIFY_FABRIC_TRANSMIT_CNT よりも少ない場合は、ファブリックの内部でパケットの損失が起こっています。ファブリックでパケットがドロップされる原因について、さらにトラブルシューティングを進める必要があります。

ソフトウェアで交換されるパケット

ステップ 1 宛先 IP アドレスのハードウェア チェーンが次のどちらかを示していることを確認します。

• COMPLETE の隣接関係：有効な発信パスが存在します。

• PUNT の隣接関係：ハードウェアはパケットの送出方法を知りません。単にソフトウェアで交換されるようにパケットをパント（迂回）するだけです。送信隣接関係が PUNT の場合、これは ARP がまだ解決されていないことに起因する可能性があります。

ステップ 2 宛先 IP 用の ARP エントリが存在するかどうかを表示するには、show arp location コマンドを使用します。

RP/0/RSP0/CPU0:router# show arp location node-id

a. ARP エントリが存在しない場合、または不完全な場合は、スタティック ARP エントリを追加します。Tx 隣接関係が「COMPLETE」を示していることを確認します。

RP/0/RSP0/CPU0:router# show cef {ipv4} 192.1.1.1/32 hardware egress detail location 0/4/CPU0

b. その場合、問題は ARP エントリが更新されないことにあります。トラブルシューティングの対象を ARP エントリが追加されない原因の追求に向けます（これには、 show arp 、 show arp idb、 show adjacency gig node-id detail location node-id 、 show arp trace などのステップが含まれます）。

c. Tx 隣接関係がまだ「PUNT」を示している場合は、ARP データベースにエントリは追加されるものの、fib_mgr が隣接関係を「COMPLETE」としてマークできないことを意味します。

d. これは fib_mgr、ARP、または AIB の問題です。スタティック ARP エントリをいったん削除し、AIB および CEF のデバッグを有効にしてスタティック ARP エントリを再設定します。デバッグ メッセージから、ARP が AIB 内部にエントリを追加しているかどうか、および AIB が fib_mgr に通知しているかどうかがわかります。

ステップ 3 パケットがファブリック内でドロップされる場合があります。これを確認するには、ファブリックのカウンタを表示します。

回避策

ステップ 1 発信インターフェイスに対して shut コマンド（後に commit を続ける）と no shut コマンド（後に commit を続ける）を使用します。

ステップ 2 宛先 IP 用のスタティック ARP エントリを追加します。

トレースルートが失敗する

traceroute は、宛先への接続性を確認するときに使用します。宛先へのトレースルートが失敗する場合は、次のコマンドを使用します。

• show cef {ipv4} { destination_ip }/ (mask } hardware egress detail location node-id：プレフィクスに関連するハードウェア データ構造を表示します。

• show interface location { outgoing_interface } accounting ：発信インターフェイスからの入力または出力パケットを表示します。

ステップ 1 宛先 IP アドレスの送信隣接関係が適切であるかどうかをチェックします。「Tx Adjacency」の状態を確認します（「COMPLETE」である必要があります）。

RP/0/RSP0/CPU0:router# show cef {ipv4} prefix hardware egress detail location node-id

ステップ 2 送信隣接関係が COMPLETE でない場合は、問題があります。送信隣接関係が「PUNT」を示している場合は、おそらく宛先 IP に対応する MAC アドレスが学習されていません。「static arp」エントリを追加して、送信隣接関係が「COMPLETE」に移行するかどうかを確認します。宛先 IP アドレスが OSPF などのルーティング プロトコルによってアドバタイズされる場合、送信隣接関係が「PUNT」になることはありません。

送信隣接関係が「DROP」の場合は、ルートを DROP に明示的に向ける宛先 IP アドレスへのスタティック ルートが存在することを意味します。

送信隣接関係が「COMPLETE」の場合は、設定されているハードウェア チェーンに問題はありません。カウンタを確認する必要があります。

ステップ 3 出力パケットが、送信されたトレースルート パケットと一致しているかどうかを確認します。

RP/0/RSP0/CPU0:router# show interface location outgoing_interface accounting

回避策

ステップ 1 発信インターフェイスに対して shut コマンド（後に commit を続ける）と no shut コマンド（後に commit を続ける）を使用します。

ステップ 2 宛先 IP 用のスタティック ARP エントリを追加します。

ルートの追加が失敗する

Out Of Resource（OOR; リソース枯渇）の間は、既存のルートが削除されない限り、ルータは追加のルートを受け入れません。

• show cef resource location node-id：各種データ構造の PI 状態を表示します。理想的な状態は GREEN です。状態が YELLOW または RED の場合は、OOR と呼ばれる状態に入っていることを意味します。

• show cef platform trace {ipv4} error reverse location node-id：プロトコル IPv4 のプラットフォーム ltrace エラーを表示します。

• show cef platform trace common error reverse location node-id：すべてのプロトコルのプラットフォーム ltrace 一般エラーを表示します。

ステップ 1 正確にどのリソースが枯渇しているかを特定します。「max entries」と「used entries」を比較し、使用されているエントリ数が上限に近いデータ構造を確認します。

RP/0/RSP0/CPU0:router# show cef resource location node-id

ステップ 2 枯渇しているデータ構造が特定されたら、それが予測された状況か、予測外の状況であるかを確認できます。通常は、LEAF ごとに（IPv4 でも同じ）NR_LDI 構造のエントリが 4 つ必要です。そのため、NR_LDI 構造でリソース枯渇が起こっている場合は、IP リーフの数は適切で、NR_LDI の数が上限に達するのは妥当であるのかどうかを確認します。

ステップ 3 show cef resource location node-id で状態が「GREEN」と示される場合は、OOR 状態ではありません。ルートを追加できない原因は他にあります。場合によっては、何が起こっているかを把握するために、次のデバッグをイネーブルにする必要があります。

a. RP/0/RSP0/CPU0:router# debug cef errors location node-id

b. RP/0/RSP0/CPU0:router# debug cef {ipv4} error location node-id

c. トレースバックを監視する場合は、SBT ツールを使用してトレースバックをデコードします。

回避策

OOR 状態が発生していて、これが予測されたものである場合は、既存のルートをいくつか削除します。

継続的なトレースバック

トレースバックが継続的に（通常は 15 秒間隔で）コンソールに表示される場合は、ハードウェア内のエントリのプログラミングが正常ではありません。これは、15 秒経過するたびにソフトウェアが試行を繰り返すために起こります。

• show cef platform trace common all all reverse location node-id--：すべてのプラットフォーム ltrace 一般メッセージを表示します。

• show cef platform trace {ipv4} all all reverse location node-id：IPv4 のすべてのプラットフォーム ltrace プロトコル メッセージを表示します。

回避策

ステップ 1 prm_server プロセスを再起動します。

ステップ 2 LC を再起動します。

fib_mgr が起動しない

fib_mgr は、基盤となるハードウェアに依存します。基盤となるプロセスまたはハードウェアが起動しない場合は、おそらく fib_mgr も起動しません。

• show cef platform trace common all reverse location node-id：プラットフォーム ltrace 一般メッセージを表示します。

• show cef platform trace common event reverse location node-id：プラットフォーム ltrace 一般イベントを表示します。

• show cef platform trace {ipv4 or mpls} error reverse location node-id：プロトコル IPv4 または MPLS に対して記録されたプラットフォーム ltrace エラー メッセージを表示します。

• show cef trace reverse location node-id：すべての CEF ltrace メッセージを表示します。

コア ファイルを収集し、SBT を使用してトレースバックをデコードします。

回避策

ステップ 1 prm_server プロセスを再起動します。

ステップ 2 LC を再起動します。

CEF エントリが同期しない

RSP の cef エントリが管理インターフェイスを指していて、その結果、ルータから発信されるトラフィックが LC インターフェイスではなく管理インターフェイスから送出される場合があります。

• show cef trace event reverse location node-id：PI CEF ltrace イベントを表示します。

• show cef trace error reverse location node-id：PI CEF ltrace エラーを表示します。

• show cef platform trace common event reverse location node-id：CEF プラットフォーム一般イベントのトレースを表示します。

• show cef platform trace common error reverse location node-id：CEF プラットフォーム一般エラーのトレースを表示します。

ステップ 1 管理インターフェイスから送出するために設定されたデフォルト ルート 0.0.0.0/0 を探します。

ステップ 2 問題のプレフィクスについて設定されたスタティック ARP を探します。ARP により、管理インターフェイスを経由するエントリと LC インターフェイスを経由するエントリの 2 つのエントリがインストールされている可能性があります（プレフィクスがどちらのルートによっても到達できるため）。

ステップ 3 上記が該当しない場合は、管理インターフェイスを経由する ARP エントリをアドバタイズしているものがあるかどうかを確認します （これには show arp を使用します）。原因が特定されたら、ARP をクリアし、CEF エントリを再度確認します。

回避策

• 管理インターフェイスに対して shut コマンド（後に commit を続ける）と no shut コマンド（後に commit を続ける）を使用します。

• clear arp-cache

• LC を再起動します。

fib_mgr がクラッシュする

• show cef platform trace common all reverse location node-id：CEF プラットフォーム一般トレースを表示します。

• show cef platform trace common event reverse location node-id：CEF プラットフォーム一般イベントのトレースを表示します。

• show cef platform trace common error reverse location node-id：CEF プラットフォーム一般エラーのトレースを表示します。

• show cef platform trace {ipv4 or mpls} error reverse location node-id：IPv4 または MPLS の CEF プラットフォーム プロトコル トレースを表示します。

ステップ 1 トリガーが prm の再起動またはクラッシュの場合、これは予測される状況です。

ステップ 2 基盤となるプロセス（prm_server）がダウンまたはクラッシュした場合、おそらく fib_mgr は起動しません。

ステップ 3 コア ファイルを保存します。

ステップ 4 SBT を使用してトレースバックをデコードします。ワークスペースのルートから、./util/bin/sbt -p (process_name) -f (log_file) を使用します。

ステップ 5 コンソール ログを保存します。

回避策

fib_mgr または LC を再起動します。

トレースバックが表示される

これは、何らかのトリガー（インターフェイスの shut/no shut やその他の同様のトリガーなど）の結果としていくつかのエラー トレースバックがコンソールに表示されるというシナリオです。

• show cef trace event location node-id：主要イベントの CEF トレースを表示します。

• show cef trace errors location node-id：主要エラーの CEF トレースを表示します。

• show cef platform trace common errors location node-id：すべてのプロトコルにわたる一般エラーの CEF プラットフォーム トレースを表示します。

• show cef platform trace {ipv4 or mpls} errors location node-id：プロトコル IPv4 または MPLS のエラーの CEF プラットフォーム トレースを表示します。

• show logging

ステップ 1 SBT ツールを使用してトレースバックをデコードします。ワークスペースのルートから、./util/bin/sbt -p (process_name) -f (log_file) を使用します。

ステップ 2 コア ファイルを保存します。

回避策

トレースバックがサービスに影響を与える場合は、次の手順を実行します。

ステップ 1 fib_mgr プロセスを再起動します。

ステップ 2 LC を再起動します。

サブインターフェイスでのカプセル化の変更が原因でトラフィックが失われる

トラフィックが L3 サブインターフェイス経由で転送されている場合に、そのサブインターフェイスでカプセル化が変更されたとき、15 秒経過するまでトラフィックが再開されないことがあります。

• show cef trace event reverse location node-id：主要イベントの CEF トレース メッセージを表示します。

• show cef trace error reverse location node-id：主要エラーの CEF トレース メッセージを表示します。

• show cef platform trace common error location node-id：すべてのプロトコルにわたる一般エラーの CEF プラットフォーム トレースを表示します。

• show cef platform trace {ipv4 or mpls} event location node-id：プロトコル IPv4 または MPLS の主要イベントの CEF プラットフォーム トレースを表示します。

• show cef platform trace {ipv4 or mpls} error location node-id：プロトコル IPv4 または MPLS の主要エラーの CEF プラットフォーム トレースを表示します。

• show arp location node-id：ARP 関連の情報を表示します。

サブインターフェイスでカプセル化が dot1q vlan 300 から dot1q vlan 200 に変更されると、fib_mgr はこのインターフェイスに対応するすべてのプレフィクスを削除してから再作成します。すべてのプレフィクスを追加するまでに 15 秒かかります。その間、トラフィックは転送されません。たとえば、アドレス 192.0.0.0/8 のインターフェイスがあり、192.2.2.2 のスタティック ARP エントリがあるとします。

RP/0/RSP0/CPU0:router#show run | inc arp

（スタティック ARP ではなく）通常の隣接関係では、遅延が起こる可能性は低くなります。

VLAN カラーが変更されると、次のことが起こります。

• 隣接関係が削除され、隣接ルート 192.2.2.2 が削除されます。

• 接続ルートが削除されます。

• 接続ルートが追加される前に隣接関係が追加されます。FIB では、対応する接続ルートのない隣接関係の追加はエラーとして扱われるため、ルート 192.2.2.2 の設定は再試行に回されます。

• 接続ルート 192.0.0.0/8 が追加されます。

• FIB の再試行タイマーは 15 秒なので、隣接ルート 192.2.2.2 は 15 秒後に追加されます。

回避策

スタティック ARP エントリを削除します。

RSP フェールオーバー中にトラフィックが失われる

RSP フェールオーバーが原因でトラフィックが失われることがあります。これは、プレフィクスの学習に使用される IGP がダウンしていることを意味する場合があります。次の説明は、IGP として OSPF を使用していることを前提とします。

• show process failover ：フェールオーバー中のプロセスの詳細を表示します。

• debug ospf ha ：OSPF HA 関連のデバッグをイネーブルにします。

• debug ospf instance nsf ：フェールオーバーの前に実行し、デバッグ ログを収集します。

• show process failover ：フェールオーバーの後に実行します。

ステップ 1 ネクストホップ ルータでフェールオーバーが作動したかどうかをチェックします。

a. フェールオーバーが作動した場合、OSPF はダウンします。

a. フェールオーバーが作動していない場合は、OSPF で nsf cisco が設定されていることを確認します。

nsf cisco が設定されている場合は、フェールオーバー中にネクストホップに到達可能かどうかを確認します。
到達不能な場合は、リンクがダウンしているか、ネゴシエーションに問題がある可能性があります。

回避策

ルータをリロードします。

IP マルチキャスト

IP マルチキャストは、単一の情報ストリームを企業や家庭の何千もの受信者に同時に送信することによってトラフィックを削減する技術であり、帯域幅を大量に消費します。このセクションの内容は次のとおりです。

• 「show および debug コマンドの使用方法」

• 「マルチキャスト PIE のインストールが失敗する」

• 「PIE がインストールされているにもかかわらず、マルチキャスト CLI が使用できない」

• 「「This command not authorized」エラー メッセージ」

• 「ダイナミック IGMP 障害」

• 「一部のインターフェイスでトラフィックが失敗する」

• 「受信側インターフェイスでのスループットの損失」

show および debug コマンドの使用方法

手順概要

1. show igmp {global-interface | groups | | interface | nsf | old-output | snooping | ssm | summary | traffic | vrf name }

2. show pim {bgp-safi | bsr | context | df | group-map | interface | ipv4 | ipv6 | join-prune | mdt | mstatic | multicast | neighbor | nsf | old-output | range-list | rpf | safi-all | summary | table-context | topology | traffic | tunnel | unicast | vrf}

3. show mrib {client | route | table-info}

4. show mfib {connections | counter | encap-info | hardware | interface | ipv4 | ipv6 | lsm | mdt | nsf | route | svd | table-info | vrf)

5. show mfib hardware { | interface { location node-id} | ltrace | resource-counters | route }

6. show mfib hardware route { accept-bitmap | olist | statistics | summary } {* | A.B.C.D | A.B.C.D/length | detail | hex-dump} location node-id

7. show mfib hardware route summary location node-id

8. debug mrib errors

9. debug mrib events

10. debug mfib warning

11. debug mfib errors

12. debug mlib errors

13. debug mlib warning

詳細手順

マルチキャスト PIE のインストールが失敗する

ステップ 1 指定したインストール ID の詳細情報を表示します。

RP/0/RSP0/CPU0:router# show install log [1-4294967295] detail

ステップ 2 PIE ファイルの名前が正しいことを確認し、コマンドを再度実行します。

ステップ 3 PIE ファイルの場所が正しいことを確認し、コマンドを再度実行します。

ステップ 4 PIE ファイルのアクセス権が適切である（755 である）ことを確認し、コマンドを再度実行します。

ステップ 5 TFTP ディレクトリからロードする場合は、次のことを確認します。

a. ルータがネットワークに接続されている。

b. TFTP アドレスが適切に設定されている。

c. TFTP サーバに接続できる。

RP/0/RSP0/CPU0:router# ping tftp-server-addr

d. ルータからローカルにロードする場合は、PIE ファイルがルータに格納されていることを確認します。

ステップ 6 すべてのノードの状態が「IOS XR RUN State」であることを確認します。

RP/0/RSP0/CPU0:router# show platform

PIE がインストールされているにもかかわらず、マルチキャスト CLI が使用できない

show install active ：アクティブ パッケージ情報を表示します。

次のものが正しいことを確認します。

• PIE ファイルの名前

• PIE ファイルの場所

• すべてのノードでの PIE ファイルのインストール

「This command not authorized」エラー メッセージ

設定モードまたは EXEC モードで特定のコマンドを実行するとき、「This command not authorized」というエラー メッセージが表示され、それ以降アクセスできなくなります。これは、コマンドを実行したユーザが適切な権限を持っていないことを意味します。目的のコマンドを使用するための「Cisco-Support」権限および「root」権限をユーザが持っているかどうかをチェックします。

show config run ：（管理モードから実行）システムで現在動作している管理コンフィギュレーションを表示します。

ダイナミック IGMP 障害

ダイナミック IGMP 障害とは、Dynamic (*,G) がタイムアウトすることです。グループとルートが正しく設定およびセットアップされているにもかかわらず、テスターから Cisco ASR 9000 シリーズ ルータに送信されたトラフィックが Rx テスター ポートで受信されません。

ステップ 1 考えられる原因の 1 つとして、IGMP グループがタイムアウトしていることが挙げられます。これをチェックする 1 つの方法は、(*,G) のスタティック ルートを作成し、トラフィックが受信されるようになるかどうかを確認することです。トラフィックが受信される場合は、グループがタイムアウトしていることを意味します。

ステップ 2 ステップ 1 の結果を立証するには、スタティック ルートを削除し、現象をより明確にするためにクエリー間隔を短くします（その結果、1 分あたりのクエリー数が増加します）。

RP/0/RSP0/CPU0:router# conf t
RP/0/RSP0/CPU0:router(config)# router igmp
RP/0/RSP0/CPU0:router(config-igmp)# query-interval 1
RP/0/RSP0/CPU0:router(config-igmp)# commit

ステップ 3 設定した間隔でインターフェイスからパケットが送出されることを確認します。

ステップ 4 テスターが IGMP メンバシップ レポートで応答することをチェックします。パケットがテスターで受信された場合、ステップ 1 の結果は立証されます。回避策を実施してください。

回避策

一時的な回避策としてスタティック グループを設定します。

一部のインターフェイスでトラフィックが失敗する

一部のインターフェイスまたはチャネルでトラフィックが失敗します。グループとルートは正しく設定され、セットアップされています。トラフィックはテスターから Cisco ASR 9000 シリーズ ルータに送信されます。送信されたトラフィックは一部のインターフェイスでは正しく受信されますが、残りのインターフェイスでは受信されません。また、あるインターフェイスで一部のビデオ チャネルだけが正しく受信され、残りのビデオ チャネルが受信されないこともあります。これには次のような原因が考えられます。

• OLIST が適切に設定されていない。

• UIDB 値がハードウェアに正しく設定されていない。

• MGID が正しく設定されていない。

ステップ 1 パケットが入力 NP からファブリックを経由して出力 NP に移動していることを確認します。

RP/0/RSP0/CPU0:router# show mfib hardware route statistics location {ingress node-id | egress node-id }

ステップ 2 ルートの olist インターフェイスを表示します。

RP/0/RSP0/CPU0:router# show mfib hardware route olist location {ingress node-id | egress node-id }

ステップ 3 特定のルートおよび送信元の統計情報を表示します。

RP/0/RSP0/CPU0:router# show mfib hardware route stat [src ip addr] location {ingress node-id | egress node-id }

一部のインターフェイスでトラフィックが失敗する：MGID

ステップ 1 パケットが入力 NP からファブリックを経由して出力 NP に移動していることを確認します。

RP/0/RSP0/CPU0:router# show mfib hardware route statistics location {ingress node-id | egress node-id }

ステップ 2 ルートの olist インターフェイスを表示します。

RP/0/RSP0/CPU0:router# show mfib hardware route olist location {ingress node-id | egress node-id }

ステップ 3 パケットが入力 NP からファブリックに送出され、出力 NP でファブリックから受信されていることを確認します。

RP/0/RSP0/CPU0:router# show mfib hardware route statistics location {ingress node-id | egress node-id }

ステップ 4 ルートの MGID を表示します。

RP/0/RSP0/CPU0:router# show controllers bundle bundle-ether bundle-id location {ingress node-id | egress node-id }

受信側インターフェイスでのスループットの損失

トラフィックはルート上で送受信されますが、受信側でスループットの損失が起こります。

ステップ 1 パケットが入力 NP からファブリックを経由して出力 NP に移動していることを確認します。

RP/0/RSP0/CPU0:router# show mfib hardware route statistics location {ingress node-id | egress node-id }

ステップ 2 上記のコマンドから、パケットが RP にパントされているかどうかがわかります。パントされている場合は、そのチャネルの送信元が一部の IP オプションを設定しているかどうかをチェックします。

マルチ プロトコル ラベル スイッチング（MPLS）

Multi Protocol Label Switching（MPLS; マルチ プロトコル ラベル スイッチング）は、IP パケットやイーサネット フレームなどの異なる種類のトラフィックを伝送します。このセクションの内容は次のとおりです。

• 「show および debug コマンドの使用方法」

• 「IP パケットが LSP に転送されない」

• 「IP パケットが MPLS TE トンネルに転送されない」

• 「MPLS パケットが MPLS TE トンネルに転送されない」

• 「MPLS TE トンネルが起動しない」

• 「FRR によって保護されたトンネルが FRR の作動後にダウンする」

• 「MPLS TE FRR データベースが構築されない」

• 「MPLS FRR 切り替え時間のデバッグ」

• 「Reverse Path Forwarding（RPF）」

show および debug コマンドの使用方法

手順概要

1. debug mpls ldp transport events

2. debug mpls ldp transport connections

3. show mpls forwarding tunnels

4. debug mpls ea platform {all | errors | events | info} [ location ]

5. show cef platform trace [adj | all } common | ipv4 | ipv6 | mpls | rpf | te]

6. show cef platform { resource | trace }

7. show mpls forwarding labels label hardware egress location node id

詳細手順