ก่อนเพิ่ม OTV ให้เขียนสัญญา Ethernet ที่คุณต้องการ

เวิร์กโหลดย้ายไปยังศูนย์ข้อมูลแห่งที่สองและเริ่มหมดเวลาบนบริการที่ตอบสนองได้ดีจากแห่งแรก มีคนเสนอ OTV เพราะ Layer 2 VPN ที่มีอยู่ «ไม่ทำ broadcast» ข้อสรุปนั้นมักจะเร็วเกินไป หมวดหมู่บริการและสัญญาเฉพาะที่คุณซื้อเป็นคำถามสองข้อที่ต่างกัน และการหมดเวลายังไม่ได้ถูกโยงไปยังข้อใดข้อหนึ่ง

อาการที่เริ่มการเปรียบเทียบ

เขียนสิ่งที่แอปพลิเคชันต้องการจริง ๆ ก่อนเปรียบเทียบผลิตภัณฑ์ จำนวนไซต์ ขอบเขต VLAN การเรียนรู้ที่อยู่ ความทนทานต่อ flooding และพฤติกรรมเมื่อล้มเหลวอธิบายความต้องการ «Layer 2» และ «OTV» อธิบายสถาปัตยกรรม และไม่มีอันใดเป็นความต้องการในตัวเอง ห้าคุณสมบัติบนหน้าหนึ่งจะอยู่ได้นานกว่าการเปรียบเทียบผู้ขายใด ๆ

จากนั้นตรวจสอบว่าบริการปัจจุบันตอบสนองห้าคุณสมบัติเหล่านั้นแล้วหรือไม่ Layer 2 VPN ที่ผู้ให้บริการจัดการอาจรวมถึงการส่งต่อ multipoint และการเรียนรู้ในระนาบควบคุมที่การดูใบแจ้งหนี้เพียงครั้งเดียวไม่ได้กล่าวถึง

หากบริการปัจจุบันตอบสนองความต้องการเหล่านั้น การหมดเวลาอยู่ที่อื่น: ปัญหา MTU ความไม่สมมาตรของการกำหนดเส้นทาง กฎไฟร์วอลล์ที่ต่างกันระหว่างไซต์ การเปลี่ยน overlay จะทิ้งสาเหตุนั้นไว้และเพิ่มการย้ายข้อมูล

สิ่งที่ป้ายไม่ได้บอกคุณ

Layer 2 VPN เป็นหมวดหมู่ ไม่ใช่ผลิตภัณฑ์ VPWS แบบจุดต่อจุดและ VPLS แบบ multipoint ส่งต่อต่างกัน และหมวดหมู่นี้รวมบริการที่มีการเรียนรู้ในระนาบควบคุมและการจัดการลูปตลอดจนบริการที่ง่ายกว่า การสมมติว่า Layer 2 VPN ทุกตัวเชื่อมต่อสองไซต์พอดีและ flood ทุกอย่างคือวิธีสร้างการเปรียบเทียบที่ผิด ชื่อบนสัญญาไม่ได้บอกอะไรเกี่ยวกับตารางส่งต่อที่อยู่เบื้องหลัง

ถาม ว่าบริการที่มีอยู่ใช้รูปแบบการส่งต่อใด และแอปพลิเคชันต้องการรูปแบบใด ความต้องการแบบ hub-and-spoke และแบบ full-mesh ให้การออกแบบที่ต่างกันแม้ทั้งสองจะถูกอธิบายว่าเป็น Layer 2

OTV ลากเส้นเขตของมันที่ไหน

OTV ทำงานบนการขนส่ง IP ด้วยการเข้าถึง MAC ในระนาบควบคุมและบทบาท edge ที่กำหนดไว้ ข้อมูล spanning-tree ภายในยังคงอยู่ภายในแทนที่จะขยายเป็นโดเมนเดียวที่ไม่ถูกควบคุมทั่วการขนส่ง นั่นคือความแตกต่างจริงจากการขยายแบบบริดจ์ธรรมดา และเป็นเหตุผลที่ผู้คนหันมาใช้มัน

เขตแดนสำคัญพอ ๆ กับประโยชน์ การจัดการ unicast, broadcast และ multicast ที่ไม่รู้จักขึ้นอยู่กับแพลตฟอร์มและการกำหนดค่า และคู่ edge ต้องร่วมมือผ่านกลไก multihoming ที่รองรับ อุปกรณ์อิสระสองเครื่องที่ส่งต่อ VLAN เดียวกันไม่ใช่การออกแบบเดียวกัน และก่อให้เกิดโหมดล้มเหลวที่ต่างกัน

Flooding ถูกลดลง ไม่ได้ถูกกำจัด

การระงับ flooding ที่ไม่จำเป็นบางส่วนไม่เหมือนกับการรับประกันว่าจะไม่มีเฟรม broadcast หรือ multicast ใดข้ามการขยายเลย พายุที่เริ่มในไซต์หนึ่งยังคงกินการขนส่งได้ และคุณสมบัติแพลตฟอร์มที่กรองคลาสทราฟฟิกหนึ่งไม่กรองคลาสอื่น ความผิดหวังส่วนใหญ่กับ overlay ใด ๆ มาจากความแตกต่างนี้

ดังนั้นคำถามไม่ใช่ OTV หยุดพายุ broadcast หรือไม่ แต่เป็นคลาสทราฟฟิกใดที่ข้าม ภายใต้เงื่อนไขใด และอะไรจำกัดอัตราเมื่อมันข้าม

ยืนยัน underlay ขณะอยู่ที่นั่น: การส่งมอบที่รองรับ ขนาดแพ็กเก็ต การกำหนดเส้นทาง และความเป็นเพื่อนบ้านที่รีลีสที่เลือกต้องใช้ ไม่มีสิ่งใดมาฟรีกับ overlay และอุโมงค์ที่พอดีเฟรม 1500 ไบต์ไม่ใช่โดยอัตโนมัติอุโมงค์ที่พอดีเฟรมที่ติดแท็กของคุณ

สัญญาที่ต้องขอเป็นลายลักษณ์อักษร

สำหรับบริการใดก็ตามที่คุณเลือก ขอคำตอบหกข้อเดิม: ขอบเขตจุดต่อจุดหรือ multipoint การจัดการเฟรมและแท็กของลูกค้า รูปแบบการเรียนรู้ MAC ขีดจำกัด flooding พฤติกรรมการกู้คืน และขนาดเฟรมสูงสุดตั้งแต่ต้นจนจบ บริการสองรายการที่ชื่อเดียวกันอาจต่างกันในทุกข้อ ขอคำตอบเป็นลายลักษณ์อักษร เพราะวิศวกรที่กำหนดค่าบริการอาจไม่ใช่คนที่ตอบคำถาม

เลือกการเปลี่ยนแปลงเฉพาะสำหรับความต้องการที่บริการปัจจุบันพิสูจน์ได้ว่าไม่สามารถตอบสนองได้ การขยาย VLAN ต่อไปยังขยายการพึ่งพาของแอปพลิเคชันและ Ethernet ไปด้วย ชื่อ overlay ใหม่ไม่ได้ลบสิ่งเหล่านั้น

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