มันเหมาะสมหรือไม่ที่จะนำ OSPF ไปใช้กับ Metro Ethernet?

เมื่อฉันต้องการเชื่อมต่อเว็บไซต์สาขาจำนวนหนึ่งเข้าด้วยกันสำหรับลูกค้าฉันมักจะแนะนำ MPLS VPN ผ่านผู้ให้บริการที่เชื่อถือได้ CE ที่แต่ละไซต์พูด BGP ด้วย PE ต้นน้ำและแต่ละไซต์จะมีหมายเลขด้วย ASN ส่วนตัว สิ่งนี้สะดวกมากสำหรับเราเนื่องจาก BGP ให้บริการเครื่องมือด้านวิศวกรรมจราจรจำนวนมากและคำจำกัดความของเรา จำกัด เพียง n + 1 สำหรับ n ไซต์ (+1 เป็นสภาพแวดล้อม colo ของเรา)

อย่างไรก็ตามเมื่อเร็ว ๆ นี้ฉันได้สังเกตเห็นความสนใจของลูกค้าที่เพิ่มขึ้นในโซลูชัน Metro Ethernet ลูกค้าของเราหลายคนมีเว็บไซต์สาขาภายในพื้นที่เมืองใหญ่และราคา MetroE กำลังมาที่หลายร้อยดอลลาร์ (USD) น้อยกว่าบริการ MPLS สำหรับวงจรที่มีความเร็วเท่ากัน ในขณะที่สิ่งนี้เป็นที่น่าสนใจฉันไม่แน่ใจว่าจะสร้างเส้นทางในเลเยอร์สองแกนหลักได้ดีที่สุดในขณะที่หลีกเลี่ยงการเปลี่ยนทอพอโลยีเครือข่ายให้กลายเป็นฮับและก้าน

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

มันสมเหตุสมผลหรือไม่ มีข้อควรระวังที่ต้องระวังเมื่อปรับใช้ OSPF ในลักษณะนี้ (ตัวอย่างเช่นฉันควรพิจารณาปิดใช้งานการท่วม LSA) หรือไม่ หรือมีวิธีอื่นที่ฉันมองข้ามไปหรือไม่

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

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

ไม่มีอะไรผิดปกติในการสร้างบริการของคุณเองบนแพลตฟอร์ม MetroE - คุณเพียงแค่ต้องทำงานกับความต้องการของลูกค้าเพื่อกำหนดประเภทของการกำหนดเส้นทางที่เหมาะสม หากคุณกำลังทำงานกับเครือข่ายสำนักงานขนาดเล็ก OSPF / IS-IS / EIGRP อาจเป็นวิธีที่ยอดเยี่ยมในการแลกเปลี่ยนข้อมูลเส้นทางระหว่างไซต์ที่เชื่อมต่อโดยตรงที่คุณสร้างขึ้น หากคุณเป็น NSP / ISP / * SP มากกว่าการแยกโครงสร้างพื้นฐานและเส้นทางลูกค้าระหว่าง IGP และ EGP มีความสำคัญมากขึ้นเมื่อคุณขยายขนาด

ในฐานะวิศวกร ISP เราใช้ลิงก์ MetroE และ EWAN อย่างกว้างขวางเพื่อสร้างกระดูกสันหลังของเราและใช้ความรู้ของเราเกี่ยวกับการเชื่อมโยงทางกายภาพเพื่อออกแบบสภาพแวดล้อม iBGP / eBGP ของเรา ในหลาย ๆ กรณีเราใช้ตัวสะท้อนเส้นทางและตัวสะท้อนเส้นทางคู่ (ตัวสะท้อนเส้นทาง - ลูกศรบนทั้งสองด้านของการเล็ง) เพื่อลดจำนวนเพื่อนของเรา iBGP อย่างไรก็ตามยกเว้นว่าคุณกำลังติดต่อกับเราเตอร์ 6+ ตัวใน POP, iBGP ก็ปรับขนาดได้ค่อนข้างดี

กล่าวโดยย่อ - หากเป็นเพียงไคลเอนต์เดียวที่ไม่ได้ให้บริการเครือข่ายกับลูกค้าของตนเอง - ใช้ IGP หากการเชื่อมต่อภายนอกต้องใช้ร่วมกันระหว่างไซต์ที่มี failover / redundancy / ฯลฯ ให้ตรวจสอบเส้นทางกายภาพที่คุณมีอยู่อย่างใกล้ชิดและออกแบบ eBGP / iBGP ของคุณเพื่อสะท้อนสิ่งนั้น ไม่มีจุดในการมีเราเตอร์ในสถานที่ห่างไกลที่มีเพียง 1 ลิงค์ภายนอกไซต์ไปยัง iBGP เพียร์กับเราเตอร์อื่น ๆ ทั้งหมดใน AS - ใช้ตัวสะท้อนเส้นทางแบบคู่

การเปลี่ยนจาก L3VPN ที่มีการจัดการ (สิ่งที่ฉันถือว่าคุณหมายถึงโดย "MPLS VPN") เป็น L2VPN เป็นขั้นตอนที่ดีที่คุณสามารถเรียกใช้โปรโตคอลที่ไม่ใช่ IP และรับการควบคุมทั้งหมดของโปรโตคอลเส้นทางและแพลตฟอร์มการกำหนดเส้นทางที่กำหนดเส้นทางของคุณ โทโพโลยี

สมมติว่าคุณวางที่อยู่อีเทอร์เน็ต MAC หนึ่งที่ด้าน CPE ของแต่ละไซต์ของคุณอุปกรณ์ของผู้ให้บริการจะเรียนรู้และส่งต่อ 1 ที่อยู่ MAC ต่อไซต์ได้ง่ายกว่าการเรียนรู้และกำหนดเส้นทางเครือข่ายย่อยที่อาจเกิดขึ้นได้

โปรโตคอลที่ชาญฉลาดนี่เป็นคำถามที่ยากที่จะตอบโดยไม่ต้องมีข้อมูลมากนักเนื่องจากทางเลือกที่ดีที่สุดนั้นขึ้นอยู่กับปริมาณการใช้และแผนการเติบโตของคุณ

นี่เป็นเพียงลูกค้ารายใหญ่ที่ต้องการการเชื่อมต่อภายในและอินเทอร์เน็ตหรือขายการเชื่อมต่อด้วยหรือไม่ สมมติว่ามันอยู่ภายในทั้งหมดจากนั้นคุณเพียงแค่ปรับใช้ IGP และอาจใช้ eBGP บางตัวเพื่อประกาศเส้นทาง

หากคุณไม่มีหลายไซต์หรือส่วนนำหน้าภายในโพรโทคอล link-state เช่น OSPF หรือ IS-IS เหมาะสมที่สุดเนื่องจากมันจะมาบรรจบกันอย่างรวดเร็วและสามารถสร้าง FIB จาก RIB ได้อย่างรวดเร็วหากมีเพียงไม่กี่คำนำหน้า .

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

หากคุณกำลังจะมีเว็บไซต์จำนวนมากไซต์ที่น่าสนใจจำนวนมาก (หนึ่งเส้นทาง "อัปสตรีม" ไม่มีเราเตอร์ดาวน์สตรีมอื่น ๆ ) หรือเส้นทางปั่นจำนวนมากคุณจะต้องดูโปรโตคอลหรือโทโพโลยีอื่น ๆ

ในกรณีเช่นนั้นฉันขอแนะนำให้ใช้ BGP กับตัวสะท้อนเส้นทาง ด้วยวิธีนี้คุณสามารถจัดเตรียมตัวสะท้อนเส้นทางที่มีน้ำหนักมาก 2+ ที่ซี่ประกาศและซึ่งซี่อื่น ๆ สามารถคว้าตารางเส้นทางได้ ด้วยวิธีนี้คุณสามารถปรับใช้ CPE ที่มีน้ำหนักเบาได้ที่ไซต์ที่มีผู้พูดจำนวนมากของคุณที่เพิ่งเชื่อมต่อประกาศพื้นที่และรับตารางภายในหรือเส้นทางเริ่มต้นไปยังเราเตอร์ที่ทำ

โดยประมาณฉันขอแนะนำเครื่องชั่งและอุปกรณ์บางอย่าง (และสมมติว่าทรูพุตย่อยกิกะบิต):

• 1 - 20 ซี่ - OSPFv3 ระหว่างไซต์ทั้งหมด จูนิเปอร์ SRX240 หรือคล้ายกันสำหรับเว็บไซต์ทั้งหมด
• 20 - 100 ซี่ - iBGP พร้อมตัวสะท้อนเส้นทาง Juniper SRX240 ในซี่ Juniper MX5 / 10/40/80 สำหรับการสะท้อนเส้นทาง (หรือ Debian Linux / BIRD)
• 100 - 500 ซี่ - เริ่มแบ่งพวกมันออกเป็นเครือข่าย L2, ASes หรือพื้นที่อื่น

เพียงเพิ่มสองบิตที่ถูกมองข้ามไปยังการอภิปราย BGP:

• หากคุณเรียกใช้ iBGP คุณจะต้องใช้โปรโตคอลการกำหนดเส้นทางอื่นเพื่อสร้างการเชื่อมต่อระหว่าง BGP ครั้งต่อไป จากมุมมองของการออกแบบ iBGP เป็นเครื่องมือที่สามารถปรับขยายได้มากกว่าโปรโตคอลเส้นทาง
• หากคุณใช้ eBGP คุณไม่จำเป็นต้องใช้เซสชัน BGP เต็มรูปแบบเพื่อการรับส่งข้อมูลแบบ end-to-end ที่ดีที่สุด การประมวลผล Hop BGP ครั้งต่อไปสามารถแก้ไขปัญหาเหล่านั้นได้อย่างดี

ดูhttp://blog.ioshints.info/2011/08/bgp-next-hop-processing.htmlสำหรับรายละเอียดเพิ่มเติม

คุณสามารถเรียกใช้ OSPF (หรือ IGP อื่น ๆ ) ได้ดีบนบริการเมโทร - อีเธอร์เน็ตแบบหลายจุดและมันควรจะทำงานได้ดีมาก

อาจมีเหตุผลในการเรียกใช้ BGP ต่อไปอย่างไรก็ตาม ... แม้ว่าพวกเขาจะมีข้อโต้แย้งเหมือนกันว่าทำไมคุณอาจต้องการเรียกใช้ BGP ภายในเครือข่ายของคุณเองเช่นกัน

คุณไม่จำเป็นต้องใส่ลำโพง BGP ทั้งหมดของคุณใน AS เดียวกันบนเครือข่าย "ออกอากาศ" เช่นนั้น คิดว่าเป็นประเภท IXP ภายในที่ดำเนินการโดยโทรคมนาคมซึ่ง AS ส่วนตัวของคุณสามารถเชื่อมต่อซึ่งกันและกันผ่านเลเยอร์ 2 เมช คุณไม่จำเป็นต้องบำรุงรักษาเครือข่าย BGP แบบเต็มรูปแบบเนื่องจากการอัปเดต BGP สามารถส่งข้อความอัปเดตต่อไปซึ่งไม่เหมือนกับที่เซสชันเพื่อนมา

ตัวอย่างเช่นหากคุณมีเลเยอร์ 2 ประกบกับเราเตอร์ A, B และ C อยู่และคุณมี BGP เพียร์ระหว่าง A และ B และระหว่าง B และ C เมื่อ C ได้รับการอัปเดตสำหรับเส้นทางที่เกิดขึ้นที่ A มันจะ มี A ในฐานะ hop ครั้งต่อไปแม้ว่าพวกเขาจะได้เรียนรู้ผ่านเซสชัน peering กับ B. แน่นอนว่าคุณจะต้องการเส้นทาง peering มากกว่าเพียงฮับเดียวและพูดดังนั้นคุณไม่ได้ขึ้นอยู่กับฮับเดียว แต่คุณ ไม่จำเป็นต้องใช้ตาข่ายแบบเต็มโดยวิธีการใด ๆ

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

อย่างที่บอกไปแล้วว่าฉันมีลิงค์ metro-E อยู่สองตัว (ชี้ไปที่จุดในกรณีของฉัน) ที่ฉันรัน OSPF และ iBGP ข้ามและมันก็ใช้ได้ดี

สิ่งที่เกี่ยวกับการกำหนดค่าเซิร์ฟเวอร์เส้นทางด้วย 'spokes' beeing rs-clients ของฮับ / เราเตอร์หลัก

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

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

ฉันขอแนะนำให้อ่านและตัดสินใจเกี่ยวกับโทโพโลยี OSPF ทางเลือกเช่นเริ่มต้นจาก NBMA แทนที่จะเป็นมาตรฐาน ในไม่ช้าคุณจะรู้ว่าไม่มีวิธีใดที่ OSPF จะเลือกอย่างถูกต้องระหว่างสองพา ธ ไปยังเราเตอร์ / ไซต์เดียวกันภายในอีเธอร์เน็ตเมโทรเดียวกันเนื่องจากวิธีการคำนวณค่าใช้จ่ายผ่านอินเตอร์เฟสขาออกทั้งลิงค์หลักและสำรอง WAN จะปรากฏเหมือนกัน ค่าใช้จ่ายใน OSPF มาตรฐาน อย่างไรก็ตามหากคุณเลือกที่จะใช้ NBMA คุณสามารถกำหนดค่าใช้จ่ายเพื่อนบ้านได้ด้วยตนเอง แต่ตอนนี้คุณต้องกำหนด mesh / adjacencies ด้วยตนเอง

ไม่ว่าคุณจะทำอะไรไปทางไหนฉันไม่ทำซ้ำอย่าเข้าร่วมที่ชั้น 2 คุณเพียงแค่ถามหาปัญหาในภายหลังถ้าคุณต้องการความสามารถในการเชื่อมต่อของเลเยอร์ 2 ให้ใช้ OTV หรือเลเยอร์ 2 อื่น ๆ

คุณจะพบว่าคุณจะได้เรียนรู้มากขึ้นเกี่ยวกับ OSPF อย่างรวดเร็ว (และจำเป็นต้องรู้มากกว่านี้) มากกว่าเมื่อเปรียบเทียบกับผู้ให้บริการ MPLS-VPN ที่เรียบง่ายซึ่งแกน WAN ถูกซ่อนไว้จากคุณ

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