คำถามติดแท็ก mtu

ตามตารางที่นี่มันบอกว่า MTU = 1500 bytes และส่วนของ payload คือ 1500 - 42 bytes หรือ 1458 bytes (<- นี่มันผิดจริงๆ!) ตอนนี้คุณต้องเพิ่มส่วนหัว IPv4 และ UDP ซึ่งเป็น 28 ไบต์ (20 IP + 8 UDP) นั่นทำให้ข้อความแอปพลิเคชันสูงสุดที่ฉันสามารถทำได้คือ 1430 ไบต์! แต่ด้วยการค้นหาหมายเลขนี้ในอินเทอร์เน็ตฉันเห็น 1472 แทน ฉันคำนวณผิดตรงนี้หรือเปล่า สิ่งที่ฉันต้องการค้นหาคือข้อความแอปพลิเคชันสูงสุดที่ฉันสามารถส่งได้โดยไม่ต้องเสี่ยงกับการแตกแฟรกเมนต์ ไม่ใช่ 1500 แน่นอนเพราะมันมีส่วนหัวของเฟรม ใครช่วยได้บ้าง ความสับสนคือ PAYLOAD อาจมีขนาดใหญ่ถึง 1500 ไบต์และนั่นคือ MTU ดังนั้นขนาดในสายสำหรับน้ำหนักบรรทุกของ 1500 คืออะไร? …

22 networking  tcp  ethernet  udp  mtu 

มีการเพิ่มรายละเอียดใหม่ในตอนท้ายของคำถามนี้ เป็นไปได้ว่าฉันมีสาเหตุที่ศูนย์ ฉันมีการตั้งค่า VPN ที่ใช้ UDP OpenVPN ในtapโหมด (ฉันต้องการtapเพราะฉันต้องการ VPN เพื่อส่งแพ็คเก็ตแบบหลายผู้รับซึ่งดูเหมือนจะไม่สามารถทำได้กับtunเครือข่าย) กับลูกค้าจำนวนหนึ่งผ่านอินเทอร์เน็ต ฉันพบว่าการเชื่อมต่อ TCP บ่อยครั้งค้างผ่าน VPN นั่นคือฉันจะสร้างการเชื่อมต่อ TCP (เช่นการเชื่อมต่อ SSH แต่โปรโตคอลอื่น ๆ มีปัญหาที่คล้ายกัน) และในบางช่วงระหว่างเซสชันดูเหมือนว่าทราฟฟิกจะหยุดการส่งผ่านเซสชัน TCP นั้น ดูเหมือนว่าจะเกี่ยวข้องกับจุดที่การถ่ายโอนข้อมูลขนาดใหญ่เกิดขึ้นเช่นถ้าฉันเรียกใช้lsคำสั่งในเซสชัน SSH หรือถ้าฉันcatเป็นแฟ้มบันทึกที่ยาว การค้นหาของ Google บางคำตอบจำนวนมากเช่นนี้ก่อนหน้านี้ใน Server Faultแสดงให้เห็นว่าผู้ร้ายน่าจะเป็นปัญหา MTU: ในช่วงที่มีการรับส่งข้อมูลสูง VPN พยายามส่งแพ็กเก็ตที่ทิ้งบางส่วนไว้ในท่อระหว่าง จุดสิ้นสุด VPN คำตอบที่ลิงก์ข้างต้นแนะนำให้ใช้การตั้งค่าการกำหนดค่า OpenVPN ต่อไปนี้เพื่อบรรเทาปัญหา: fragment 1400 mssfix สิ่งนี้ควร จำกัด MTU ที่ใช้บน …

19 vpn  openvpn  tcp  mtu 

ฉันมีปัญหานี้ซึ่งฉันสามารถเชื่อมต่อกับเว็บไซต์เช่น google.com และ ibm.com เท่านั้นเมื่อ mtu ถูกตั้งค่าไว้ที่ 1500 แต่ถ้าฉันพยายามเชื่อมต่อกับสิ่งอื่นมันจะแสดงหน้าว่าง เมื่อ mtu ลดลงถึง 1499 มันก็เริ่มทำงาน ฉันอยากรู้ว่าทำไมงานนี้และถ้ามี mtu ที่ 1499 อาจทำให้เกิดปัญหาในอนาคต จริง ๆ แล้วฉันไม่ค่อยรู้เรื่องนี้เท่าไหร่ฉันแค่ได้ยินเรื่องนี้และกำลังหาคำอธิบายที่ดี เมื่อฉันได้รับคำอธิบายว่าทำไม MTU ถึงตกหล่นเพียง 1 ไบต์ฉันจะอัปเดตคำถามของฉันพร้อมคำอธิบาย

16 mtu 

เรามีอุปกรณ์ฝังตัวจำนวนมากติดตั้งไว้ที่ลูกค้าทุกคนโทรกลับบ้านเพื่อใช้บริการ OpenVPN ของเรา โดยทั่วไปแล้วใช้งานได้ดี แต่ลูกค้าของเราบางรายมีปัญหาเกี่ยวกับเส้นทางของ MTU ที่รุนแรง อิทธิพลของเราที่มีต่อลูกค้าในการแก้ไขปัญหาเครือข่ายของพวกเขานั้นมี จำกัด ดังนั้นเราจึงต้องการ OpenVPN เพื่อจัดการกับมัน โดยสรุปคำถามของฉันคือ: ฉันจะลด MTU ที่มีพา ธ ต่ำของลูกค้าบางรายบนฐานต่อไคลเอ็นต์ได้อย่างไรโดยไม่ต้องใช้การตั้งค่าร่วมที่รองรับกรณีที่เลวร้ายที่สุดสำหรับลูกค้าทั้งหมด โปรดทราบว่ากรณีที่เลวร้ายที่สุดของเรามันค่อนข้างแย่: เส้นทาง MTU 576 ลดลงทุกส่วนไม่แยกส่วนไม่ให้เกียรติ DF-bit คุณเห็นว่าทำไมฉันถึงไม่ต้องการแก้ปัญหานี้ในระดับโลก OpenVPN manpageมีจำนวนของ MTU --link-mtu, --tun-mtu, --fragment and --mssfixเกี่ยวข้องกับตัวเลือกที่โดดเด่นที่สุด แต่มันก็บอกว่า --link-mtu [... ] เป็นการดีที่สุดที่จะไม่ตั้งค่าพารามิเตอร์นี้จนกว่าคุณจะรู้ว่าคุณกำลังทำอะไรอยู่ --tun-mtu [... ] วิธีที่ดีที่สุดคือใช้ตัวเลือก --fragment และ / หรือ --mssfix เพื่อจัดการกับปัญหาการปรับขนาด MTU ดังนั้นผมจึงเริ่มการทดลองด้วย--fragmentและ--mssfixแต่เร็ว …

16 ip  openvpn  mtu  ip-fragmentation 

โอเคฉันเพิ่งแก้ไขปัญหาจัมโบ้เฟรมระหว่าง Xserves ไม่กี่เครื่อง, Netgear GSM7224 และ Drobo B800i มันกลับกลายเป็นว่า Xserves (Mac OS X 10.6.8 Server) และ Drobo B800i ยอมรับ MTU ในหน่วยไบต์ตามปกติ (1,500-9,000) แต่ Netgear ดูเหมือนจะต้องการรวมถึงส่วนหัว / ส่วนท้ายอีเธอร์เน็ต (รถพ่วง) ) และในที่สุดฉันก็ลงเอยด้วย Xserves & Drobo ที่กำหนดค่าด้วย MTU ที่ 9000 และพอร์ต Netgear ที่ตั้งค่าเป็น MTU ที่ 9216 ฉันใช้คำสั่งต่อไปนี้สำหรับการทดสอบและตรวจสอบ MTU ระหว่าง Xserves ทั้งสองเหนือ Netgear (หมายเหตุ: …

14 tcp  ethernet  tcpip  gigabit-ethernet  mtu 

ฉันมีปัญหากับอุโมงค์ OpenVPN ซึ่งไม่ถึงความเร็วของสาย เกตเวย์เป็นเซิร์ฟเวอร์เสมือน Debian Jessy ที่โฮสต์ที่ OVH ไคลเอนต์เป็นของฉัน freebsd 10.2 homeserver (Intel I3 Ivy Bridge) หรือ RaspberryPI2 ของฉัน ฉันปิดการเข้ารหัสและการรับรองความถูกต้อง ฉันมีการเชื่อมต่อ FTTH แบบสมมาตร 100mbit / s แต่อุโมงค์มาถึงความเร็ว 20-40mbit / s เท่านั้น การเชื่อมต่อโดยตรง (โดยไม่มีอุโมงค์) ให้ผลตอบแทน 100mbit / s ที่ฉันคาดไว้เสมอ ฉันทดสอบประสิทธิภาพด้วย iperf3 ฉันแรกลองกับเซิร์ฟเวอร์ freebsd ของฉัน ฉันลองตั้งค่าทั้งหมดที่แนะนำเกี่ยวกับ mssfix ชิ้นส่วนและอื่น ๆ ไม่มีอะไรช่วย จากนั้นฉันคิดว่าบางทีมันอาจเป็นเครื่อง freebsd …

13 vpn  performance  openvpn  mtu 

เมื่อฉัน ping ไซต์ระยะไกลที่มีชุดบิต DF และขนาดแพ็คเก็ตที่ใหญ่เกินไปสำหรับเราเตอร์ของฉันข้อความ "การกระจายตัวที่จำเป็น" ของ ICMP แรกจะถูกส่งจากเราเตอร์ หลังจากนั้นข้อความมาจาก localhost ของฉัน Netstat -rC (บน Linux) อนุญาตให้ฉันดูแคชตารางเส้นทาง แต่ 1) ดูเหมือนว่าจะแสดง MTU ภายใต้คอลัมน์ที่ชื่อว่า MSS (ซึ่งฉันคาดว่าจะเป็น TCP MSS ที่ต่ำกว่าของลิงก์) 2) แสดงค่าเป็น 1500 เสมอ localhost ของฉันต้องแคช PMTU ไว้ที่ใดที่หนึ่งเพื่อให้สามารถสร้างข้อความที่ต้องการการกระจายตัว แต่ฉันจะเห็นได้อย่างไร นี่คือตัวอย่างในเครื่องของฉัน (-n บน netstat ยับยั้งการค้นหา DNS ย้อนกลับ): [root@vbcentos ~]# ping -c 4 -M do …

13 networking  mtu 

ฉันมีแอปพลิเคชันที่จะได้รับประโยชน์จากเฟรม Ethernet ที่ใหญ่ขึ้น (ในทางทฤษฎีเราสามารถลดจำนวนแพ็กเก็ตขาออกได้มากกว่า> 50% หรืออาจเท่ากับ 66%) ฉันยังอยู่ในกระบวนการระบุข้อกำหนดระบบเครือข่ายกับ บริษัท ผู้ให้บริการโฮสต์สำหรับการติดตั้งเซิร์ฟเวอร์แอปพลิเคชันใหม่ของฉัน อย่างน้อยก็ไม่ควร จำกัด การเชื่อมต่อลูกค้าจากการได้รับประโยชน์จาก Jumbo Frames แต่มันเป็นความจริงแค่ไหน? คำถามทั่วไปบางข้อสมมติว่าเซ็กเมนต์ของเครือข่ายที่เราสามารถควบคุมได้นั้นเป็นมิตรกับจัมโบ้เฟรม(สวิทช์มีความสามารถในการ MTU ขนาดใหญ่, การค้นหาพา ธ ICMP MTU ที่ได้รับอนุญาต ฯลฯ ) : เป็นจริงหรือไม่ที่จะส่งจัมโบ้เฟรมผ่านอินเทอร์เน็ตสาธารณะ? มันเชิญปัญหาเครือข่ายที่ไม่มีที่สิ้นสุดพยายามสนับสนุน Jumbo Frames ผ่านอินเทอร์เน็ตสาธารณะหรือไม่? มีข้อกังวลอื่น ๆ ที่ฉันไม่ได้พิจารณาหรือไม่?

13 networking  mtu  jumboframes 

ฉันกำลังพยายามใช้ MTU ขนาด 9000 ไบต์สำหรับการสื่อสารที่เก็บข้อมูลระหว่างผู้เข้าร่วม KVM และระบบโฮสต์ โฮสต์มีบริดจ์ ( br1) พร้อม MTU 9000 ไบต์: host# ip link show br1 8: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP link/ether fe:54:00:50:f3:55 brd ff:ff:ff:ff:ff:ff inet 172.16.64.1/24 brd 172.16.64.255 scope global br1 inet6 fe80::21b:21ff:fe0e:ee39/64 scope link valid_lft forever preferred_lft forever แขกมีอินเตอร์เฟสที่เชื่อมต่อกับบริดจ์นี้ซึ่งมี MTU 9000 …

11 linux  networking  kvm-virtualization  bridge  mtu 

ฉันใช้อีเธอร์เน็ตที่รวดเร็วขนาด 100 Mbps ซึ่งมีขนาดเฟรมน้อยกว่า 1500 ไบต์ (1472 ไบต์สำหรับเพย์โหลดตามตำราของฉัน) ในนั้นฉันสามารถส่งและรับแพ็คเก็ต UDP ที่มีขนาดข้อความ 65507 ไบต์ซึ่งหมายความว่าขนาดแพ็คเก็ตคือ 65507 + 20 (IP Header) + 8 (UDP Header) = 65535 หากขนาดส่วนบรรจุของเฟรมเองมีขนาดสูงสุด 1472 ไบต์ (ตามตำราของฉัน) ขนาดแพ็กเก็ตของ IP จะใหญ่กว่าขนาดที่นี่คือ 65535 อย่างไร ฉันใช้รหัสผู้ส่งเป็น char buffer[100000]; for (int i = 1; i < 100000; i++) { int len = send …

11 tcpip  udp  network-protocols  mtu 

ฉันใช้การรวมกันของอินเตอร์เฟส -, vlan- และสะพาน - อินเตอร์เฟสเพื่อให้ความซ้ำซ้อนและเลเยอร์เครือข่ายแบบลอจิคัลที่แตกต่างกันไปยัง xen domU's การตั้งค่านี้ทำงานได้ดี แต่ฉันไม่แน่ใจเล็กน้อยว่าการตั้งค่าที่แตกต่างกันในส่วนต่อประสานเหล่านี้มีผลต่อกันอย่างไร เพื่อแสดงให้เห็นนี่คือการตั้งค่าของฉันใน dom0 ทั่วไป: /- vlan10 -- br10 eth0 -\ / > bond0 <--- vlan20 -- br20 eth1 -/ \ \- vlan30 -- br30 การพิจารณาบอนด์ -, vlan- และบริดจ์อินเทอร์เฟซนั้นเป็นตรรกะมากกว่าทางกายภาพการตั้งค่า MTU บนอินเตอร์เฟสเหล่านี้มีผลกระทบใด ๆ หรือไม่หากอินเทอร์เฟซทางกายภาพ (eth0, eth1) มีชุด MTU ที่แตกต่างกัน

9 linux  networking  vlan  bonding  mtu