Rapid Spanning-Tree (RSTP)

[Cẩm Thanh]

Mạng doanh nghiệp mà “lên chậm” vì STP thì cảm giác rất thật: cắm thiết bị vào là không ping được, ứng dụng timeout, người dùng gọi helpdesk liên tục. Và khi bạn xem nguyên nhân sâu hơn, thứ làm bạn đau nhất thường không phải là lỗi cấu hình, mà là cơ chế hội tụ của Spanning-Tree.

Trong bài viết này, tôi sẽ chia sẻ theo đúng tinh thần thực chiến dựa trên “Rapid Spanning-Tree (RSTP)”: RSTP thực chất là một bước tiến so với Classic STP, giúp giảm thời gian hội tụ bằng cách thay đổi trạng thái cổng và cơ chế xử lý BPDU, đặc biệt ở các tình huống thay đổi topo. Tôi sẽ giải thích kỹ thuật theo hướng “bạn dùng để làm được việc”, kèm ví dụ để bạn hình dung nhanh.

1) Classic Spanning-Tree và những gì khiến bạn phải chờ

Classic Spanning-Tree (STP chuẩn “cổ điển” trong tài liệu) có các trạng thái tiêu biểu trên cổng: Blocking, Listening, Learning, Forwarding.

Điều làm thời gian hội tụ chậm đến từ “logic đi qua các bước” trước khi forward. Khi topo thay đổi, switch không chỉ cần quyết định cổng nào cần forward, mà còn cần “đợi” đủ điều kiện theo cơ chế chuyển trạng thái dựa trên timers (hệ thống thời gian).

Trong môi trường thực tế, nếu có link flapping, thay đổi uplink, hoặc thay thiết bị, Classic STP sẽ phải xử lý theo hướng an toàn nhưng đôi khi quá thận trọng. Bạn sẽ cảm nhận điều này rõ nhất khi thay đổi diễn ra “tại thời điểm người dùng đang online”.

2) RSTP là gì? Không phải “làm nhanh bằng may rủi”, mà là đổi cơ chế

RSTP (Rapid Spanning-Tree) là sự tiến hóa của STP cổ điển, mục tiêu chính là hội tụ nhanh hơn trong các tình huống thay đổi topo.

Điểm cốt lõi trong tài liệu: RSTP không chỉ thay đổi “tên trạng thái”, mà quan trọng hơn là thay đổi cách cổng đi vào forwarding.

Trong RSTP, một trạng thái được nhấn mạnh là Discarding thay vì giữ kiểu Blocking của Classic. Ý nghĩa thực chiến của Discarding là: cổng có thể bị loại bỏ đường truyền tại một thời điểm nhất định, nhưng cơ chế chuyển sang forward được “tăng tốc” hơn, thay vì phải chờ theo một chuỗi bước cũ.

Ngoài ra, tài liệu mô tả một khác biệt quan trọng về các trạng thái mà cổng đi qua:

• Classic STP có logic “Blocking, Listening, Learning, Forwarding”.
• Rapid STP có cơ chế “chuyển qua Discarding, Learning (khi cần), rồi Forwarding” theo cách linh hoạt hơn.

Nói thẳng theo kinh nghiệm: bạn muốn RSTP giúp mạng “đổi quyết định nhanh”, giảm thời gian port bị treo lâu trước khi bắt đầu chuyển tiếp frame dữ liệu.

3) Nhìn bằng ví dụ topo: vì sao non-root/ root cổng lại khác nhau?

Trong STP/RSTP, bạn sẽ luôn có khái niệm:

• Root bridge: switch làm gốc của cây spanning-tree.
• Non-root bridges: các switch còn lại.

Trong ví dụ của tài liệu, có một root bridge ở trên cùng (root). Các switch phía dưới được coi là non-root. Các cổng nối giữa các switch được chọn theo tiêu chí chi phí đường đi và vai trò trong cây.

Trong thế giới thực, khi một link thay đổi, toàn bộ “cây logic” phải cập nhật: cổng nào là designated port, cổng nào là root port, và cổng nào bị chặn để tránh loop
.
RSTP giúp cập nhật nhanh hơn ở phần “chuyển trạng thái cổng” khi cần thay đổi.

4) BPDU trong RSTP: thay đổi cách phân bổ và cách “đánh dấu loại thông tin”

Một phần rất quan trọng trong tài liệu là chương về BPDU và sự khác nhau giữa:

• Classic STP BPDU
• Rapid Spanning-Tree BPDU (RSTP)

Trong tài liệu, có nhấn rằng BPDU không phải lúc nào cũng được gửi liên tục kiểu “đồng loạt cho mọi thứ”.

Điểm khác biệt nổi bật là:

• Trong RSTP có thêm các bits/flags trong BPDU để biểu diễn vai trò trạng thái và cách xử lý.
• Tài liệu gọi phiên bản BPDU mới này là “Version 2 BPDU” (trong ngữ cảnh RSTP).

Vì sao bạn cần hiểu điều này? Vì hội tụ nhanh không chỉ là “giảm timer”, mà là thiết bị dựa trên thông tin trong BPDU để quyết định nhanh, thay vì phải chờ quá trình chuyển trạng thái theo timers như Classic.

Trong thực chiến, nếu bạn debug BPDU, bạn sẽ thấy RSTP “hành xử có chiến lược” hơn: nó gửi đúng kiểu thông điệp và kỳ vọng các switch lân cận phản hồi đúng vai trò.

5) RSTP dùng “UpLinkFast-like” ý tưởng gì trong chính sách cấu trúc?

Tài liệu nhấn một mảng khác mà bạn nên biết khi triển khai: cơ chế liên quan đến uplink và cách RSTP có thể chuyển cổng sang forward nhanh khi thiết bị phát hiện có thay đổi vai trò.

Điểm tài liệu ghi khá rõ: khi cấu hình “một cơ chế tương tự như UplinkFast”, switch có thể cho phép trạng thái chuyển nhanh hơn trong tình huống mất uplink (link failure).

Dịch sang ngôn ngữ vận hành: nếu bạn chỉ trông chờ STP cổ điển, thời gian phục hồi có thể phụ thuộc timers. Nếu bạn bật các tính năng đúng ngữ cảnh (đúng vai trò uplink, đúng edge), thời gian quay lại dịch vụ sẽ tốt hơn.
6) Cơ chế đồng bộ hóa (Synchronization) trong RSTP: vì sao chuyển nhanh?

Đây là phần “ăn điểm” nhất về lý thuyết của tài liệu: RSTP có cơ chế đồng bộ.

Một chuỗi hành động theo logic giữa các switch:

• Khi có tình huống mới xảy ra (ví dụ thay đổi trạng thái liên quan đến cổng không-root),
• RSTP sử dụng các thông điệp và cơ chế đồng bộ để các switch liên quan “agree” (thỏa thuận) trước khi một nhóm cổng chuyển nhanh sang forwarding.

Quy trình dạng nhiều bước:

1. Proposal (đề xuất)
2. Sync (đồng bộ)
3. Agreement (xác nhận/thỏa thuận)
4. Forwarding (chuyển tiếp)

Tư duy cần nắm: RSTP muốn đảm bảo rằng “nhóm cổng” chuyển sang forwarding không bị lệch nhịp gây ra loop tạm thời. Vì vậy, thay vì chờ timer-based state machine như Classic, nó dùng cơ chế “hỏi đáp/đồng bộ” để đạt trạng thái nhanh nhưng vẫn giữ an toàn.

7) Tại sao RSTP có thể bỏ qua Listening/Blocking lâu như Classic?

Trong phần tài liệu về điểm khác nhau của trạng thái cổng, có một thông điệp rất thực dụng:

• RSTP không nhất thiết phải đi qua toàn bộ các trạng thái giống Classic theo kiểu “timer cứng”.
• Cổng có thể đi thẳng về forwarding nhanh hơn, với điều kiện RSTP xác thực được vai trò và đồng bộ với các switch liên quan.

Bạn sẽ thấy trong tài liệu có nhấn mạnh: Rapid Spanning-Tree không chỉ thay đổi timer, mà thay đổi cơ chế chọn và chuyển trạng thái dựa theo dữ liệu BPDU và cơ chế đồng bộ.

Nói như người làm: Classic STP giống như “chờ đủ bài học rồi mới cho thi”, còn RSTP giống như “biết điều kiện rồi thì cho làm ngay, nhưng có kiểm tra nhanh để không hỏng”.

8) RSTP tương thích với Classic STP: chuyển dần để mạng không bị “đổi sốc”

Một điều tôi luôn coi là điều kiện tiên quyết trong triển khai doanh nghiệp: không ai muốn RSTP chạy xong rồi làm mạng mất ổn định vì tương thích.

Tài liệu có đoạn kết nhấn mạnh mấu chốt:

• Nếu switch chạy RSTP nối với switch chạy spanning-tree “phiên bản cũ”, thì RSTP sẽ có cơ chế tương thích.
• Trong trường hợp có nhiều switch, nếu không có đủ điều kiện RSTP đầy đủ, hệ thống có thể fallback về Classic.

Nói theo thực tế vận hành: bạn phải kiểm tra phiên bản tính năng và hiểu rằng topology có thể quyết định hành vi hội tụ. Đôi khi trong mạng thật, chỉ cần một thiết bị không hỗ trợ đầy đủ RSTP, phần còn lại có thể không đạt được tốc độ “nhanh nhất”.

9) Cơ chế thay đổi topo: RSTP khác gì khi có “link failure” hoặc thay đổi đường đi?

Tài liệu nhấn rằng RSTP có cơ chế khác với Classic STP khi topo thay đổi:

• Classic STP thường sẽ “flood” thay đổi theo kiểu dựa vào quá trình và timers.
• RSTP có xu hướng phản ứng theo cơ chế nhanh hơn, dùng thông điệp và đồng bộ để quyết định cổng nào forward/blocked.

Trong thực chiến, bạn nên hình dung:

• Khi có sự kiện link thay đổi, RSTP cố gắng cập nhật cây logic nhanh hơn, giảm thời gian gián đoạn dịch vụ.
• Đồng thời, RSTP hạn chế tình trạng làm cổng chuyển trạng thái theo cách “đợi timer” quá lâu.

10) Lời khuyên triển khai thực chiến (theo đúng tinh thần CCIE mindset trong tài liệu)

Nếu bạn muốn RSTP phát huy đúng hiệu quả (không chỉ “bật lên cho có”), tôi gợi ý bạn làm 3 bước tư duy:

• Thứ nhất, hiểu vai trò root và các cổng (root port, designated port, non-designated/blocked).
  Nếu bạn không hiểu cổng nào đang làm gì, bạn sẽ debug mù.
• Thứ hai, đừng chỉ nhìn timer; hãy nhìn cách BPDU thay đổi.
  RSTP hội tụ nhanh nhờ cơ chế BPDU và đồng bộ hóa, không phải “may mắn”.
• Thứ ba, kiểm tra tương thích theo thiết bị trong topology.
  Nếu có switch chạy spanning-tree kiểu cũ, tốc độ hội tụ có thể giảm. Và đây là điều tài liệu nhắc rõ: có thể fallback về classic.

Kết bài

Rapid Spanning-Tree không phải phép màu, nhưng là một bước tiến đúng hướng: thay đổi cơ chế chuyển trạng thái và cách dùng BPDU để hội tụ nhanh hơn mà vẫn giữ an toàn loop. Trong môi trường doanh nghiệp, nơi thay đổi link diễn ra thường xuyên và người dùng không thể “chờ cho STP học xong”, RSTP là lựa chọn rất đáng tối ưu.