อาจค้นพบ PLC และได้รับคำตอบจากคำสั่งสั้น ๆ แต่การอัปโหลดสูตรการผลิตหรือการแสดงผลระยะไกลกลับค้างอยู่เรื่อย ๆ การเปลี่ยนโมดูลออปติคัลหรือเพิ่มความเร็วพอร์ตสวิตช์อาจไม่ทำให้ปัญหาเปลี่ยนไป นอกจากไฟเลี้ยง คุณภาพลิงก์ และซอฟต์แวร์แล้ว ควรตรวจสอบขีดจำกัดที่มักถูกมองข้ามด้วย นั่นคือเส้นทางการสื่อสารนี้รองรับแพ็กเก็ตได้ใหญ่เพียงใด? MTU อธิบายขนาด ไม่ใช่ความเร็ว การแยก MTU ออกจากความยาวเฟรม Ethernet, จัมโบเฟรม และเซกเมนต์ TCP ช่วยอธิบายได้ว่าเหตุใดแพ็กเก็ตขนาดเล็กจึงใช้งานได้ แต่ขนาดใหญ่กลับล้มเหลว
เริ่มจากการห่อหุ้ม: ข้อมูลแอปพลิเคชันมีชั้นภายนอกหลายชั้น
ข้อมูลจากคอมพิวเตอร์หรือตัวควบคุมมักไม่ได้ปรากฏบนสายสัญญาณในรูปแบบเดียวกับที่แอปพลิเคชันสร้างขึ้นโดยตรง ในการเชื่อมต่อ TCP ข้อมูลแอปพลิเคชันจะได้รับส่วนหัว TCP ก่อน ซึ่งมีข้อมูลการขนส่ง เช่น พอร์ตและหมายเลขลำดับ จากนั้นส่วนหัว IP จะระบุว่าแพ็กเก็ตมาจากที่ใดและกำลังจะไปที่ใด สุดท้ายเฟรม Ethernet จะบรรทุกแพ็กเก็ตนั้นผ่านลิงก์ภายในเครื่องข่าย ฝั่งรับจะถอดชั้นเหล่านี้ออกในลำดับย้อนกลับ แต่ละชั้นมีความยาวของตัวเอง จึงไม่สามารถใช้ตัวเลขเดียวอธิบายทั้งหมดได้
ในที่นี้ MTU ของ IP หมายถึงแพ็กเก็ต IP แบบครบถ้วนที่มีขนาดใหญ่ที่สุดที่อินเทอร์เฟซสามารถส่งได้ โดยรวมส่วนหัว IP และเพย์โหลด IP แต่ไม่รวมส่วนหัว Ethernet ภายนอกและลำดับตรวจสอบเฟรม อินเทอร์เฟซ Ethernet ทั่วไปจำนวนมากใช้ MTU ของ IP ขนาด 1500 ไบต์ แต่ค่านี้ไม่ใช่การตั้งค่าที่ใช้ได้กับทุกระบบ แท็ก VLAN เพิ่มข้อมูลให้กับเฟรมภายนอก ความยาวเฟรมสูงสุดที่ระบุในคู่มือจะรวมแท็กและลำดับตรวจสอบหรือไม่ ขึ้นอยู่กับนิยามในคู่มือนั้น ข้อความที่ระบุว่าอุปกรณ์รองรับเฟรมขนาดใหญ่เพียงอย่างเดียวไม่เพียงพอที่จะระบุการตั้งค่าที่แน่นอนได้
MSS และจัมโบเฟรม: อย่างหนึ่งจำกัดข้อมูล TCP อีกอย่างเพิ่มขนาดที่เฟรมรองรับได้
MSS หรือขนาดเซกเมนต์สูงสุด จำกัดส่วนข้อมูลแอปพลิเคชันที่บรรทุกในเซกเมนต์ TCP หนึ่งเซกเมนต์ ให้มอง MTU เป็นขนาดของพัสดุที่ห่อแล้ว และ MSS เป็นสิ่งของภายใน เมื่อเริ่มการเชื่อมต่อ TCP ฝั่งรับแต่ละฝั่งจะประกาศค่า MSS ที่ตนพร้อมรับ ฝั่งส่งยังต้องคำนึงถึงอินเทอร์เฟซของตัวเองและเส้นทางด้วย การเลือกตัวเลขที่ปลายทางทั้งสองเพียงอย่างเดียวไม่ได้รับประกันว่าเส้นทางทั้งหมดจะรองรับขนาดนั้นได้ ตัวเลือกของ TCP เวอร์ชันของ IP และการห่อหุ้มเพิ่มเติมอาจส่งผลต่อพื้นที่ที่ใช้ได้
โดยทั่วไปจัมโบเฟรมมีขนาดใหญ่กว่าเฟรม Ethernet แบบปกติ จัมโบเฟรมอาจลดจำนวนเฟรมที่ต้องใช้ในการบรรทุกข้อมูลปริมาณหนึ่ง แต่ไม่ได้เพิ่มแบนด์วิดท์ของพอร์ตหรือรับประกันว่าการตอบสนองด้านการควบคุมจะเร็วขึ้น อะแดปเตอร์เครือข่ายของอุปกรณ์ปลายทาง พอร์ตสวิตช์ อินเทอร์เฟซเราเตอร์ และอุปกรณ์ระหว่างทางทั้งหมดต้องเป็นไปตามข้อกำหนดที่เกี่ยวข้อง การเปิดใช้จัมโบเฟรมบนสวิตช์หนึ่งเครื่องไม่สามารถทำให้ PLC หรืออุปกรณ์ระยะไกลที่ไม่รองรับรับเฟรมเหล่านั้นได้ ข้อความควบคุมสั้น ๆ อาจไม่ได้รับประโยชน์ในทางปฏิบัติจากการเพิ่มขีดจำกัดเฟรม
ตรวจสอบส่วนที่จำกัดที่สุดของเส้นทาง ไม่ใช่เพียงปลายทางทั้งสอง
ลองนึกถึงรถส่งของที่ออกเดินทางบนถนนกว้าง แล้วไปถึงสะพานแคบในภายหลัง พัสดุขนาดใหญ่อาจบรรทุกได้ที่จุดเริ่มต้น แต่ไม่ได้รับอนุญาตให้ข้ามสะพานนั้น Path MTU คือขีดจำกัดขนาดที่กำหนดโดยลิงก์ต่าง ๆ ตลอดเส้นทางจากผู้ส่งถึงผู้รับ การกำหนดเส้นทาง การเข้าถึงระยะไกล หรือทันเนลอาจทำให้ค่านี้เล็กกว่าขีดจำกัดของ LAN ภายใน เส้นทางสำรองหรือเกตเวย์ความปลอดภัยที่เพิ่มเข้ามาใหม่ก็อาจเปลี่ยนขนาดที่เคยใช้งานได้เช่นกัน
สวิตช์ Layer 2 ทำหน้าที่หลักในการส่งต่อเฟรม Ethernet หากเฟรมมีขนาดเกินขีดจำกัดการรับ สวิตช์อาจทิ้งเฟรมนั้นและเพิ่มค่าตัวนับที่เกี่ยวข้อง สวิตช์ไม่ได้ช่วยแก้ปัญหาด้วยการแบ่งแพ็กเก็ต IP ที่อยู่ภายในออกเป็นชิ้นเล็กลง การแบ่งแฟรกเมนต์ IP เป็นหน้าที่ของชั้น IP อย่าสับสนระหว่างการตั้งค่าความยาวเฟรมของสวิตช์กับ MTU ของ IP บนเราเตอร์ วาดแผนผังอุปกรณ์และอินเทอร์เฟซจริงตลอดเส้นทาง โดยแยกการสวิตช์ภายในเครือข่าย การกำหนดเส้นทางระหว่างซับเน็ต และการห่อหุ้มแบบทันเนลให้ชัดเจน การเปรียบเทียบเพียงหน้าจอการตั้งค่าของปลายทางสองฝั่งยังไม่เพียงพอ
IPv4 รายงานแพ็กเก็ตขนาดเกินอย่างไร และ IPv6 แตกต่างอย่างไร
ในการค้นหา Path MTU แบบดั้งเดิมของ IPv4 ฝั่งส่งจะตั้งแฟล็ก DF หรือ Don’t Fragment ซึ่งหมายถึงห้ามแบ่งแฟรกเมนต์ หากเราเตอร์ต้องส่งต่อแพ็กเก็ตนั้นไปยังลิงก์ที่มี MTU เล็กกว่าและไม่สามารถแบ่งแฟรกเมนต์ได้ เราเตอร์จะทิ้งแพ็กเก็ตและส่งข้อผิดพลาด ICMP ที่แจ้งว่าจำเป็นต้องแบ่งแฟรกเมนต์กลับไปยังต้นทาง ต้นทางใช้ข้อมูลแจ้งกลับนี้เพื่อลดขนาดแพ็กเก็ตสำหรับเส้นทางนั้น แล้วลองใหม่ ICMP เปรียบเสมือนใบแจ้งปฏิเสธการจัดส่ง แม้ไม่ใช่คำสั่งของแอปพลิเคชัน แต่สามารถช่วยให้การสื่อสารของแอปพลิเคชันดำเนินต่อได้
หากข้อมูลแจ้งกลับที่จำเป็นนี้ถูกกรองทิ้ง ฝั่งส่งอาจพบการหมดเวลาซ้ำ ๆ คำสั่งสั้นอาจใช้งานได้ ขณะที่การถ่ายโอนขนาดใหญ่แทบไม่คืบหน้า ระบบจริงอาจใช้กลไกตรวจสอบหรือกลไกสำรองอื่นด้วย จึงไม่ได้หมายความว่าข้อผิดพลาดที่ถูกกรองทุกครั้งจะทำให้ค้างถาวรอย่างหลีกเลี่ยงไม่ได้ เมื่ออนุญาตให้แบ่งแฟรกเมนต์ใน IPv4 เราเตอร์สามารถแบ่งแพ็กเก็ต และฝั่งรับจะประกอบกลับ เราเตอร์ IPv6 ไม่แบ่งแฟรกเมนต์เช่นนี้ระหว่างทาง แต่จะใช้ข้อความ Packet Too Big แจ้งให้ต้นทางปรับขนาด ไม่ควรรวมกลไกเหล่านี้เป็นขั้นตอนแก้ไขเดียวที่ใช้กับทุกกรณี
ทันเนลเพิ่มชั้นห่อหุ้มอีกชั้น ทำให้แพ็กเก็ตที่เคยมีขนาดเหมาะสมใหญ่ขึ้นได้
การเชื่อมต่อเพื่อบำรุงรักษาระยะไกลอาจนำแพ็กเก็ตเดิมไปใส่ไว้ในการห่อหุ้มภายนอกชุดใหม่ เปรียบเหมือนนำกล่องที่บรรจุเรียบร้อยแล้วไปใส่ในลังขนส่ง เส้นทางต้องรองรับขนาดรวมทั้งหมด ข้อมูลแอปพลิเคชันไม่ได้เปลี่ยนไป แต่แพ็กเก็ตที่เห็นบนเส้นทางภายนอกมีขนาดใหญ่ขึ้น หากอุปกรณ์ไม่ได้คำนึงถึง MTU ที่ใช้งานได้จริงของทันเนลและนโยบายการส่งอย่างถูกต้อง ความล้มเหลวอาจเกิดขึ้นเฉพาะเส้นทางระยะไกล ขณะที่การเข้าถึงภายในยังใช้งานได้
อย่าลบจำนวนไบต์คงที่ค่าเดียวออกจาก VPN หรือทันเนลทุกประเภท โปรโตคอล วิธีเข้ารหัส และจำนวนชั้นการห่อหุ้มมีผลต่อโอเวอร์เฮด จึงต้องอ้างอิงรายละเอียดของระบบที่ใช้งานนั้น การปรับ MSS ของ TCP สามารถลดขนาดเซกเมนต์ TCP บนเส้นทางหนึ่งได้ แต่ไม่ได้จัดการทราฟฟิก UDP ทุกชนิดโดยอัตโนมัติหรือใช้แทนการตรวจสอบขนาดที่เฟรมรองรับได้ เก็บรักษาการตั้งค่าเดิมของอุปกรณ์ความปลอดภัย ระบุทราฟฟิกที่ได้รับผลกระทบ และตรวจสอบข้อมูลแจ้งข้อผิดพลาดที่จำเป็น อย่าปิดนโยบายความปลอดภัยทั้งหมดเพียงเพื่อให้แพ็กเก็ตขนาดใหญ่ผ่านได้
การแก้ไขปัญหา: ปรับความยาวการทดสอบโดยมีเหตุผลที่ชัดเจน
ในช่วงเวลาบำรุงรักษา ให้บันทึกค่าฐานจากแพ็กเก็ตขนาดเล็กที่ใช้งานได้ แล้วค่อย ๆ เพิ่มความยาวการทดสอบ สังเกตว่าความล้มเหลวเกิดใกล้ขีดจำกัดเดิมอย่างสม่ำเสมอหรือไม่ ตรวจสอบให้ชัดว่าเครื่องมือแสดงเพย์โหลดของแอปพลิเคชัน ความยาวแพ็กเก็ต IP หรือความยาวเฟรมทั้งหมด พารามิเตอร์คำสั่งไม่ได้มีความหมายเหมือนกันในทุกระบบปฏิบัติการ การ ping แบบปกติสำเร็จหนึ่งครั้งไม่ได้พิสูจน์ว่าเฟรมขนาดใหญ่ใช้งานได้ตลอดเส้นทาง อย่าทดสอบโหลดหนักโดยไม่จำกัดบนลิงก์ควบคุมที่ใช้งานจริง
เปรียบเทียบหลักฐานที่ฝั่งส่ง ฝั่งรับ และอุปกรณ์ระหว่างทาง มีการส่งคำขอออกไปหรือไม่? มีข้อผิดพลาดเกี่ยวกับความยาวส่งกลับมาหรือไม่? พอร์ตสวิตช์นับการทิ้งเฟรมขนาดเกินหรือไม่? เราเตอร์หรือทันเนลรายงานแพ็กเก็ตขนาดเกินหรือไม่? แพ็กเก็ตที่ใหญ่ผิดปกติในการจับข้อมูลบนโฮสต์อาจเกิดจากการออฟโหลดของอะแดปเตอร์เครือข่ายด้วย แพ็กเก็ตนั้นอาจไม่ได้มีขนาดเท่ากันบนสายสัญญาณจริง ใช้จุดสังเกตภายนอกที่เหมาะสมเมื่อจำเป็น ตัวนับการสูญเสียเพียงตัวเดียวไม่สามารถยืนยันว่า MTU เป็นสาเหตุได้ ต้องพิจารณาความแออัด ข้อผิดพลาดของสายสัญญาณ และความผิดปกติในการประมวลผลของอุปกรณ์ปลายทางด้วย
ก่อนทดสอบ ให้บันทึกว่าความยาวที่เครื่องมือใช้หมายถึงชั้นใด เครื่องมือบางชนิดรับค่าความยาวข้อมูลทดสอบ บางชนิดรายงานแพ็กเก็ต IP ทั้งหมด และบางชนิดแสดงเฟรมบนสายสัญญาณ การนำตัวเลขเหล่านี้มาปะปนกันอาจทำให้พฤติกรรมของอุปกรณ์ที่สอดคล้องกันดูขัดแย้งกัน บันทึกเครื่องมือ นิยามความยาว การตั้งค่าการแบ่งแฟรกเมนต์ และทิศทาง เปลี่ยนเงื่อนไขทีละอย่างเพื่อให้ระบุสาเหตุของผลลัพธ์ได้ชัดเจน การเปลี่ยนอะแดปเตอร์ ทันเนล และสวิตช์พร้อมกันอาจทำให้บริการกลับมาได้ชั่วคราว แต่บดบังคอขวดเดิม
กำหนดให้ขีดจำกัดขนาดเป็นส่วนหนึ่งของการทดสอบตรวจรับระบบอุตสาหกรรม
เอกสารที่ FCTEL เผยแพร่สำหรับสวิตช์อุตสาหกรรมแบบจัดการได้เป็นจุดเริ่มต้นในการตรวจสอบอินเทอร์เฟซและเงื่อนไขเครือข่าย แต่การระบุว่ารุ่นใดรองรับจัมโบเฟรมขนาดหนึ่งหรือไม่ และเป็นการตั้งค่ารายพอร์ตหรือทั้งระบบ ยังต้องอ้างอิงคู่มือหรือเอกสารที่ได้รับการยืนยันของรุ่นนั้น ความเร็วระดับกิกะบิตและความสามารถในการจัดการเพียงอย่างเดียวไม่ได้ยืนยันว่ารองรับจัมโบเฟรม พอร์ตทองแดงและพอร์ตออปติคัลใช้สื่อทางกายภาพต่างกัน การเปลี่ยนจากสายทองแดงเป็นใยแก้วนำแสงไม่ได้ขจัดข้อจำกัดความยาวเฟรมหรือแพ็กเก็ต IP
บันทึกการตรวจรับสามารถระบุค่า MTU ของอุปกรณ์ปลายทาง นิยามความยาวเฟรมสูงสุดของอุปกรณ์แต่ละเครื่อง ข้อจำกัดของการกำหนดเส้นทางและทันเนล เงื่อนไขการทดสอบทั้งสองทิศทาง และจุดที่เกิดความล้มเหลว หากแอปพลิเคชันต้องใช้เฟรมขนาดใหญ่ ให้ตรวจสอบทุกส่วนของเส้นทาง หากไม่จำเป็น การตั้งค่าแบบปกติที่ผ่านการทดสอบแล้วมักดูแลรักษาง่ายกว่า ตอบคำถามสามข้อ: ขนาดใดผ่านได้ เมื่อเกินขีดจำกัดจะเกิดอะไรขึ้น และแอปพลิเคชันสามารถกลับมาทำงานได้หรือไม่เมื่อเส้นทางเปลี่ยนไป? ขนาดในภาพประกอบเหล่านี้เป็นตัวอย่างเพื่ออธิบาย ไม่ใช่ข้อมูลจำเพาะผลิตภัณฑ์ของ FCTEL หรือผลการวัดภาคสนาม
เอกสารอ้างอิงทางเทคนิค: RFC 1191: การค้นหา Path MTU ของ IPv4; RFC 8201: การค้นหา Path MTU ของ IPv6; Cisco: การแบ่งแฟรกเมนต์, MTU, MSS และพฤติกรรมของทันเนล; Cisco: ตัวอย่างการแก้ไขปัญหา MTU ของสวิตช์. แหล่งข้อมูล FCTEL ที่เกี่ยวข้อง: บทความทางเทคนิค และ เอกสารสวิตช์ FCTELE FCM-G24FG4 แบบจัดการได้ พร้อมพอร์ต Gigabit Ethernet 24 พอร์ต + พอร์ตคอมโบ 4 พอร์ต.
