Điều gì gây ra tổng sản lượng giảm trên giao diện chuyển đổi cisco?

Tôi có khung gầm lưỡi HP c7000 chứa các bộ chuyển mạch Cisco 3120X và Cisco 3120G chạy ios 12.2 (58) SE1. Bản thân các lưỡi dao được tải rất nhẹ nhưng nhiều giao diện trên các công tắc lưỡi khác nhau trong khung máy cho thấy số lượng đầu ra giảm khá cao. Nếu tôi kiểm tra số lượng đầu ra giảm liên tục, tôi không chỉ thấy bộ đếm tăng mà đôi khi nó còn giảm. Các số không tương quan với các gói / s được ghi trên giao diện. Cài đặt QoS được mặc định cho nền tảng.

Tất cả các mẫu sau đây được lấy trong khoảng thời gian 30 giây:

bc1019-3120-stack> sh int gi2 / 0/7 | tôi giảm sản lượng
  Hàng đợi đầu vào: 0/75/0/0 (kích thước / tối đa / giọt / xả); Tổng sản lượng giảm: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | tôi giảm sản lượng
  Hàng đợi đầu vào: 0/75/0/0 (kích thước / tối đa / giọt / xả); Tổng sản lượng giảm: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | tôi giảm sản lượng
  Hàng đợi đầu vào: 0/75/0/0 (kích thước / tối đa / giọt / xả); Tổng sản lượng giảm: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | tôi giảm sản lượng
  Hàng đợi đầu vào: 0/75/0/0 (kích thước / tối đa / giọt / xả); Tổng sản lượng giảm: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | tôi giảm sản lượng
  Hàng đợi đầu vào: 0/75/0/0 (kích thước / tối đa / giọt / xả); Tổng sản lượng giảm: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | tôi giảm sản lượng
  Hàng đợi đầu vào: 0/75/0/0 (kích thước / tối đa / giọt / xả); Tổng sản lượng giảm: 2255550
bc1019-3120-stack> sh int gi2 / 0/7 | tôi giảm sản lượng
  Hàng đợi đầu vào: 0/75/0/0 (kích thước / tối đa / giọt / xả); Tổng sản lượng giảm: 451110
bc1019-3120-stack> sh int gi2 / 0/7 | tôi giảm sản lượng
  Hàng đợi đầu vào: 0/75/0/0 (kích thước / tối đa / giọt / xả); Tổng sản lượng giảm: 451110
bc1019-3120-stack> sh int gi2 / 0/7 | tôi giảm sản lượng
  Hàng đợi đầu vào: 0/75/0/0 (kích thước / tối đa / giọt / xả); Tổng sản lượng giảm: 902220
bc1019-3120-stack> sh int gi2 / 0/7 | tôi giảm sản lượng
  Hàng đợi đầu vào: 0/75/0/0 (kích thước / tối đa / giọt / xả); Tổng sản lượng giảm: 1353330
bc1019-3120-stack> sh int gi2 / 0/7 | tôi giảm sản lượng
  Hàng đợi đầu vào: 0/75/0/0 (kích thước / tối đa / giọt / xả); Tổng sản lượng giảm: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | tôi giảm sản lượng
  Hàng đợi đầu vào: 0/75/0/0 (kích thước / tối đa / giọt / xả); Tổng sản lượng giảm: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | tôi giảm sản lượng
  Hàng đợi đầu vào: 0/75/0/0 (kích thước / tối đa / giọt / xả); Tổng sản lượng giảm: 1804440
bc1019-3120-stack> sh int gi2 / 0/7 | tôi giảm sản lượng
  Hàng đợi đầu vào: 0/75/0/0 (kích thước / tối đa / giọt / xả); Tổng sản lượng giảm: 451490

bc1019-3120-stack> sh int gi2 / 0/7 | i tỷ lệ đầu ra
  Tốc độ đầu ra 5 phút 301000 bit / giây, 119 gói / giây

1) Có bất cứ điều gì khác có thể làm giảm đầu ra ngoài máy chủ không nhận được khung đủ nhanh không?

2) Số lượng đầu ra tối đa giảm xuống mà bộ đếm giao diện có thể ghi là bao nhiêu? Liệu nó cuộn qua khi đạt đến mức tối đa?

3) Điều gì sẽ được coi là tỷ lệ giảm sản lượng lành mạnh?

Trừ khi có ai đó đang xóa các bộ đếm, bạn sẽ không bao giờ thấy bất kỳ bộ đếm loại đo đường nào (những bộ tăng dựa trên hành động gói) giảm, chúng sẽ luôn tăng. Phần đó nghe có vẻ như một lỗi.

Theo như những gì gây ra đầu ra giảm cụ thể, có rất nhiều nguyên nhân khác nhau mà rất khó xác định chính xác. Đôi khi có sự tắc nghẽn bên trong bảng nối đa năng của công tắc và những điểm này có thể hiển thị khi đầu ra giảm trên giao diện gửi đi. Trong những trường hợp hiếm hoi, bạn cũng có thể nhận được các vi mạch không xuất hiện khi được thăm dò trong khoảng thời gian 1 phút nhanh chóng làm quá tải giao diện, nhưng sau đó giảm xuống rất nhanh. Tôi sẽ đề nghị lấy SNMP OID để giảm đầu ra và sau đó vẽ đồ thị đó và xem nó tương ứng với bộ đếm CLI như thế nào.

Nói chung, bạn không muốn bất kỳ sự sụt giảm đầu ra nào vì chúng chỉ ra một gói không đi đến đích. Nhưng, nếu bạn đang chạy các liên kết của mình (mà bạn nói là bạn không) thì chúng không thể tránh khỏi ở một mức độ nào đó, chủ yếu là do bộ đệm chuyển đổi nội thất, v.v.

Suy nghĩ đầu tiên của tôi là lũ lụt unicast, đặc biệt là nếu các quầy tăng đồng loạt trên một số cổng trong cùng một vlan. Tôi đồng ý với Aaron rằng bộ đếm giảm âm thanh giống như một lỗi. Bộ đếm có thể sẽ lăn qua lúc 2 ^ 64, nhưng điều đó sẽ không xảy ra trong vòng vài giây. Tôi sẽ xem xét tỷ lệ đầu ra lành mạnh giảm xuống bằng 0, nhưng điều này không thực tế - ngay cả trong trung tâm dữ liệu. Bạn đang làm đường lên 10G?

Có vẻ như bạn đang gặp lỗi CSCtq86186. Lỗi này đã được tìm thấy trên 3750, 2960, nhưng nó cũng có thể ảnh hưởng đến các công tắc lưỡi.

Nếu bạn đang gặp lũ lụt đơn phương, chạy wireshark trên một trong các máy chủ hoặc kéo dài một trong các cổng sẽ cho thấy điều đó khá nhanh chóng.

Nghe có vẻ như bạn có lõi thừa trong cấu trúc liên kết vuông? Nếu vậy, hãy thử thêm lệnh này vào giao diện vlan của bạn:

arp timeout 300

Các bảng CAM giữ các mục trong 5 phút trong khi các bảng ARP được giữ trong bốn giờ (mặc định). Đặt ARP để khớp với CAM có thể loại bỏ lũ unicast với chi phí tăng nhẹ cho CPU. Catalyst 6500/6000 Chuyển đổi các vấn đề về bảng ARP hoặc CAM

Giọt đầu ra khá phổ biến trên các công tắc nhỏ hơn với bộ đệm nhỏ vì bất kỳ cụm nào sẽ làm mất bộ đệm. Tôi không thực sự quen thuộc với 3120 vì vậy tôi không thể nói về kích thước của bộ đệm, nhưng ít nhất đó là lý do phổ biến cho đến khi người ta có thể giảm sản lượng.

Các lý do cụ thể là chặn đầu dòng (HOLB), trong đó nhiều cổng nguồn đang gửi đến một đích và do đó chúng tôi bị tắc nghẽn. Một lý do phổ biến khác là khi đi từ tốc độ cổng cao hơn xuống mức thấp hơn, tức là 10G đến 1G hoặc 40G đến 10G.

Tôi khuyên bạn nên chạy chương trình điều khiển ethernet-điều khiển X trong đó X là cổng của bạn. Bạn sẽ nhận được một số thông tin liên quan đến việc giảm đầu ra, như nếu có thứ gì đó đang cố xuất ra các khung lớn, điều này có thể xảy ra nếu bạn không có MTU nhất quán trên mạng của mình.