ルータ : Cisco 12000 シリーズ ルータ

トラブルシューティング:Cisco 12000 シリーズ インターネット ルータでの ignored パケットとメモリ不足による廃棄

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2002 年 4 月 16 日) | 英語版 (2015 年 4 月 22 日) | フィードバック


目次


概要

この文書は、Cisco 12000 シリーズ インターネット ルータでの show interfaces コマンドの出力が、ignored エラーの数の増加を示している場合のトラブルシューティング方法を説明しています。 それはまた mem ドロップどんどん増えるにトラブルシューティング に 役立つ ヒントを execute-on slot <slot #> show controllers (frfab の出力の提供しません | こうしたエラーのトラブルシューティングを行う場合は、カウンタが単なる履歴値ではなく、増加していることを確認してください。

show interfaces の出力に表示される入力キューのドロップ(廃棄)数の増加については、この文書ではなく、「トラブルシューティング:Cisco 12000 シリーズ インターネット ルータでの入力ドロップ」で説明しています。

前提条件

要件

この文書を読むには、Cisco 12000 シリーズ インターネット ルータ アーキテクチャを理解している必要があります。特に、ToFab キューと FrFab キューの理解が必要です。 show controllers frfab の出力の読み方参照して下さい | 参照用の tofabキューコマンド

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • Cisco IOSか。 Cisco 12000 シリーズ インターネット ルータをサポートするソフトウェア リリース。 通常は、12.0S および 12.0ST リリースです。

  • この文書では Cisco 12000 プラットフォームのすべてを対象としています。 これには、12008、12012、12016、12404、12410、および 12416 が含まれます。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

症状

Cisco 12000 シリーズ インターネット ルータでは、分散アーキテクチャを使用して転送パフォーマンスを最適化しています。 高い転送レートをサポートするために、着信および発信ラインカードの両方でパケット バッファを保持しています。 これらのパケット バッファにはさまざまなサイズがあり、通常は Maximum Transmission Unit(MTU; 最大伝送ユニット)サイズのフレームをサポートするように設計されています。

パケットの発信インターフェイスを決定した後、転送プロセッサは次の処理を行います。

  1. 転送プロセッサはパケットの情報(メモリ上の位置など)を指し示すポインタを、発信インターフェイスの仮想出力キューに送信します。

  2. ラインカードのスケジューラが、スケジューラに要求を出します。 マスター スケジューラが許可を出し、パケットはバッファ メモリからスイッチング ファブリックを経由して発信ラインカードに転送されます。

  3. 発信ラインカードはパケットをバッファに入れます。

  4. 発信 LC の L3 プロセッサおよび関連する Application-Specific Integrated Circuits(ASIC; 特定用途集積回路)が、インターフェイスからパケットを伝送します。

発信インターフェイスが輻輳状態になると、超過パケットのバッファリングが始まります。 輻輳状態が続いている間、発信 LC の送信キューは満杯の状態が続きます。 この場合は、発信 LC のエンジン タイプに応じて次のことが起こります。

発信 LC のエンジン タイプ 発信輻輳への対応 エラー カウンタ
エンジン 0 および 1 バックプレッシャ信号を送信する。 着信インターフェイスは超過パケットのバッファリングを開始する。 show interfaces コマンド出力の無視された エラーおよび/または L3 フォワーディングエンジンによる受信 LC の execute-on slot <slot#> show controllers tofab qm stat コマンド出力の mem ドロップ無し。か。
エンジン 2、3、4 出力側の超過パケットをすべてドロップする。 発信 LC での execute-on slot <slot #> show controllers frfab QM stat コマンド出力の no mem drop。

?L3 エンジンのための無視された エラーを 0、1、および 2 入力 LC 得ます。 しかし、エンジン 2 LC のポート数が 4、16、およびそれ以上の場合、このカウンタは増えません。

インテリジェントなネットワーク デバイスでは、1 つまたは複数の高速インターフェイスが相対的に低速のインターフェイスにデータを送信する場合、インターフェイスの速度に不一致が生じます。 低速の発信インターフェイスは、高速の着信インターフェイスが出力保留キューにデータを送信する速さではバッファを戻せないため、その部分で生じた遅れがある種のドロップにつながります。 このパケットの流れにより、発信インターフェイスはバッファの管理速度でバッファを戻すという前提が崩れます。

インターフェイス速度の不一致に加えて、到達するパケットの速度が CPU の処理速度を超えると、ignored エラーの数が増えます。 Cisco 12000 ではこうした状況はほとんど起こりませんが、通常は非常に小さいパケットが大量に到達した場合や、Access Control List(ACL; アクセス コントロール リスト)やトラフィック ポリシングなどの CPU 中心の機能がソフトウェアに実装されている LC で、これらの機能が有効になっている場合などに、このような状況が発生します。 この問題は、多くの機能がソフトウェアに実装されているエンジン 0 LC でよく起こります。 しかし、それ以降のエンジンでは、ほとんどすべての機能がハードウェアに実装されています。 たとえば、エッジ アプリケーション向けに設計されているエンジン 3(IP Services Engine(ISE; IP サービス エンジン))とエンジン 4+ のラインカードは拡張 IP サービス(QOS など)をハードウェアに実装していて、パフォーマンスに影響が生じることはありません。 このハードウェアには、1 ポート CHOC-48 ISE、4 ポート CHOC-12 ISE、16 ポート OC-3 POS ISE、4 ポート OC-12 POS ISE、1 ポート OC-48 POS ISE、1 ポート OC-48 POS ISE などの種類があります。

ignored カウンタは、入力ラインカードに到達したパケットを処理するために適切なサイズのバッファが使用できない場合にも増えます。 しかしこの状態は非常にまれなので、この文書では説明していません。

発信インターフェイスの加入過多の管理

引き起こされるアウトプットインターフェイス 加入超過による無視された エラーおよび mem ドロップへのソリューションはあらゆる L3 エンジン型のため同じではないです -- バッファ飢餓を防いで下さい。 つまり、FrFab キューがいっぱいにならないようにするメカニズムが必要になります。

エンジン 0 および 1

簡単に説明すれば、ignored カウンタが増えるのは、入力 Line Card(LC; ラインカード)に到達したパケットを処理するために適切なサイズのバッファが使用できない場合です。 そのため一般的には、ignored パケットが Cisco IOS ソフトウェアのバグを示すことはありません。

Cisco 12000 シリーズ ルータで、0 以外の ignored カウンタを持つ show interfaces コマンドの出力例を次に示します。

router#show interfaces G3/0
GigabitEthernet3/0 is up, line protocol is up
  Hardware is GigMac GigabitEthernet, address is 0030.71f5.7980 
     (bia 0030.71f5.7980)
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Full-duplex mode, link type is force-up, media type is SX
  output flow-control is unsupported, input flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:00:07
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 99000 bits/sec, 74 packets/sec
  5 minute output rate 104000 bits/sec, 68 packets/sec
    478 packets input, 71057 bytes, 0 no buffer
    Received 19 broadcasts, 0 runts, 0 giants, 0 throttles
    2 input errors, 2 CRC, 0 frame, 0 overrun, 25 ignored

    !--- Ignored counter is > 0. Ensure it is incrementing.

    
    0 watchdog, 53 multicast, 0 pause input
    541 packets output, 139133 bytes, 0 underruns
    0 output errors, 0 collisions, 0 interface resets
    0 babbles, 0 late collision, 0 deferred
    0 lost carrier, 0 no carrier, 0 pause output
    0 output buffer failures, 0 output buffers swapped out

発信 LC がエンジン 0 または 1 の場合は、この発信 LC にこれ以上データを送信しないよう伝えるバックプレッシャ メッセージが発信 LC から他の LC に送信されます。 着信インターフェイスはこの指示を受けて、この宛先スロットに対応する ToFab キューに超過パケットをバッファリングします。

ignored カウンタが増える最も可能性の高い原因を切り分けるためには、入力 LC の ToFab キューを調べる必要があります。 ToFab キューをチェックするには、attach コマンドを使用して Maintenance BUS(MBUS; メンテナンス バス)経由で LC に接続するか、または execute-on slot <slot#> show controllers tofab queue コマンドを使用します。 このコマンドを数回実行して、次の症状があるかどうかを調べます。

  • 非 IPC フリー キューの #Qelem カラムの値が減少していて小さい、または 0 であること。

  • 宛先スロットのキューの #Qelem カラムの値が大きいこと。

エンジン 2、3、4

最近の L3 エンジン アーキテクチャを使用したラインカードは、バックプレッシャ メカニズムを使用しません。 その代わりに、インターフェイスが輻輳状態で、 FrFab キューがいっぱいになった場合、パケットは出力ラインカードに到達した時点でドロップされます。

エンジン 2 LC は、小さなバッファ プールがいっぱいになると、次に大きいプールに「フォールバック」します。 たとえば、エンジン 2 LC が 300 バイトのパケットを格納する必要がある場合、まず 608 バイトのバッファを持つプールからバッファを要求します。 このプールが空の場合は、1568 バイトのプールからバッファを得ようとします。

こうしたドロップは、次のように execute-on slot <slot #> show controllers frfab QM stat コマンド出力の no mem drop(メモリ不足によるドロップ)としてカウントされます。

Router#execute-on slot 1 show controller
frfab QM stat
========= Line Card (Slot 1) =======

174 no mem drop, 0 soft drop, 0 bump count 

!--- Look for an incrementing value for the "no mem drop" counter

0 rawq drops, 0 global red drops, 0 global force drops
0 no memory (ns), 0 no memory hwm (Ns)
no free queue
0       0       0       0
0       0       0       0
0       0       0       0
0       0       0       0
0 multicast drops
Tx Counts
 Interface 0
8390658710246 TX bytes, 2098330790 TX pkts, 212452 kbps, 6641 pps
 Interface 1
0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 2
0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 3
0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS

LC で着信インターフェイスの輻輳や単純にパケットがドロップされてしまうほど、FrFab 側でパケットがバッファリングされないようにする方法を見つける必要があります。

エンジン 2 LC を除くすべてのラインカードで有効な解決策として、マルチインターフェイスの LC の特定の発信インターフェイスで使用可能なバッファの数を減らす方法があります。 デフォルトでは、インターフェイスは分割された FrFab バッファのすべてを使用できます。 デフォルト以外の値を設定するには、tx-queue-limit コマンドを使用します。 これにより、特定のポート用のインターフェイス キューに設定された数を超えるパケットが出力 LC にバッファリングされる事態を回避できます。 このコマンドには必ず、このインターフェイス用のすべての FrFab キューが含まれないような小さい数を設定してください。 この方法は優先順位の高いパケットと低いパケットを区別せず、特定のインターフェイスのパケットに対して無条件にテール ドロップを行う点に注意してください。

エンジン 3 ラインカードでは、従来の Command Line Interface(CLI; コマンドライン インターフェイス)の代わりに、Modular QoS CLI(MQC; モジュラ QoS CLI)を使用する必要があります。 このコマンドはエンジン 2 ベースのラインカードではサポートされていません。

従来の Class of Service(COS; サービス クラス)設定を使用した設定例を次に示します。

interface POS 0/0
    tx-queue-limit <max Q length in packets>

MQC を使用した設定例を次に示します。

policy-map TX_QUEUE_LIMIT
    class class-default
        queue-limit 

interface POS 0/0
    service-policy out TX_QUEUE_LIMIT

さらに高速の出力インターフェイスを実装して、パイプを太くするという解決策もあります。 しかしより大きいパイプはすぐに一杯になできます。 従って、推奨される ソリューションは発信 LC の Quality of Service (QoS) メカニズムを設定することです。

Cisco の Weighted Random Early Detection(WRED; 重み付けランダム早期検出)機能は、差別化されたインテリジェントなドロップメカニズムを実現します。 この機能は、TCP フローなどの適応型のトラフィックを扱えるよう設計されています。 キュー サイズを監視し、計算した平均キューが設定可能な最小しきい値を超えると、複数のフローからランダムにパケットをドロップして、一定の平均キュー サイズを維持しようとします。

Cisco 12000 シリーズに WRED を実装すると、FrFab キューがいっぱいになる事態が回避され、ドロップするパケットを選択できます。 エンジン 0 LC はソフトウェアで WRED をサポートしますが、エンジン 1 LC は WRED をまったくサポートしません。 その他の L3 エンジンの LC はハードウェアで WRED をサポートします。

WRED の設定に関する詳細については、これらの文書を参照して下さい:

この輻輳回避メカニズムが機能するのは、TCP ベースの環境だけです。 TCP はトラフィック転送の速度を落とすことで、適切かつ確実にトラフィックのドロップに対応します。 TCP によるパケット損失の対処方法については、「TCP によるトラフィック損失の対処方法」と「ルータと TCP との相互作用」を参照してください。

Cisco 12000 シリーズ ルータでサポートされている QOS メカニズムにはその他に、Committed Access Rate(CAR; 専用アクセス レート)を使用するトラフィック ポリシング(エンジン 0 LC)と、Per Interface Rate Control(PIRC)と呼ばれる CAR の変更バージョン(エンジン 2 LC)があります。 発信インターフェイスでトラフィック ポリシングを設定してください。

着信ラインカードでの過負荷状態の CPU の管理

この状況が起こるのは非常にまれです。

着信 LC の CPU に負荷がかかりすぎているかどうかをチェックするには、execute-on slot <slot #> show controllers tofab queues コマンドを使用します。 「Raw Queue」行の #Qelem カラムの数が非常に大きい場合は、大量のパケットを(LC 自体に搭載されている)CPU で処理しようとしていることを表しています。 この場合はパケットの量に CPU の処理が追いつかないため、ignored パケットが増え始めます。 これらのパケットは、Gigabit Route Processor(GRP; ギガビット ルート プロセッサ)ではなく、LC の CPU に送信されます。

この時点で行うべきことは、トラフィックの一部をこの着信 LC から他へ移動し、CPU への影響を軽減させることです。

また、LC の設定を調べて、CPU に影響を与える機能が LC に設定されていないかどうかをチェックします。 一部の機能(CAR、ACL、NetFlow など)がソフトウェアに実装されているために、LC のパフォーマンスを悪化させている可能性があります(エンジン 0 LC の場合のみ)。 この場合は該当する機能を削除するか、その機能の実装方法が改善されている新しいリリースに Cisco IOS ソフトウェアをアップグレードする必要があります(ターボ ACL など)。 各種 LC の実装機能や改良済みの機能を調べるには、「Cisco 12000 シリーズ ルータのリリース ノート」を参照してください。

最終的には、使用している LC を、必要な機能をハードウェアに実装している最近の LC に交換する以外に解決策がない場合があります。 これは LC のエンジン タイプによります。

次のショートカット コマンドを使用すると、LC の L3 エンジン タイプを調べることができます。

Router#show diag | i (SLOT | Engine)
...
SLOT 1  (RP/LC 1 ): 1 port ATM Over SONET OC12c/STM-4c Multi Mode
  L3 Engine: 0 - OC12 (622 Mbps)
SLOT 3  (RP/LC 3 ): 3 Port Gigabit Ethernet
  L3 Engine: 2 - Backbone OC48 (2.5 Gbps)
...

エンジン 3(ISE)とエンジン 4+ のラインカードはエッジ アプリケーション向けに設計されていて、拡張 IP サービス(QOS など)をハードウェアに実装しているため、パフォーマンスに影響が生じることはありません。

設計ガイドラインの要約

  • ターボ ACL を使用します。これにより、ACL をルータでコンパイルしてから LC プロセッサにダウンロードできるので、パフォーマンスが最適化されます。

  • ACL で「log」キーワードを使用しないようにします。

  • 可能な場合は、発信 ACL を使用しないようにします。 エンジン 0、1、2 の LC が搭載されたシステムでは、ACL のすべての処理が着信 LC で行われます。 パケットの宛先となる発信インターフェイスが判明すると、発信 ACL フィルタリングでさえ着信カードで行われます。 こうした理由から、インターフェイスで発信 ACL を設定すると、システムのすべての LC に影響がおよびます。 また、エンジン 2 LC は、着信 ACL と発信 ACL のどちらも実行できますが、ハードウェア転送を実行する ASIC で両方同時に実行するわけではありません。 LC に着信 ACL と発信 ACL の両方を設定すると、発信アクセス リストに対しては CPU ベースの転送へとフォールバックされるため、LC のスイッチング パフォーマンスに影響がおよびます。 ただし、エンジン 3 やエンジン 4+ などの新しいエンジンは、ACL などの拡張 IP サービス向けに高度に最適化されており、発信 LC で発信 ACL を処理します。

  • 特定の機能を必要とするトラフィックを特定の LC のセットに割り当てます。

  • 機能を必要としないトラフィックを他の LC のセットに割り当て、ピーク時のパケット転送のパフォーマンスが下がらないようにします。

  • 高いパフォーマンスが必要な場合は、上位のエンジン タイプを持つ LC を使用します。

  • バックボーンまたはコアの方向に接続する LC で、ハードウェアまたはマイクロコードでサポートされる機能を実行するように設計します。

ケース スタディ

このケース スタディでは、スロット 6 の LC のインターフェイスで増えている ignored エラーのトラブルシューティング方法を示します。

手順 1 - スロット 6 の ToFab キューをチェックする。

Router#exec slot 6 show controllers tofab queue
========= Line Card (Slot 6) =======
Carve information for ToFab buffers
   SDRAM size: 134217728 bytes, address: 30000000, carve base: 30019100
   134115072 bytes carve size,  4 SDRAM bank(s), 8192 bytes SDRAM pagesize,
      2 carve(s)
   max buffer data size 4544 bytes, min buffer data size 80 bytes
   174538/174538 buffers specified/carved
   110797216/110797216 bytes sum buffer sizes specified/carved
        Qnum    Head    Tail            #Qelem  LenThresh
        ----    ----    ----            ------  ---------

   4 non-IPC free queues:
        88964/88964 (buffers specified/carved), 50.97%, 80 byte data size
        1       21120          84604     81074   262143
        54076/54076 (buffers specified/carved), 30.98%, 608 byte data size
        2       122270         116965    49567   262143
        26165/26165 (buffers specified/carved), 14.99%, 1568 byte data size
        3       164160         145355    19518   262143

        !-- Out of the 26165 buffers that are carved, only 19518 are available

        5233/5233 (buffers specified/carved), 2.99%, 4544 byte data size
        4       172325         172088    5233    262143
   IPC Queue:
        100/100 (buffers specified/carved), 0.5%, 4112 byte data size
        30      61             60              100     262143
   Raw Queue:
        31      44229          88895        0       43634

        !-- The Raw Queue has a low or 0 value for the #Qelem column, indicating
        !-- that the CPU is not overwhelmed with packets destined to it.

   ToFab Queues:
        Dest
        Slot
        0       73769          60489           0       262143
        1       7909           27395           0       262143
        2       61416          71346           0       262143
        3       80352          14567           0       262143
        4       138236         107121        18955     262143     

        !-- 18955 packets are waiting for space in the outbound queues
        !-- on the LC in slot 4.

        5       4852           48171           0       262143
        6       98318          111757          0       262143
        7       44229          88895           0       262143
        8       0              0               0       262143
        9       0              0               0       262143
        10      0              0               0       262143
        11      0              0               0       262143
        12      0              0               0       262143
        13      0              0               0       262143
        14      0              0               0       262143
        15      0              0               0       262143
 Multicast      0              0               0       262143

手順 2 - スロット 4 の FrFab キューのチェック

ToFab キューの出力は、キューに置かれている多くのパケットがスロット 4 の LC を宛先としていることを示しているため、この LC の FrFab キューをチェックします。

Router#exec slot 4 show controllers frfab queue
========= Line Card (Slot 4) =======
Carve information for FrFab buffers
   SDRAM size: 67108864 bytes, address: 20000000, carve base: 2002D100
   66924288 bytes carve size,  0 SDRAM bank(s), 0 bytes SDRAM pagesize, 
      2 carve(s)
   max buffer data size 4544 bytes, min buffer data size 80 bytes
   65534/65534 buffers specified/carved
   66789056/66789056 bytes sum buffer sizes specified/carved
        Qnum    Head    Tail            #Qelem  LenThresh
        ----    ----    ----            ------  ---------
   4 non-IPC free queues:
        
        26174/26174 (buffers specified/carved), 39.93%, 80 byte data size
        1       10123   4332            14515   65535
        
        19630/19630 (buffers specified/carved), 29.95%, 608 byte data size
        2       27898   37167           12279   65535
        
        13087/13087 (buffers specified/carved), 19.96%, 1568 byte data size
        3   0       52275          0       65535        

        !-- Zero buffers available for this pool

        
        6543/6543 (buffers specified/carved), 9.98%, 4544 byte data size
        4       60805   60804           6543    65535
   
   IPC Queue:
        
        100/100 (buffers specified/carved), 0.15%, 4112 byte data size
        30      75      74              100     65535
   
   Raw Queue:
        
        31      0       80              0       65535
   
   Interface Queues:
        
        0       0       39413           0       65535
        1       0       44192           0       65535
        2       48426   58230           32111   65535     

        !-- Interface 2 is using half or 32111 of the carved packet buffers

        3       0       41219           0       65535

手順 3 - オーバースクライブ状態の同じインターフェイスを対象にした show interfaces コマンド出力の比較

show controllers frfab queue の出力に示された輻輳状態のインターフェイスを、同じインターフェイスの show interfaces の出力と比較します。 次の出力から、出力インターフェイス速度が回線速度と同じであり、輻輳状態にあることがわかります。

Router#show interfaces POS 4/2
POS4/2 is up, line protocol is up
  Hardware is Packet over SONET
  Description: Pacbell OC3 to other ISP...
  Internet address is 10.10.10.10/30
  MTU 4470 bytes, BW 155000 Kbit, DLY 100 usec, rely 255/255, load 156/255
  Encapsulation HDLC, crc 32, loopback not set
  Keepalive set (10 sec)
  Scramble enabled
  Last input 00:00:01, output 00:00:03, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy: FIFO  Output queue 0/300, 0 drops; input queue 0/300, 
     0 drops
  5 minute input rate 20274000 bits/sec, 6263 packets/sec
  5 minute output rate 148605000 bits/sec, 28776 packets/sec
  
!-- The output interface rate is at line rate which means that the interface 
  !-- is oversubscribed.


     1018621328 packets input, 2339977099 bytes, 0 no buffer
     Received 0 broadcasts, 1 runts, 0 giants, 0 throttles
              0 parity
     1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     378645 packets output, 156727974 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     1 carrier transitions

手順 4 - ソリューションの実装

このステップでは、特定の発信インターフェイスのアーキテクチャに基づいて増加する ignored エラーを解決します。解決策については、この文書の「症状」の項を参照してください。 たとえばエンジン 0 LC では、一部のトラフィックを他のインターフェイスに振り分けるようにするか、一時的な措置として、このインターフェイスがラインカードのフリー キューから使用できるパケット バッファの数を減らします。 次のコマンドを使用します。

Router(config)#int POS 4/2
Router(config-if)#tx-queue-limit 5000

Cisco IOS ソフトウェアの不具合

Cisco IOS ソフトウェアのバグが原因でカウンタが増える場合があります。 該当するトレインの最新の Cisco IOS ソフトウェア リリースを使用していて、すでに修正済みのバグがすべて取り除かれていることを確認してください。 それでも ignored パケットが解消されず、この文書の情報では問題が解決しない場合は、Cisco Technical Assistance Center(TAC)にお問い合せください。


関連情報


Document ID: 18003