MST and PVST+ Interoperability

[Cẩm Thanh]

Bạn đã bao giờ gặp tình huống “bất ngờ” khi triển khai MST và PVST/PVST+ trong cùng một mạng: một số VLAN đi bình thường, một số VLAN lại bị chặn vai trò, thậm chí có lúc bạn thấy thông báo kiểu như inconsistent inferior PVST BPDU received và toàn bộ vòng lặp phát triển… nhưng không phải vòng lặp L2 “thông thường”?

Nếu đã từng vướng, tin vui là: đa số sự cố đều có gốc rễ từ cơ chế trao đổi BPDU và logic chọn vai trò Root/Designated/Non-Designated tại biên giữa MST và PVST/PVST+.

Bài chia sẻ này mình sẽ đi sâu theo đúng tinh thần tài liệu “MST and PVST+ Interoperability”, đồng thời biến nó thành kinh nghiệm thực chiến để bạn áp dụng ngay khi lab/triển khai.

1) MST và PVST+ “nói chuyện” với nhau bằng cách nào?

Trong thực tế, bạn thường gặp 2 kiểu thiết kế:

• Một phía chạy MST (Multiple Spanning Tree): nhiều VLAN được map vào một hoặc vài instance MST để giảm số lượng spanning-tree phải chạy.
• Một phía vẫn chạy PVST/PVST+: mỗi VLAN chạy một spanning-tree riêng (tức là số instance tăng theo số VLAN).

Vấn đề nằm ở chỗ: MST và PVST+ là hai “đơn vị spanning-tree” khác nhau về cách tổ chức. Vì vậy, tài liệu nhấn mạnh: chúng tương thích theo hướng “liên thông” nhưng cần đúng cách hiểu về cách thông tin được chuyển ở biên.

Cách nhìn đơn giản nhưng đúng bản chất:

• MST tạo ra các instance theo miền MST (MST region).
• PVST+ tạo ra instance theo từng VLAN.
• Khi đi qua thiết bị/mạch nối giữa hai miền, thông tin về topology (Root/Cost/Role…) sẽ được trao đổi theo cơ chế ánh xạ giữa MST instance và PVST+ VLAN.

Nói kiểu “đời” hơn: giống như bạn có một đoàn xe chạy theo lịch tuyến A (PVST+ theo VLAN) và một đoàn xe chạy theo tuyến B (MST theo instance). Hai bên chỉ “hiểu nhau” khi bạn biết điểm nào là tương ứng tuyến nào và nguyên tắc ưu tiên khi hội đồng chọn hướng đi.
2) Thông tin ở “biên” được quyết định như thế nào?

Trong tài liệu, phần quan trọng nhất nằm ở ý: PVST+ và MST không thể “giữ nguyên” thông tin lẫn nhau 1-1 theo đúng instance/VLAN, nên tồn tại cơ chế chuyển đổi.

Tài liệu mô tả rằng:

• MST sẽ gửi/nhận thông tin theo instance MST.
• PVST+ sẽ gửi/nhận thông tin theo VLAN.
• Khi cùng tồn tại, thiết bị biên phải dùng thông tin từ các BPDU nhận được để quyết định vai trò của cổng.

Một điểm mình thấy trong thực chiến cực hay gặp: bạn tưởng mình “chỉ map VLAN đúng” nhưng thực tế vẫn có thể mất vai trò Root/Designated ở một số VLAN vì logic “inferior/superior” giữa BPDU của bên kia không khớp kỳ vọng.

3) Lý thuyết cốt lõi: Designated Port, Root Port và Non-Designated Port ở biên

Tài liệu đi theo logic MST/PVST+ chọn vai trò cổng. Mình tóm đúng ý nhưng triển khai theo cách bạn có thể “bắt lỗi” khi triển khai.

3.1) Designated Port: khi biên được chọn làm cổng chỉ định

Trong MST biên, nếu bạn muốn cổng ở boundary trở thành Designated port (cổng được chọn để forward theo phía mà thông tin tốt nhất), thì kiểm tra chính là:

• MST BPDU cho VLAN/instance đó phải “superior” hơn so với PVST+ BPDU tương ứng nhận được trên cổng biên.

Nếu MST BPDU không superior, cổng biên sẽ không forward với vai trò Designated. Bạn sẽ thấy trạng thái chuyển nhanh sang dạng bị chặn hoặc thay đổi role.

Ví dụ dễ hình dung:

• Giả sử bạn map VLAN 10 và VLAN 20 vào cùng MST instance, nhưng do bạn chỉnh MST priority hoặc do “cost” bất lợi ở một phía, BPDU của phía PVST+ vẫn “thua” hoặc “hơn” theo tiêu chí superior.
• Khi đó, cổng biên không thể cứ “làm Designated theo cảm giác” được, nó phải dựa vào so sánh superior/inferior của BPDU.

3.2) Root Port: biên có thể trở thành Root port hay không?

Tài liệu nêu rõ một “bẫy” quan trọng:

• Biên interface (boundary) có thể trở thành Root port cho một VLAN (trong ngữ cảnh PVST+) hoặc cho một instance (trong ngữ cảnh MST) nếu nó nhận BPDU tốt nhất theo quy tắc root/cost.

Nhưng vì biên đang phải so sánh xuyên kiểu (MST instance với PVST+ VLAN) nên cùng một cổng có thể đóng vai khác nhau theo từng nhóm VLAN.

Bẫy thực chiến:

• Bạn cấu hình Root Bridge cho MST instance rất “đẹp”,
• nhưng PVST+ VLAN khác lại mang ưu tiên/cost mặc định khiến Root port không “được” chọn theo như bạn nghĩ,
• dẫn tới một số VLAN forward, một số VLAN bị chặn.

3.3) Non-designated port: vì sao có lúc biên bị chặn?

Nếu cổng ở boundary:

• nhận BPDU không superior,
• và/hoặc không thỏa điều kiện để Root/Designated,

Thì nó chuyển sang non-designated (bị chặn cho mục tiêu tránh loop).

Nội dung tài liệu nhấn mạnh trường hợp thực thi: trạng thái của boundary interface hiển thị ra đúng vai trò theo so sánh BPDU. Nghĩa là bạn không “đấu cấu hình” với spanning-tree, bạn “đấu với kết quả so sánh BPDU”.

4) Trường hợp quan trọng trong tài liệu: PVST+ domain → MST domain hoặc ngược lại gây mất đồng bộ theo biên

Đây là đoạn mình coi như “xương sống” để biến thành kinh nghiệm triển khai.

4.1) Khi một phía PVST+ dùng VLAN mapping không đồng nhất theo cách thiết bị biên hiểu

Tài liệu có mô phỏng tình huống:

• Bạn có topology 3 switch (SW1 – SW2 – SW3) và nhiều VLAN.
• Bạn chạy MST và PVST+ ở các phần khác nhau.
• Mục tiêu là: VLAN nào map về MST instance nào, và root bridge cho mỗi instance phải đúng.

Tài liệu mô phỏng việc:

• Trên SW1, chạy MST (có nhiều instance map theo VLAN).
• Khi bạn “đẩy” root/priority theo từng instance, bạn sẽ thấy thông báo và trạng thái role ở biên thay đổi.

4.2) “Mismatch ưu tiên” gây thông báo PVST simulation inconsistency

Trong log mô phỏng của tài liệu, có dòng kiểu:

• MST/PVST simulation inconsistency… blocking… Inconsistent inferior PVST BPDU… claiming root

Đây là keyword rất đáng chú ý trong thực chiến. Nó thường xuất hiện khi:

• Ở biên, thiết bị phải “mô phỏng” PVST+ để tương thích với MST (hoặc ngược lại),
• nhưng do so sánh superior/inferior bị xung đột (thường đến từ priority/cost khác kỳ vọng),
• nên cổng bị đưa vào trạng thái chặn để tránh lẫn topology.

Điều mình rút ra:
Nếu bạn thấy thông báo simulation inconsistency, đừng chỉ nghĩ “chắc do loop”. Hãy coi đó là dấu hiệu:

• mapping VLAN ↔ MST instance có thể đúng,
• nhưng Root/cost/priorities không thỏa tiêu chí superior theo biên, dẫn tới thiết bị biên không dám forward.

5) Truy vết bằng cấu hình thực chiến đúng tinh thần tài liệu

Phần tiếp theo tài liệu là lab mẫu để quan sát hiệu ứng. Mình sẽ kể lại theo dạng “quy trình làm bài” để bạn có thể tái hiện trong lab và suy ra nguyên nhân khi gặp lỗi thật.

5.1) Khởi tạo VLAN và trunk, đưa các VLAN lên đường truyền trunk

Trong bài lab, các switch dùng trunk và tạo nhiều VLAN (ví dụ VLAN 10, 20, 30, 40, 50, 60). Ý ở đây là: phải đảm bảo VLAN xuất hiện đúng trên trunk trước khi bạn quan sát spanning-tree mapping.

Nếu bạn bỏ bước này (hoặc VLAN không thực sự đi qua trunk), bạn sẽ không thấy đúng BPDU tương ứng ở biên.

Ví dụ thực tế:

• PVST+ theo VLAN 10/20 có BPDU,
• nhưng MST bên kia không “có VLAN đó trong miền map” hoặc VLAN không carry qua trunk,
• thì output role sẽ “không giống lab”.

5.2) Tạo MST region và map VLAN vào MST instance

Tài liệu dùng ý tưởng map VLAN thành các instance để giảm số spanning-tree.

Trong mô phỏng:

• Một số VLAN được map về instance 1, một số VLAN về instance 2…

Kinh nghiệm thực chiến quan trọng:

• Khi bạn triển khai doanh nghiệp, đừng map “ngẫu nhiên theo cảm giác”. Hãy map theo thực tế luồng dịch vụ, vì khi xảy ra sự cố, bạn sẽ cần biết vì sao VLAN X lại bị ảnh hưởng bởi instance Y.

5.3) Chỉnh MST priority để điều khiển Root theo instance (MST → PVST+ simulation sẽ theo đó)

Trong lab, tài liệu cho thấy:

• Bạn đổi priority root của instance 1 hoặc instance 2,
• kết quả là thiết bị biên (SW PVST+ side) sẽ thay đổi Root/designated cho các VLAN thuộc instance đó.

Nhưng tài liệu cũng chỉ ra: nếu bạn làm “sai logic” (ví dụ priority làm cho BPDU MST bên kia không superior so với PVST+ mô phỏng), thì cổng biên bị chặn và ra cảnh báo.

5.4) Thử “tạo bất đối xứng” để xem vì sao biên bị blockin

Tài liệu có mô phỏng “đổi priority root” theo một hướng khiến PVST+ start complaining.

Thông điệp thực chiến ở đây:

• MST instance là một thế giới,
• PVST+ VLAN là một thế giới,
• và tại biên, thiết bị phải quyết định dựa trên “siêu đẳng/thua kém” của BPDU.

Nếu bạn làm cho bên PVST+ “giả lập” (simulation) tin rằng nó có Root tốt hơn, trong khi MST instance lại công bố Root khác (hoặc cost/prio xung đột), thì biên sẽ block để bảo toàn loop-free.

6) “Điểm rơi” hay gặp nhất: tưởng rằng chỉ cần mapping là đủ, nhưng thực ra còn phải kiểm soát RootPort theo từng VLAN/instance

Đây là phần mình muốn bạn ghi nhớ.

Tài liệu kết thúc bằng thông điệp “tương thích được, nhưng không phải tuyệt đối dễ”.

Mình diễn đạt theo kiểu kinh nghiệm:

1. Đúng mapping VLAN ↔ MST instance là điều kiện cần.
2. Đúng priority/cost của root cho instance là điều kiện đủ để biên xử lý ổn định.
3. Nếu bạn chỉ map mà không kiểm soát priority/cost, rất có thể:
   • VLAN thuộc cùng instance bạn nghĩ “đồng hành”,
   • nhưng thực tế biên tính superior theo PVST+ mô phỏng và khiến một số VLAN không còn theo đúng forwarding path.

Nói thẳng: spanning-tree interoperability không chỉ là “dịch ngôn ngữ”, mà còn là “thống nhất luật chơi”.

7) Kết luận: Checklist nhanh theo đúng tinh thần tài liệu (dành cho khi bạn triển khai thật)

Nếu bạn đang triển khai mạng lai MST và PVST+ (hoặc chuyển đổi dần), mình khuyên bạn đi theo checklist tư duy sau:

• Xác nhận VLAN tồn tại và carry qua trunk như dự kiến.
• Map VLAN vào MST instance đúng theo thiết kế (và hiểu rõ VLAN nào chịu quản lý bởi instance nào).
• Thiết kế Root Bridge theo instance trong MST: priority phải khiến BPDU MST “superior” khi so với PVST+ simulation ở biên.
• Khi gặp thông báo kiểu simulation inconsistency / blocking:
  • đừng vội đoán loop,
  • hãy coi đó là dấu hiệu so sánh BPDU superior/inferior tại boundary không như mong đợi.
• Thử kiểm tra role theo VLAN: vì biên có thể “forward” cho một nhóm VLAN và “block” cho nhóm VLAN khác tùy theo mapping và kết quả so sánh.

Chốt lại: MST và PVST+ có thể tương thích và làm việc cùng nhau được. Nhưng để nó ổn định trong môi trường thật, bạn phải hiểu sâu cách thiết bị ở biên “quyết định vai trò” dựa trên thông tin BPDU mô phỏng giữa MST instance và PVST+ VLAN.

Nếu bạn muốn, mình có thể viết tiếp phần “gỡ lỗi theo triệu chứng” dựa trên log thực tế (ví dụ nhận đúng câu chữ inconsistency/inferior/superior), để bạn biết chính xác phải kiểm tra priority/cost/mapping ở đâu trước.