แพ็กเกจที่ถูกดร็อปจำนวนมากเมื่อ tcpdumping บนอินเตอร์เฟสที่ไม่ว่าง


12

ความท้าทายของฉัน

ฉันต้องทำการ tcpdumping ข้อมูลจำนวนมาก - จริง ๆ แล้วจากอินเทอร์เฟซ 2 เหลือในโหมด promiscuous ที่สามารถเห็นปริมาณการใช้งานจำนวนมาก

เพื่อสรุปมันขึ้นมา

  • บันทึกปริมาณการใช้งานทั้งหมดในโหมดที่หลากหลายจาก 2 อินเตอร์เฟส
  • อินเทอร์เฟซเหล่านั้นไม่ได้กำหนดที่อยู่ IP
  • ไฟล์ pcap จะต้องหมุนต่อ ~ 1G
  • เมื่อไฟล์ 10 TB ถูกเก็บไว้ให้เริ่มต้นการตัดที่เก่าที่สุด

ฉันกำลังทำอะไรอยู่

ตอนนี้ฉันใช้ tcpdump เช่นนี้:

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

$FILTERมีฟิลเตอร์ src / DST -i anyเพื่อที่ฉันสามารถใช้ เหตุผลนี้คือว่าฉันมีสองอินเตอร์เฟสและฉันต้องการเรียกใช้การถ่ายโอนข้อมูลในเธรดเดียวมากกว่าสอง

compress.sh ดูแลการมอบหมาย tar ให้กับ CPU core อื่นบีบอัดข้อมูลให้ชื่อไฟล์ที่เหมาะสมและย้ายไปยังตำแหน่งเก็บถาวร

ฉันไม่สามารถระบุสองอินเทอร์เฟซได้ดังนั้นฉันเลือกใช้ตัวกรองและการถ่ายโอนข้อมูลจากanyอินเทอร์เฟซ

ตอนนี้ฉันไม่ได้ดูแลทำความสะอาดใด ๆ แต่ฉันวางแผนที่จะตรวจสอบดิสก์และเมื่อฉันเหลือ 100G ฉันจะเริ่มเช็ดไฟล์ที่เก่าที่สุด - นี่น่าจะดี

และตอนนี้; ปัญหาของฉัน

ฉันเห็นแพ็คเก็ตที่ตกลงมา สิ่งนี้มาจากดัมพ์ที่รันมาสองสามชั่วโมงและรวบรวมไฟล์ pcap ประมาณ 250 กิ๊ก:

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

ฉันจะหลีกเลี่ยงแพ็กเก็ตจำนวนมากที่ถูกทิ้งได้อย่างไร?

สิ่งเหล่านี้ฉันได้ลองหรือดูไปแล้ว

เปลี่ยนมูลค่าของ/proc/sys/net/core/rmem_maxและ/proc/sys/net/core/rmem_defaultสิ่งที่ช่วยได้จริงๆ - จริง ๆ แล้วมันดูแลเพียงครึ่งหนึ่งของแพ็กเก็ตที่ถูกทิ้ง

ฉันได้ดูที่gulp ด้วย - ปัญหาของ gulp คือว่ามันไม่รองรับหลายอินเตอร์เฟสในกระบวนการเดียวและมันก็โกรธถ้าอินเทอร์เฟซไม่มีที่อยู่ IP น่าเสียดายที่ตัวจัดการแจกไพ่ในกรณีของฉัน

ปัญหาต่อไปคือเมื่อทราฟฟิกไหลผ่านท่อผมไม่สามารถหมุนแบบอัตโนมัติได้ การรับไฟล์ 10 TB ขนาดใหญ่หนึ่งไฟล์นั้นไม่ได้มีประสิทธิภาพมากและฉันไม่มีเครื่องจักรที่มี 10TB + RAM ที่ฉันสามารถเรียกใช้งาน wireshark ได้

คุณมีข้อเสนอแนะใด? อาจเป็นวิธีที่ดีกว่าในการทำทราฟฟิกของฉันโดยสิ้นเชิง


ในกรณีของฉันฉันใช้ตัวเลือก -s0 การเปลี่ยนเป็น -s1600 (ขวาเหนือ MTU) แก้ไขให้ฉัน
LatinSuD

คำตอบ:


11

tcpdump เก็บข้อมูลที่เข้ามาในบัฟเฟอร์วงแหวน หากบัฟเฟอร์โอเวอร์โฟลว์ก่อนที่ tcpdump จะประมวลผลเนื้อหาคุณจะสูญเสียแพ็กเก็ต

ขนาดบัฟเฟอร์บัฟเฟอร์เริ่มต้นน่าจะเป็น 2048 (2MiB)

ในการเพิ่มขนาดบัฟเฟอร์ให้เพิ่ม-Bตัวเลือก:

tcpdump -B 4096 ...

คุณควรลองใช้ที่เก็บดิสก์ที่เร็วกว่า


ฉันจะลองเปลี่ยนขนาดบัฟเฟอร์ ฉันเกือบจะแน่ใจว่าความเร็วในการจัดเก็บดิสก์ไม่ใช่ปัญหา มันเขียนข้อมูลที่มีประมาณ 15M / วินาทีเมื่อทิ้งและเมื่อ dd'ing ไฟล์ 17 กิ๊ก: 17179869184 ไบต์ (17 GB) คัดลอก 23.5737 s, 729 MB / s (ใช้ bs = 8k นับ = 2048k)
Frands Hansen

7

ฉันได้พบวิธีแก้ปัญหาที่จะอยู่กับ แพ็คเกจที่ถูกลดลงนั้นลดลงจาก. 0047% เป็น. 00013% ซึ่งไม่ได้ดูเหมือนอะไรมากในตอนแรก แต่เมื่อเราพูดถึงแพ็กเก็ตนับล้านมันค่อนข้างมาก

การแก้ปัญหาประกอบด้วยหลายสิ่ง หนึ่งคือการเปลี่ยนขนาดบัฟเฟอร์แหวนตามที่ Michael Hampton แนะนำ

นอกจากนี้ฉันสร้าง ramfs และถ่ายโอนข้อมูลสดไปที่นั้นอีกครั้งเขียนสคริปต์การบีบอัดของฉันเพื่อดูแลการย้ายทิ้งจาก ramfs ไปยังดิสก์ สิ่งนี้ลดจำนวนเงินที่น้อยมาก แต่เพียงพอที่จะโดดเด่น - แม้ว่าการทดสอบและการทำเบนช์มาร์กทั้งหมดของดิสก์จะแสดงให้เห็นว่าดิสก์ไม่ควรเป็นคอขวด ฉันเดาว่า accesstime มีความสำคัญมากที่นี่

การปิดใช้งานเธรดไฮเปอร์ยังทำได้มากกว่าที่คุณคิด


คุณหมายถึง "การปิดใช้งานเธรดไฮเปอร์" ช่วยได้มากหรือไม่ มันช่วยได้มากแค่ไหน? ขอบคุณ
พัฒนาซอฟต์แวร์

ตรงไปตรงมาฉันจำไม่ได้เฉพาะอีกต่อไป ฉันเปลี่ยนสถานที่ทำงานตั้งแต่นั้นมา แต่จากสิ่งที่ฉันเขียนดูเหมือนว่าการปิดใช้งานเธรดไฮเปอร์ช่วยปัญหานี้ได้
Frands Hansen
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.