BPDUs đi như thế nào, và từng switch đổi trạng thái ra sao sau khi topology thay đổi?

[Cẩm Thanh]

Bạn đã bao giờ “đang chạy Spanning-Tree ngon lành”, rồi chỉ vì một thay đổi rất nhỏ ở đường uplink, STP bỗng dưng chuyển trạng thái hàng loạt… và kết quả là mạng nghẽn, chập chờn, hoặc gián đoạn vài chục giây?

Điểm khó nhất không nằm ở việc STP hội tụ lại, mà nằm ở câu hỏi: nó hội tụ bằng cách nào, các BPDUs đi như thế nào, và từng switch đổi trạng thái ra sao sau khi topology thay đổi?

Trong bài chia sẻ này, mình sẽ đóng vai kỹ sư mạng đã từng triển khai thực chiến và cũng từng “dính” đủ loại tình huống xoay quanh STP. Mình bám sát nội dung từ tài liệu “Spanning-Tree Reconvergence” để giải thích sâu lý thuyết, đồng thời ghép với ví dụ thực tế để bạn hình dung được cơ chế reconvergence một cách trực quan. 1) Topology hội tụ (Converged Topology): Khi STP đã “ổn”

Trước khi nói đến reconvergence, ta phải hiểu STP đang ở trạng thái nào khi topology ổn định.

Tài liệu minh hoạ một mô hình gồm 5 switch (SW1, SW2, SW3, SW4, SW5) nối theo dạng hình chữ U đối xứng. Mọi liên kết đều tồn tại, và STP đã hội tụ về root bridge.

Trong phần “Converged Topology”, ý chính là:

• SW1 là root bridge
• Các switch còn lại không phải root bridge sẽ có các cổng với vai trò:
  • Root port (RP): cổng tốt nhất mà switch đó dùng để hướng về root
  • Designated port (DP): cổng được chỉ định để forward trên segment đó
  • Non-designated / blocked: cổng không forward để tránh loop

Điểm mấu chốt: Khi topology chưa đổi, STP không “làm lại từ đầu” sau mỗi gói tin; nó đã giữ đúng trạng thái forwarding/blocking theo tính toán nhất quán của toàn mạng.

Để mô tả trạng thái port trong tài liệu (theo vai trò nhìn thấy trên sơ đồ), ý nghĩa là:

• SW2, SW3, SW4, SW5 mỗi con sẽ có một hoặc một số cổng đóng vai trò khác nhau (RP/DP/block), và tất cả đã phù hợp với quan hệ “best path to root”.

Nói theo kiểu thực chiến: lúc này bạn có thể ping qua switch, lưu lượng chạy đúng, và STP “ngủ yên”.

2) Vì sao reconvergence thú vị? Bởi vì STP phản ứng với thay đổi

Đến phần quan trọng: “When the topology changes”.

Tài liệu đặt vấn đề rất đúng kiểu troubleshooting:

• “Topology thay đổi” không phải chỉ là switch bị tắt/mất link.
• Nó có thể là bạn shutdown một cổng cụ thể (cổng upstream/downstream), hoặc thay đổi khiến cổng đó không còn tham gia STP logic nữa.
• Khi đó, STP không còn giữ nguyên trạng thái cũ, và phải tính lại:
  • Ai là root mới?
  • Ai là root port mới ở từng switch?
  • Ai là designated port trên từng segment?
  • Những cổng nào phải chuyển tiếp state theo thứ tự để tránh loop?

Nhưng STP sẽ không “cứ tự hiểu” ngay. Nó cần dữ liệu trao đổi qua BPDUs (Bridge Protocol Data Units).

2.1) Các BPDUs và “bài toán tuổi message age”

Tài liệu đi sâu vào cơ chế BPDUs lan truyền khi root/topology đổi.

Khi một switch phát hiện cần thay đổi (ví dụ root bị mất do bạn shutdown một interface ở root hướng ra ngoài), nó sẽ phát ra/forward BPDUs để các switch khác so sánh và cập nhật.

Điểm kỹ thuật nổi bật trong tài liệu là:

• BPDUs chứa thông tin định danh root, bridge priority, root path cost…
• Quan trọng nhất để “tính theo thời gian lan truyền” là trường Message Age.

Tài liệu minh hoạ rất rõ dòng logic:

• BPDUs được tạo (tại thời điểm nó được gửi đi)
• Message Age tăng dần khi đi qua các switch
• Nhờ Message Age mà các switch biết được “bản tin này mới hay cũ” và quyết định có chấp nhận thông tin mới nhất hay không

Mình diễn giải theo trực giác:

• Hãy coi BPDUs như “tin báo thay đổi top” chạy trong mạng.
• Tin đó càng đi xa thì càng “cũ hơn” (age tăng).
• Switch ở phía sau chỉ tin vào tin “đúng nhất / còn hiệu lực / mới nhất” dựa trên so sánh theo cơ chế STP.

Trong tài liệu, khi root còn là SW1, các switch nhận BPDUs và giữ đúng trạng thái. Khi một interface bị shutdown, root phía đó không còn hợp lệ, và một BPDUs mới sẽ được sinh ra với các giá trị cập nhật.

Kết quả là:

• Switch nào nhận BPDUs mới “tốt hơn” thì đổi root port/DP/block theo quy tắc.
• Switch nào không nhận được BPDUs từ hướng superior thì sẽ tự tiến hành chuyển trạng thái theo con đường còn lại.

2.2) Tạo “scenario” shutdown để quan sát reconvergence

Tài liệu mô phỏng hai tình huống chính bằng cách “tác động vào cổng” trên SW1, rồi quan sát STP trên từng switch.

Bạn có thể hình dung đây là cách lab thường làm khi học STP:

• Chạy trạng thái converged
• Chụp/quan sát BPDUs và port roles
• Shutdown từng interface theo kịch bản
• Xem các switch thay đổi như thế nào

Trong phần “2.2” và các mục kế tiếp của tài liệu, kịch bản được triển khai theo kiểu:

• Tắt một cổng GigabitEthernet trên SW1
• Theo dõi debug spanning-tree events
• Đồng thời kiểm tra lại vai trò port trên các switch khác nhau

Điều mình muốn nhấn mạnh: Reconvergence trong STP không phải chỉ là “đổi root”. Nó là một chuỗi thay đổi state và lan truyền BPDUs theo thứ tự để đảm bảo không tạo loop. 2.3) Lần shutdown thứ nhất: Shutdown Gi0/1 trên SW1

Tài liệu mô tả rất cụ thể các quan sát trên SW1 bằng debug kiểu sự kiện:

• SW1 là root bridge ban đầu
• Khi bạn shutdown Gi0/1 trên SW1, SW1 phát sinh topology change
• Các switch còn lại nhận thông tin mới và tính lại đường tốt nhất đến root

Cốt lõi bạn cần nắm:

1. SW1 đang là root nên nó gửi thông tin root/TC theo logic của root
2. Khi một cổng root bị shutdown, “topology thay đổi” làm một số switch không còn nhìn thấy đường như cũ
3. Switch ở xa sẽ so sánh các BPDUs mới, và một số switch bắt đầu chuyển:
   • trước tiên là chọn root port mới
   • sau đó là chuyển state theo tiến trình chống loop

Tài liệu còn thể hiện rõ mô tả trạng thái theo từng thời điểm (debug event). Ví dụ:

• có thời điểm SW1 generate TCP trap do topology change
• sau đó SW2 nhận BPDUs và chọn lại root/role

Trong tình huống này, có một khái niệm quan trọng trong STP mà nhiều người hay hiểu sai:

• Không phải cứ “thấy root đổi là mọi cổng chuyển ngay sang forwarding”.
• STP dùng cơ chế state machine (listening/learning/forwarding…) theo thứ tự để đảm bảo loop không xảy ra.

2.4) BPDUs sau khi cổng thay đổi: Nhìn “root bridge” và “bridge id” thay đổi thế nào

Một phần rất đáng học trong tài liệu là đoạn mô tả BPDUs cụ thể:

• Khi topology đổi, BPDUs giữa các cặp switch có các trường:
  • Root Identifier
  • Root Path Cost
  • Bridge Identifier (của switch gửi)
  • Bridge Priority/Port ID
• Và Message Age tăng theo chặng

Ví dụ trong tài liệu:

• BPDUs mà SW1 gửi về hướng SW2/SW3/SW4/SW5 có root identifier tương ứng (SW1 là root lúc đầu)
• Khi bạn shutdown interface, BPDUs mới bắt đầu xuất hiện với root path và root identifier thay đổi theo cách “ai đó trở thành root mới trong mắt một phần mạng”.

Nói kiểu thực chiến:

• Khi bạn nghi STP flapping/reconverging, đôi khi nhìn “port state” chưa đủ.
• Bạn cần nhìn “BPDUs thực sự” để biết:
  • switch nào đang claim root
  • switch nào đang quảng bá đường “tốt hơn”
  • thông điệp có bị già đi quá mức hay không (age/forward delay)

2.5) Shutdown lần hai: Shutdown Gi0/2 trên SW1 và diễn biến trên hai nhánh

Tài liệu tiếp tục kịch bản với việc shutdown một cổng khác (Gi0/2).

Trong reconvergence STP, shutdown liên tiếp hoặc shutdown đúng “cạnh” của topology thường gây ra hiện tượng:

• Một số switch chỉ bị ảnh hưởng tạm thời rồi quay lại
• Một số switch thì bị “đứt hướng superior” nên phải chấp nhận root mới
• Các cổng non-designated sẽ chuyển sang trạng thái “learning rồi forwarding” theo logic chọn đường

Tài liệu mô tả trạng thái theo các bước và nhấn mạnh:

• Có thời điểm một switch nhận được superior BPDU (tức là thấy thông tin “tốt hơn” từ đúng hướng)
• Sau đó, cổng của switch có thể chuyển state sang forwarding vì nó trở thành root port hoặc designated port mới trên segment đó

Nhưng cũng có một mấu chốt kỹ thuật:

• Cổng không nhận được superior BPDU sẽ bị ép phải tự tính lại và phát sinh hành vi khác so với cổng vẫn còn “được root thông báo”.

Điều này giải thích vì sao trong thực tế, có switch gần root thì hội tụ nhanh, có switch xa thì có thể chuyển sau hoặc mất thêm thời gian. 3) Mổ xẻ “truyền thông thay đổi”: STP flooding TC và việc port chuyển trạng thái

Một phần kết luận của tài liệu (và cũng là “xương sống” của bài học) là:

• STP quyết định thay đổi port roles dựa trên các BPDUs nó nhận được.
• Khi topology change xảy ra, nó phát ra TC/hoặc các BPDU có thông tin mới.
• Switch khác nhận BPDU đó và quyết định:
  • có chấp nhận root mới không
  • cổng nào là RP/DP mới
  • cổng nào vẫn phải block để tránh loop

Tóm gọn thành một chuỗi logic thực chiến:

1. Bạn tác động topology (shutdown interface)
2. Root (hoặc một phía) phát sinh topology change
3. Các switch nhận BPDU mới và so sánh “đường nào tốt hơn đến root”
4. Các switch đổi role trên các port theo tiêu chí:
   • root bridge id, path cost, bridge id, port id…
5. State machine chuyển dần để tránh loop
6. Khi mọi switch thống nhất về topology tree mới, reconvergence hoàn tất

4) Kết luận: Bạn nên làm gì khi gặp reconvergence ngoài đời?

Nếu bạn đang quản trị mạng và “đang chạy ổn mà bỗng STP reconverge”, thì kinh nghiệm mình rút ra (và cũng bám vào đúng nội dung tài liệu):

• Hãy luôn nghĩ theo hướng BPDUs quyết định port state, không phải theo cảm giác.
• Khi shutdown/mất link, hãy truy vết xem:
  • switch nào đang claim root mới theo BPDUs
  • root port mới nằm ở đâu
  • cổng nào bị chuyển state do không nhận superior BPDU
• Nếu reconvergence làm gián đoạn, thường nguyên nhân là:
  • topology change đến từ nơi ảnh hưởng “đường tốt nhất”
  • hoặc bạn đang cấu hình khiến STP path cost/port roles thay đổi dẫn đến “chọn đường khác”
• Debug spanning-tree events + quan sát BPDU exchange giúp bạn trả lời đúng câu hỏi:
  • “STP đã xử lý bằng cách nào?”
  • “Vì sao cổng A chuyển nhưng cổng B lại không?”

Bài học lớn nhất: STP không “đổi cho biết”, nó đổi vì nó so sánh dữ liệu BPDUs và chọn cấu trúc không loop mới. Reconvergence là quá trình đồng bộ hóa thông tin đó giữa các switch.