Multiple Spanning Tree (MST)

[Cẩm Thanh]

Bạn đã bao giờ gặp tình huống mà mạng đang chạy STP rất “ngon”, nhưng đến lúc bạn mở rộng VLAN ra thêm, kết nối có vẻ vẫn chạy… lại bắt đầu phát sinh vòng lặp logic, hoặc chặn luồng không như mong đợi? Đây chính là lý do tôi muốn chia sẻ về Multiple Spanning Tree (MST) theo đúng tinh thần thực chiến: lúc thiết kế bạn cần hiểu thứ STP đang tính toán, và lúc cấu hình bạn cần biết vì sao cùng một vật lý topo lại cho ra nhiều dạng cây logic khác nhau.

Trong bài này, mạch ý chính là một vấn đề rất hay gặp: khi bạn có quá nhiều VLAN, nếu cứ để PVST/RPVST (hoặc Rapid PVST) chạy riêng cho từng VLAN thì số lượng instance STP bùng nổ. Bài này tôi sẽ đi sâu cả lý thuyết lẫn “cách làm” để bạn có thể tự tin triển khai MST trong tình huống thật.
1) Vì sao phải có MST? (Vấn đề “quá nhiều instance” khi dùng per-VLAN STP)

Trong PVST/Rapid PVST, STP được tính theo từng VLAN như một instance riêng. Tài liệu mô tả ví dụ:

• Nếu bạn có 1 switch chạy PVST với 20 VLAN thì sẽ có 20 instance spanning-tree khác nhau cho 20 VLAN đó.
• Tệ hơn: nếu bạn có nhiều switch, mỗi switch phải tạo và tính toàn bộ các instance tương ứng, dẫn tới việc CPU/băng thông control plane phải “cõng” số instance tăng theo số VLAN.

Quan trọng là: về mặt “hình học topo” (các link vật lý), nhiều VLAN có thể thực sự không cần phải chạy cây STP khác nhau hoàn toàn. Nhưng khi dùng PVST/RPVST, hệ thống coi mỗi VLAN là một thế giới riêng, nên bạn phải “trả giá” cho sự tách rời đó.
2) Ý tưởng cốt lõi của MST: Gom nhiều VLAN vào ít instance STP hơn

MST (Multiple Spanning Tree) là cách giải quyết vấn đề trên bằng cơ chế:

• Bạn không tính STP cho mỗi VLAN riêng lẻ nữa.
• Thay vào đó, bạn gom nhiều VLAN vào cùng một MST instance.
• Mỗi instance sẽ tạo ra một spanning tree logic riêng cho nhóm VLAN đó.

Trong topo minh họa của tài liệu, có một cấu trúc với nhiều switch và nhiều VLAN “rơi vào” các nhóm khác nhau. Điểm then chốt là:

• MST cho phép bạn thiết kế để giảm số spanning-tree calculations (instance).
• Về mặt triết lý: MST tạo ra cây theo “nhóm VLAN”, không còn theo “mỗi VLAN = 1 instance”.

Tài liệu nêu rất rõ một kết luận mà khi làm thực chiến bạn phải thuộc lòng:

“MST works with the concept of regions.”
Nghĩa là MST hoạt động dựa trên khái niệm region (vùng).

3) MST Region là gì? Vì sao phải nói đến “region” trước khi nói đến cấu hình?

Tài liệu mô tả: khi bạn cấu hình MST, switch sẽ cần biết “thuộc region nào” và “vùng đó chạy bao nhiêu MST instance”.

Lý giải theo cách dễ hiểu:

• Cùng một physical topology, nhưng nếu các switch thuộc cùng một MST region và có cấu hình MST tương đồng về thông số, thì họ sẽ nhìn thấy cùng một “phiên bản STP logic” trong region đó.
• Ngược lại, nếu một switch thuộc “bên ngoài” region, thì nó không xem MST chi tiết như bên trong; nó chỉ “nhìn thấy” một phiên bản STP tương đương theo cơ chế tương thích.

Tài liệu nhấn mạnh các trường hợp switch sẽ ở cùng region nếu thỏa:

• MST configuration name trùng
• MST configuration revision number trùng
• MST instance-to-VLAN mapping table trùng

Đây là phần thực chiến cực quan trọng:
Rất nhiều người cấu hình MST rồi “chờ hiệu lực”, nhưng vì mapping/level revision không khớp giữa các switch trong region nên topo logic vẫn không hội tụ đúng ý.

4) Bên trong MST region: “Instance tạo ra cây riêng cho từng nhóm VLAN”

Trong tài liệu, có một mô hình mô tả rất rõ:

• Bạn tạo MST region.
• Trong region đó, có MST instance 0 (cây chính cho một nhóm VLAN),
• các instance khác tương ứng với các nhóm VLAN khác.

Mấu chốt là:
IST (Internal Spanning Tree) được dùng như cây “trụ cột” cho toàn region, và các MST instance tạo ra các cây “bên trong”.

Nói đơn giản theo tinh thần tài liệu:

• MST giúp bạn “che” chi tiết chạy instance ra khỏi phần “bên ngoài”.
• Bên ngoài region, phần tương thích sẽ chỉ nhìn thấy thứ tương ứng với IST, kiểu như một “bản rút gọn”.

5) Còn “bên ngoài MST region” thì sao? (Tại sao topology nhìn khác?)

Tài liệu dùng ý “other version of STP” để giải thích:

• Switch ở ngoài MST region không nhìn thấy đầy đủ cây của từng instance.
• Nó chỉ nhìn thấy một phiên bản theo cơ chế tương thích.

Đây chính là lý do khi bạn benchmark/cắm cấu hình xong, đôi khi bạn thấy:

• Switch A (trong region) thấy port này forwarding/blocking theo instance nào đó,
• nhưng switch B (ngoài region) lại cho bạn “một cách nhìn khác”.

Thực tế triển khai sẽ luôn phải chấp nhận điều này và chuẩn hóa theo đúng cách MST quy định.
6) MST Configuration: Những tham số bắt buộc phải nắm

Tài liệu đi sang phần 1. MST Configuration và nêu cấu hình để tạo MST region “NetworkLessons” với:

• MST configuration name: NetworkLessons
• MST configuration revision number: (được dùng để nhận diện phiên bản cấu hình region; tài liệu lấy một con số do người học tự đặt)
• MST instance VLAN mapping table: ánh xạ VLAN vào instance

Ví dụ mapping được mô tả trong tài liệu:

• Instance 1: VLAN 10, 20, 30
• Instance 2: VLAN 40, 50, 60

Khi làm thực chiến, bạn cần ghi nhớ: MST instance là đơn vị tính STP logic. Mapping VLAN chính là “quy ước công việc”.

7) Cách cấu hình MST trong IOS/CLI (theo đúng “flow” thực tế từ tài liệu)

Tài liệu thể hiện các bước “điều phối” trên các switch, theo đúng tinh thần:

1. Vào spanning-tree mode MST
2. Đặt name + revision
3. Tạo instance và gán VLAN vào instance tương ứng
4. Enable MST (và kiểm tra show)

Tài liệu cũng đưa lệnh để kiểm tra trạng thái MST instance thông qua lệnh dạng:

• show spanning-tree mst configuration
• sau đó dùng các thông tin:
  • MST configuration name
  • revision
  • số instance được cấu hình
  • VLAN mapped vào instance nào

Điểm thực chiến tôi muốn bạn chú ý:
Trong bài lab của tài liệu, các switch được cấu hình để thống nhất mapping và revision. Nếu bạn chỉ sửa mapping trên một switch mà không sửa các switch còn lại trong region, các cây logic sẽ bị “lệch phiên bản”.

8) “IST” và “Root bridge” trong MST: Vì sao bạn thấy root khác nhau?

Tài liệu sau đó chuyển sang kiểm tra “root bridge”:

• Bạn có thể đặt lại priority cho MST instance (cụ thể trong tài liệu có thay đổi priority để làm switch trở thành root cho một instance nhất định).

Nói bản chất:

• Mỗi MST instance sẽ có một root cho cây spanning-tree của instance đó.
• Trong khi bên trong region, IST hoạt động như xương sống tương thích.
• Vì vậy, cùng một switch có thể là root cho instance này, nhưng lại không phải root cho instance khác (tùy bạn set priority và mapping VLAN).

Trong tài liệu có ví dụ:

• Cho một thời điểm, SW1 là root bridge cho IST (internal spanning tree)
• Sau đó tài liệu thay đổi priority để làm SW2 trở thành root bridge cho MST instance 2
• Tiếp tục làm tương tự cho instance 3

Thực chiến ở đây là: để dự đoán port forwarding/blocking, bạn không thể chỉ nhìn “root của STP” chung. Bạn cần hiểu “root theo IST” và “root theo instance”.
9) Cách đọc kết quả sau khi cấu hình: Port nào forwarding/blocking theo instance nào?

Tài liệu thể hiện các bước kiểm tra bằng cách xem:

• Vai trò của các cổng
• Root/Designated/Alternate (nội dung trong show sẽ cho bạn biết vai trò trên từng interface)

Ý quan trọng tôi muốn bạn “đóng khung” lại:

• Trong MST, vai trò port có thể khác nhau tùy instance/VLAN.
• Nếu bạn map VLAN X vào instance 2, thì các quyết định forwarding/blocking của VLAN X sẽ theo cây của instance 2.

Nói cách khác:
MST làm bạn “có thể thiết kế” chỗ nào chặn/lưu thông theo từng nhóm VLAN.

10) “PVI/PVST vs MST”: Vì sao tài liệu còn nhắc đến PVST+ và PVRST-PVST interaction?

Trong bài này, phần Forum Replies nhắc lại điểm “đau đầu” mà người mới hay mắc:

• “IST is called IT/ST (Internal Spanning-Tree) …”
• “PVST uses 1 STP instance for each VLAN …”
• “To make the two compatible, here’s what happens…”
• MST region sẽ được đánh dấu/đối sánh sao cho PVST bên ngoài có thể tương thích.

Thực chiến bạn cần hiểu 1 câu cốt lõi:

MST và PVST không tính giống nhau (về số instance), nên khi đi qua biên region bạn sẽ có “hành vi tương thích”.
Vì vậy, đừng kỳ vọng “một cách nhìn duy nhất” cho mọi thiết bị.

11) Ví dụ thực chiến (mang đúng tinh thần tài liệu): Thiết kế giải pháp cho 3 nhóm VLAN để tối ưu luồng

Giả sử mạng bạn có 3 nhóm VLAN tương ứng 3 miền logic (giống cách tài liệu map):

• VLAN 10/20/30 -> MST instance 1
• VLAN 40/50/60 -> MST instance 2
• (nếu thêm) VLAN 70/80/90 -> MST instance 3

Bạn muốn làm các chính sách thường gặp trong thực tế:

• Cho instance 1 root ở SW1 để luồng VLAN 10/20/30 đi theo hướng SW1
• Cho instance 2 root ở SW2 để luồng VLAN 40/50/60 đi theo hướng SW2
• Cho instance 3 root ở SW3 (nếu triển khai)

Khi mapping như vậy, bạn tạo được khả năng:

• chia tải logic,
• tránh “mọi VLAN đều bị kéo về một root duy nhất” như mô hình PVST đơn thuần,
• giảm bùng nổ instance.

Đây chính là “trúng đích” mà người ta dùng MST trong core/distribution nhiều VLAN.

12) Checklist những điều bạn phải tự kiểm trước khi gọi là “MST triển khai thành công”

Nếu bạn muốn MST chạy ổn định và đúng ý nghĩa “mỗi nhóm VLAN 1 cây logic”, hãy chắc chắn:

• MST configuration name giữa các switch trong cùng region phải khớp
• MST revision number phải khớp
• MST instance-to-VLAN mapping phải khớp
• Bạn set root priority theo đúng instance bạn muốn (IST ≠ MST instance)
• Khi kiểm tra, phải xem theo instance/VLAN mapping, không chỉ nhìn “root của toàn mạng”

Nếu bạn bỏ qua 1 trong các mục trên, bạn sẽ gặp những triệu chứng kiểu:

• một số VLAN có forwarding như ý,
• một số VLAN thì không,
• hoặc root “không đúng” như kỳ vọng.