ข้อผิดพลาดของอินเตอร์เฟสอีเธอร์เน็ต

เซิร์ฟเวอร์ Ubuntu ของฉันอินเตอร์เฟสอีเทอร์เน็ตที่เชื่อมต่อกับมัลติเพล็กเซอร์ของ ISP แสดงข้อผิดพลาด นี่คือภาพรวม:

          RX packets:204564288 errors:3193970 dropped:0 overruns:0 frame:3138402
          TX packets:29305799 errors:38752 dropped:0 overruns:0 carrier:38762
          collisions:2205053 txqueuelen:1000

ส่วนต่อประสานของอูบุนตูนั้นมีความสามารถในการพิมพ์สองด้านเต็มรูปแบบ แต่สามารถต่อเชื่อมได้เพียงครึ่งเดียว เมื่อฉันเชื่อมต่ออุปกรณ์อื่น (เราเตอร์) กับ MUX มันก็แสดงให้เห็นข้อผิดพลาดดังกล่าว แบนด์วิดท์ที่กำหนดคือ 50 mbps แต่ฉันได้รับเพียง 20 mbps ISP ลังเลที่จะเปลี่ยนอุปกรณ์ (ดูเหมือนสวิตช์อีเธอร์เน็ตหรือฮับ) ใน MUX วิศวกรของ ISP โทษว่าเป็นความผิดของฉัน แต่ฉันตรวจสอบกับอุปกรณ์มากกว่า 3 ตัวทุกตัวแสดงข้อผิดพลาด ดังนั้นมีเครื่องมือใดสำหรับ Linux ที่ฉันสามารถใช้เพื่อตรวจสอบสาเหตุของข้อผิดพลาดเหล่านั้นอย่างลึกซึ้งหรือมีสิ่งใดที่ฉันสามารถทำได้เพื่อกำหนดค่าอินเทอร์เฟซเซิร์ฟเวอร์ของฉันใหม่เพื่อกำจัดข้อผิดพลาดเหล่านั้นหรือไม่

คุณน่าจะมีการพิมพ์สองด้านที่ไม่ตรงกันในบัญชีของ ISP ที่เข้ารหัสด้านข้างของพวกเขาเป็นเต็ม 100 ปิดการใช้งานการเจรจาต่อรองอัตโนมัติบน ISP Ethernet PHY

เมื่อ ISP ตั้งค่าเป็น 100 เต็มและด้านที่เหลือของคุณอยู่ที่อัตโนมัติ / อัตโนมัติ (ลางสังหรณ์ แต่เป็นเรื่องธรรมดา) การเจรจาอัตโนมัติที่ด้านข้างของคุณจะกำหนดค่าอินเทอร์เฟซให้เป็น 100-Half - สองเพล็กซ์ไม่ตรงกัน จะยังคงเต็ม 100

แก้ไข

คุณสามารถแก้ไขปัญหาด้วยการเข้ารหัส Ethernet PHY ของคุณเป็น 100 เต็ม - หรือเฉพาะสิ่งที่ ISP ตั้งไว้ ISP ส่วนใหญ่ใช้ 100 เต็ม

รายละเอียดเพิ่มเติม

ด้วยการที่เพล็กซ์ดูเพล็กซ์ 100- เต็ม 100- ครึ่งด้าน 100- เต็มปิดการใช้งาน CSMA / CD ในขณะที่ CSMA / CD ยังคงมีผลในด้าน 100- ครึ่ง การส่งสัญญาณด้านเต็ม 100 โดยไม่คำนึงว่าสื่อนั้นว่างหรือไม่ ด้าน 100- ครึ่งดำเนินการตรวจสอบ CSMA / CD และย้อนกลับตามที่กำหนดโดย CSMA / CD นี่คือเหตุผลที่คุณจะสามารถบรรลุ 20 MB / s ในสิ่งที่ควรจะเป็นวงจรอินเทอร์เน็ต CSMA / CD backoff เนื่องจากการชนด้านการตรวจจับ 100 ครึ่งกำลัง จำกัด ปริมาณงาน

ด้วยการเข้ารหัสอินเทอร์เฟซเป็น 100 เต็มเพื่อให้ตรงกับ ISP ทั้งสองฝ่ายจะปิดการใช้งาน CSMA / CD ดังนั้นการตรวจสอบย้อนกลับและการชนกันของข้อมูลจะถูกปิดการใช้งานและคุณควรบรรลุตัวเลขที่ใกล้เคียงกับอัตราข้อมูลวงจรอินเทอร์เน็ต

ประวัติศาสตร์

ISP หลายคนใช้รหัสยากในการส่งต่อ PHY Ethernet PHY เนื่องจากมีเวลาที่เชื่อถือได้มากขึ้น เมื่อ Ethernet มาตรฐานจานเดิม 802.3u 100 MB / s ได้รับการปล่อยตัวอัตโนมัติการเจรจาต่อรองของความเร็วและเพล็กซ์เป็นปัจจุบันแต่ไม่จำเป็นต้อง มันไม่ได้จนกว่ามาตรฐาน 802.3z 1 Gb / s Gigabit Ethernet เมื่อการเจรจาต่อรองอัตโนมัติเป็นสิ่งจำเป็นโดยมาตรฐาน

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

เหตุผลที่เป็นไปได้นี้เกิดจากสิ่งต่อไปนี้ - หากด้านใดด้านหนึ่งมีการกำหนดรหัสแบบยากไว้ที่ 100 เต็มส่วนอีกด้านหนึ่งที่ใช้การเจรจาต่อรองอัตโนมัติมักจะคิดว่าส่วนที่ 100 Mb / s ถ้าด้านใดด้านหนึ่งถูกกำหนดค่าให้เป็น 10 เต็ม - อีกด้านหนึ่งที่ใช้การเจรจาต่อรองอัตโนมัติสามารถหาส่วนที่ 10 Mb / s ความสามารถในการกำหนดความเร็วลิงก์นั้นมาจากคุณสมบัติที่เรียกว่าการตรวจจับแบบขนานซึ่งจะพยายามรับสัญญาณเลเยอร์ทางกายภาพที่ได้รับบนความเร็วลิงก์ที่สนับสนุนในเครื่องทั้งหมดจนกว่าจะพบการจับคู่ อย่างไรก็ตามการตรวจจับแบบขนานนั้นใช้งานได้กับความเร็วเท่านั้นไม่ใช่การจับคู่แบบดูเพล็กซ์ นี่คือสาเหตุที่การจับคู่แบบเพล็กซ์ไม่สามารถเกิดขึ้นได้ - เนื่องจากอินเทอร์เฟซจะถอยกลับไปเป็นฮาล์ฟดูเพล็กซ์เสมอเมื่อไม่สามารถกำหนดด้านอื่น ๆ ผ่านการเจรจาอัตโนมัติ

แท่นสำหรับนักพูดบนถนน

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

ฉันไม่เคยมี ISP ที่ไม่ต้องการเปลี่ยน Ethernet handoff เป็น auto / auto เมื่อถูกถาม ด้วยเคเบิลและโมเด็ม DSL และเกตเวย์ส่วนใหญ่นี่ไม่ใช่ปัญหา มันเป็นเราเตอร์ NXT1 และไฟเบอร์ที่จัดการ CPE พร้อมกับอีเทอร์เน็ตแฮนด์ออฟซึ่งปัญหานี้มักจะเกิดขึ้น ปัญหาคือผู้ดูแลระบบเครือข่ายต้องถามในตอนแรก

กับผู้ให้บริการอินเทอร์เน็ตที่มีโค้ด 100 เต็มรูปแบบที่พวกเขาได้รับหน้าที่ ภาระผูกพันที่จะต้องจัดทำเป็นเอกสารและต่อเนื่อง การต่อรองอัตโนมัติเป็นเทคโนโลยีที่ตอนนี้มีเสถียรภาพมานานหลายปีและดูแลปัญหานี้ให้เรา ดังที่ได้กล่าวไว้ก่อนหน้านี้จำนวนของปัญหาที่เกิดจากการเจรจาต่อรองอัตโนมัตินั้นมีมากกว่าเมื่อเทียบกับจำนวนของปัญหาที่เกิดขึ้นเนื่องจากมีการปิดใช้งานในปี 2011 เทคโนโลยีมีอยู่เพื่อแก้ปัญหานี้ให้ใช้งาน บางทีเราควรตั้งค่าเริ่มต้น TCP, MSS และการจัดการหน้าต่างการรับสำหรับวงจรเสมือน TCP ทุกครั้งด้วยตนเองหรือไม่ ฉันเป็นเด็ก

พูดจาโผงผาง