Giảm thiểu lũ lụt đa tuyến gói không đúng định dạng IPv6

Vì vậy, chúng tôi vừa có trận lũ multicast IPv6 đầu tiên trong mạng sáng nay. Chúng tôi quản lý để ngăn chặn máy tính vi phạm bằng cách chặn địa chỉ mac bằng: mac-address-table static x.x.x vlan x drop

Trước khi chúng tôi chặn địa chỉ mac, chúng tôi đã bắt đầu chụp Wireshark để chúng tôi có thể phân tích các gói sau này.

Sau khi xem các gói, có vẻ như các gói tràn ngập mạng đã bị hỏng các yêu cầu DHCP DHCP liên hệ với địa chỉ multicast IPv6 33: 33: 00: 01: 00: 02.

Ảnh hưởng của trận lụt là kỳ lạ, điều duy nhất có vẻ bị ảnh hưởng là các yêu cầu DHCP4 thông thường, khách hàng thường xuyên không thể có địa chỉ IP, nhưng những người đã có trước khi lũ bắt đầu không gặp vấn đề gì ... CPU trên các thiết bị chuyển mạch cũng đạt mức cao nhất tới 95 - 100%, nhưng dường như không ảnh hưởng đến các hoạt động chuyển mạch / định tuyến giao thông thông thường.

Những gì chúng tôi cần trợ giúp để xác định là làm thế nào chỉ có 30mbps lưu lượng truy cập phát đa hướng IPv6 có thể đẩy CPU trên 6509 SUP720 lên 100% và làm cho DHCP4 DHCP bình thường ngừng hoạt động và làm thế nào để bảo vệ chúng ta khỏi điều này xảy ra lần nữa.

Mỗi cổng truy cập / máy khách có cấu hình sau:

 switchport access vlan x
 switchport mode access
 switchport nonegotiate
 switchport block multicast
 switchport block unicast
 switchport port-security maximum 2
 switchport port-security
 switchport port-security aging time 2
 switchport port-security violation restrict
 switchport port-security aging type inactivity
 storm-control broadcast level 5.00 4.00
 storm-control multicast level 5.00 4.00
 spanning-tree portfast
 spanning-tree bpduguard enable

Không phải multicast kiểm soát bão được áp dụng cho IPv6 multicast?

Dưới đây là trích xuất từ ​​bản chụp của Wireshark với các gói "ác" trên Dropbox .

Và một bộ sưu tập đồ thị nhỏ để minh họa tác động:

Chúng tôi cũng đã điều tra máy tính vi phạm và không thể tìm ra lý do hoặc có thể tái tạo vấn đề ...

Lý lịch

Tôi đang ở đâu đó chặn tải xuống Dropbox, vì vậy tôi không thể thấy lưu lượng truy cập bị bắt, nhưng tôi sẽ tiếp tục giả định đây là các đa tuyến ethernet 64 byte.

Chúng ta hãy làm một số phép toán để xem bạn cho phép bao nhiêu lưu lượng truy cập ...

Khung 64 byte là 672 bit (bao gồm 8 byte cho Preamble / SFD và 12 byte cho IFG) ...

8 * (8 + 12 + 64) = 672 bit

Điều đó có nghĩa là khung hình Gigabit Ethernet 64 byte tốc độ đường truyền là khoảng 1.488Mpps ...

(1000000000/672.0) = 1488095,24 pps

Điều này có nghĩa gì với bạn? Cấu hình kiểm soát bão hiện tại của bạn điều chỉnh lưu lượng truy cập ở mức 5% tốc độ đường truyền, do đó, bạn đang cho phép 74,4 nghìn lượt lưu lượng truy cập vào công tắc của mình trước khi kiểm soát bão bắt đầu. 74,4kpps * khung hình 64 byte là 38Mb / giây, là đúng tại những gì biểu đồ của bạn hiển thị:

Câu trả lời

Vì vậy, điểm mấu chốt là bạn cho phép quá nhiều lưu lượng truy cập vào CPU chuyển đổi, đó là lý do tại sao mức độ sử dụng CPU cao. 74,4kpps thực sự là quá nhiều để cho phép bất kỳ CPU chuyển đổi nào xử lý.

Giả sử các trạm này không nên gửi nhiều phát đa hướng hoặc quảng bá, câu trả lời đơn giản là điều tiết lưu lượng truy cập của bạn như thế này ...

   ! Note that broadcast traffic has the ethernet I/G bit set
   ! which means it is also classified technically as a multicast
   ! for storm-control purposes.  Therefore set your broadcast limit
   ! a little lower than your multicast limit
   storm-control broadcast level 0.4 0.3
   storm-control multicast level 0.5 0.3

Bây giờ, kiểm soát bão bắt đầu khi một cổng gửi 6kpps phát sóng (tốc độ đường truyền 0,4% 1GE) hoặc 7,5kpps phát đa hướng / phát sóng kết hợp (tốc độ đường truyền 0,5% 1GE).

FYI, có lẽ đáng để xem xét Chính sách điều khiển máy bay , bảo vệ CPU chuyển đổi chống lại một số cổng kết nối với nó. Hãy nhớ rằng CPP có thể phức tạp để có được đúng, vì vậy tốt nhất là bạn nên kiểm tra tốt trước khi bạn triển khai nó trong môi trường của mình.