Tại sao chúng ta có biến động cao trên biểu đồ Cacti đo băng thông?

Chúng tôi đã thử nghiệm dự phòng Etherchannel và Routing trên mạng của chúng tôi. Trong quá trình can thiệp này, chúng tôi đã thực hiện một số phép đo. Công cụ giám sát của chúng tôi là Cacti cho đồ thị. Thiết bị được giám sát là 4500-X trên VSS. Mỗi liên kết là trên một khung vật lý khác nhau.

Lược đồ :

Kiểm tra thời gian:
[t0] Liên kết trên cổng te1 / 1/14 đã bị xóa. Te2 / 1/14 đang hoạt động. Po1 đang hoạt động.
[t0 + 15] Liên kết trên cổng Te1 / 1/14 trở lại dịch vụ và kiểm tra xem cổng đó trong etherchannel Po1
[t0 + 20] Liên kết trên cổng te1 / 1/14 đã bị xóa vật lý. Te2 / 1/14 đang hoạt động. Po1 đang hoạt động.
[t0 + 35] Liên kết trên cổng Te1 / 1/14 trở lại dịch vụ và kiểm tra xem cổng đó có trở lại trong etherchannel Po1 không

Trong các thử nghiệm của chúng tôi, chúng tôi đã theo dõi lưu lượng etherchannel Po1 qua Cacti (biểu đồ bên dưới) và nhận thấy sự thay đổi đáng kể về giá trị của luồng khi chúng tôi vô hiệu hóa liên kết te1 / 1/14 (liên kết te2 / 1/14 tài sản) khá ổn định trong quá trình đảo ngược . Chúng tôi cũng đã kiểm tra các bộ đếm trên int Po1 và chúng được duy trì khá ổn định.

Hai giao diện của 10G được gói trên Etherchannels với cấu hình LACP. Bên trong etherchannel của họ là 2 vlans. Một cho lưu lượng truy cập Multicast và một cho lưu lượng truy cập Internet / Tất cả lưu lượng.

Bạn có biết một nguyên nhân có thể của hành vi này?

Để mở rộng bình luận của ytti.

Khoảng thời gian thăm dò ý kiến ​​của bạn dường như rất nhỏ, cứ sau 10 giây nếu tôi đọc đúng. Có một vài lý do bạn có thể nhận được kết quả đó.

Bên thiết bị:

• Lựa chọn bộ đếm không tốt, nếu bạn đang sử dụng bộ đếm 32 bit, họ có thể lăn qua mỗi ~ 3,4 giây nếu bạn đang chạy giao diện 10g ở tốc độ đường truyền
• Cập nhật bộ đếm, nhiều thiết bị lớn hơn chỉ cập nhật bộ đếm hai hoặc ba lần một phút và chúng không bao giờ có thể được dựa vào để được đồng bộ hóa. Cứ sau 30 giây lại thấp như tôi muốn bỏ phiếu, và thậm chí sau đó tôi luôn muốn có ít nhất hai điểm trước khi kích hoạt bất kỳ cảnh báo hoặc thực hiện hành động nào
• Có thể có một hình ảnh xác thực vì các gói được gửi để xử lý CPU (có lẽ là dòng net) có thể được tính ngay lập tức so với các gói sẽ không được xử lý theo lô (đã thấy điều này trên Juniper MX)

Bên xe đẩy:

• Là người bỏ phiếu chính xác trong khoảng thời gian, và nếu không, nó sẽ đưa kết quả của nó với thời gian bỏ phiếu thực tế (ví dụ: x bit trong yz giây) để có thể tính được tỷ lệ hợp lý
• Điều gì xảy ra khi bộ đếm đặt lại hoặc SNMP GET không phản hồi, các công cụ khác nhau phản hồi những công cụ này theo những cách khác nhau

Vấn đề của bạn là như vậy, rằng việc lấy mẫu bộ định tuyến và bỏ phiếu của riêng bạn không xảy ra cùng một lúc. Đó là, mặc dù khoảng thời gian bỏ phiếu là tĩnh, nhưng khoảng thời gian bỏ phiếu chứa số lượng mẫu khác nhau mà toán học của bạn không tính đến.
Hãy xem xét bạn đã thăm dò t1, t2, t3 nhưng bộ định tuyến không lấy mẫu bất cứ thứ gì ở khoảng thời gian t1, t2, vì vậy tất cả lưu lượng giữa t1, t3 đã kết thúc ở giá trị được thăm dò t2, t3. Làm cho tỷ lệ của bạn là 0 tại t1, t2 và trên linates tại t2, t3

Bây giờ tôi sẽ đề xuất một giải pháp, nhưng vui lòng xác minh điều này với một người có hiểu biết về toán học.

Giao diện đầu tiên bạn quan tâm (nếu ge-1/1/1):

snmpbulkwalk SWITCH ifDescr | grep ge-1/1/1

Sau đó, bạn sẽ thấy số if Index của nó, giả sử nó là '42'.

Sau đó làm một cái gì đó như:

while true; do
  snmpbulkwalk SWITCH ifHCInOctets.42 >> DATA
  date >> DATA
  sleep 1
done

Bây giờ phân tích kết quả để xác định mức độ thường xuyên trung bình các quầy thực sự được cập nhật. (Tôi có thể tạo tập lệnh cho phân tích nếu cần)

Rồi đến phần chúng ta cần toán, nhưng tôi sẽ đề xuất một giải pháp ngây thơ.

Nếu khoảng thời gian cập nhật của bạn là 10 giây, hộp thăm dò cứ sau 5 giây, tức là gấp đôi so với cập nhật. Sau đó, mẫu của bạn sẽ là

t0, t5, t10, t15, t20, t25, t30

Bây giờ đây sẽ là dữ liệu thô của bạn, mà bạn sẽ không sử dụng, nhưng bạn muốn khôi phục các mẫu thực tế từ nó như thế này

s1 = (t0+t5+t10)/3
s2 = (t10+t15+t20)/3
s3 = (t20+t25+t30)/3

Lý do ở đây là, chúng tôi muốn rò rỉ qua các biên giới để giảm ảnh hưởng của các khoảng thời gian bỏ phiếu không chính xác tại công tắc của bạn.

Sau đó, bạn vẽ sơ đồ s1, s2, s3 và bạn sẽ có kết quả chính xác / mượt mà hơn nhiều so với những gì bạn đang thấy bây giờ.

Tuy nhiên tôi chắc chắn đây không phải là vấn đề mới và tôi chắc chắn có giải pháp chính thức làm thế nào để phục hồi độ chính xác tối ưu, không may tạo ra giải pháp đó nằm ngoài bộ kỹ năng của tôi. Một cái gì đó math.stackexchange mọi người sẽ được trang bị tốt hơn để giải quyết.

Vì bạn đang bỏ phiếu với cùng tốc độ với các bộ đếm được cập nhật, nên bạn có thể không đồng bộ.

Bằng cách cấu hình

snmp-server hc poll <<hundredths of a second>>

bạn có thể giảm khoảng thời gian trong đó các bộ đếm SNMP được cập nhật thành khoảng 1 giây. Điều này sẽ dẫn đến một giá trị chính xác hơn cho thông lượng khi bạn bỏ phiếu cứ sau 10 giây.

FYI, đây là một lệnh ẩn.