Đầu ra giọt trên giao diện nối tiếp: Hàng đợi tốt hơn hoặc kích thước hàng đợi đầu ra?


16

Trên các bộ định tuyến biên Internet nói eBGP với nhiều nhà mạng và iBGP với nhau, tất cả các giao diện ở phía LAN và WAN đều là GE ngoại trừ một serial full-DS3 (~ 45Mbps) trên mỗi bộ định tuyến. Mặc dù tôi nghĩ rằng tôi hầu như không gửi nhiều lưu lượng ra bên ngoài trên các giao diện nối tiếp - trong phạm vi 3-10Mbps - tôi thấy hàng đợi đầu ra không đổi (OQD). Có phải lời giải thích có khả năng là thực sự có lưu lượng truy cập bùng nổ mà tôi không thấy vì khoảng thời gian tải ở mức tối thiểu 30 giây và bỏ phiếu SNMP trung bình lưu lượng truy cập trong 5 phút, vì vậy những điều đó sẽ không làm sáng tỏ sự bùng nổ?

Nền tảng này là Cisco 7204VXR NPE-G2. Xếp hàng nối tiếp là fifo .

Serial1 / 0 là lên, giao thức dòng lên
  Phần cứng là M2T-T3 + pa
  Mô tả: -remond-
  Địa chỉ Internet là abcd / 30
  MTU 4470 byte, BW 44210 Kbit, DLY 200 usec,
     độ tin cậy 255/255, txload 5/255, rxload 1/255
  HDLC đóng gói, crc 16, loopback không được đặt
  Bộ giữ nguyên (10 giây)
  Khởi động lại-Trì hoãn là 0 giây
  Đầu vào cuối 00:00:02, đầu ra 00:00:00, đầu ra không bao giờ treo
  Lần xóa cuối cùng của bộ đếm "hiển thị giao diện" 00:35:19
  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: 36
  Chiến lược xếp hàng: fifo
  Hàng đợi đầu ra: 0/40 (kích thước / tối đa)
  Tốc độ đầu vào 30 giây 260000 bit / giây, 208 gói / giây
  Tốc độ đầu ra 30 giây 939000 bit / giây, 288 gói / giây
     410638 gói đầu vào, 52410388 byte, 0 không có bộ đệm
     Đã nhận được 212 chương trình phát sóng, 0 runts, 0 gã khổng lồ, 0 điều tiết
              0 chẵn lẻ
     0 lỗi đầu vào, 0 CRC, 0 khung hình, 0 tràn, 0 bị bỏ qua, 0 hủy bỏ
     Đầu ra 515752 gói, 139195019 byte, 0 vượt mức
     0 lỗi đầu ra, 0 đính, 0 đặt lại giao diện
     0 lỗi bộ đệm đầu ra, 0 bộ đệm đầu ra hoán đổi
     0 chuyển tiếp tàu sân bay
   rxLOS không hoạt động, rxLOF không hoạt động, rxAIS không hoạt động
   txAIS không hoạt động, rxRAI không hoạt động, txRAI không hoạt động

24 giờ sau sẽ hiển thị hàng ngàn OQD. Chúng tôi đẩy ra lưu lượng truy cập nhiều hơn vào khoảng 3 giờ sáng mỗi ngày, vì vậy có thể có một số lưu lượng truy cập bùng nổ ở đây tôi không đủ sức nặng để hướng tới.

Last clearing of "show interface" counters 1d01h
Input queue: 0/75/0/158 (size/max/drops/flushes); Total output drops: 12049

Tôi muốn đẩy lưu lượng truy cập ra ngoài nhiều hơn trên DS3, nhưng không phải là mối quan tâm của tôi đối với OQD. ISP cấp 2 phía sau DS3 có POP tăng gấp đôi số điểm tiên phong với hơn 6 cấp 1, vì vậy, ý tưởng là đưa lưu lượng truy cập đó lên mạng với khách hàng càng sớm, trái với ISP chính của chúng tôi trên GE là cấp 1 , nhưng phải làm việc theo cách của họ đối với trao đổi tiên phong của họ. Lưu lượng truy cập trong nước không phải là một mối quan tâm.

Có một chiến lược xếp hàng tốt hơn fifo trong tình huống này? Nhìn vào các tài liệu của Cisco về việc giảm hàng đợi đầu vào và đầu ra, việc tăng kích thước hàng đợi bên ngoài không được khuyến nghị vì các gói đã có trên bộ định tuyến và tốt hơn là nên bỏ đầu vào để TCP có thể điều chỉnh lại ứng dụng. Có rất nhiều băng thông trên các liên kết GE của chúng tôi, vì vậy thực sự không cần phải điều tiết đầu vào. Không có bản đồ chính sách trên các bộ định tuyến này. 90% lưu lượng truy cập đi đến từ các phản hồi HTTP của chúng tôi; hầu hết phần còn lại từ FTP và SMTP. Các liên kết GE đẩy 50-200 + Mbps.

Bạn có đề nghị bất kỳ điều chỉnh cho bộ đệm kích thước hàng đợi đầu ra? Các giao diện nối tiếp này là các liên kết dự phòng của chúng tôi mà tôi muốn sử dụng nhiều hơn vì lý do được đưa ra trước đó (nếu hợp lệ), nhưng được điều chỉnh bằng các chính sách BGP của tôi, cố gắng không làm quá tải giao diện nối tiếp đó (hầu như rất ít thời gian).

Câu trả lời:


13

Bạn nói đúng, bạn sẽ không thực sự thấy sự bùng nổ dễ dàng trên SNMP. 1GE có thể gửi 1,48Mpps, do đó, sẽ mất rất ít thời gian để làm nghẽn 45Mbps, có thể xử lý dưới 75kpps.

Nếu đường vào của bạn là 1GE và đầu ra là 45Mb / giây, thì rõ ràng điểm tắc nghẽn 45Mb / giây sẽ cần phải bỏ các gói. Điều này là bình thường và dự kiến. Nếu bạn tăng bộ đệm, bạn sẽ giới thiệu thêm độ trễ.
1GE mất 0,45ms để gửi 40 khung hình IP 1500B, tức là số lượng cụm bạn có thể xử lý. Tuy nhiên, việc xử lý chúng trên 45Mb / giây đã mất 10ms.

Nếu bạn không có bất kỳ vấn đề cấp tính nào, tôi có thể sẽ không làm gì với nó. Nhưng nếu một số lưu lượng truy cập đủ điều kiện để giảm hơn các lưu lượng khác, thì bạn nên thay thế FIFO bằng hàng đợi dựa trên lớp. Nói có thể bạn muốn ưu tiên để giảm nhiều ftp hơn và ít voip hơn.
Sau đó, sẽ có ý nghĩa hơn khi thêm bộ đệm vào lưu lượng truy cập ftp, vì nó không thực sự nhạy cảm với độ trễ.

Nếu bạn muốn thử vận ​​may của mình với bộ đệm sâu hơn, một cái gì đó như thế này sẽ đủ:

policy-map WAN-OUT
 class class-default
    fair-queue
    queue-limit 200 packets
!
interface Serial1/0
  service-policy output WAN-OUT

Điều này sẽ gây ra bộ đệm 50ms trên Serial1 và sẽ cho phép bạn xử lý các vụ nổ lên tới 2,25ms từ giao diện Gige duy nhất.


Đường vào chính và đi ra là 1GE trên các đường dẫn chính của chúng tôi với một số phần trăm lưu lượng truy cập trên DS3. Đã chỉnh sửa Q để hiển thị 90% bên ngoài là lưu lượng phản hồi HTTP với FTP và SMTP chiếm phần còn lại.
generalnetworkerror

Tôi sẽ tránh sử dụng DS3 khi Gige có sẵn, do sự chậm trễ gây ra bởi bộ đệm. Tất cả những ứng dụng được đề cập dường như rất chậm trễ và chịu đựng mất mát.
ytti

Một lý do khác mà tôi đã không đề cập đến khi cố gắng sử dụng nhiều DS3 hơn là để tránh các khoản phí nổ trên các liên kết GE WAN có tốc độ> 100Mb. Mặc dù chúng tôi bùng nổ hàng ngày trên 100Mb, nhưng nó vẫn chưa đủ dài để quan trọng (chưa).
generalnetworkerror

Bạn có thể tăng lưu lượng truy cập đến DS3 và thậm chí giảm các gói tin bằng cách đưa ra độ trễ nhiều hơn. Nhưng nếu bạn đang dự kiến ​​tăng tỷ lệ lưu lượng truy cập của mình, thì vấn đề sẽ ngày càng trở nên tồi tệ hơn. Hãy nhớ rằng ethernet không bao giờ là bất cứ điều gì khác ngoài 100% hoặc 0%, chỉ là 100% thay đổi trong bao lâu. Vì vậy, bạn sẽ luôn luôn đệm bộ đệm do mạng 1GE tốc độ cao gây ra.
ytti

2
Lý do của tôi cho 200 gói là độ trễ cần thiết để gửi chúng ra trên 45Mb / giây, tốc độ 50ms vẫn là độ trễ chấp nhận được cho các ứng dụng dữ liệu. Bạn nên tự hỏi, bạn sẽ chịu đựng được bao lâu và sau đó chỉ định bộ đệm để đáp ứng mục tiêu đó. Trong tình huống của bạn, tôi chỉ cần sử dụng gige.
ytti

8

OQD thường được gây ra bởi một trong hai điều sau:

  1. Bạn đang sử dụng liên kết; với mức sử dụng cao liên tục hoặc lưu lượng truy cập cao.

  2. Bạn có một bản đồ chính sách được áp dụng cho giao diện được định cấu hình để thực hiện một số việc như kiểm soát hoặc định hình một số hoặc tất cả lưu lượng truy cập

  3. Có một số loại lỗi trên giao diện, hãy xem các bộ đếm lỗi ( show interface Serial1/0 counters errors) và kiểm tra xem nó có bị rơi các gói do lỗi không.

Bạn có thể xem xét (nếu bạn chưa có) đặt bản đồ chính sách để thực hiện những việc như giao nhiệm vụ quan trọng cho hàng đợi của mình, cho phép tránh tắc nghẽn trên giao thông thông thường (WRED) hoặc thậm chí chỉ cho phép xếp hàng công bằng trên giao thông băng thông được chia sẻ giữa các luồng truyền qua giao diện.

Như bạn đã đề cập, một tùy chọn khác sẽ là tăng kích thước hàng đợi đầu ra trên giao diện nhưng nếu bạn sử dụng bản đồ chính sách thì dù sao cũng không cần điều này vì chính sách sẽ tạo ra các hàng đợi phụ khác.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.