「一樓接上去可以用，四樓接同一套設備卻完全不通。」
檢查過 IP、Gateway 和設備設定，看起來都差不多；網路線有 Link，交換器 Port 也顯示 Up，但只要設備搬到四樓，某些網段就像憑空消失。
更麻煩的是，它不是所有功能都不能用。
可能出現：
這類「只有部分流量失效」的問題，通常比完全斷線更煩。因為實體層看起來沒事，設備甚至還會亮著綠燈，彷彿在告訴你：
我有連線啊，剩下的是你的問題。
最後沿著路徑檢查，才發現一樓是直接連到支援 VLAN 的 Switch Port，四樓中間卻多了一台不明設備；而原本需要承載多個 VLAN 的連線，沒有完整保留 802.1Q Tag。
問題不一定是 AP，也不一定是 DHCP。
可能只是原本應該走 Trunk 的地方，被當成普通 Access 連線處理了。
最簡單的版本是：
| Port 類型 | 主要用途 | 通常承載的 VLAN |
|---|---|---|
| Access Port | 連接一般終端設備 | 一個 |
| Trunk Port | 連接需要多 VLAN 的設備 | 多個 |
Access Port 常接：
Trunk Port 常接：
不過這只是基本分類。
真正排錯時，還要理解：
不然只記得「Access 一個、Trunk 多個」，遇到現場還是很容易直接卡住。
假設某個 Switch Port 設定為 VLAN 20 的 Access Port：
interface GigabitEthernet1/0/10
switchport mode access
switchport access vlan 20
連在這個 Port 上的電腦，通常送出的是沒有 802.1Q Tag 的一般 Ethernet Frame。
Switch 收到後，會根據 Port 設定判斷：
這個 Frame 是從 VLAN 20 的 Access Port 進來，所以它屬於 VLAN 20。
接著 Switch 便在 VLAN 20 裡學習 MAC、Flood Broadcast 或轉送 Unicast。
當 Frame 從 Access Port 送回終端時，通常也會以 Untagged 的形式送出。
因此，一般電腦不需要知道自己位於 VLAN 20。
它只需要設定：
IP：10.10.20.35/24
Gateway：10.10.20.1
至於 VLAN ID，交給 Switch Port 處理。
假設使用者原本應該進入 VLAN 20，Port 卻被設為 VLAN 30。
Client 可能：
如果 VLAN 30 也有 Internet，使用者甚至可能覺得一切正常。
直到他要開內部系統、連印表機或存取檔案伺服器時，問題才浮現。
這就是 VLAN 設定錯誤很麻煩的地方：
它不一定讓網路全斷，而是讓設備在錯誤的世界裡正常生活。
假設兩台 Switch 之間需要傳遞：
VLAN 10：IT
VLAN 20：Office
VLAN 30：Production
VLAN 50：Server
如果每個 VLAN 都拉一條獨立網路線，四個 VLAN 就需要四條介面。
規模再大一點，機房很快就會變成網路線主題樂園。
因此，Trunk 可以在同一條實體連線上承載多個 VLAN。
為了讓對端知道每個 Frame 屬於哪個 VLAN，Switch 會使用 IEEE 802.1Q，在 Ethernet Frame 中加入 VLAN Tag。
簡化概念如下：
原始 Ethernet Frame
→ 加入 802.1Q Tag
→ 標示 VLAN ID
→ 經過 Trunk
→ 對端依 Tag 分回對應 VLAN
例如：
Frame A：VLAN 20
Frame B：VLAN 30
Frame C：VLAN 50
雖然都走同一條實體線路，但對端仍能根據 Tag 將它們分開。
這就像三個部門的包裹共用同一台物流車，但每個箱子都有明確標籤，不會因為坐同一台車就全部混成同一個部門。
802.1Q 會在 Ethernet Frame 中加入四個 Byte 的資訊。
其中包含：
對一般排錯來說，最常注意的是 VLAN ID。
VLAN ID 使用 12 bit，理論範圍為：
0 ～ 4095
其中部分數值保留，因此一般可使用 VLAN 範圍通常為：
1 ～ 4094
Cisco 環境還會區分 Normal Range 與 Extended Range，但對今天的重點來說，先知道 Tag 能告訴對端 Frame 屬於哪個 VLAN 就夠了。
另一個值得注意的地方是：加入 Tag 後，Frame 會稍微變大。
正常支援 802.1Q 的交換器會處理這種 Tagged Frame；但某些老舊、不相容或用途特殊的中間設備，可能無法正確轉送。
Cisco 常見概念設定如下：
interface GigabitEthernet1/0/48
switchport mode trunk
這代表介面以 Layer 2 Trunk 模式運作。
但只設定成 Trunk，還不代表設計完整。
通常還需要考慮：
Trunk 可以承載多個 VLAN，但不代表一定要把交換器上的所有 VLAN 全部送過去。
可以限制允許通過的 VLAN：
interface GigabitEthernet1/0/48
switchport mode trunk
switchport trunk allowed vlan 10,20,30,50
此時這條 Trunk 只允許：
VLAN 10
VLAN 20
VLAN 30
VLAN 50
其他 VLAN 即使存在，也不會通過這條連線。
假設某台 AP 提供：
管理 VLAN：10
員工 SSID：VLAN 20
訪客 SSID：VLAN 100
Switch Port 的 Allowed VLAN 卻只有：
10,20
結果可能是：
AP 並沒有完全離線，所以問題很容易被誤判成：
但真正原因只是 VLAN 100 沒被允許通過 Trunk。
這也是為什麼「部分功能正常」反而是重要線索。
它代表整條連線可能沒有完全死亡，而是只有特定 VLAN 被遺漏。
假設公司新增 VLAN 120，並且已經完成：
Client 卻仍拿不到 IP。
因為 VLAN 120 若需要經過多台 Switch，沿途每一段 Trunk 都必須允許它。
路徑可能是：
Client
→ Access Switch A
→ Distribution Switch
→ Core Switch
→ DHCP Relay
→ DHCP Server
只要中間某一段 Trunk 沒有 VLAN 120，封包就會在那裡停止。
因此新增 VLAN 時，不能只看起點和終點。
要檢查整條路徑：
VLAN 不會因為 Core 上建立完成，就自動理解你希望它去哪裡。
在 802.1Q Trunk 上，多數 VLAN Frame 會帶有 Tag。
但 Native VLAN 的 Frame，在許多預設行為下會以 Untagged 形式傳送。
例如：
Native VLAN：99
當 Trunk 收到 Untagged Frame 時，可能將它歸入 VLAN 99。
概念設定：
interface GigabitEthernet1/0/48
switchport mode trunk
switchport trunk native vlan 99
Native VLAN 的用途和設計會依設備與環境不同，但最重要的原則是：
Trunk 兩端的 Native VLAN 應保持一致。
假設：
Switch A Native VLAN：99
Switch B Native VLAN：1
Switch A 送出的 Untagged Frame，認為它屬於 VLAN 99；Switch B 收到後，卻把它歸入 VLAN 1。
也就是同一個 Frame，在兩端被理解成不同 VLAN。
可能造成：
Cisco Log 可能出現類似：
Native VLAN mismatch discovered
看到這類訊息，不要只把 Log 清掉。
Log 已經很努力提示兩端對 Untagged 流量的理解不同了。
雖然兩者都可能處理 Untagged Frame，但用途不同。
套用於 Access Port，決定終端送入的 Untagged Frame 屬於哪個 VLAN。
套用於 Trunk Port，決定 Trunk 上的 Untagged Frame 被歸入哪個 VLAN。
因此，查看 Switch Port 時不能只看到：
VLAN 20
就直接說它是 VLAN 20。
還要確認它是：
同一個介面畫面可能同時出現多種 VLAN 資訊，全部混在一起看，結論通常會很有創意。
假設：
Switch A：Trunk
Switch B：Access VLAN 20
兩端對 Frame 的處理方式不同。
可能出現：
這種情況最迷惑人的地方，是它不一定完全中斷。
例如 Native VLAN 的 Untagged 流量可能還能通，讓人以為線路正常；其他帶 Tag 的 VLAN 卻全部消失。
所以排錯 Trunk 時，要同時確認兩端的：
不能只查其中一端。
網路線是雙向的，兩端設定只看一邊，多少有點單方面宣布交往。
Cisco 常見指令：
show interfaces trunk
可能看到：
Port Mode Encapsulation Status Native vlan
Gi1/0/48 on 802.1q trunking 99
以及：
Vlans allowed on trunk
10,20,30,50
還可能顯示：
這裡需要分清楚：
設定上允許通過。
不只允許，而且 VLAN 存在並處於 Active。
除了允許與 Active，STP 也處於 Forwarding 狀態。
所以看到 VLAN 在 Allowed List 裡，還不能直接證明它正在正常轉送。
可以使用：
show interfaces GigabitEthernet1/0/48 switchport
重點可能包括：
它能協助回答：
這個 Port 被設定成什麼，以及它現在實際以什麼模式運作？
設定意圖和 Operational State 不一定完全相同，尤其環境中使用動態協商時。
Cisco 的 Dynamic Trunking Protocol 可以協商介面是否形成 Trunk。
常見模式概念包括：
簡化理解：
| A 端 | B 端 | 常見結果 |
|---|---|---|
| Trunk | Trunk | Trunk |
| Trunk | Dynamic Auto | Trunk |
| Dynamic Desirable | Dynamic Auto | Trunk |
| Dynamic Auto | Dynamic Auto | 通常不形成 Trunk |
| Access | Trunk | 不一致／異常 |
實際結果仍需依設備與設定確認。
企業環境通常偏好明確指定模式，而不是讓關鍵連線依靠動態協商猜彼此的心意。
例如 Switch 對 Switch 的正式上聯，通常會清楚定義為 Trunk；一般使用者 Port 則明確設為 Access。
若設備不需要 DTP，也可以依規範關閉協商：
switchport nonegotiate
但前提是對端模式已正確設定。
企業 AP 可能同時提供多個 SSID。
例如：
| SSID | VLAN | 用途 |
|---|---|---|
| CORP | 20 | 員工 |
| GUEST | 100 | 訪客 |
| DEVICE | 120 | 設備 |
如果 AP 採用 Local Switching 或 FlexConnect Local Switching，Client 流量可能由 AP 直接送入對應 VLAN。
此時 AP 所接的 Switch Port 就需要承載：
因此通常需要 Trunk，或依廠牌採用相應的 Tagged／Untagged 設計。
如果誤設為單一 Access VLAN，可能只有：
不一定。
以集中式無線架構為例，Local Mode AP 的 Client Data 可能透過 CAPWAP Tunnel 回到 Wireless Controller 集中交換。
這種情況下，AP 所接 Switch Port 不一定需要承載每個 Client VLAN；它可能只需要 AP 的管理與 CAPWAP 連線。
FlexConnect 採 Local Switching 時，AP 才更常需要在本地 Switch Port 上轉送對應 Client VLAN。
所以不能看到 AP 有三個 SSID，就直接宣布 Switch Port 一定要允許三個 VLAN。
要先確認：
這也是企業無線排錯很重要的一點：
同樣是 AP，流量實際走法可能完全不同。
企業常見接法：
Switch
→ IP Phone
→ PC
Switch Port 可能設定：
interface GigabitEthernet1/0/10
switchport mode access
switchport access vlan 20
switchport voice vlan 40
此時：
因此這個 Port 雖然顯示為 Access Mode，仍可能同時處理 Data VLAN 與 Voice VLAN。
這算是常見的特殊情境。
所以「Access 一定只能看到一個 VLAN」是方便入門的說法，但實務上仍有 Voice VLAN 這類例外。
一台 VMware、Hyper-V、KVM 或其他虛擬化主機，可能同時執行多台位於不同 VLAN 的 VM。
例如：
VM-A：VLAN 20
VM-B：VLAN 30
VM-C：VLAN 50
如果同一張實體 NIC 要承載多個 VLAN，Switch Port 可能需要設定為 Trunk，並由：
處理 VLAN Tag。
排錯時要確認 Tag 由誰負責：
如果 Physical Switch 與 Hypervisor 都以為對方會加 Tag，最後可能沒有人加；如果雙方都重複處理，結果同樣不會太理想。
這裡要講精確一點。
真正的 Ethernet Hub 工作在 Layer 1，理論上只負責重複電氣訊號，不會理解或主動移除 802.1Q Tag。
所以不能簡單說：
Hub 一定不支援 VLAN，因此 Trunk 一定不能過。
但現場被稱作「Hub」的設備，很多其實是：
這些設備可能：
因此，如果直連 Switch 時 Trunk 正常，中間加入某台「Hub」後失效，正確結論不是立刻背一句「Hub 不能傳 VLAN」。
而是進一步確認：
名稱不可靠，型號、規格和實際封包才可靠。
現場最危險的一句話之一，就是：
那台只是一個普通 Hub 啦。
通常講完後，故事才正要開始。
假設有一台需要傳遞多個 VLAN 的設備。
一樓連線：
設備
→ Managed Switch Trunk Port
→ Core Network
結果：
四樓連線：
設備
→ 中間網路設備
→ Managed Switch
→ Core Network
結果：
這時可以進行控制變因：
全部正常，降低設備本身故障的可能性。
如果恢復正常，問題範圍集中到：
若 Untagged 流量正常，Tagged VLAN 失敗，就高度懷疑中間路徑沒有正確保留 802.1Q Frame。
確認不同 VLAN 的 MAC 是否能從預期 Port 被學到。
若條件允許，可觀察：
這樣才能從「四樓不能用」，逐步證明是哪個環節失效。
Client 剛進入某個 VLAN 時，通常先透過 DHCP 取得 IP。
如果該 VLAN 沒有通過 Trunk，DHCP Discover 就無法到達：
結果 Client 可能拿到：
169.254.x.x
使用者看到的是：
Wi-Fi 沒網路。
我們可能先查 DHCP Server，但其實 Server 根本沒有收到 Discover。
因此，遇到特定 VLAN 拿不到 IP 時，可以沿著路徑檢查：
Client
→ Access Port／SSID
→ VLAN Mapping
→ Trunk
→ Gateway／Relay
→ DHCP Server
若其他 VLAN DHCP 正常，尤其要比較它們在 Trunk 上的差異。
排錯時看到 VLAN 100 不通，有人可能直接設定：
switchport trunk allowed vlan all
接著 VLAN 100 恢復，問題看似解決。
但這同時可能讓許多原本不需要通過的 VLAN 進入該連線，增加：
比較好的方式是：
「先全部開放看看」可以是受控的短暫診斷手段，但不能默默變成正式設計。
否則半年後有人問為什麼這條 Trunk 有 80 個 VLAN，答案只剩：
當時這樣比較快。
這句話通常不會讓接手的人感到比較快樂。
假設目前 Trunk 允許：
10,20,30
如果想增加 VLAN 40，要注意指令語意。
某些 Cisco 設定中：
switchport trunk allowed vlan 40
可能會將原本清單直接替換成只剩 VLAN 40。
如果想加入，應依設備語法使用：
switchport trunk allowed vlan add 40
否則新增一個 VLAN 的同時，原本三個 VLAN 全部消失。
你成功修好一個部門，也順便讓另外三個部門下班，效率確實非常高，只是方向不太對。
變更前應先：
每個 VLAN 在 Trunk 上是否能正常轉送，還可能受到 Spanning Tree 影響。
即使 VLAN：
若 STP 將某個 Port 對該 VLAN 置於 Blocking／Discarding，流量仍不會經過。
Cisco show interfaces trunk 中可能區分：
因此，不要只看到 VLAN 在 Allowed List 就結案。
還要確認：
遇到「部分 VLAN 正常、部分 VLAN 不通」時，可以按照以下流程。
先問：
不要因為設備看起來很專業，就直接把 Port 改成 Trunk。
例如：
Client
→ AP
→ Access Switch
→ Distribution Switch
→ Core
→ Gateway
→ DHCP Server
標出每一段需要承載的 VLAN。
檢查：
檢查：
確認目標 VLAN：
檢查：
確認：
查看：
不要只測新 VLAN。
還要確認：
Access Port 通常將一般終端的 Untagged Frame 放入單一 VLAN；Trunk Port 則透過 802.1Q Tag，在同一條實體連線上承載多個 VLAN。
排錯時，要特別確認：
當只有部分 VLAN 失效時，不要急著重啟所有設備。
這種症狀反而是在告訴你：
實體連線可能還活著，只是某些帶著標籤的 Frame 沒能走完整條路。
iThome鐵人賽
看影片追技術