先理解問題邊界
按 IEEE 802.1Q，Trunk 上的帶標籤幀在 4 位元組標籤中攜帶 12 位元的 VLAN 識別碼（可用範圍 1 至 4094），而未攜帶標籤的幀則歸入該端口設定的 Native VLAN。Native VLAN 的存在是為了兼容不認得標籤的裝置，代價是這個歸屬完全由本地端口設定決定，不會在鏈路上協商或校驗。因此兩端設定不同時，鏈路仍會正常 up，只是同一批未標籤幀在兩端被當成不同網段的流量。
這個「鏈路正常但流量錯位」的特性，決定了排查方向。徵狀通常集中在單一網段：管理介面失聯、某個 VLAN 取不到 DHCP 位址、生成樹端口角色與設計不符，或原應隔離的兩個網段意外互通。帶標籤的 VLAN 多數不受影響，所以「只有一個網段有事、其餘正常」本身就是指向 Native VLAN 的線索。
排查前必須保留現況。先把兩端的端口配置、Trunk 狀態、允許 VLAN 清單、生成樹端口角色及介面計數器輸出存檔，再動手改設定，否則修正後無法判斷究竟哪一項是成因。實務上不少個案在盲目重設端口後徵狀消失，但成因未確認，數週後同類問題在另一條 Trunk 重現。
亦要留意安全維度。Native VLAN 是雙標籤式 VLAN hopping 的前提之一：攻擊者從存取端口送出外層標籤等於 Native VLAN 的雙標籤幀，外層在 Trunk 被剝除後，內層標籤令幀進入本不應到達的 VLAN。所以 Native VLAN 的處理既是連通性問題，也是隔離邊界問題。
設計輸入
盤點資產、角色、流量、依賴、故障域和現有文件，先確認需求再選技術。
驗證輸出
以配置、測試結果、變更紀錄及責任人形成可維護的交付文件。
常見盲點
不要只看標稱規格；兼容性、權限邊界、預留及故障狀態同樣影響結果。
規劃／排查工作表
| 階段 | 要回答的問題 | 留下的證據 |
|---|---|---|
| 症狀定位 | 失效範圍是單一 VLAN 還是全部？管理網段是否同時受影響？ | 受影響網段清單及測試時間 |
| 端口模式 | 兩端是否都真正處於 Trunk？有否一端仍為 Access？ | 兩端端口狀態輸出存檔 |
| 參數比對 | 兩端 Native VLAN 編號、允許 VLAN 清單、標籤 Native 選項是否一致？ | 逐項比對表（改動前後） |
| 鏈路確認 | 鄰接發現顯示的對端設備及端口是否與設計相符？ | 鄰接資訊截取及拓撲對照 |
| 轉發驗證 | MAC、ARP、DHCP、生成樹角色及錯誤計數器是否正常？ | 各表輸出及計數器觀察期紀錄 |
| 隔離驗證 | 應隔離的 VLAN 之間確實不通？未標籤幀只出現在預期 VLAN？ | 連通性矩陣及抓包結果 |
| 收尾 | 端口文件是否已更新？全網 Native VLAN 模板是否已統一？ | 端口表版本及變更紀錄 |
實務流程
- 記錄失效範圍：哪些 VLAN 不通、哪些正常、管理網段是否同時受影響，並記下開始時間及最近一次變更。
- 保存兩端現況輸出（端口配置、Trunk 狀態、允許 VLAN、生成樹角色、介面計數器）後才動手修改。
- 確認兩端端口模式一致；若一端仍為 Access，先解決模式問題再談 Native VLAN。
- 逐項比對兩端 Native VLAN 編號、允許 VLAN 清單及是否啟用標籤 Native VLAN，把差異寫在比對表上。
- 以鄰接發現資訊核實對端設備與端口，排除接錯線這一類更基本的成因。
- 按設計統一 Native VLAN，改動一端後即時複測，避免同時改兩端而無法判斷成因。
- 逐 VLAN 驗證取址、閘道可達、管理可達及應有的隔離，並在 Trunk 抓包確認未標籤幀的歸屬。
- 更新端口文件及 VLAN 分配表，並把「兩端 Native VLAN 比對」列入日後 Trunk 驗收清單。
設計對照
Native VLAN 與帶標籤 VLAN 的差別在於「歸屬資訊放在哪裡」。帶標籤 VLAN 的歸屬寫在幀本身，兩端只需允許該 VLAN 通過，即使編號理解不同也會立即表現為不通，容易發現；Native VLAN 的歸屬只存在於各自端口的本地設定，鏈路不會校驗，錯配後表現為靜默的錯誤轉發。這正是同一條 Trunk 上「標籤流量全對、未標籤流量出事」的原因。
Native VLAN 的處理策略有三種，取捨各異。沿用預設編號最省事，但該編號通常同時是大量存取端口的預設 VLAN，一旦錯配即牽連使用者流量，且是雙標籤攻擊的現成外層；改用一個全網統一、不承載任何使用者流量的專用編號，錯配時影響面極小，代價是要維護一份人人遵守的模板；啟用標籤 Native VLAN 令未標籤幀也帶標籤傳送，兩端不一致時會直接不通而非靜默錯轉，惟需兩端都支援同一設定，混合環境要先驗證。
另一組對照是「先修好」與「先查清」。生產環境的即時壓力往往推向前者，重設端口後徵狀消失即收工；但成因未定位，同一模板會在下一條 Trunk 重演。折衷做法是先存檔全部現況輸出，再以最小改動恢復服務，事後憑存檔完成成因分析，並把結論寫回配置模板。
最後是與生成樹的關係。Native VLAN 錯配影響的是未標籤 BPDU 的歸屬，可能令端口角色與設計不符甚至進入不一致狀態，因此排查時不要把生成樹告警當作獨立故障處理。反過來，若生成樹拓撲本身正在變動，也會掩蓋 Native VLAN 錯配的徵狀，宜待拓撲穩定後再比對。
香港場景
香港的商業樓宇多為分層租用，弱電機櫃設於各層電錶房，交換機常在不同年份、由不同承辦商分批加裝。新舊機型的預設 Native VLAN 未必相同，接手方按自己習慣配置新一端，就形成典型的兩端不一致。實務上接手既有網絡的第一步，是把每條 Trunk 兩端的 Native VLAN 抄成一張表，而非只看拓撲圖。
學校、商場及公共屋邨項目常見閉路電視、門禁、辦公及訪客 Wi-Fi 共用同一批交換機，隔離要求明確。若 Native VLAN 錯配令攝影機網段與辦公網段互通，除了運作風險，亦牽涉個人資料處理的合規問題；涉及影像資料的系統應在設計文件中寫明隔離邊界，並在驗收時逐對測試不通性，而非僅測連通性。
本地工程另一常見情況是分期入伙：第一期只啟用部分樓層，其餘端口預先佈線待用。預留的 Trunk 若沿用臨時設定，第二期接上時便出現不一致。建議預留端口一律按同一模板配置好 Native VLAN 與允許清單，並在端口表標明「已佈線待啟用」。
由於本地租約期短、搬遷及重組頻繁，端口與 VLAN 文件的更新紀律比設備選型更影響長期穩定。把 Native VLAN 寫入全網統一模板，並在每次加設 Trunk 時做兩端比對，是成本最低的預防措施。
常見問題
Native VLAN 不一致會出現甚麼徵狀？
排查時應先檢查哪些設定？
修正後如何確認問題已解決？
Native VLAN 不一致與 VLAN Hopping 有何關係？
應如何規劃 Native VLAN 以避免再次不一致？
權威參考
- IEEE 802.1Q（VLAN 標籤格式、VID 範圍與 Native VLAN 概述）
- VLAN hopping（雙標籤攻擊與 Native VLAN 的關係）
- Spanning Tree Protocol（IEEE 802.1D／802.1Q 生成樹端口角色）
- RFC 2131（Dynamic Host Configuration Protocol）