ACIでのスイッチドポートアナライザ(SPAN)の設定

概要

このドキュメントでは、シスコアプリケーションセントリックインフラストラクチャ(ACI)でスイッチドポートアナライザ(SPAN)を設定する方法について説明します。 

背景説明

一般に、SPANには3つのタイプがあります。ローカルSPAN、リモートSPAN(RSPAN)、およびEncapsulated Remote SPAN(ERSPAN) これらのSPANの違いは、主にコピーパケットの宛先です。Cisco ACIはローカルSPANおよびERSPANをサポートします。

Cisco ACIのSPANタイプ

Cisco ACIには、ファブリックSPAN、テナントSPAN、およびアクセスSPANの3種類のSPANがあります。各SPANの違いは、コピーパケットの送信元です。

すでに述べたように –

• ファブリックSPANは、リーフスイッチとスパインスイッチ間のインターフェイスで送受信されるパケットをキャプチャします。
• アクセスSPANは、リーフスイッチと外部デバイス間のインターフェイスで送受信されるパケットをキャプチャします。
• テナントSPANは、ACIリーフスイッチ上のエンドポイントグループ(EPG)で送受信されるパケットをキャプチャします。

このSPAN名は、Cisco ACI GUIで設定する場所に対応します。

• ファブリックSPANは、Fabric > Fabric Policiesで設定します。
• アクセスSPANは、Fabric > Access Policiesで設定します。
• テナントSPANはTenants > {each tenant}で設定します。

各SPANの宛先に関しては、アクセスSPANだけがローカルSPANとERSPANの両方に対応できます。他の2つのSPAN（ファブリックとテナント）は、ERSPANのみを実行できます。

制限事項とガイドライン

『Cisco APIC Troubleshooting Guide』の「Limitations & Guidelines」を参照してください。これは、「トラブルシューティングツールと手法> SPANの使用」で説明されています。

コンフィギュレーション

このセクションでは、各SPANタイプの設定に関連する簡単な例を紹介します。後のセクションで、スパンのタイプを選択する方法について特定のサンプルケースがあります。

SPANの設定については、『Cisco APIC Troubleshooting Guide: Troubleshooting Tools and Methodology』 > 「Using SPAN」でも説明しています。

UIは現在のバージョンとは異なる場合がありますが、設定方法は同じです。

アクセスSPAN(ERSPAN)

トポロジの例

設定例

場所：

FABRIC > ACCESS POLICIES > Troubleshoot Policies > SPANの順に移動します。

• SPANソースグループ
• SPAN宛先グループ

SPAN送信元グループは、宛先と送信元を結び付けます。

方法：

1. SPANソースグループ(SRC_GRP1)を作成します。
2. SPAN Source Group(SRC_GRP1)の下にSPAN Source(SRC1)を作成します。
3. SPAN Source(SRC1)の次のパラメータを設定します。
   – 方向 – ソースEPG（オプション）
   – 送信元パス（複数のインターフェイスを指定できます）
   
   

   注：各パラメータの詳細については、図を参照してください。

4. SPAN宛先グループ(DST_EPG)を作成します。
5. SPAN Destination(DST)を作成します。
6. SPAN Destination(DST)の次のパラメータを設定します
   – 宛先EPG
   -宛先 IP
   – 送信元IP/プレフィクス(任意のIPを指定できます。プレフィックスが使用される場合、未定義ビットにはソースノードのノードIDが使用されます。たとえば、node-101のprefix: 1.0.0.0/8 => src IP 1.0.0.101)
     – その他のパラメータはデフォルトのままにしておくことができます。
   
   

   注：各パラメータの詳細については、図を参照してください。

7. SPAN宛先グループが適切なSPAN送信元グループに関連付けられていることを確認します。
8. Admin Stateが有効になっていることを確認します。
   
   

   注：この管理状態でDisabledを選択すると、SPANは停止します。後で再利用する場合は、すべてのポリシーを削除する必要はありません。

また、ERSPANの宛先IPが、指定された宛先EPGの下のエンドポイントとして学習されていることを確認してください。前述の例では、192.168.254.1をTenant TK > Application profile SPAN_APP > EPG SPANで学習する必要があります。または、宛先デバイスがサイレントホストの場合、このEPGの下で宛先IPをスタティックエンドポイントとして設定できます。

アクセスSPAN（ローカル）

トポロジの例

設定例

• 場所：

Fabric > ACCESS POLICIES > Troubleshoot Policies > SPAN

- SPANソースグループ

- SPAN宛先グループ

SPAN送信元グループは、宛先と送信元を結び付けます.



• 方法：

1. SPANソースグループ(SRC_GRP1)の作成
2. SPAN Source Group(SRC_GRP1)の下にSPAN Source(SRC1)を作成します
3. SPAN Source(SRC1)の次のパラメータを設定します
   -方向
   – ソースEPG（オプション）
   – 送信元パス（複数のインターフェイスを指定できます）
   ※各パラメータの詳細は画像を参照してください。
4. SPAN宛先グループ(DST_Leaf1)の作成
5. SPAN宛先(DST)の作成
6. SPAN Destination(DST)のこれらのパラメータを設定します
   – 宛先インターフェイスおよびノード。
7. SPAN宛先グループが適切なSPAN送信元グループに関連付けられていることを確認します。

8. Admin Stateが有効になっていることを確認します。
   こ※管理状態でDisabledを選択すると、SPANが停止します。後で再利用する場合は、すべてのポリシーを削除する必要はありません。

宛先インターフェイスでは、インターフェイスポリシーグループによる設定は必要ありません。ACIリーフのインターフェイスにケーブルを接続すると機能します。

制限事項：

• ローカルSPANでは、宛先インターフェイスと送信元インターフェイスを同じリーフ上に設定する必要があります。
• 宛先インターフェイスは、UPである限り、EPG上にある必要はありません。
• 仮想ポートチャネル(vPC)インターフェイスが送信元ポートとして指定されている場合、ローカルSPANは使用できません 
  ただし、回避策があります。第1世代のリーフでは、vPCまたはPCのメンバである個々の物理ポートをSPANソースとして設定できます。このローカルSPANを使用して、vPCポート上のトラフィックに使用できます。
  ただし、このオプションは第2世代リーフでは使用できません(Cisco Bug ID CSCvc11053)。 代わりに、「VPCコンポーネントPC」でのSPANのサポートは、Cisco Bug ID CSCvc44643(2.1(2e)、2.2(2e)以降で追加されています。これにより、どの世代のリーフでも、vPCのメンバであるポートチャネルをSPANソースとして設定できます。これにより、どの世代のリーフでも、vPCポート上のトラフィックにローカルSPANを使用できます。
• 第2世代のleavesでポートチャネルの個々のポートを指定すると、パケットのサブセットのみがスパニングされます（Cisco Bug ID CSCvc11053によるも同様です）。
• PCとvPCは、ローカルSPANの宛先ポートとしては使用できません。4.1(1)からは、PCをローカルSPANの宛先ポートとして使用できます。

ACLフィルタを使用したアクセスSPAN

アクセススパンソースでACLフィルタを使用できます。この機能により、特定のフローまたはSPAN送信元に入出力されるトラフィックのフローにSPANを適用できます。
SPANフロー固有のトラフィックが必要な場合は、SPAN Aclを送信元に適用できます。
ファブリックSPANおよびテナントSPANのソースグループ/ソースではサポートされません。
フィルタグループにフィルタエントリを追加する場合は、現在フィルタグループを使用しているすべてのソースのtcamエントリが追加される可能性があるため、注意が必要です。

フィルタグループは次のものに関連付けることができます。
-Span Source：フィルタグループは、このSpan Sourceの下で定義されているすべてのインターフェイスでトラフィックをフィルタリングするために使用されます。
-Span Source Group：フィルタグループ（xなど）は、このSpan Source Groupの各Span Sourceで定義されたすべてのインターフェイスでトラフィックをフィルタリングするために使用されます。

この設定スナップショットでは、フィルタグループがSpanソースグループに適用されます。

特定のSpan Sourceがすでにフィルタグループ（yなど）に関連付けられている場合、そのフィルタグループ(y)が、この特定のSpan Sourceの下にあるすべてのインターフェイスのフィルタグループに代わって使用されます

– ソースグループに適用されたフィルタグループは、そのソースグループ内のすべてのソースに自動的に適用されます。
– 送信元で適用されるフィルタグループは、その送信元にのみ適用されます。
– フィルタグループがソースグループとそのソースグループ内のソースの両方に適用され、ソースに適用されたフィルタグループが優先されます。
– ソースに適用されたフィルタグループは削除され、親ソースグループに適用されたフィルタグループは自動的に適用されます。
– ソースグループに適用されたフィルタグループが削除され、現在そのソースグループに継承されているすべてのソースから削除されます。

テナントSPAN(ERSPAN)

トポロジの例

設定例

• 場所：

テナント> {テナント名} >ポリシーのトラブルシューティング> SPAN

- SPANソースグループ

- SPAN宛先グループ

※ SPAN送信元グループは、宛先と送信元を結び付けます。

• 方法：

1. SPANソースグループ(SRC_GRP)の作成
2. SPANソースグループ(SRC_GRP)でのSPANソース(SRC_A)の作成
3. SPAN Source(SRC_A)の次のパラメータの設定
        -方向
        – ソースEPG
   ※各パラメータの詳細は画像を参照してください。
4. SPAN宛先グループ(DST_GRP)の作成
5. SPAN宛先(DST_A)の作成
6. SPAN Destination(DST_A)の次のパラメータを設定します
        – 宛先EPG
        -宛先 IP
        – 送信元IP/プレフィックス
        – その他のパラメータはデフォルトのままにしておくことができます。
   ※各パラメータの詳細は画像を参照してください。
7. SPAN宛先グループが適切なSPAN送信元グループに関連付けられていることを確認します。
8. Admin Stateが有効になっていることを確認します。
   こ※管理状態でDisabledを選択すると、SPANが停止します。後で再利用する場合は、すべてのポリシーを削除する必要はありません。

ファブリックSPAN(ERSPAN)

トポロジの例

設定例

• 場所：

Fabric > FABRIC POLICIES > Troubleshoot Policies > SPAN

– ファブリック

- SPAN宛先グループ

SPAN送信元グループが宛先と送信元を結び付ける

• 方法：

1. SPANソースグループ(SRC_GRP)の作成
2. SPAN Source Group(SRC_GRP)の下にSPAN Source(SRC_A)を作成します
3. SPAN Source(SRC_A)の次のパラメータを設定します
        -方向
        – プライベートネットワーク（オプション）
        – ブリッジドメイン（オプション）
        – 送信元パス（複数のインターフェイスを指定できます）
   ※各パラメータの詳細は画像を参照してください。
4. SPAN宛先グループ(DST_GRP)の作成
5. SPAN宛先(DST_A)の作成
6. SPAN Destination(DST_A)の次のパラメータを設定します
         – 宛先EPG
        -宛先 IP
        – 送信元IP/プレフィックス
        – その他のパラメータはデフォルトのままにしておくことができます。
   ※各パラメータの詳細は画像を参照してください。
7. SPAN宛先グループが適切なSPAN送信元グループに関連付けられていることを確認します。
8. Admin Stateが有効になっていることを確認します。
   ※の管理状態でDisabledを選択すると、SPANが停止します。後で再利用する場合は、すべてのポリシーを削除する必要はありません。

これについては後の「ERSPANのバージョン（タイプ）」セクションで説明しますが、ERSPANバージョンIIをファブリックSPANに使用し、バージョンIをテナントSPANとアクセスSPANに使用していることを確認できます。

GUI による確認

• SPAN設定ポリシーの検証

1. Fabric > ACCESS POLICIES > Troubleshoot Policies > SPAN > SPAN Source Groups > Operationalタブ
2. [Fabric] > [FABRIC POLICIES] > [Troubleshoot Policies] > [SPAN] > [SPAN Source Groups] > [Operational]タブ
3. テナント> {テナント名} >ポリシーのトラブルシューティング> SPAN > SPANソースグループ> Operationalタブ

動作状態がupであることを確認してください。

• ノード自体でのSPANセッションの検証

1. SPAN Configuration Policy orFabric > INVENTORY > Node > Span Sessions > { SPAN session name }から、各セッションをダブルクリックします

動作状態がupであることを確認してください。

SPANセッション命名規則：

     – ファブリックSPAN:fabric_xxxx

     – アクセスSPAN:infra_xxxx
     – テナントSPAN:tn_xxxx

ACI SPANタイプの選択

このセクションでは、各ACI SPANタイプ（アクセス、テナント、ファブリック）の詳細なシナリオについて説明します。各シナリオの基本トポロジについては、前のセクションで説明しています。

これらのシナリオを理解している場合は、特定のインターフェイス上のパケットのみをキャプチャする必要がある、またはインターフェイスに関係なく特定のEPG上のすべてのパケットをキャプチャする必要があるなど、要件に適したACI SPANタイプを選択できます。

Cisco ACIでは、ソースグループと宛先グループを使用してSPANが設定されます。送信元グループには、インターフェイスやEPGなどの複数の送信元ファクタが含まれます。宛先グループには、ローカルSPANの宛先インターフェイスやESPANの宛先IPなどの宛先情報が含まれます。

パケットをキャプチャした後、キャプチャしたパケットをデコードするには、「SPANデータの読み取り方法」の項を参照してください。

アクセスSPAN(ERSPAN)

ケース 1

送信元「Leaf1 e1/11 e1/34 & Leaf2 e1/11」 | Dst 「192.168.254.1」

• ソースグループ
  • リーフ1 e1/11
  • リーフ1 e1/34
  • リーフ2 e1/11
• 通知先グループ
  • EPG Xの192.168.254.1

アクセスSPANでは、1つのSPANセッションに対して複数のインターフェイスを指定できます。EPGに関係なく、指定されたインターフェイスで送受信されるすべてのパケットをキャプチャできます。

複数のリーフスイッチから複数のインターフェイスを送信元グループとして指定する場合、宛先グループはローカルSPANではなくERSPANである必要があります。

この例では、EPG1とEPG2のすべてのVMからパケットをコピーします。

CLIのチェックポイント

• ステータスがup (active)であることを確認してください。
• destination-ipは、ERSPANの宛先IPです。
• origin-ipは、ERSPANの送信元IPです

ケース 2

送信元「Leaf1 e1/11 & Leaf2 e1/11」 | Dst 「192.168.254.1」

• ソースグループ
  • リーフ1 e1/11
  • リーフ2 e1/11
• 通知先グループ
  • EPG Xの192.168.254.1

この例では、Leaf1 e1/34が、前のCase1で設定されたSPANソースグループから削除されています。

この例のキーポイントは、アクセスSPANはEPGに関係なく送信元インターフェイスを指定できることです。

CLIのチェックポイント：

• leaf1の送信元インターフェイスが「Eth1/11 Eth1/34」から「Eth1/11」に変更されます。

ケース 3

Src "Leaf1 e1/11 & Leaf2 e1/11 & EPG1 filter" | Dst "192.168.254.1"

• ソースグループ
  • リーフ1 e1/11
  • リーフ2 e1/11
  • フィルタEPG1
• 通知先グループ
  • EPG Xの192.168.254.1

この例は、アクセスSPANが送信元ポートで特定のEPGを指定できることを示しています。これは、複数のEPGが1つのインターフェイス上を流れ、このインターフェイス上のEPG1のトラフィックのみをキャプチャする必要がある場合に便利です。

EPG1がリーフ2に展開されていないため、リーフ2のSPANが障害F1553およびF1561で失敗します。ただし、Leaf1上のSPANは引き続き動作します。

また、EPG1はLeaf1で2つのVLAN(VLAN-751、752)を使用するため、2つのVLANフィルタがLeaf1のSPANセッションに自動的に追加されます。

CLI(35、39)のVLAN IDは、いわゆるPI-VLAN(Platform Independent VLAN)と呼ばれる内部VLANであり、実際の回線上のIDではないことに注意してください。図に示すように、show vlan extendedコマンドは、実際のencap VLAN IDとPI-VLANのマッピングを示します。

このSPANセッションでは、EPG2(VLAN-753)が同じインターフェイス上を流れる場合でも、Leaf1 e1/11上のEPG1(VLAN-752)のパケットだけをキャプチャできます。

CLIのチェックポイント：

• フィルタVLANは、フィルタに使用されるEPGに従って追加されます。
• リーフに対応するEPGがない場合、そのリーフのSPANセッションは失敗します。

ケース 4

送信元「Leaf1-Leaf2 vPC」 | Dst "192.168.254.1"

• ソースグループ
  • リーフ1 - 2e1/11
• 通知先グループ
  • EPG Xの192.168.254.1

vPCインターフェイスが送信元として設定されている場合、宛先はインターフェイス（ローカルSPAN）ではなくリモートIP(ERSPAN)である必要があります

アクセスSPAN（ローカルSPAN）

ケース 1

送信元「Leaf1 e1/11 e1/34」 | Dst「Leaf1 e1/33」

• ソースグループ
  • リーフ1 e1/11
  • リーフ1 e1/34
• 通知先グループ
  • リーフ1 e1/33

アクセスSPANは、ローカルSPAN（宛先として特定のインターフェイス）を使用することもできます

ただし、この場合、送信元インターフェイスは宛先インターフェイスと同じリーフ上に存在する必要があります。

ケース 2

Src "Leaf1 e1/11 e1/34 & EPG1 filter | Dst " Leaf1 e1/33"

• ソースグループ
  • リーフ1 e1/11
  • リーフ1 e1/34
  • EPG1フィルタ
• 通知先グループ
  • リーフ1 e1/33

ローカルSPANを使用するアクセスSPANは、ERSPANと同様にEPGフィルタも使用できます。

ケース 3

Src "Leaf1 e1/11 & Leaf2 e/11" | Dst "Leaf1 e1/33" （悪いケース）

• ソースグループ
  • リーフ1 e1/11
  • リーフ2 e1/11
• 通知先グループ
  • リーフ1 e1/33

ケース 4

Src "Leaf1 e1/11 & EPG3 filter" | Dst "Leaf1 e1/33" （悪いケース）

• ソースグループ
  • リーフ1 e1/11
  • EPG3フィルタ
• 通知先グループ
  • リーフ1 e1/33

これは、アクセスSPAN(ERSPAN)のケース3に似ていますが、この例では、EPG3がLeaf1に存在しないため、Leaf1の唯一のSPANセッションが失敗します。そのため、SPANはまったく機能しません。

ケース 5

Src "EPG1 filter" | Dst "Leaf1 e1/33" （悪いケース）

• ソースグループ
  
  • EPG1フィルタ
• 通知先グループ
  • リーフ1 e1/33

アクセスSPANのEPGフィルタは、送信元ポートが設定されている場合にのみ機能します。指定するソースがEPGのみである場合は、アクセスSPANの代わりにテナントSPANを使用する必要があります。

CASE 6

Src "Leaf1 - Leaf2 vPC" | Dst "Leaf1 e1/33" （悪いケース）

• ソースグループ
  
  • リーフ1-2 vPC
• 通知先グループ
  • リーフ1 e1/33

vPCインターフェイスは、ローカルSPANを使用して送信元として設定できません。ERSPANを使用してください。アクセスSPAN(ERSPAN)については、ケース4を参照してください。

CASE 7

Src "Leaf1 e1/11 | Dst "Leaf1 e1/33 & e1/33 belongs to EPG" （faultで動作）

SPANの宛先I/FがすでにEPGに属している場合、物理I/Fの下で障害「F1696 : Port has an invalid configuration of both EPG and span destination」が発生します。

しかし、この障害が発生しても、SPANは問題なく動作します。このエラーは、同じI/F上にある顧客の通常のEPGトラフィックに影響を与える可能性があるため、SPANによって引き起こされる追加のトラフィックに関する警告にすぎません。

テナントSPAN(ERSPAN)

ケース 1

送信元「EPG1」 | Dst「192.168.254.1」

• ソースグループ
  
  • EPG1（フィルタなし）
• 通知先グループ
  • EPG Xの192.168.254.1

テナントSPANはEPG自体を送信元として使用し、アクセスSPANはフィルタのためだけにEPGを使用します。

テナントSPANの重要な点は、個々のポートを指定する必要がなく、ACIが各リーフスイッチで適切なVLANを自動的に検出することです。そのため、特定のEPGのすべてのパケットを監視する必要があり、そのEPGのエンドポイントがリーフスイッチの複数のインターフェイスに属している場合に便利です。

ファブリックSPAN(ERSPAN)

ケース 1

送信元「Leaf1 e1/49-50」 | Dst 「192.168.254.1」

• ソースグループ
  
  • リーフ1 e1/49-50
• 通知先グループ
  • EPG Xの192.168.254.1

ファブリックSPANは、ファブリックポートを送信元として指定します。ファブリックポートは、リーフスイッチとスパインスイッチ間のインターフェイスです。

このSPANは、リーフスイッチとスパインスイッチ間でパケットをコピーする必要がある場合に便利です。ただし、リーフスイッチとスパインスイッチ間のパケットはiVxLANヘッダーでカプセル化されます。だから、それを読むにはちょっとしたトリックが必要です。「SPANデータの読み方」を参照してください。

ケース 2

Src "Leaf1 e1/49-50 & VRF filter" | Dst "192.168.254.1"

• ソースグループ
  
  • リーフ1 e1/49-50
  • VRFフィルタ
• 通知先グループ
  • EPG Xの192.168.254.1

ファブリックSPANは、アクセスSPANだけでなく、フィルタも使用できます。ただし、フィルタタイプは異なります。ファブリックSPANは、仮想ルーティングおよび転送(VRF)またはBDをフィルタとして使用します。

Cisco ACIでは、前述のように、ファブリックポートを通過するパケットはiVxLANヘッダーでカプセル化されます。このiVxLANヘッダーには、仮想ネットワーク識別子(VNID)としてVRFまたはBD情報が含まれています。 パケットがレイヤ2(L2)として転送されると、iVxLAN VNIDはBDを表します。パケットがレイヤ3(L3)として転送されると、iVxLAN VNIDはVRFを表します。

そのため、ファブリックポート上のルーテッドトラフィックをキャプチャする必要がある場合は、フィルタとしてVRFを使用します。

ケース 3

Src "Leaf1 e1/49-50 & BD filter" | Dst "192.168.254.1"

• ソースグループ
  
  • リーフ1 e1/49-50
  • BDフィルタ
• 通知先グループ
  • EPG Xの192.168.254.1

前のケース2で説明したように、ファブリックSPANはフィルタとしてBDを使用できます。

ファブリックポートでブリッジされたトラフィックをキャプチャする必要がある場合は、フィルタとしてBDを使用します。

CPUへのスパン

• この機能は、バージョン6.2(1)以降で使用できます
• ミラーリングされたトラフィックを外部コレクタではなくリーフスイッチのCPUポート(sup-eth0)に送信するSPAN宛先オプションを提供します。
• SPANトラフィックがCPUを圧迫しないように、レートリミッタが組み込まれています。
• SPAN統計情報（ – HXのみ）:HXプラットフォームスイッチのstatisticsコマンドは、トラフィックがCPUにミラーリングされていることを確認します。

設定手順

• 新しいSPAN宛先グループを作成します。
• 宛先インターフェイスを指定する際に、ターゲットとしてsup-eth0（CPUポート）を選択または入力できるようになりました。
• この宛先グループをSPAN送信元グループ（ミラーリングするトラフィックを定義する）に関連付けます。

ビデオリンク：

https://community.cisco.com/t5/data-center-and-cloud-knowledge-base/aci-span-to-cpu-in-cisco-aci/ta-p/5372105

対応プラットフォーム

SPANからCPUは、これらのプラットフォームでのみサポートされます。このリストは静的ではなく、時間とともに変更される可能性があります。

• FX2 
• FX3 
• GX
• GX2 
• 高 

SPAN統計情報のサポート

• HXのみ

ポリサーレートをチェックするCLIはありません（IP優先順位をチェック）。500 Kbpsでハードコードされています。

制限と制限

バージョン固有のリリース情報を確認してください。たとえば、『Cisco APIC基本設定ガイド、リリース6.2(x)』などです。

• SPANからCPUは、ポートベースのSPANではなく、ACLベースのSPANでのみサポートされます。つまり、SPANからCPUへの変換はスケールモードではサポートされず、フィルタモードでのみサポートされます。
• Cisco Nexus 9000 FX2スイッチ以降は、SPAN-to-CPU機能をサポートします
• この機能がサポートされていないスイッチで設定されている場合は、エラーが発生します。APIC GUIで、System > Faultsの順に選択してFaultsタブをチェックします。
• リーフ上のファブリックポートとvPCポートは、SPANからCPUへのセッションの送信元インターフェイスとしてはサポートされていません。vPCポートの場合は、スイッチ単位の送信元として、Virtual Port Channelの代わりにパスタイプVPCコンポーネントPCを使用します。
• アクセスポートとアクセスポートチャネルのみがサポートされます。アクセスポートはレイヤ2またはレイヤ3ポートとして設定できます。
• TXマルチキャストはサポートされていません。
• SPANからCPUへのセッションと他のセッションの間で送信元を共有する場合、ポリサーは両方のセッションに適用されます。したがって、SPAN-to-CPUセッションの送信元を他のセッションと共有することは推奨されません。

設定の概要

ローカルSPANの設定と同様に、次のように設定します。

• アクセスポートを送信元パスとする送信元グループ
• 宛先がsup-eth0である宛先グループ

一般的なローカルSPANの宛先との唯一の違いは、宛先インターフェイスとしてsup-eth0を選択することです。

手順1:GUIでSPANをCPUに設定する

Fabric > Access Policies > Troubleshooting > SPAN > SPAN Destination Groupsの順にクリックします。

 

送信元、宛先、およびフィルタ情報を含むSPAN設定：

ステップ2：リーフのSPANセッションを確認します

他のSPAN設定と同様に、スイッチのCLIを使用してセッションを確認できます。

leaf103# show monitor session all

 session 5
---------------
name : spansource_vpc_component
description : Span session 5
type : sup
scale-mode : filter
state : up (active)
mode : access
Filter Group : 4
source intf :
rx : [Po3, FG:4] 
tx : [Po3, FG:4] 
both : [Po3, FG:4] 
source VLANs :
rx : 
tx : 
both : 
filter VLANs : filter not specified
filter L3Outs : filter not specified
destination ports : sup-eth0
tx :
both :
filter VLANs : filter not specified
filter L3Outs : filter not specified
destination ports : sup-eth0

ステップ3：適用されたフィルタの確認

リーフスイッチにプログラムされているフィルタエントリを確認します。

leaf103# show monitor filter 4
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
Filter name (id): interandintraepg (4)
Filter Entries:
Src IP                                          Dst IP                                          Src port        Dst port           Proto             dscp           dot1p               Routeable       tcpflags
------                                          ------                                          --------        --------           -----             ----           -----               ----------      ---------
10.1.121.0/24                                   10.1.130.0/24                                   -               -                  -                 -              -                   both
10.1.121.0/24                                   10.1.121.0/24                                   -               -                  -                 -              -                   both
10.1.130.0/24                                   10.1.121.0/24                                   -               -                  -                 -              -                   both
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________

手順4:HX上のSPAN統計情報の確認

セッションごとのミラー化パケットカウンタは、トラフィックが一致し、ミラー化されているかどうかを示します。HXプラットフォームスイッチのみ。

aci-HX-leaf# vsh_lc
module-1# show platform internal hal span session all stats
SPAN hardware session id:30 asic:0 slice:0 packet counts:2557
SPAN hardware session id:31 asic:0 slice:0 packet counts:510634359

ステップ5：リーフ上のSPANトラフィックのキャプチャおよびデコード

設定が完了すると、一致するすべてのトラフィック（例：eth1/4を通過するサブネット間のICMP）がCPUにSPANされます。

SPANのトラフィックを表示する場所

• SPANのトラフィックは、tahoe0インターフェイスでtcpdumpを使用してキャプチャできます。

• 組み込みスクリプトを使用してデコードおよびフィルタリングできます。

  • /isan/utils/span_to_cpu_parser.py

キャプチャとデコードの例

キャプチャの例は、設定の項で示したものとは異なるセットアップのものです

pod16-leaf3# tcpdump -xxxvi tahoe0 | python3 isan/utils/span_to_cpu_parser.py --decoder tahoe --verbose --payload
tcpdump: listening on tahoe0, link-type EN10MB (Ethernet), capture size 262144 bytes
Frame 9 
Time: 1970-01-01T19:01:53.944622+00:00
ieth-extn:
sup_code=0x2b sup_qnum=0x6

icmp-request(8): id:0x7710, seq:0xf00
Payload:
Internal Header:
0x0000: 0101 0101 0101 0000 0000 0000 a00e 0000 ................
0x0010: 0404 0404 8889 0000 0000 ae00 0000 0006 ................
0x0020: 2b00 0000 fb00 0000 003f ffff ffc0 0000 +........?......
0x0030: 1000 0000 ....
Frame Data:
0x0000: 0022 bdf8 19ff acf2 c5f8 2e01 8100 0a6d .".............m
0x0010: 0800 4500 0054 ff89 0000 ff01 aec9 c0a8 ..E..T..........
0x0020: 7802 c0a8 1402 0800 a049 7710 0f00 114e x........Iw....N
0x0030: 5d69 7f67 0e00 cdab 0000 cdab 0000 cdab ]i.g............
0x0040: 0000 cdab 0000 cdab 0000 cdab 0000 cdab ................
0x0050: 0000 cdab 0000 cdab 0000 cdab ............

注意: span_to_cpu_parser.pyはknet_parser.pyで、ISTACK_SUP_CODE_SPAN(0x2b) （SPANで扱うトラフィック）を含むパケットをフィルタする関数を追加したものです。

出力をPCAPに保存

—writeオプションを使用すると、デコードされた出力をpcapファイルに保存できます。

pod16-leaf3# tcpdump -xxxvi tahoe0 | python3 /isan/utils/span_to_cpu_parser.py --decoder tahoe --write /data/techsupport/mualshei-SPAN-CPU.pcap
tcpdump: listening on tahoe0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
Bye!
659 packets captured
662 packets received by filter
0 packets dropped by kernel

次に、それを読み返します。

pod16-leaf3# tcpdump -r /data/techsupport/mualshei-SPAN-CPU.pcap
reading from file /data/techsupport/mualshei-SPAN-CPU.pcap, link-type EN10MB (Ethernet)
20:07:43.966489 IP truncated-ip - 10 bytes missing! 192.168.120.2 > 192.168.20.2: ICMP echo request, id 30480, seq 27905, length 64
20:07:43.966901 IP truncated-ip - 10 bytes missing! 192.168.20.2 > 192.168.120.2: ICMP echo reply, id 30480, seq 27905, length 64
20:07:44.966505 IP truncated-ip - 10 bytes missing! 192.168.120.2 > 192.168.20.2: ICMP echo request, id 30480, seq 28161, length 64
20:07:44.966843 IP truncated-ip - 10 bytes missing! 192.168.20.2 > 192.168.120.2: ICMP echo reply, id 30480, seq 28161, length 64

問題

• SPAN Session down / "no-oper-src-dst"：送信元インターフェイスが動作可能で、プラットフォームがSPAN to CPU機能をサポートし、サポートされる送信元を確認します。
• 使用不可能な宛先PathEp障害:APICスイッチとリーフスイッチの両方が、機能をサポートするバージョン上に存在することを検証し、プラットフォームがSPANからCPUへの機能をサポートしていることを確認します
• tahoe0でパケットが観察されない：セッションの状態がup（アクティブ）、フィルタが正しくトラフィックが一致していることを確認し、フィルタモードを使用していることを確認し、宛先がsup-eth0として設定されていること、およびセッションがローカルアクセスSPAN（スパインではない/ファブリックではない/vPCソースではない）であることを確認します。

SPAN宛先デバイスに必要なもの

tcpdump、wiresharkなどのパケットキャプチャアプリケーションを実行するだけです。ERSPAN宛先セッションなどを設定する必要はありません。

ERSPANの場合

SPANパケットは宛先IPに転送されるため、必ずERSPANの宛先IPを持つインターフェイスでキャプチャツールを実行してください。

受信されたパケットはGREヘッダーでカプセル化されます。ERSPAN GREヘッダーをデコードする方法については、このセクションの「ERSPANデータの読み方」を参照してください。

ローカルSPAN用

ACIリーフのSPAN宛先インターフェイスに接続するインターフェイスで、キャプチャツールを実行してください。

このインターフェイスではrawパケットが受信されます。ERSPANヘッダーを処理する必要はありません。

ERSPANデータの読み方

ERSPANバージョン（タイプ）

ERSPANは、コピーされたパケットをカプセル化して、リモートの宛先に転送します。このカプセル化にはGREが使用されます。GREヘッダーのERSPANのプロトコルタイプは0x88beです。

Internet Engineering Task Force（IETF；インターネット技術特別調査委員会）のドキュメントでは、ERSPANのバージョンは、versionではなくtypeと記述されています。

ERSPANには3つのタイプがあります。I、IIおよびIII。ERSPANタイプについては、このRFCドラフトで説明されています。また、このGRE RFC1701は各ERSPANタイプを理解するためにも役立つ可能性があります。

各タイプのパケット形式を次に示します。

ERSPANタイプI（Broadcom Trident 2で使用）

タイプIでは、GREヘッダーのシーケンスフィールドは使用されません。ERSPANタイプIIおよびIIIの場合、GREヘッダーの後に続く必要があるERSPANヘッダーも使用しません。Broadcom Trident 2はこのERSPANタイプIのみをサポートします。

ERSPAN Type IIまたはIII

シーケンスフィールドがSビットによってアクティブ化される場合、これはERSPANタイプIIまたはIIIである必要があります。ERSPANヘッダーのバージョンフィールドは、ERSPANタイプを識別します。ACIでは、タイプIIIは2016年3月20日の時点ではサポートされていません。

アクセスまたはテナントSPANのSPAN送信元グループに、第1世代と第2世代の両方のノードの送信元がある場合、ERSPAN宛先は、ノードの各世代からERSPANタイプIとIIの両方のパケットを受信します。ただし、Wiresharkで一度に復号化できるERSPANタイプは1つだけです。デフォルトでは、ERSPAN Type IIだけがデコードされます。ERSPANタイプIのデコードを有効にすると、WiresharkはERSPANタイプIIをデコードしません。WiresharkでERSPANタイプIを復号化する方法については、後述のセクションを参照してください。

このタイプの問題を回避するには、SPAN宛先グループでERSPANタイプを設定できます。

• SPANバージョン（バージョン1またはバージョン2）:ERSPANタイプIまたはIIを指します。
• Enforce SPAN Version（オンまたはオフ）：ソースノードのハードウェアで、設定されたERSPAN Typeがサポートされていない場合に、SPANセッションを失敗させる必要があるかどうかを決定します。

デフォルトでは、SPAN VersionはVersion 2で、Enforce SPAN Versionはオフになっています。つまり、送信元ノードがERSPANタイプIIをサポートする第2世代以降の場合、タイプIIのERSPANを生成します。送信元ノードが、ERSPANタイプII（ファブリックSPANを除く）をサポートしない第1世代の場合、Enforce SPAN Versionがチェックされていないため、タイプIにフォールバックします。その結果、ERSPANの宛先は、混合タイプのERSPANを受信します。

次の表に、アクセスSPANとテナントSPANの各組み合わせについて説明します。

SPANバージョン	SPANバージョンの適用	第1世代ソースノード	第2世代ソースノード
バージョン 2	非選択	タイプIを使用	タイプIIを使用
バージョン 2	チェックボックスをオンにします。	失敗	タイプIIを使用
バージョン 1	非選択	タイプIを使用	タイプIを使用
バージョン 1	チェックボックスをオンにします。	タイプIを使用	タイプIを使用

ERSPANデータの例

テナントSPAN/アクセスSPAN(ERSPAN)

パケットはERSPANタイプIでカプセル化されるため、デコードする必要があります。これはWiresharkで実行できます。「ERSPAN Type 1のデコード方法」の項を参照してください。

キャプチャされたパケットの詳細（ERSPANタイプI）

ファブリックSPAN(ERSPAN)

Wiresharkは自動的にERSPAN Type IIをデコードします。ただし、iVxLANヘッダーによってカプセル化されたままです。

デフォルトでは、WiresharkはACI内部ヘッダーであるため、iVxLANヘッダーを認識しません。iVxLANヘッダーのデコード方法を参照してください。

キャプチャパケットの詳細（ERSPANタイプII）

ERSPAN Type Iのデコード方法

オプション 1Edit > Preference > Protocols > ERSPANの順に移動し、FORCEにチェックマークを付けて疑似ERSPANフレームをデコードします。

• Wireshark(GUI)

• Tshark（WiresharkのCLIバージョン）:

user1@linux# tshark -f 'proto GRE' -nV -i eth0 -o erspan.fake_erspan:true

オプション 2Decode As > Network > ICMP（ICMPの場合）の順に選択します。

iVxLANヘッダーのデコード方法

iVxLANヘッダーは宛先ポート48879を使用します。そのため、WiresharkでUDP宛先ポート48879をVxLANとして設定すると、iVxLANヘッダーとVxLANヘッダーを復号化できます。

1. 最初にiVxLANカプセル化パケットが選択されていることを確認してください。
2. Analyze > Decode As > Transport > UDP destination (48879) > VxLANの順に選択します。
3. 続いてApplyを実行します。

Precision Time Protocol(PTP)を実行するユーザネットワークでerspanキャプチャを取得すると、GREカプセル内の未知のethertype(0x8988)のためにWiresharkがデータを解釈しないことが時々見られます。0x8988は、PTPが有効であるときにデータプレーンパケットに挿入される時間タグのethertypeです。Ethertype 0x8988を「Cisco ttag」としてデコードし、パケットの詳細を明らかにします。

更新履歴

改定	発行日	コメント
3.0	07-Oct-2026	再フォーマット
2.0	06-Aug-2024	Call-to-Actionワードを含むように名称変更 'follow'を削除しました 更新されたMDFタグ
1.0	01-Feb-2023	初版