STP không chỉ cần hội tụ. STP còn cần được bảo vệ.

[ThanhTho]

Khi học về Spanning Tree Protocol, chúng ta thường tập trung vào các câu hỏi như:

• Root Bridge được bầu như thế nào?

• Root Port và Designated Port được xác định ra sao?

• STP loại bỏ loop bằng cơ chế nào?

Đó là những kiến thức nền tảng.
Nhưng trong môi trường Enterprise, có một câu hỏi còn quan trọng hơn:
Điều gì sẽ xảy ra nếu một Switch "không mong muốn" tham gia vào quá trình bầu chọn Root Bridge?
Hay nói cách khác...
Ai sẽ bảo vệ kiến trúc STP của bạn?
Đó chính là mục tiêu của LAB 3.
Không phải học thêm vài câu lệnh Cisco.
Mà là hiểu cách Cisco thiết kế các cơ chế để bảo vệ toàn bộ Layer 2 trước những sự cố tưởng chừng rất nhỏ.
Root Guard – Bảo vệ Root Bridge, không phải thay đổi Root Bridge

Rất nhiều người biết lệnh:
spanning-tree guard root
Nhưng lại chưa từng quan sát nó hoạt động.
Trong bài Lab này, chúng ta cố tình tạo ra một tình huống "xấu".
Đầu tiên cấu hình Bridge Priority theo thứ tự:

SW1 < SW2 < SW3 < SW4

Sau đó...
Giảm Priority của SW4 xuống thấp hơn cả SW1.
Theo đúng thuật toán STP, chuyện gì phải xảy ra?
SW4 sẽ gửi Superior BPDU.
Nếu không có bất kỳ cơ chế bảo vệ nào, toàn bộ hệ thống sẽ bắt đầu Root Bridge Re-Election.
Root Bridge thay đổi.
Root Port thay đổi.
Designated Port thay đổi.
Traffic Layer 2 được tính toán lại.
Điều đáng nói là...
STP hoàn toàn không sai.
Nó chỉ đang làm đúng thuật toán của mình.
Đây là điều rất nhiều kỹ sư mới thường nhầm lẫn.
Họ nghĩ mạng bị lỗi.
Thực tế mạng đang hoạt động đúng như những gì giao thức được thiết kế.
Bây giờ mới đến phần thú vị.
Lab yêu cầu bật:
spanning-tree guard root
trên các cổng uplink.
Sau đó tiếp tục cho SW4 gửi Superior BPDU.
Lúc này...
SW4 vẫn gửi BPDU.
Nhưng Switch bên kia từ chối việc thay đổi Root Bridge.
Interface không Shutdown.
Không mất Link.
Không bị Err-disable.
Nó chuyển sang trạng thái:
Root-Inconsistent
Cho đến khi Superior BPDU biến mất.
Đây chính là điểm hay của Root Guard.
Cisco không chặn kết nối vật lý.
Cisco chỉ chặn ý định trở thành Root Bridge.
Muốn hiểu điều này, đọc tài liệu là chưa đủ.
Phải tự tay tạo ra Superior BPDU rồi quan sát bằng:
show spanning-tree

mới thấy được sự khác biệt.
BPDU Guard – Chặn sự cố trước khi nó trở thành sự cố

Một Access Port sinh ra để kết nối:

• PC

• Laptop

• Printer

• IP Phone

Nhưng ngoài thực tế...
Người dùng có thể cắm bất cứ thứ gì.
Một switch mini.
Một Access Point có chức năng bridge.
Hay thậm chí một Catalyst khác.
Điều thú vị của Lab này là...
Không chỉ cấu hình BPDU Guard.
Mà tự đóng vai người dùng, cắm thêm một Switch vào Access Port.
Ngay lập tức...
Port chuyển sang trạng thái:
Err-disable
Điều này khiến nhiều học viên bất ngờ.
Vì sao Cisco không để STP tự xử lý?
Câu trả lời rất đơn giản.
Nếu một Access Port đã nhận được BPDU...
Thì thiết bị kết nối phía sau không còn là End Device nữa.
Đó là dấu hiệu cho thấy topology Layer 2 đang thay đổi.
Cisco chọn cách:
Block ngay lập tức.
Thay vì chờ loop xuất hiện rồi mới xử lý.
Đó là tư duy thiết kế của Enterprise.
Nhưng Lab chưa dừng lại ở đó.
Port đã Err-disable.
Bây giờ nếu người dùng rút Switch ra thì sao?
Có phải kỹ sư Network sẽ phải đăng nhập để:

shutdown
no shutdown

mỗi lần như vậy?
Lab tiếp tục cấu hình:

errdisable recovery cause all
errdisable recovery interval 30

Sau 30 giây.
Port tự hoạt động trở lại nếu điều kiện gây lỗi không còn.
Một tính năng nhỏ.
Nhưng giúp giảm đáng kể công việc vận hành trong mạng doanh nghiệp.
BPDU Filtering – Một lệnh rất nhỏ, nhưng có thể phá hỏng cả Layer 2

Theo mình...
Đây là phần giá trị nhất của toàn bộ Lab.
Rất nhiều người biết lệnh:

spanning-tree bpdufilter enable

Nhưng lại không thật sự hiểu điều gì xảy ra phía sau.
Trong Lab, chúng ta cố tình tắt STP trên một interface bằng BPDU Filtering.
Ngay sau đó quan sát trạng thái của các port.
Điều gì xảy ra?
Interface không còn gửi và nhận BPDU.
Đối với STP...
Việc không còn nhận BPDU đồng nghĩa với việc:
"Đường đến Root Bridge có thể đã mất."
Một Alternate Port đang Blocking sẽ bắt đầu chuyển qua:
Listening
↓
Learning
↓
Forwarding
Và...
Layer 2 Loop xuất hiện.
Không phải vì STP hoạt động sai.
Mà vì chính chúng ta đã khiến STP không còn đủ thông tin để đưa ra quyết định.
Đây là bài học rất quan trọng.
BPDU Filtering không phải là tính năng dùng để "tăng tốc".
Nó chỉ nên dùng khi bạn hiểu rất rõ mình đang làm gì.
Loop Guard – Thà Block nhầm còn hơn Forward nhầm

Ngay sau khi tạo được Loop bằng BPDU Filtering.
Lab tiếp tục yêu cầu bật:
spanning-tree loopguard default
Đây mới là phần thể hiện rõ triết lý thiết kế của Cisco.
Khi Alternate Port không còn nhận được BPDU.
Cisco không lập tức cho phép Port Forward.
Thay vào đó.
Port được chuyển sang trạng thái:
Loop-Inconsistent
Nó sẽ chờ.
Cho đến khi BPDU quay trở lại.
Nói cách khác.
Cisco giả định rằng:
"Có thể đây chỉ là lỗi truyền BPDU, chứ chưa chắc topology đã thay đổi."
Đó là một giả định cực kỳ an toàn.
Bởi trong Layer 2.
Forward nhầm một Port còn nguy hiểm hơn Block nhầm một Port.
Đây cũng là lý do Loop Guard thường được triển khai trên các liên kết giữa các Switch trong mạng Enterprise.
Điều mình đánh giá cao nhất ở LAB này

LAB 3 không dạy học viên ghi nhớ:

• Root Guard

• BPDU Guard

• BPDU Filtering

• Loop Guard

Mà dạy một tư duy quan trọng hơn nhiều.
Đừng tin vào lý thuyết cho đến khi bạn tự tạo ra lỗi và quan sát giao thức xử lý lỗi đó.
Bạn sẽ chủ động:

• Tạo Superior BPDU để kiểm tra Root Guard.

• Cắm thêm Switch vào Access Port để kích hoạt BPDU Guard.

• Tự gây Loop bằng BPDU Filtering.

• Quan sát Loop Guard ngăn vòng lặp hoạt động.

• Theo dõi từng thay đổi bằng các lệnh:

show spanning-tree
debug spanning-tree events

Đó cũng là cách học gần nhất với môi trường Enterprise.
Không phải học để thi.
Mà học để khi đứng trước một hệ thống hàng trăm Switch, bạn biết vì sao Cisco thiết kế từng cơ chế bảo vệ Layer 2 như vậy.
Trong các dự án thực tế, anh em thường triển khai đầy đủ Root Guard, BPDU Guard và Loop Guard, hay chỉ sử dụng một vài tính năng? Điều gì khiến anh em đưa ra lựa chọn đó?