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

เส้นทางกำหนดการเข้าถึง แฮชกำหนดการกระจาย

ตำนาน: /32 หมายถึงเส้นทางเดียว

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

ดูรายการส่งต่อที่ติดตั้งไว้ ไม่ใช่แค่การแสดงเส้นทาง เพราะข้อจำกัดของฮาร์ดแวร์หรือนโยบายอาจตัดผู้สมัครที่ระนาบควบคุมยังประกาศอยู่

เอนโทรปีต้องมาจากไหน

ระหว่าง VTEP สองตัว ที่อยู่ต้นทางและปลายทางภายนอกคงที่ และพอร์ตปลายทาง UDP คือ 4789 ในการติดตั้งแบบปกติ แฮชที่อ่านเฉพาะค่าเหล่านั้นเห็นอินพุตคงที่และคืนเส้นทางคงที่ มีบางอย่างในเฮดเดอร์ภายนอกต้องแปรผัน และ VTEP คืออุปกรณ์ที่ทำให้มันแปรผันได้

RFC 7348 เสนอให้สกัดพอร์ตต้นทาง UDP จากฟิลด์ภายในเฟรมที่ห่อหุ้ม บทสนทนาภายในที่ต่างกันจึงสร้างทูเพิลภายนอกที่ต่างกัน ซึ่งให้สิ่งที่แฮชการรับส่งทั่วไปนำไปใช้งานได้

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

ตรวจแฮชที่คุณได้รับจริง

วัดแทนการสันนิษฐาน จับตัวอย่างทราฟฟิกที่ห่อหุ้มและดูพอร์ตต้นทางภายนอก แล้วเปรียบเทียบผลกับรายการส่งต่อและตัวนับต่อลิงก์

show ip route 10.255.0.5/32
show ip cef 10.255.0.5 internal
ip route show 10.255.0.5
tcpdump -ni eth0 -c 200 'udp port 4789' -vv

พอร์ตต้นทางเดียวที่ปรากฏในบทสนทนาภายในต่าง ๆ มากมายหมายความว่า VTEP ไม่ได้แปรผันฟิลด์นั้น และการปรับแต่งอันเดอร์เลย์ใด ๆ ก็ไม่กระจายโหลด พอร์ตต่างกันจำนวนมากโดยมีฮอปถัดไปใช้เพียงตัวเดียวกลับชี้ไปที่กลุ่มส่งต่อ

บันทึกตัวนับก่อนและหลังตัวอย่าง และสังเกตทราฟฟิกที่ไม่เกี่ยวข้องซึ่งใช้ลิงก์อัปโหลดร่วมกัน ไม่อย่างนั้นตัวเลขจะดูแย่กว่าที่แฮชสมควรได้รับ

การกระจายเท่าเทียมไม่ได้หมายความว่าอะไร

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

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

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

บทความที่เกี่ยวข้อง