Spanning-Tree Backbone Fast

[Cẩm Thanh]

Mình đã có dịp “đau đầu” khá nhiều với STP trong các buổi sự cố thực chiến, đặc biệt là những môi trường có nhiều switch và uplink/backbone kiểu tam giác vòng lặp. Và có một điểm mình muốn chia sẻ thẳng: trong STP, không chỉ quan trọng “chọn root” mà còn quan trọng “cách hệ thống xử lý khi gián đoạn đường backbone”. Chỉ cần xử lý chậm vài chục giây là business đã kịp la rồi.

Trong bài viết này, mình sẽ chia sẻ kinh nghiệm thực chiến theo đúng nội dung trong tài liệu bạn gửi: Spanning-Tree Backbone Fast – cơ chế giúp rút ngắn thời gian khôi phục khi backbone link bị mất bằng cách chủ động “dò” root nhanh hơn thay vì chờ theo cơ chế chuẩn.

1) Bối cảnh STP: vì sao backbone failure lại “đáng sợ”?

Ở mô hình cơ bản, STP hoạt động theo logic:

• Switch bầu ra root bridge dựa vào Bridge Priority (và tiếp theo là các tiêu chí như MAC nếu priority trùng).
• Mỗi switch chọn root port (cổng tốt nhất để đi về root).
• Mỗi switch xác định designated ports để đảm bảo không tạo vòng lặp.

Giờ giả sử ta có topology dạng backbone giữa các switch. Khi xảy ra sự cố link ở “đường về root” hoặc đường backbone liên quan đến root path, có một vấn đề rất thực tế:

• STP “chuẩn” sẽ phải đi qua giai đoạn listening / learning theo thời gian ngẫu nhiên hoặc cấu hình theo chuẩn STP.
• Trong lúc chờ, một số cổng sẽ không forwarding, khiến traffic “đứng”.

Thứ làm mình khó chịu là: thực tế đôi khi “điểm gãy” là một link giữa switch không phải root, nhưng lại ảnh hưởng tới vai trò root trên toàn đoạn. Kết quả là nhiều switch vẫn phải đợi quá lâu để chuyển trạng thái.

2) Tài liệu đưa ra kịch bản: khi link backbone giữa SW1 và SW2 bị đứt

Trong tài liệu có 3 switch chính: SW1, SW2, SW3.

• Root bridge được chọn là SW1 với:
  • Priority 32768
  • MAC AAA
• Hai switch còn lại là non-root:
  • SW2 Priority 32768 MAC BBB
  • SW3 Priority 32768 MAC CCC (trong hình mô tả)
• Cổng backbone đi giữa:
  • SW1 và SW2 có đường truyền qua cổng kiểu Fa0/16
  • SW1 và SW3 cũng qua đường truyền tương tự (tài liệu thể hiện backbone theo hướng từ root đi ra các non-root)
• Các liên kết khác sẽ có trạng thái chặn/mở để tránh loop.

Tài liệu mô tả một tình huống cụ thể:
Khi link giữa SW1 và SW2 bị gián đoạn (indirect fail), dẫn đến việc SW2 nhận ra tình trạng lỗi thông qua việc không còn nhận BPDU như bình thường.

Điểm quan trọng ở đây là: “backbone failure” trong ngữ cảnh Backbone Fast là kiểu mà switch non-root nhận ra upstream backbone bị gãy và có cơ hội chuyển nhanh về forward nếu nó xác định được nhanh rằng root vẫn như cũ (hoặc thông tin mà nó “hỏi” được sẽ cho phép chuyển nhanh).
3) Cơ chế STP chuẩn xử lý thế nào trong tài liệu (và vì sao tốn thời gian)

Trong mô tả, khi SW2 mất liên kết backbone:

1. Tìm thấy mình không còn liên lạc về root
   SW2 phát hiện BPDU từ hướng về root không còn đến. Tài liệu mô tả mốc thời gian kiểu:
   • một đoạn indirect failure detection
   • sau đó phải chờ theo max age để đảm bảo không có thông tin BPDU “trễ”
2. Cổng bị đưa vào listening/learning trước khi forwarding
   Đây chính là cơ chế “an toàn” của STP chuẩn. Nhưng trong thực tế, nó khiến phục hồi chậm.
3. Tài liệu nêu tổng thời gian dao động theo logic max-age + listening/learning.
   Trong phần output debug, bạn có thể thấy giai đoạn:
   • “listening state”
   • rồi “learning state”
   • cuối cùng “forwarding state”

=> Điểm rút ra: STP chuẩn không biết chắc “đứt backbone thì root đã thay đổi hay chưa”, nên nó phải chờ đủ thời gian để tránh tạo loop sai.

4) Backbone Fast: thay đổi tư duy từ “chờ” sang “hỏi thông minh”

Bây giờ vào phần chính: Spanning-Tree Backbone Fast.

Ý tưởng cốt lõi (mình diễn giải theo đúng logic tài liệu):

• Khi một non-root switch mất liên lạc và nghi ngờ cổng root bị ảnh hưởng gián tiếp, nó không chỉ chờ max-age rồi mới chuyển.
• Nó có thể phát sinh cơ chế “request” (RL**Q) để dò xem root path còn tồn tại hay không, từ đó quyết định:
  • có thể chuyển nhanh sang forwarding hay không
  • hay cần giữ trạng thái chờ theo STP chuẩn

Trong tài liệu có các thông điệp/khái niệm chính:

• RLQ (Root Link Query): non-root switch gửi truy vấn để hỏi “liệu đầu bên kia có nhận root tốt không / có còn thông tin root hợp lệ không?”
• Response RLQ: đầu còn lại trả lời bằng thông tin liên quan root path.

Khi RLQ được dùng đúng ngữ cảnh backbone failure, switch sẽ giảm đáng kể thời gian “không forwarding” vì nó có thông tin xác nhận nhanh hơn.

5) Trong kịch bản: Backbone Fast làm gì cụ thể giữa SW2 và SW3?

Tài liệu mô tả quy trình debug khá “đúng chất lab”: 5.1 SW1 không đổi: vẫn là root (VLAN1 root)

Trong quá trình mô phỏng có dòng dạng:

• “SW1 is the spanning tree root” với VLAN1

Tức là root không thay đổi (không có chuyện SW2/SW3 được bầu lại thành root).
Vậy nếu root vẫn tồn tại ổn định, thì việc chờ full STP max-age là lãng phí. 5.2 SW2 nhận BPDU liên quan root bị mất, và bắt đầu Backbone Fast

Khi SW2 không còn nhận BPDU từ SW1 (upstream), SW2 sẽ xác định đó là tình huống backbone failure theo ngữ cảnh của backbone fast.

Trong debug output, tài liệu thể hiện:

• SW2 gửi RLQ hỏi phía còn lại (trong hình/diễn giải là hỏi hướng tới SW3 thông qua cổng Fa0/16 tương ứng logic)

Đây là mấu chốt:
Thay vì chỉ “đợi timer hết rồi mới chuyển trạng thái”, SW2 chủ động hỏi để xác minh “root path”.

5.3 SW3 trả lời: giúp SW2 ra quyết định nhanh

Tài liệu mô tả:

• SW3 nhận RLQ
• tạo response
• thông tin response cho thấy root còn có đường hợp lệ qua nhánh nào đó, và/hoặc xác nhận cổng nhận liên quan root path

Kết quả:

• SW2 chuyển trạng thái theo hướng listening/learning ngắn hơn hoặc bỏ phần chờ dài.

5.4 Kết quả thời gian: Backbone Fast bỏ được phần chờ max time

Trong phần giải thích, tài liệu nêu rằng:

• Nếu enable backbone fast đúng cách, SW2 có thể skip khoảng thời gian chờ max age (hoặc một phần đáng kể của nó) và chuyển sang forwarding sớm.
• Tài liệu còn nhấn mạnh “save 20 seconds of time” (ý là có tiết kiệm thời gian đáng kể, dựa vào logic dự phòng của bộ timer trong STP).

Nói cách khác:
Backbone Fast tối ưu phục hồi khi root vẫn nguyên, chỉ backbone link gãy “gián tiếp”. 6) Cách cấu hình trong tài liệu: enable Backbone Fast là bật lệnh trên từng switch

Trong phần “Configurations”, tài liệu cho thấy cấu hình mẫu tương tự trên SW1/SW2/SW3:

• Ở chế độ global/config:
  • spanning-tree backbonefast
    (được bật theo kiểu global command)

Tài liệu nhấn mạnh thêm:

• “globally command” nên áp dụng cho nhiều switch trong miền STP để phát huy đúng cơ chế.
• Sau khi bật, bạn có thể dùng debug để quan sát event và backbone fast details.

Vì mình làm thực chiến, lời khuyên của mình là:

Đừng bật một vài switch lẻ tẻ rồi kỳ vọng performance như lab. STP là “hệ thống đồng bộ”; thiếu tham gia của một phía thì cơ chế hỏi/đáp (RLQ/response) không thể chạy trọn chu kỳ như kỳ vọng.
7) Dùng debug như thế nào để “nhìn thấy” Backbone Fast trong sự cố thật

Tài liệu có phần debug theo kiểu:

• Bật debug backbonefast detail / debug spanning-tree events
• Quan sát chuỗi chuyển trạng thái và event RLQ

Trong thực chiến, debug giúp bạn trả lời 3 câu hỏi “đúng bản chất sự cố”:

1. Link gãy “thật sự” ở đâu: cổng nào stop nhận BPDU?
2. Switch đang làm gì: đang chờ timer hay đang gửi RLQ request?
3. Kết quả RLQ: phía bên kia có trả lời không và thông tin trả lời dẫn đến forwarding sớm không?

Nếu bạn chỉ nhìn interface up/down mà không nhìn RLQ/listening/learning, bạn sẽ khó chứng minh “vì sao” một số VLAN recovery nhanh hơn một số VLAN khác.

8) Một điểm hay trong tài liệu: thử mô phỏng “indirect failure” và so sánh hành vi

Tài liệu có mô phỏng hai kịch bản:

• Trường hợp không enable backbone fast:
  • SW2 phải đi qua waiting + listening/learning theo timer chuẩn
  • total recovery lâu
• Trường hợp enable backbone fast:
  • SW2 gửi RLQ
  • nhận response
  • chuyển trạng thái theo hướng nhanh hơn
  • tiết kiệm thời gian phục hồi

Đây là dạng so sánh rất “đúng kỹ thuật”:

Cùng topology, cùng kiểu fail, chỉ khác backbonefast bật/tắt.

Trong lab của mình, mình cũng hay làm đúng kiểu: tắt/bật từng feature để “cô lập” nguyên nhân.

9) Kết luận kinh nghiệm thực chiến: khi nào nên dùng Backbone Fast?

Tóm lại theo đúng nội dung tài liệu và góc nhìn vận hành:

• Backbone Fast phù hợp khi bạn có backbone link hoặc liên kết uplink dạng “gián tiếp tác động root path”.
• Khi root bridge không thay đổi, backbonefast giúp giảm thời gian cổng chuyển trạng thái bằng cách xác minh nhanh thông tin root path qua RLQ.
• Nếu toàn mạng phức tạp và bạn đang tối ưu convergence, đây là một trong những “đòn” có thể giúp recovery nhanh hơn so với STP chuẩn chỉ dựa max age + listening/learning.

Nhưng để “đúng bài”, bạn cần:

• bật consistent trên các switch trong miền
• biết đọc debug để xác minh việc RLQ chạy và cổng chuyển trạng thái do RLQ hay do timer