การกำหนดเส้นทางทราฟฟิกออกลิงก์ที่แตกต่างจาก BGP AS เดียวกัน


19

ฉันมีสองไซต์ A และ B ใน BGP AS 65000 และไซต์ที่สาม C ใน AS 65001 ทั้งสามไซต์มีการเชื่อมต่อผ่านผู้ให้บริการ MPLS และมีการเชื่อมต่อภายในระหว่างไซต์ A และ B ฉันพยายามโน้มน้าว BGP เพื่อให้ทราฟฟิกจากไซต์ A ไปยังไซต์ C จะถูกกำหนดเส้นทางผ่านลิงก์ MPLS ของไซต์ A และทราฟฟิกจากไซต์ B ไปยังไซต์ C จะกำหนดเส้นทางผ่านลิงก์ MPLS ของไซต์ B โทโพโลยีนั้นคล้ายคลึงกับสิ่งที่อธิบายไว้ในตัวอย่างนี้

AS 65000 และ 65001

เราเตอร์ขอบที่ไซต์ A และ B ทั้งคู่จะเห็นลิงก์ MPLS ของตัวเองเป็นเส้นทางที่ดีที่สุดเนื่องจากเส้นทาง EBGP เป็นที่ต้องการมากกว่าเส้นทาง IBGP อย่างไรก็ตามเราเตอร์ที่อยู่ภายใน AS 65000 จะชอบลิงค์เดียวหรือลิงค์อื่น เป้าหมายของฉันคือการบังคับให้เราเตอร์ทั้งหมดในแต่ละเว็บไซต์ต้องการลิงค์ที่ใกล้เคียงที่สุด (น่าเสียดายที่ฉันไม่สามารถแยกทั้งสองไซต์ออกเป็น ASes แยกได้ในเวลานี้)

มีวิธีที่ดีที่จะทำสิ่งนี้ให้สำเร็จในขณะที่ยังยอมให้มีการเชื่อมต่อกับไซต์ C ระหว่างไซต์ A และ B ได้หรือไม่

แก้ไข: ฉันควรสังเกตว่าไม่มีการใช้ IGP ที่นี่ ความจริงแล้วเครือข่ายในแต่ละไซต์นั้นมีอยู่ภายใน VRF ซึ่งเป็นส่วนหนึ่งของเครือข่ายที่ใหญ่กว่ามาก ดังนั้นการแก้ปัญหาใด ๆ จะต้องพึ่งพา BGP ทั้งหมด


เฮ้เจเรมี - มีวิธีแก้ปัญหาที่ดีสองข้อด้านล่างนี้ แต่ฉันไม่สามารถคาดเดาได้อย่างปลอดภัยว่าคุณมีอำนาจควบคุม IGP คุณช่วยอธิบายได้ไหม?
John Jensen

ไม่มี IGP ในสถานการณ์นี้ นี่เป็นตัวแทนของ VRF เพียงหนึ่งเดียวในเครือข่ายที่ใหญ่กว่ามาก รายละเอียดที่ฉันได้ทิ้งไว้เพื่อความชัดเจน
Jeremy Stretch

นั่นคือสิ่งที่ฉันกลัว :-) ขอขอบคุณที่ชี้แจง
John Jensen

ฉันคิดว่ามีบางอย่างขาดหายไป ดังนั้นเราสองคนคิดว่ามีการเชื่อมโยง (อาจมากเนื่องจากเราเตอร์ภายในหลายตัว?) ระหว่าง A และ B ภายใน AS 65000 นอกจากนี้คุณเห็นว่าอะไรเป็นสิ่งที่ดีที่สุดย่อย? a / หรือเราเตอร์จำนวนมากใกล้กับ A (การพูดทอพอโลยี) ส่งปริมาณข้อมูลผ่าน B เพื่อไปที่ C หรือไม่
jwbensley

@javano ปัญหาคือทั้ง A และ B (เราเตอร์ edge) เป็น iBGP เพียร์ใน ASN เดียวกันดังนั้นคำนำหน้าใด ๆ (es) เรียนรู้จาก C ในทั้งสองจะมี 2 เส้นทางใน RIB ในกล่องทั้งสองและเส้นทาง eBGP จะ ชนะเสมอการรับส่งข้อมูลขาออกจาก AS6500 ถึง AS65001 จะติดอยู่ที่ลิงก์เดียว
John Jensen

คำตอบ:


12

มีคำจำกัดความที่ชัดเจนระหว่างไซต์ A และไซต์ B หรือไม่

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

เมื่อชุมชนนี้ถูกใส่คำนำหน้า (พูด 100: 1 สำหรับไซต์ A และ 100: 2 สำหรับไซต์ B) จากนั้นคุณสามารถเพิ่มนโยบายให้กับเราเตอร์ของไซต์ A แต่ละไซต์เพื่อเพิ่ม LP สำหรับเส้นทางใด ๆ ที่มีชุมชน 100: 1 และ เช่นเดียวกันสำหรับไซต์ B ที่มีชุมชน 100: 2

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


1
นี่อาจเป็นวิธีที่ดีที่สุดในการไป แต่ถ้า Jeremy ประกาศสรุปครั้งเดียวจาก C เขาจะต้องแยกมันออกเป็นชิ้น ๆ เพื่อให้การทำงานมีประสิทธิภาพ
John Jensen

ฉันคิดว่านี่เป็นเส้นทางที่ฉันจะไป จะต้องทำการทดลองในวันพรุ่งนี้และดูว่าฉันถูกขัดขวางได้ทุกที่หรือไม่
Jeremy Stretch

@JohnJensen ไม่จำเป็นต้องมีสิ่งนี้เนื่องจากทั้งไซต์ A และ B กำลังได้รับส่วนนำหน้าเหมือนกันจากผู้ให้บริการดังนั้นจึงสามารถทำการแก้ไขคำนำหน้าเว็บไซต์ของพวกเขาเองได้
David Rothera

1
เมื่อทราบเพิ่มเติมเกี่ยวกับการคิดเกี่ยวกับมันมากขึ้นมันอาจจะดีกว่าที่จะใช้คุณลักษณะที่สำคัญในพื้นที่เช่นน้ำหนักแทนที่จะเป็นสกรรมกริยาเช่น LP
David Rothera

1
@DavidRothera หากมีคำนำหน้าหลายคำประกาศจาก C คุณต้องถูกต้อง - เป็นไปได้ที่อาจมีเพียงหนึ่งคำนำหน้ามาจาก C ซึ่งในกรณีนี้ฉันไม่แน่ใจว่าการตั้ง localpref กับชุมชนจะสร้างความแตกต่าง ในการแก้ปัญหาของ Jeremy เนื่องจากมีคำนำหน้าเดียวที่มีตัวเลือกของชุมชนสองแห่งและค่า LP ที่แตกต่างกันสองค่า LP ที่สูงกว่าจะเป็นที่ต้องการและทราฟฟิกจะยังคงอยู่ที่ลิงก์เดียว การยอมรับด้วยว่าการใช้แอตทริบิวต์ที่มีนัยสำคัญในระดับท้องถิ่นอาจดีกว่า
John Jensen

6

ป้อนคำอธิบายรูปภาพที่นี่เมื่อฉันทำสิ่งที่คล้ายกันฉันไม่ได้ใช้ eBGP ระหว่างเราเตอร์ ฉันให้เราเตอร์ที่พูด BGP ส่งเส้นทางเริ่มต้นลงไปที่เราเตอร์ไซต์ A และไซต์ B ผ่าน OSPF แล้วกระจายเส้นทาง OSPF ไปยัง BGP อีกครั้ง ในลิงค์ระหว่างสองไซต์ฉันใช้ค่าใช้จ่าย OSPF

สิ่งนี้ช่วยให้ไซต์ A มีเส้นทางไปยังเครือข่ายเครือข่ายไซต์ B และเส้นทางเริ่มต้นที่จะออกจากไซต์ A (ค่าใช้จ่าย OSPF จะเก็บเส้นทางเริ่มต้นจากไซต์ B เป็นตัวเลือกรองหากคุณสูญเสียลิงก์ไซต์ A) ไซต์ A จะพูดคุยโดยตรงกับไซต์ B ไม่ใช่การใช้ MPLS เว้นแต่ว่ามีการเชื่อมโยงล้มเหลวระหว่างไซต์

และค่าใช้จ่าย OSPF จะแปลเป็น BGP MED ในระหว่างการแจกจ่ายซ้ำซึ่งทำให้เครือข่ายผู้ให้บริการ MPLS ต้องการส่งการเข้าชมไซต์ A ไปยังไซต์ A โดยตรง แต่ยังใช้ไซต์ B เพื่อไปยังไซต์ A หากจำเป็น


3

ฉันรู้สึกว่าข้อมูลบางอย่างหายไป ทำไมเราเตอร์ขอบถึงไม่เลือกเส้นทางที่ดีที่สุดอยู่แล้ว

คุณมี iBGP แบบเต็มตาข่ายใน 65000 หรือไม่ หรือคุณใช้การสะท้อนเส้นทาง

หากคุณมี iBGP แบบตาข่ายเต็มรูปแบบเราเตอร์แต่ละตัวจะเรียนรู้เส้นทางจากทั้ง [AB] และจะหันไปเปรียบเทียบต้นทุน IGP กับการกระโดดครั้งต่อไปซึ่งควรแปลเป็นกล่องขอบที่ใกล้เคียงที่สุด

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


2

หากคุณมีอำนาจควบคุม IGP:

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

หากคุณไม่สามารถควบคุม IGP:

บางทีคุณสามารถใช้นโยบายการนำเข้ากับเราเตอร์ภายในเพื่อให้พวกเขาต้องการประกาศเส้นทางของเราเตอร์ทางออก eBGP ที่ต้องการ ตัวอย่างเช่นหาก iBGP มีสองประกาศสำหรับคำนำหน้าที่กำหนด (หนึ่งจากไซต์เราเตอร์และอีกหนึ่งจากเราเตอร์ไซต์ B แต่เพียงหนึ่งติดตั้งลงใน RIB) จากนั้นคุณสามารถ local-up ขึ้นประกาศที่ต้องการตามมา ฉันจะต้องทดลองใช้ แต่ไม่เห็นว่าทำไมจึงไม่ทำงาน


ใช่ว่าจะเป็นวิธีที่ดีที่สุดที่ฉันจินตนาการว่าคุณมีความสามารถในการใช้ IGP น่าเสียดายที่ไม่ใช่กรณีของฉัน :( ฉันได้อัปเดตคำถามเพื่อรวมถึงรายละเอียดที่ถูกละเลยนี้
Jeremy Stretch

ฉันชอบคำตอบของ David Rothera เหมือนกันกับของฉัน แต่เขาเพิ่มรายละเอียดของการใช้ชุมชน :)
netdad
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.