Xin chào ! Nếu đây là lần đầu tiên bạn đến với diễn đàn, xin vui lòng danh ra một phút bấm vào đây để đăng kí và tham gia thảo luận cùng VnPro.
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • STP Dispute (Tranh chấp STP)

    STP Dispute (Tranh chấp STP)


    STP dispute là cơ chế dùng để kiểm tra xem BPDU nhận được trên một interface có còn “đúng kỳ vọng” hay không.
    Nói cách khác: nó kiểm tra trạng thái của port sau khi xem BPDU đến.
    Nếu phát hiện có một vấn đề “không khớp” (ví dụ do cấu hình, do nhận nhầm BPDU, hoặc do tình huống liên quan đến role/state), port sẽ phải đổi trạng thái để tránh đưa mạng vào tình huống không an toàn.
    Mục tiêu cuối cùng: phòng ngừa trường hợp loop / sai trạng thái do BPDU bị bất nhất. 1) Cấu hình (ví dụ 2 switch)


    Tài liệu dùng 2 switch:
    • SW1SW2 nối với nhau qua 2 liên kết (tức có redundancy ở L2).
    • Vẽ topology và cho chạy STP trước để xem trạng thái bình thường.
    1.1 Kiểm tra trạng thái STP ban đầu


    Khi show spanning-tree được in ra, cả SW1SW2 có các thông số như:
    • VLAN (ví dụ VLAN0001)
    • Root ID / Bridge ID
    • Priority
    • Cost
    • Hello Time / Max Age / Forward Delay
    • Trạng thái vai trò từng interface (Root/Designated/Alternate…)
    Ở trạng thái ban đầu:
    • Tài liệu thể hiện rằng SW2 là root bridge (hoặc sau khi chọn role thì đúng như mô tả).
    • Các interface vào đúng vai trò theo STP.
    2) Tạo tình huống “STP dispute”


    Tài liệu mô tả tình huống xảy ra khi:
    • SW1 và SW2 hoạt động bình thường (STP converged).
    • Sau đó cáp/đường nối bị gây gián đoạn kiểu không làm đứt hẳn mà làm cho port/đường đi còn lại nhận BPDU không còn phù hợp kỳ vọng.
    • Đặc biệt tài liệu cho thấy STP dispute được kích hoạt khi một port đáng lẽ ở vai trò designated nhưng BPDU nhận được lại dẫn tới trạng thái “dispute”.
    2.1 Bật debug trên SW1


    Bước tiếp theo trong tài liệu:
    • bật STP debugging để thấy sự kiện
    • sau đó cấu hình để lọc/không nhận BPDU đúng cách trên một interface (dạng ACL/BPDU filter ở hướng vào SW2)
    Ý chính trong đoạn config:
    • Trên SW2, áp điều khiển để ngăn SW2 nhận BPDU từ SW1 qua interface/mục tiêu cụ thể.
    • Kiểm tra bằng show access-lists xem dòng deny/permit đã đúng.
    3) Quan sát trạng thái sau khi dispute xảy ra


    Khi cấu hình đã tác động:
    • Trên SW1, STP chuyển interface sang state có nhãn P2p Dispute trong output.
    • Điều này thể hiện: hai interface ở phía SW1 là designated, nhưng bị chặn và hiển thị “dispute”.
    Tài liệu nhấn mạnh một câu kiểu:
    “Cả hai interface đều là designated port, nhưng chúng bị block và hiển thị dispute.”
    Đây là điểm cốt lõi của “STP dispute”:
    • STP không chỉ dựa vào vai trò dự đoán, mà còn cần chắc chắn BPDU phù hợp.
    • Khi phát hiện bất nhất, STP sẽ block để xử lý an toàn.
    4) Vì sao dispute xảy ra? (giải thích bằng nội dung BPDU)


    Tài liệu giải thích nguyên nhân nằm trong BPDU mà SW2 phát tới SW1.
    Cụ thể:
    • Port (đáng lẽ designated) trong BPDU của SW2 được gửi với một thông tin (ví dụ root path/bridge/priority… hoặc cách mô tả role) khiến SW1 hiểu là “không khớp”.
    • Do đó SW1 đưa interface vào dispute-blocking.
    Kết luận theo tài liệu:
    • “Port được chỉ định (designated) trong BPDU” → SW2 gửi BPDU từ góc nhìn của nó.
    • Nhưng vì SW1 là root bridge, nên về mặt logic, những interface “alternate/non-designated” phải hành xử khác.
    • Vì không khớp thông tin trong BPDU, STP tạo dispute để tránh sai trạng thái.
    Và tài liệu cũng kết luận:
    • SW2 sẽ giữ trạng thái kết nối kiểu ‘clueless’ trong thời gian đó vì nó không nhận BPDU từ SW1 như bình thường,
    • nên SW1 phải block để không tạo tình huống loop/sai hội tụ.
    5) Kết quả cuối cùng: mạng không bị loop (và vẫn an toàn)


    Tài liệu viết theo hướng:
    • Khi STP dispute bật, port vào blocking đúng mục tiêu.
    • Nhờ cơ chế dispute, ta không bị chuyển vào vòng lặp bridging như một số trường hợp cấu hình sai khác.
    Từ đó kết lại:
    “Thanks to our STP dispute, at least we don't have a bridging loop…” 6) Cấu hình (Configurations)


    Cuối tài liệu có phần liệt kê cấu hình mẫu trên:
    • SW1
    • SW2
    Trong đó có các điểm chính:
    • đặt spanning-tree mode rapid-pvst
    • cấu hình priority của VLAN 1
    • trên SW2 có áp ACL để filter/deny BPDU (đoạn giống kịch bản dispute)
    Bạn có thể dùng phần này để copy lab đúng như tài liệu. 7) Chuyển bài (Next Lesson)
    • Previous Lesson: STP Root Guard
    • Next Lesson: STP Bridge Assurance
    Attached Files
Working...
X