Rất nhiều gói bị rơi khi tcpdumping trên giao diện bận rộn

Thử thách của tôi

Tôi cần thực hiện nhiều dữ liệu - thực tế là từ 2 giao diện còn lại ở chế độ lăng nhăng có thể nhìn thấy rất nhiều lưu lượng.

Tổng hợp lại

• Đăng nhập tất cả lưu lượng trong chế độ lăng nhăng từ 2 giao diện
• Các giao diện đó không được gán địa chỉ IP
• tập tin pcap phải được xoay mỗi ~ 1G
• Khi 10 TB tệp được lưu trữ, hãy bắt đầu cắt bớt phần cũ nhất

Những gì tôi hiện đang làm

Ngay bây giờ tôi sử dụng tcpdump như thế này:

ifconfig ethX promisc
ifconfig ethX promisc
tcpdump -n -C 1000 -z /data/compress.sh -i any -w /data/livedump/capture.pcap $FILTER

Các $FILTERchứa bộ lọc src / dst vì vậy mà tôi có thể sử dụng -i any. Lý do cho điều này là, tôi có hai giao diện và tôi muốn chạy kết xuất trong một luồng chứ không phải hai.

compress.sh đảm nhiệm việc gán tar cho lõi CPU khác, nén dữ liệu, đặt tên tệp hợp lý và di chuyển đến vị trí lưu trữ.

Tôi không thể chỉ định hai giao diện, do đó tôi đã chọn sử dụng bộ lọc và kết xuất từ anygiao diện.

Ngay bây giờ, tôi không làm bất kỳ công việc vệ sinh nào, nhưng tôi có kế hoạch theo dõi đĩa và khi tôi còn 100G, tôi sẽ bắt đầu xóa các tập tin cũ nhất - điều này sẽ ổn thôi.

Và bây giờ; vấn đề của tôi

Tôi thấy các gói bị rơi. Đây là từ một bãi chứa đã chạy trong vài giờ và thu thập được khoảng 250 hợp đồng tệp pcap:

430083369 packets captured
430115470 packets received by filter
32057 packets dropped by kernel  <-- This is my concern

Làm thế nào tôi có thể tránh được rất nhiều gói bị rơi?

Những điều tôi đã thử hoặc nhìn vào

Thay đổi giá trị /proc/sys/net/core/rmem_maxvà /proc/sys/net/core/rmem_defaultthực sự có ích - thực sự nó chỉ quan tâm đến khoảng một nửa số gói bị rơi.

Tôi cũng đã xem xét gulp - vấn đề với gulp là, nó không hỗ trợ nhiều giao diện trong một tiến trình và nó sẽ tức giận nếu giao diện không có địa chỉ IP. Thật không may, đó là một công cụ thỏa thuận trong trường hợp của tôi.

Vấn đề tiếp theo là, khi lưu lượng truy cập chảy qua một đường ống, tôi không thể quay vòng tự động. Nhận một tệp 10 TB khổng lồ không hiệu quả lắm và tôi không có máy có RAM 10TB + mà tôi có thể chạy wireshark, vì vậy đó là hết.

Bạn có đề nghị nào không? Thậm chí có thể là một cách tốt hơn để làm lưu lượng truy cập của tôi hoàn toàn.

tcpdump lưu trữ dữ liệu đến trong bộ đệm vòng. Nếu bộ đệm tràn ra trước khi tcpdump xử lý nội dung của nó, thì bạn sẽ mất các gói.

Kích thước bộ đệm vòng mặc định có lẽ là 2048 (2MiB).

Để tăng kích thước bộ đệm, thêm -Btùy chọn:

tcpdump -B 4096 ...

Bạn cũng nên thử sử dụng lưu trữ đĩa nhanh hơn.

Tôi đã kết thúc việc tìm kiếm một giải pháp đó là sống cùng. Các gói bị rơi đã giảm từ 0,0047% xuống còn 0,00013% - ban đầu có vẻ không giống lắm, nhưng khi chúng ta đang nói về hàng triệu gói, thì nó khá là nhiều.

Các giải pháp bao gồm một số điều. Một là thay đổi kích thước bộ đệm vòng theo đề xuất của Michael Hampton.

Ngoài ra, tôi đã tạo một ramfs và thực hiện việc đổ trực tiếp vào đó, viết lại tập lệnh nén của mình để đảm nhiệm việc chuyển các bãi chứa từ ramfs sang đĩa. Điều này chỉ làm giảm số lượng rất ít, nhưng đủ để đáng chú ý - mặc dù tất cả các thử nghiệm và điểm chuẩn của đĩa cho thấy, đĩa không nên là nút cổ chai. Tôi đoán accesstime là rất quan trọng ở đây.

Vô hiệu hóa siêu luồng cũng làm nhiều hơn bạn nghĩ.