はじめに
ネットワーク デバイスおよびプロトコルの複雑化とともに、ネットワーク上で起こる問題の原因究明は困難になりつつあり、特定のデバイス上でフレームが正しく送受信されているか、たびたびチェックすることが必要となっています。そういった問題を解決するための、いくつかのキャプチャツール、デバッグ、およびトリックがありますが、それら全てが実ネットワーク上で実現できるものであったり、運用が出来る状態になっているというわけではありません。
ELAM (Embedded Logic Analyzer Module)は、Cisco ASICs 内でパケットがどのように転送されているのか確認できるエンジニアリング ツールです。ELAM は、フォワーディング パイプラインに組み込まれたものであり、性能やコントロール プレーンのリソースに影響を与えることなく、リアルタイムにパケットをキャプチャできます。例えば、以下のような疑問の解決に役立ちます:
- パケットはフォワーディング エンジンに到達しているか。
- どのポートおよび VLAN でパケットが受信されているのか。
- (L2 〜 L4 データ)パケットがどのように見えるか。
- パケットはどこで変更され、どこに転送されたのか。
その他色々...
ELAM は負荷が少なく、非常に強力かつ緻密です。スイッチを扱う Cisco Technical Assistance Center (TAC) エンジニアにとって極めて重要なトラブルシューティング ツールです。
ELAM の課題
ELAM は社内用の診断ツールとして設計されました。CLI 構文は、Cisco ASICs の内部のコード名が使われているため、ELAM データの解釈には、ハードウェア固有のアーキテクチャおよびフォワーディングの知識が必要です。Cisco デバイス内部の独自実装を公開することになるため、それほど詳細は公開できません。
これらの理由により、ELAM はカスタマーサポートには対応していない社内用の診断ツールとなっています。外部用のコンフィグレーションガイドは無く、構文および動作は予告なしに変更されることがあります。
このような免責事項および課題があるにも関わらず、なぜ今、ELAM について考察するのでしょうか。
まず、TAC エンジニアは、問題を特定するために ELAM を利用することが一般的です。あなたの問題が断続的であった場合、TAC から ELAM を実行するよう求められることもあるかも知れません。ここで理解して頂きたいのは、その手順は負荷が少なく、問題の根本的原因の分析に役立つものだということです。
また、他のツールでは問題の切り分けができないことがあります(例えば、SPAN、ACL ヒット数、出力が多いデバッグなど、稼働中に変更を行うことが難しい場合があります)。TAC に連絡する時間が取れない場合、ELAM はあなたの持つ最後の手段として非常に有効なツールとなります。
ELAM の基本事項
ELAM は、各プラットフォームの完全なアーキテクチャの知識が無くても実行できます。このセクションでは、Nexus 7000 並びに Catalyst 6500 および 7600 のプラットフォーム上で ELAM を実行するための基本事項を示します。
ELAM ワークフロー
前述にある通り、ELAM は基盤となるハードウェアに依存するため、CLI 構文も使用するハードウェアに依存します。ただし、各プラットフォームでは以下の図が示すようなワークフローに従います。このワークフローが、異なるプラットフォームでどのように適用されているのかについては、ELAM Examples のセクションを参照してください。
![elam_workflow.png](/legacyfs/online/legacy/5/6/3/165365-elam_workflow.png)
- 入力フォワーディング エンジン(FE)を識別します。プラットフォームが複数の FE を持っている場合、キャプチャしようとしているパケットの転送を決定している FE を識別することが重要です。その上で、適切な FE の ELAM を設定します。
- ELAM トリガーを設定します。キャプチャしたいパケットの詳細をトリガーとして設定する必要があります。一般的に、トリガーには送信元 IP アドレスおよび宛先 IP アドレス、またはレイヤ 4 のポート番号が含まれます。 ELAM は複数のフィールドを指定することができ、すべてのフィールドで論理積を行います。
- ELAM を実行します。
- ELAM のトリガーが作動し、結果が表示されるのを待ちます。
中央集中型フォワーディングと分散型フォワーディング
ELAM を実行する最初のステップは、適切なフォワーディング エンジン(FE)を識別することです。 Catalyst 6500 の クラシック ライン カード や、中央集中型フォワーディング(CFC) ラインカード は、アクティブなスーパバイザが転送先の決定を行う中央集中型フォワーディングを利用します。クラシック ライン カードもしくは CFC ラインカードに入ってくるパケットの場合、アクティブなスーパバイザ上で ELAM を実行する必要があります。
分散フォワーディング(DFC)対応のラインカードによる転送先の決定は、ラインカード上の FE によって局所的に決まるため、スーパバイザには送信されません。 DFC ラインカードに入ってくるパケットの場合、ラインカード上で ELAM を実行する必要があります。
Nexus 7000 の場合、すべてのラインカードが完全分散型で、ほとんどのラインカードで複数の FE を持っています。この場合、パケットを受信するポートを知る必要があり、そのポートにマップする FE を決定します。
ハードウェアと転送アーキテクチャの詳細については、以下の URL 先を参照してください。
BRKARC-3465 Cisco Catalyst 6500 Switch Architecture
https://ciscolive365.com/connect/sessionDetail.ww?SESSION_ID=7674
BRKARC-3470 - Cisco Nexus 7000 Switch Architecture
https://ciscolive365.com/connect/sessionDetail.ww?SESSION_ID=7677
データ バス(DBUS)およびリザルト バス(RBUS)
DBUS は、 FE が転送先を決定するために使用する情報が含まれています。プラットフォーム特有の内部フィールドや、フレームのヘッダ情報が含まれています。 DBUS で確認できるレイヤ 2〜4 の情報は、パケットが受信された場所の判定に役立ちます。
RBUS は、 FE による転送決定情報が含まれています。 RBUS を確認することによって、フレーム変更の有無および送信元の判定に役立ちます。
ローカルターゲット ロジック(LTL)
LTL は、ポートまたはポートのグループを表すために使用されるインデックスです。送信元 LTL インデックスおよび宛先 LTL インデックスによって、フレームがどこで受信されたのか、どこに送信されたのかを知ることができます。プラットフォームやスーパバイザによって、LTL の値をデコードするためのコマンドは異なります。
Flood ビット
LTL の値は 5 桁以下の 16 進数で表示されます(0xa2c など)。 Flood ビットは LTL における 16 番目のビットです。 RBUS は、宛先 LTL インデックスと、 Flood ビットを分けて表示する場合もあります。正確な LTL を得るためには、これらをマージする必要があります。以下に例を示します。
RBUS data:
FLOOD ........................... [1] = 1
DEST_INDEX ...................... [19] = 0x48
この例では、宛先 LTL インデックスは 0x48 となっています。 Flood ビットが 1 であるため、 LTL の 16 番目のビットに 1 を設定する必要があります。
0x00048 = 0000 0000 0000 0100 1000
|
+---- Flood bit, set to 1 = 0x08048
Flood ビットを加えた宛先インデックスは 0x8048 となります。
ELAM Examples
ELAM によって基本的な IPv4 や IPv6 のユニキャストフローを検証する例を以下に示します。 ELAM の課題のセクションで説明したように、すべての内部フィールドやパケットのタイプ(再循環マルチキャスト、トンネル、 MPLS など)を説明できるというわけではありません。
- ELAM Example: Sup720
- ELAM Example: Sup720 (日本語訳)
- ELAM Example: Sup2T
- ELAM Example: Sup2T (日本語訳)
- ELAM Example: Nexus7000 M-series
- ELAM Example: Nexus7000 M-series (日本語訳)
- ELAM Example: Nexus7000 F1
- ELAM Example: Nexus7000 F1 (日本語訳)
- ELAM Example: Nexus7000 F2
- ELAM Example: Nexus7000 F2 (日本語訳)
参考として、モジュール タイプごとに ELAM で使用される内部 ASIC 名を次の表に示します。
プラットフォーム | モジュール タイプ | 内部 ASIC 名 |
---|
Catalyst 6500/ Cisco 7600 | Sup720 (PFC3, DFC3) | Superman |
Catalyst 6500 | Sup2T (PFC4, DFC4) | Eureka |
Nexus 7000 | M-Series | Eureka |
Nexus 7000 | F1 | Orion |
Nexus 7000 | F2 | Clipper |
カスタマー向け ELAM 利用法
IOS 12.2(50)SY 以降、Catalyst 6500 Sup2T で “show platform datapath” コマンドが追加されています。このコマンドは、 ELAM でのキャプチャおよび特定のパケットの転送結果の表示に利用できます。
Nexus 7000 の バージョン 6.2(2) では、 ELAM を容易に使用するための "elame" スクリプトが追加されています。
N7KA# source sys/elame
elam helper, version 1.015
Usage:
elame [<src>] <dest> [vlan <vlan#>] [vrf <vrf_name>] [int <interface> | vdc] [trace]
where
<src>, <dest> are ipv4 addresses in form 1.2.3.4
<vlan>, <interface> - indicate ingress vlan/interface
vdc - use all elams in current vdc
trace - keep record of all outputs in volatile:elame.log
英語版:https://supportforums.cisco.com/docs/DOC-36219