Aruba CX Switch Mirror 實踐與設定大全

上一篇文章只有寫到如何簡單設定，這一篇會繼續延伸，把HPE Aruba CX Switch Mirror各種方式寫出來。同時也修正一些誤解，建議只看此篇就能得到所有答案。

Mirror是把特定流量複製，並且往特定輸出介面拋出。接上特定介面的設備就能收錄到正常流量的鏡像檔，然後就能進行流量分析。

最近在工作上碰到Mirror的案例，發現有時候規劃者思路沒有做到Mirror流量與正常流量分離。由於Mirror的流量是一模一樣，萬一混入正常流量的線路，會變成重覆封包。

為了簡化與避免風險，Mirror建議額外使用獨立線路。避免Mirror輸出被重覆收錄到。

Aruba CX Switch Mirror 設定 – JN的電腦網路日常

https://higherlogicdownload.s3.amazonaws.com/HPE/UploadedImages/653face5-e4c9-4dae-b868-60dcc906bac2/AOS-CX_10_7_-_Mirroring_Enhancements.pdf

收錄動機與建議位置

使用Mirror最常見的動機是臨時除錯，這部分會有特定關心流量，像是符合什麼網段，或是特定Client。

接著是長期網路維運，作為網路整體使用的分析，能看到主要使用分布，或是特定Client的存取行為。

長期網路維運會一直持續運作，對於Mirror來說，我們會選擇在最完整的流量進行，例如：網頁伺服器，就會選在伺服器前端的交換器蒐集。網路架構就像一顆樹，最後會收斂到根，這個例子，根就是網頁伺服器。

建議位置盡量靠近目標流量的根，萬一沒辦法，往上一層，此時牽涉到的設備更多，調整更多設備的設定會讓架構更複雜。

此外也要考慮獨立線路與介接介面類型，在最接近根源考慮的越少，往上一層，影響設備數目越多，獨立線路的數量也會倍增。

如果流量大，建議使用專門的Mirror用途Switch，並使Mirror流量只單方向進到Mirror用途Switch，確保Mirror流量可以與生產環境分離。、

收到封包時為HPE CX Switch Mirror判斷時間點

收到封包時，優先判斷要不要mirror，然後處理介面vlan access trunk設定或是ACL。

舉例，interface 1/1/1 為 Routing 介面，即L3介面。有設備不斷往1/1/1傳送帶有vlan tag 890的流量。

mirror機制是先進行，因此若有mirror session 收集source vlan 890的話，也能被收錄到。

如果封包同時符合source vlan與souce interface，則只會進行一次鏡像複製。

interface 1/1/1
routing
exit

mirror session 1
source interface 1/1/1
destination interface 1/1/2
enable
exit

Mirror的來源VLAN，會在進來時複製，即使是L3介面，也能準確複製到Source。

HPE CX Switch限制

Mirror Session最多只有四個。

Mirror流量有Tag則導出有Tag，沒Tag則導出沒Tag。

啟用Mirror Session的來源介面與目標介面不能重疊。

CPU產生的L3 Route(PBR)，將不會被Mirror到目的Port。

詳情可以參考我上一篇文章，主要來說，如果是以interface作為Source，沒有其他條件與動作，就能很好的被收集到。

如果要蒐集所有流量，Trunk的設定要一致，尤其是Native，而且避免蒐集Access Port。

Mirror Source可以有多個。Destination也可以有多個，但多個Dest間要有共同的VLAN。

其他限制

source interface在所有型號可以用。

source vlan只在6200、6300、6400、8100、8360、8400可以使用。

詳細資訊可以參考Command Line Guide與Monitoring Guide。關於限制的部分，Command Guide比較準確。

官方線上Command Line Guide

Model	mirror session	mirror endpoint	Source interface	Source VLAN	Destination Interface	Destination Tunnel
6000	4	V	52	X	1	V
6100	4	V	52	X	1	V
6200	4	V	64	1024	64	V
6300	4	V	64	1024	64	V
6400	4	V	64	1024	64	V
8100	4	V	V	V	V	V
8320	4	X	128	X	1	V
8325	4	X	128	X	1	V
8360	4	V	64	V	64	V
8400	4	X	256	6	1	V
9300	4	X	128	X	1	V
10000	4	X	72	X	1	V

※Source 、 Destination相關限制數目為Per Session。

※LAG視做一個Interface，不能作為Mirror Endpoint的Destination Interface。

Mirror Session與Mirror Endpoint

Mirror Session與Cisco所提的Switch Port Analyzer(SPAN)類似，都是把來源介面或是VLAN導出。

流量怎麼來，符合條件就完整複製，然後才去看後續是否符合ACL與介面設定是否要處理。

Mirror Session導出時如果是本機的介面，就是Local Mirror。如果透過Tunnel，就是Remote Mirror。

Remote Mirror會透過GRE封裝，外面會套一層交換器IP、MAC並傳送目的IP，因此需要先解開這層傳遞用的封裝，才能看到流量原來的樣子。

Mirror Endpoint可以針對特定來源的GRE封裝或是EPSPAN封裝的流量解開，然後再鏡像從特定介面導出。

因此Mirror Endpoint是檢查進來的封包是不是否符合Mirror Endpoint的來源條件，符合才做處理，即設備負責解開Remote Mirror的封裝再導出，這樣就能使原始流量能重現並被正確分析。

LAB環境

本次要做所有流量監控，因此在核心交換器，會收錄各Downlink的Rx。(單一介面Both，多介面RX，避免封包重覆收錄。)

核心交換器將流量導出，使用影響最小的L3 Port。避免影響到L2 VLAN。

SPAN交換器只收，使用L3 Port收集。並且再區分各VLAN導出。

VLAN 890： 10.10.89.251/24、10.10.89.252/24
VLAN 900： 10.10.90.251/24、10.10.90.252/24

Wireshark若無法正確看到VLAN TAG

為了避免VLAN TAG收錄時被去除，導致Windows排查時無法判斷Mirror是否正常。

Windows Wireshark(4.4.8)可能無法正確解讀VLAN TAG，收錄封包時被去除掉VLAN TAG，導致每個都沒有VLAN ID。

此時可以重新安裝wireshrak，確認Npcap版本，如果Npcap大於1.8.1版本，就能補回VLAN TAG。建議直接從Npcap官方網站下載1.8.2版本，安裝後，重啟

Npcap release archive

https://chatgpt.com/share/688836c5-1f90-8003-99dd-87f388c00967

筆者在更新Npcap之後，封包802.1Q就能看到了。

Port Mirror(SPAN)

最基本的Mirror，是Local Mirror。

收集本機特定Interface的流量，流量又會再區分成in或是out或是both。收集之後，會複製一份一模一樣的，無視VLAN等設定，往本機特定Interface拋出。

由於Mirror流量會無視介面設定，因此獨立線路是有其必要性。

以下為 HPE CX Switch的Local Mirror設定：蒐集1/1/48的in方向流量，鏡像後往1/1/47拋出。

mirror session 1
source interface 1/1/48 rx
destination interface 1/1/47
enable
exit

Destination Interface Config

目的端的介面設定很重要，最理想的Mirror Destination Interface是不混雜其他非鏡像的流量。

LLDP、Spanning Tree、 ARP、Loop Protection等，都可能自然從Mirror Destination Interface送出。

為了降低影響，建議使用L3 Interface，另外將LLDP Transmit關掉，這在預設值下，該介面基本上不會發送任何封包。

# Mirror Destination Interface

interface 1/1/9
    no shutdown
    no lldp transmit
    routing

Remote Mirror

Local Mirror需要線路直接接在交換器上，但是，這往往造成收錄封包的不方便與不靈活。

這如同Console與SSH，能遠端存取，就可以省下很多時間成本。

Remote Mirror將鏡像流量，透過GRE封裝等丟到目的IP。透過Wireshark，可以正確解封，看到實際鏡像流量。或是透過CX Switch設定Mirror Endpoint，將Remote Mirror解封裝後的流量，再傳到指定介面。

此方案缺點是會佔用網路線路頻寬，無法準確估計實際網路使用量。若收錄介面或VLAN發生異常巨大流量，將會因此佔用主幹線路。

直接Remote Mirror到流量分析主機

mirror session 2
    destination tunnel <dest IP> source <source IP>
    source vlan 890 rx
    source vlan 900 rx
    enable

# Example
mirror session 2
    destination tunnel 172.16.3.48 source 172.16.3.197
    source vlan 890 rx
    source vlan 900 rx
    enable

Wireshark快速過濾出ERSPAN的封包參數

gre.flags_and_version == 0x2000

ERSPAN由於經過GRE封裝，因此若Ping使用1500大小，會因為GRE添加後會超出MTU，而分割成兩份。

Mirror Endpoint

透過Remote Mirror的流量，除了導到分析工具，還可以先送到CX Switch進行解封裝，再轉送到特定介面的工具上。

LAB環境將流量從SW2導到SPAN去，途經SW1、SW3。

SPAN看到流量符合Mirror Endpoint設定的條件，解封，並導到特定介面上。

Policy Match Mirror

class ip mirror_3
    10 match any any any
policy mirror_3
    10 class ip mirror_3 action mirror 3

interface 1/1/9
    no shutdown
    no lldp transmit
    no routing
    vlan trunk native 1
    vlan trunk allowed 890,900

mirror session 3
    destination interface 1/1/9
    enable

使用這種方式，這是基於ACL、檢查封包時等方式，因此，Mirror Destination Interface Config要能支援鏡像封包傳輸。

如ACL鏡像出VLAN 890封包，但是Destination Interface是Access VLAN 900，就會無法輸出。

Destination CPU與Check

在做臨時除錯時，通常會先以遠端查看，若只是想短暫進行臨時除錯查看，使用Destination到CPU，再用指令去查看，就能馬上在終端畫面看到是否有收錄封包。

# Config
mirror session 2
    destination cpu
    source vlan 890 rx
    source vlan 900 rx
    enable

# Command，搭配ping
6200# diagnostics
6200# diag utilities tshark
Inspecting traffic mirrored to the CPU until Ctrl-C is entered.
Frame 1: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface MirrorRxNet, id 0
    Interface id: 0 (MirrorRxNet)
        Interface name: MirrorRxNet
    Encapsulation type: Ethernet (1)
    Arrival Time: Aug  1, 2025 10:10:40.233071720 CST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1754014240.233071720 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 64 bytes (512 bits)
    Capture Length: 64 bytes (512 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:vlan:ethertype:ip:icmp]
Ethernet II, Src: 10:4f:58:e5:5e:10, Dst: 5c:a4:7d:3d:b8:40
    Destination: 5c:a4:7d:3d:b8:40
        Address: 5c:a4:7d:3d:b8:40
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: 10:4f:58:e5:5e:10
        Address: 10:4f:58:e5:5e:10
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 1, DEI: 0, ID: 890
    001. .... .... .... = Priority: Background (1)
    ...0 .... .... .... = DEI: Ineligible
    .... 0011 0111 1010 = ID: 890
    Type: IPv4 (0x0800)
    Padding: 0000000000000000000000000000
    Trailer: 00000000
Internet Protocol Version 4, Src: 10.10.89.251, Dst: 10.10.89.252
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 28
    Identification: 0x0ca0 (3232)
    Flags: 0x0000
        0... .... .... .... = Reserved bit: Not set
        .0.. .... .... .... = Don't fragment: Not set
        ..0. .... .... .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: ICMP (1)
    Header checksum: 0xa636 [validation disabled]
    [Header checksum status: Unverified]
    Source: 10.10.89.251
    Destination: 10.10.89.252
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0x6c35 [correct]
    [Checksum Status: Good]
    Identifier (BE): 0 (0x0000)
    Identifier (LE): 0 (0x0000)
    Sequence number (BE): 35786 (0x8bca)
    Sequence number (LE): 51851 (0xca8b)

此方案建議搭配 Policy Match Mirror ，精準收錄目標封包，確保終端機畫面不會被文字佔滿。

Test Access Point(TAP)

TAP為專門服務工具的流量分析整體設備。

Switch進行Mirror，除了會增加Switch的運算消耗，此外，Switch沒有辦法針對鏡像流量做許多處理，這使得Switch Mirror設計要用心才能準確導出目標流量，無參雜其他非必要流量。

因此TAP設備就是專門用於讓流量分析工具能夠減少不必要的流量，也能不佔用現有網路設備的運算資源。

TAP可分為被動式與主動式：

被動式，如透過分光器去將光偏光，使用5:5或是7:3分光，這樣就能將一份傳輸變成兩份。介面會以原進、原出、鏡進、鏡出，四個為一組單位。基於物理原理而不需要電力運作，即便鏡入鏡出後端設備故障，也不影響網路運作。
※5:5用於短距離分光，同機房內使用。7:3用於長距離分光。

主動式，透過將線路中介在TAP設備上，流量經過同時，TAP依據設定整合流量並導往特定介面出去。若設備故障，網路會中斷。

實作上可以混合使用，即被動式或是主動式收容導出流量，再由後端的主動式去做進階過濾與轉送，這樣比較能合乎經濟。

Switch Mirror 與 TAP 比較

項目	費用	設定	網路設備效能影響	骨幹頻寬	流量整理	進階分析轉換
Local Mirror	低(可能需要新購線路器材)	容易	低	不佔用	低調整性	無
Remote Mirror	無	複雜	高	佔用	低調整性	無
TAP	高(新購線器器材設備授權)	容易	無到低	不佔用	高調整性	可(需要上License)