PMTUD จะทำงานเมื่อใด? (การค้นพบ Path MTU)

ในการอภิปรายที่กระตุ้นจากคำถามอื่น ๆในเว็บไซต์นี้ฉันได้ตระหนักว่าฉันไม่มีความเข้าใจที่ชัดเจนว่าเมื่อดำเนินการ Path MTU Discovery (PMTUD)

ฉันรู้ว่ามันทำอะไร - ค้นหา MTU ที่ต่ำที่สุดบนเส้นทางจากไคลเอนต์ไปยังเซิร์ฟเวอร์)
ฉันรู้ว่ามันทำได้อย่างไร - ส่งแพ็คเก็ตขนาดใหญ่ขึ้นอย่างต่อเนื่องโดยตั้งบิต "Don't Fragment" ของพวกเขาและดูว่าแพ็คเก็ตขนาดใหญ่ที่คุณสามารถผ่านได้โดยไม่ได้รับข้อผิดพลาด "ICMP Need to Fragment"

คำถามของฉันนั้นเฉพาะเจาะจงเมื่อใดที่โฮสต์จะใช้ PMTUD

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

นอกจากนี้ฉันหมายถึงเฉพาะ IPv4 ฉันรู้ว่าในเราเตอร์ IPv6 transient จะไม่รับผิดชอบในการแยกส่วนและสามารถจินตนาการว่า PMTUD เกิดขึ้นบ่อยกว่าปกติ แต่ตอนนี้ฉันกำลังมองหาตัวอย่างเฉพาะของ PMTUD ใน IPv4 (แม้ว่าถ้าการจับแพ็คเก็ตเพียงอย่างเดียวที่คุณสามารถรวบรวม PMTUD อยู่ใน IPv6 ได้ฉันก็ยังอยากเห็น)

คำตอบนั้นง่าย: เมื่อใดก็ตามที่โฮสต์พอใจ จริงๆ. มันง่ายมาก

คำอธิบายด้านล่างถือว่าเป็นสภาพแวดล้อม IPv4 เท่านั้นเนื่องจาก IPv6 ไม่ได้มีการแยกส่วนในเราเตอร์ (บังคับให้โฮสต์จัดการกับการกระจายตัวและการค้นพบ MTU เสมอ)

ไม่มีกฎที่เข้มงวดที่ควบคุมเมื่อ (หรือแม้ว่า) โฮสต์ทำ Path MTU Discovery เหตุผลที่ PMTUD โผล่ขึ้นมาก็คือการแตกเป็นเสี่ยงๆ ด้วยเหตุผลหลายประการ เพื่อหลีกเลี่ยงการแยกส่วนแพกเก็ตแนวคิดของ PMTUD ถูกนำมาใช้เป็นวิธีแก้ปัญหา แน่นอนระบบปฏิบัติการที่ดีควรใช้ PMTUD เพื่อลดการกระจายตัว

ดังนั้นความหมายที่แน่นอนของการใช้ PMTUD นั้นขึ้นอยู่กับระบบปฏิบัติการของผู้ส่งโดยเฉพาะอย่างยิ่งการติดตั้งซ็อกเก็ต ฉันสามารถพูดเฉพาะกรณีของ Linux แต่ตัวแปร UNIX อื่น ๆ อาจไม่แตกต่างกันมาก

ใน Linux, PMTUD ถูกควบคุมโดยIP_MTU_DISCOVERตัวเลือกซ็อกเก็ต คุณสามารถดึงข้อมูลสถานะปัจจุบันด้วยการgetsockopt(2)ระบุระดับIPPROTO_IPและIP_MTU_DISCOVERตัวเลือก ตัวเลือกนี้ใช้ได้สำหรับSOCK_STREAMซ็อกเก็ตเท่านั้น ( SOCK_STREAMซ็อกเก็ตเป็นซ็อกเก็ตสองทางเชื่อมต่อที่เชื่อถือได้ในทางปฏิบัติมันเป็นซ็อกเก็ต TCP แม้ว่าโปรโตคอลอื่น ๆ ที่เป็นไปได้) และเมื่อตั้งค่า Linux จะทำงาน PMTUD ตามที่กำหนดไว้ใน RFC 1191

โปรดทราบว่าในทางปฏิบัติ PMTUD เป็นกระบวนการต่อเนื่อง แพ็คเก็ตจะถูกส่งไปพร้อมกับชุดบิต DF - รวมถึงแพ็คเก็ตจับมือ 3 ทาง - คุณสามารถคิดว่ามันเป็นคุณสมบัติการเชื่อมต่อ (แม้ว่าการดำเนินการอาจเต็มใจที่จะยอมรับการกระจายตัวของระดับหนึ่งในบางจุดและหยุดส่งแพ็กเก็ตด้วย DF ชุดบิต) ดังนั้น PMTUD จึงเป็นผลมาจากความจริงที่ว่าทุกอย่างในการเชื่อมต่อนั้นถูกส่งไปกับ DF

ถ้าคุณไม่ได้ตั้งค่าIP_MTU_DISCOVERล่ะ

มีค่าเริ่มต้น โดยค่าเริ่มต้นIP_MTU_DISCOVERจะเปิดใช้งานบนSOCK_STREAMซ็อกเก็ต /proc/sys/net/ipv4/ip_no_pmtu_discนี้สามารถอ่านหรือมีการเปลี่ยนแปลงโดยการอ่าน ค่าศูนย์หมายความว่าIP_MTU_DISCOVERเปิดใช้งานโดยค่าเริ่มต้นในซ็อกเก็ตใหม่ ไม่ใช่ศูนย์หมายถึงตรงข้าม

สิ่งที่เกี่ยวกับซ็อกเก็ตแบบไร้สาย?

นี่เป็นเรื่องยุ่งยากเพราะซ็อกเก็ตที่ไม่มีการเชื่อมต่อและไม่น่าเชื่อถือจะไม่ส่งสัญญาณเซกเมนต์ที่สูญหายอีกครั้ง มันจะกลายเป็นความรับผิดชอบของผู้ใช้ในการแพ็คเก็ตข้อมูลในกลุ่มขนาด MTU นอกจากนี้ผู้ใช้คาดว่าจะทำการส่งสัญญาณที่จำเป็นในกรณีที่ข้อความผิดพลาดมากเกินไป ดังนั้นรหัสผู้ใช้จำเป็นต้องปรับใช้ PMTUD อีกครั้ง แต่ถ้าคุณกำลังขึ้นสำหรับความท้าทายที่คุณสามารถบังคับบิต DF โดยผ่านธงIP_PMTUDISC_DOsetsockopt(2)

บรรทัดล่าง

• โฮสต์ตัดสินใจเมื่อ (และถ้า) ใช้ PMTUD
• เมื่อใช้ PMTUD มันเป็นเหมือนแอตทริบิวต์การเชื่อมต่อมันเกิดขึ้นอย่างต่อเนื่อง (แต่ ณ จุดใดก็ตามการใช้งานฟรีที่จะหยุดทำ)
• ระบบปฏิบัติการที่แตกต่างกันใช้วิธีการที่แตกต่างกัน แต่โดยปกติแล้วซ็อกเก็ตที่มุ่งเน้นการเชื่อมต่อที่เชื่อถือได้จะทำหน้าที่ PMTUD ตามค่าเริ่มต้น

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

นี่อาจเป็นการตอบสนองการกระจายตัวของ ICMP ที่ต้องการ (ประเภท 3 รหัส 4) การตอบสนองอย่างชัดเจนบ่งชี้ว่าแพ็กเก็ตถูกทิ้ง โดยทั่วไปแล้วแพ็คเก็ต IPv4 ทั้งหมดจะถูกตั้งค่าด้วยการตั้งค่าสถานะ "ไม่แฟรกเมนต์" (DF) ดังนั้นแพ็กเก็ตใด ๆ ที่เกินกว่าของ MTU จะล้วงเอาการตอบสนองดังกล่าว IPv6 ไม่รองรับการแตกแฟรกเมนต์เลย

เราเตอร์บางส่วนหรือไฟร์วอลล์โฮสต์วาง ICMP ทั้งหมดบ่อยเพราะเป็นผู้ดูแลระบบไร้เดียงสาเชื่อ ICMP จะเป็นความเสี่ยงด้านความปลอดภัย หรือรูปแบบการรวมลิงค์บางอย่างอาจทำให้การส่ง ICMPไม่สมบูรณ์ วิธีอื่นที่จะค้นพบ MTU ได้รับเกินที่ไม่พึ่งพา ICMP จะถูกนำเสนอในRFC4821

tracepathเป็นเครื่องมือ Linux ที่ฉันโปรดปรานสำหรับการตรวจสอบ MTU นี่คือตัวอย่างจากโฮสต์ที่มี 9001 MTU บน LAN แต่ต้องผ่าน IPsec VPN เพื่อเข้าถึง 10.33.32.157:

$ tracepath -n 10.33.32.157
 1?: [LOCALHOST]                                         pmtu 9001
 1:  10.1.22.1                                             0.122ms pmtu 1500
 1:  169.254.3.1                                           1.343ms pmtu 1422
 1:  10.255.254.61                                        23.790ms 
 2:  no reply
^C [this host won't return an ICMP port unreachable, so tracepath won't terminate]

ข้อผิดพลาด ICMP สามารถสังเกตได้ด้วยtcpdump:

$ sudo tcpdump -p -ni eth0 'icmp and icmp[0] == 3 and icmp[1] == 4'
14:46:57.313690 IP 10.1.22.1 > 10.1.22.194: ICMP 10.33.32.157 unreachable - need to frag (mtu 1500), length 36
14:46:57.315080 IP 169.254.3.1 > 10.1.22.194: ICMP 10.33.32.157 unreachable - need to frag (mtu 1422), length 556

การค้นพบของ MTU ถูกแคช ใน Linux สามารถสังเกตและล้างด้วยip(ระวังการเปลี่ยนแปลงตั้งแต่ Linux 3.6 ):

$ ip route get 10.33.32.157
10.33.32.157 via 10.1.22.1 dev eth0  src 10.1.22.194 
    cache  expires 591sec mtu 1422
$ sudo ip route flush cache
$ ip route get 10.33.32.157
10.33.32.157 via 10.1.22.1 dev eth0  src 10.1.22.194 
    cache

สำหรับ TCP เกิน MTU อาจถูกหลีกเลี่ยงเป็นส่วนหนึ่งของการตั้งค่าการเชื่อมต่อ สิ่งที่รวมอยู่ใน SYN ที่ส่งโดยปลายแต่ละด้านจะมีขนาดเซ็กเมนต์สูงสุด (MSS) ส่วนหัวของ TCP (20 ไบต์ไม่รวมตัวเลือก ) และส่วนหัวของ IP (20 ไบต์) หมายถึง MSS และ MTU มีความเกี่ยวข้องกับความแตกต่างของ 40 ไบต์

นี่คือตัวอย่างของการตั้งค่าการเชื่อมต่อระหว่างสองโฮสต์นี้เมื่อทำการโอนย้ายไฟล์ขนาดใหญ่ด้วยscp:

$ sudo tcpdump -p -ni eth0 'host 10.33.32.157 and tcp[13]&2 == 2'
IP 10.1.22.194.45853 > 10.33.32.157.22: Flags [S], seq 634040018, win 26883, options [mss 8961,sackOK,TS val 10952240 ecr 0,nop,wscale 7], length 0
IP 10.33.32.157.22 > 10.1.22.194.45853: Flags [S.], seq 1371736848, ack 634040019, win 26847, options [mss 1379,sackOK,TS val 10824267 ecr 10952240,nop,wscale 7], length 0

ในแพคเก็ตแรกโฮสต์ท้องถิ่นเสนอ MSS 8961 นี่คือการกำหนดค่า 9001 MTU น้อยกว่า 40 ไบต์ SYN / ACK ที่ส่งคืนมามี MSS 1379 หมายถึง MTU ที่ 1419 ฉันรู้ว่าในเครือข่ายนี้โฮสต์ระยะไกลก็ส่ง 8961 ด้วย แต่เราเตอร์ได้ทำการแก้ไขค่าเนื่องจากรู้เส้นทางรวมถึงเส้นทางอินเทอร์เน็ต ( MTU 1500) โอเวอร์เฮดจากอุโมงค์ IPsec เราเตอร์นี้ยังแก้ไข MSS ที่ส่งของเราจำนวน 8961 ให้ปรากฏเป็น 1419 ที่โฮสต์อื่น นี้เรียกว่าMSS หนีบ

ดังนั้นในแง่หนึ่ง PMTUD จึงเกิดขึ้นตลอดเวลา ในทางปฏิบัติมันอาจเกิดขึ้นจริง ๆ ไม่เคยถ้า MSS clamping เกิดขึ้นและทราฟฟิกทั้งหมดที่เกิดขึ้นบน TCP หรือถ้าเราเตอร์ใดไม่มี MTU ที่เล็กกว่าสิ่งที่กำหนดค่าไว้บนอุปกรณ์ปลายทาง แม้จะไม่มี MSS clamping มันอาจเกิดขึ้นได้ยากเพียงเล็กน้อยเมื่อแคชหมดอายุ

PMTUD ใช้ในการคำนวณ MSS ที่ดีที่สุดสำหรับเซสชัน TCP ตัวอย่างหนึ่งคือการนำ BGP ไปใช้กับเราเตอร์ของซิสโก้หรือจูนิเปอร์

http://www.juniper.net/techpubs/en_US/junos12.1/topics/usage-guidelines/routing-configuring-mtu-discovery-for-bgp-sessions.html

ขอบคุณ