Làm cách nào để mô phỏng những gì xảy ra bên trong bộ đệm gói của một công tắc đơn giản?

Tôi đang gỡ lỗi một trường hợp các gói UDP bị mất trong một bộ chuyển mạch gigabit lưu trữ và chuyển tiếp và tôi muốn hình dung điều gì xảy ra bên trong bộ chuyển mạch để hiểu rõ hơn ý chính của vấn đề.

Kịch bản rất đơn giản - hai luồng dữ liệu bùng nổ đi qua 2 cổng bên trong công tắc và cả hai đều muốn rời khỏi cổng đó qua cổng thứ ba (chung cho cả hai). Vì vậy, công tắc cần giữ một số dữ liệu trong bộ đệm gói trong một thời gian.

Vấn đề là: dựa trên các tính toán đơn giản của tôi, bộ đệm phải đủ lớn để xử lý trường hợp tôi đang kiểm tra. Một luồng dữ liệu gửi các đợt 25 kB (được chia thành 1514 gói B) cứ sau 1,56 ms, luồng còn lại gửi các đợt 60 kB cứ sau 1 ms. Giờ đây, ngay cả một công tắc soho như Netgear GS105E cũng có bộ đệm kích thước 128 kB. Vì vậy, phép toán đơn giản (25+60 < 128) cho biết nó sẽ hoạt động ngay cả khi các luồng truy cập cùng một lúc (do không có lưu lượng truy cập đáng kể nào khác).

Các thử nghiệm thực tế cho thấy rằng rất nhiều gói từ cả hai luồng bị mất trên một số thiết bị chuyển mạch (có vẻ như nó bị ràng buộc với kích thước bộ đệm, nhưng không chỉ với nó). Trong mô phỏng của tôi, tôi không thể làm đầy bộ đệm khi được đặt thành 128 kB.

Tôi đã ghi hình ảnh động này cho bộ đệm có kích thước 24 kB trong đó có quá tải. Tuy nhiên, bạn có thể dễ dàng thấy rằng việc tăng bộ đệm chỉ một vài byte sẽ giải quyết được vấn đề và tất cả các gói sẽ đi qua.

Tôi đã thực hiện một số đơn giản hóa trong mô phỏng này. Tất cả các gói có cùng QoS (điều đó cũng đúng trong trường hợp thực tế). Vì vậy, tôi đã loại bỏ hàng đợi QoS khỏi mô phỏng và tôi coi tất cả lưu lượng truy cập đều quan trọng như nhau. Tiếp theo, tôi bỏ qua việc quản lý bộ nhớ đệm. Tôi có thể tưởng tượng nó là một phần quan trọng của vấn đề, nhưng tôi sẽ ngạc nhiên nếu sự đơn giản hóa của tôi với phân bổ hoàn hảo sẽ sai hơn 10% so với trường hợp thực tế. Tôi cũng giả vờ rằng bộ chuyển mạch biết độ dài khung khi nó nhận được byte đầu tiên để nó dự trữ tất cả bộ nhớ cần thiết ngay từ đầu. Vì tôi không thể tìm thấy bất kỳ tài liệu nào về kích thước của hàng đợi vào/ra của các cổng, tôi cho rằng tất cả chúng đều được đặt trong bộ đệm gói dùng chung và chúng có thể chiếm phần lớn bộ đệm khi cần (mặc dù tôi nghĩ thủ phạm có thể là Ở đâu đó).Tôi đã đặt độ trễ xử lý của từng gói thành 512 ns (độ trễ lan truyền của gói 64 B).

Tôi không chắc liệu nó có đóng vai trò gì hay không, nhưng các luồng bao gồm các gói UDP bị phân mảnh (tức là cụm 25 kB là một gói UDP duy nhất được phân đoạn thành 17 đoạn IP). Luồng thứ hai tạo ra cụm dưới dạng 2 hoặc 3 gói UDP 20 kB, mỗi gói được phân đoạn thành 14 đoạn IP.

Các lệnh trong Iperf 3.7 để sao chép luồng tương tự như luồng thực là:

iperf3 -c chìm -u -b 128M -t 600 -l 25256 --pacing-timer 1560
iperf3 -c chìm -u -b 400M -t 600 -l 20k --pacing-timer 1000

Bạn có ý tưởng nào khác mà tôi đã quên tính đến điều gì có thể khiến mô phỏng khác xa với thực tế không? Cảm ơn sự giúp đỡ của bạn!

Mã nguồn cho hình ảnh động là tại https://gist.github.com/peci1/a0346538acc6c289b2c6d596b184ad21 .

Đây là bảng kết quả của tôi từ các thí nghiệm thực tế. Luồng dữ liệu một là cố định - 128 Mbps trong các gói UDP 25 kB mỗi gói 1,56 ms. Tôi đang thay đổi các tham số của luồng thứ hai để cố gắng tìm giới hạn mà các gói của luồng đầu tiên sẽ bắt đầu bị mất bởi công tắc. tôi đã thay đổi -l (độ dài) tham số chỉ định kích thước của gói UDP và -b (băng thông) chỉ định băng thông mà các gói này sẽ tạo ra. --pacing-hẹn giờ luôn được đặt thành 1000 cho luồng thứ hai. Bạn có thể thấy rằng D-Link và Netgear GS105 hoàn toàn không thể đối phó với các đợt bùng nổ 60 kB. GS108 làm tốt hơn nhiều so với GS105, trong khi nó có chip switch gần như giống nhau (cùng "họ", chỉ khác số cổng và bộ nhớ đệm lớn hơn một chút).

(Câu hỏi này đã được di chuyển từ https://networkengineering.stackexchange.com/questions/78529/how-to-simulate-what-happens-inside-the-packet-buffer-of-a-simple-switch nơi nó được đánh dấu là lạc đề).