อะไรคือข้อแตกต่างระหว่าง“ ข้อผิดพลาด:”“ หลุด:”“ โอเวอร์รัน:” และฟิลด์“ เฟรม:” ในเอาต์พุตแพ็คเก็ต ifconfig RX

11

คนได้โปรดทำอย่างละเอียดในความแตกต่างระหว่างต่างๆRX packetsเขตข้อมูลในifconfigการส่งออก?

ตัวอย่างเช่นสมมติว่าฉันเรียกใช้ifconfigและดูต่อไปนี้:

eth0      Link encap:Ethernet  HWaddr AA:BB:CC:DD:EE:FF  
          inet addr:1.1.1.1  Bcast:1.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:202723544 errors:0 dropped:4959 overruns:0 frame:37
          TX packets:158354057 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4261083782 (3.9 GiB)  TX bytes:1224803677 (1.1 GiB)
          Interrupt:83 Memory:f6bf0000-f6c00000

ความแตกต่างระหว่างerrors: dropped: overrunsและคืออะไรframe:

ฉันเดาที่จุดนี้ (ตาม googling คลุมเครือ) คือframe:เฉพาะที่เกี่ยวข้องกับความล้มเหลวของซีอาร์ซีเมื่อนิควิเคราะห์กรอบที่เข้ามาและerrors:เป็นหมวดหมู่ทั่วไปที่กว้างขึ้น ถ้าเช่นนั้นอีกครั้งฉันจะคาดหวังให้ทั้งสองฟิลด์แสดงตัวเลข

networking centos ifconfig

— ไมค์บี
แหล่งที่มา

17

ข้อมูลดังกล่าวได้รับการบันทึกไว้ไม่ดี ฉันจะบอกสิ่งที่ฉันเข้าใจจากประสบการณ์ของฉัน

frame นับเฉพาะเฟรมที่ไม่ตรงแนวนั่นหมายถึงเฟรมที่มีความยาวไม่สามารถหารด้วย 8 ได้เนื่องจากความยาวนั้นไม่ใช่เฟรมที่ถูกต้องและมันถูกทิ้งเพียง
ในขณะเดียวกันก็errorsนับข้อผิดพลาด CRC เฟรมสั้นเกินไปและเฟรมยาวเกินไป
overruns นับว่าครั้งเมื่อมีการใช้งานเกิน FIFO เกิดจากอัตราที่บัฟเฟอร์ได้รับเต็มและเคอร์เนลไม่สามารถล้างข้อมูลได้
ในที่สุดdroppedนับสิ่งต่าง ๆ เช่นแท็ก VLAN ที่ไม่ได้ตั้งใจหรือรับเฟรม IPv6 เมื่อไม่ได้กำหนดค่าอินเทอร์เฟซสำหรับ IPv6

— jcbermu
แหล่งที่มา

ขอบคุณ ฉันพบโพสต์บล็อกที่มีการค้นพบที่คล้ายกัน blog.hyfather.com/blog/2013/03/04/ifconfig

— Mike B

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

— mdo123

8

ฉันรู้ว่านี่เป็นคำถามอายุ 1 ปี แต่เป็นอันดับที่ 1 บน Google ดังนั้นบางทีฉันสามารถเพิ่ม 5 เซนต์ได้

ครั้งแรกที่ฉันไม่ได้ตระหนักถึงกฎ mod 8 นี้บนสนามเฟรม ... มันเป็นกฎไดรเวอร์หรือกฎเคอร์เนล?

จากประสบการณ์เล็กน้อยที่ฉันมีตัวเลขเหล่านี้ค่อนข้างทั่วไปและสามารถรับข้อมูลเพิ่มเติมได้จากethtool(หากไดรเวอร์รองรับ) อดีต: นี่คือจากwatchคำสั่ง

Every 1s: ethtool -S eth1 | grep rx_ && echo  && ifconfig eth1                                                   1970-01-01 00:21:07

 rx_octets: 12635134290
 rx_frames: 8488675
 rx_broadcast_frames: 103
 rx_multicast_frames: 0
 rx_pause_frames: 0
 rx_64_byte_frames: 113
 rx_65_127_byte_frames: 47
 rx_128_255_byte_frames: 186340
 rx_256_511_byte_frames: 1
 rx_512_1023_byte_frames: 0
 rx_1024_1518_byte_frames: 8302174
 rx_greater_than_1518_byte_frames: 0
 rx_undersized_frames: 0
 rx_oversize_frames: 0
 rx_jabbers: 0
 rx_frame_check_sequence_errors: 0
 rx_length_field_frame_errors: 0
 rx_symbol_errors: 0
 rx_alignment_errors: 0
 rx_resource_errors: 283
 rx_overruns: 132
 rx_ip_header_checksum_errors: 0
 rx_tcp_checksum_errors: 0
 rx_udp_checksum_errors: 0

eth1      Link encap:Ethernet  HWaddr AA:BB:CC:DD:20:16  
          inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::a8bb:ccff:fedd:2016/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:8488675 errors:415 dropped:4 overruns:132 frame:283
          TX packets:647464 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3892403548 (3.6 GiB)  TX bytes:62273943 (59.3 MiB)
          Interrupt:147 Base address:0xc000

ขึ้นอยู่กับไดรเวอร์จะมีฟิลด์ที่แตกต่างกันในethtoolและ ifconfigฟิลด์สามารถชี้ไปที่เฟรมขนาดเล็ก / ขนาดใหญ่ได้เช่นกัน

หาก NIC & ไดรเวอร์ของคุณรองรับคุณสามารถทำได้ (หรือควร) ทำเช่น:

ifdown eth1 && modprobe -r macb && modprobe macb && ifup eth1 && ethtool -offload  eth1  rx off  tx off && ethtool -K eth1 gso off && ethtool --show-offload eth1

เพื่อรับข้อมูลเพิ่มเติม (เปิดใช้งานการอนุญาตให้แสดงข้อมูลใน ethtool) ฉันใช้ไดรเวอร์ macb ที่นี่ ... ดังนั้นตรวจสอบethtoolไดรเวอร์ของคุณ

ethtool -i eth1

นี่คือสิ่งที่ช่วยให้ฉันเข้าใจโดยปกติแล้วเกิดอะไรขึ้น

บางครั้งไม่มีข้อผิดพลาด แต่แพ็คเก็ตเสียหาย ... จากนั้นเป็นปัญหาด้านฟิสิคัลหรือไดรเวอร์มากกว่า ... และบางครั้ง sniffers แสดงทุกอย่างถูกต้อง แต่มีปัญหาหลังจากไปที่ไดร์เวอร์ / เคอร์เนล (นี่คือกรณีข้างต้น จริง)

สามารถหาได้อีกจากnetstat -sหรือถ้าคุณใส่ลงในสคริปต์ (สำหรับระบบฝังตัวเล็ก ๆ ):

awk '(f==0) { i=1; while ( i<=NF) {n[i] = $i; i++ }; f=1; next} (f==1){ i=2; while ( i<=NF){ printf "%s = %d\n", n[i], $i; i++}; f=0}'  /proc/net/netstat

เนื่องจากnetstat -sอาจจะไม่สามารถใช้ได้

— โทมัส Janicki
แหล่งที่มา

1

ขอบคุณสำหรับ heads-up เมื่อethtool -S

— kostix