เหตุใดจึงต้องใช้ iBGP ภายในระบบอัตโนมัติถ้าโปรโตคอล IGP ตอบสนองความต้องการด้านการสื่อสารภายใน

22

ทุกคนสามารถอธิบายได้ไหมว่าทำไมเราจึงต้องใช้ iBGP สำหรับเส้นทางเมื่อเรามีโปรโตคอล IGP (OSPF, RIP) สำหรับการสื่อสารภายในภายใน AS

ฉันอ่านบทความและหนังสือมากมาย แต่ไม่สามารถหาคำตอบได้

— user2720323
แหล่งที่มา

26

ทุกคนสามารถอธิบายให้ฉันทราบว่าอะไรคือความต้องการของการสื่อสาร IBGP สำหรับเส้นทางเมื่อเรามีโปรโตคอล IGP (OSPF, RIP) สำหรับการสื่อสารภายใน

ความสามารถในการปรับขนาด¹ : ลองจินตนาการว่าคุณได้รับเส้นทาง 500,000 EBGP ในมากกว่าหนึ่งแห่งที่²และคุณต้องมีอิทธิพลต่อจุดออกเส้นทางต่อใน AS ของคุณ BGP สามารถรองรับเส้นทางได้มากมายกว่าโปรโตคอล IGP ดังนั้นจึงจำเป็นต้องใช้ iBGP เว้นแต่คุณจะยินดีแจกจ่ายเส้นทางทั้งหมดที่คุณได้เรียนรู้ผ่าน eBGP
บังคับใช้ขอบเขตของความไว้วางใจ / การควบคุม: BGP มีวิธีการกรองเพื่อนร่วมงานมากกว่า IGPs (สำหรับการควบคุมสิ่งที่คุณโฆษณาและรับ)
โครงสร้างข้อมูลที่ยืดหยุ่น (ค่อนข้างเกี่ยวข้องกับสัญลักษณ์แสดงหัวข้อย่อยก่อนหน้า): ชุมชน BGP , ชุมชน BGP แบบขยาย , โลคัล pref , ฯลฯ ... สิ่งเหล่านี้ทำให้ BGP เป็นวิธีที่น่าสนใจในการใช้นโยบายการกำหนดเส้นทางเองภายในระบบปกครองตนเองของคุณเอง (โดยใช้ iBGP)

เช่นเดียวกับทุกสิ่งที่มีการค้าไม่ชอบ; ความสามารถในการปรับขนาดการควบคุมและความยืดหยุ่นที่คุณได้รับจาก iBGP หมายความว่าเป็นโปรโตคอลการบรรจบกันที่ช้ากว่า IGPs (โดยทั่วไป)

หมายเหตุท้าย:

^{1 ความ} ยืดหยุ่น :

คุณใช้ BGP เพราะคุณไม่ต้องการพกพาตารางเส้นทางอินเทอร์เน็ตทั้งหมดใน IGP ของคุณ (เช่นในกรณีของฉัน OSPF) ...
OSPF ไม่ได้ออกแบบมาเพื่อรองรับเส้นทางหลายพันในตาราง BGP อินเทอร์เน็ต ... หากคุณพยายามใช้ OSPF เพื่อจุดประสงค์นี้มันจะทำลายเครือข่ายของคุณ เมื่อใช้ตัวอย่างของ OSPF ข้อกำหนดของการประมวลผล / การท่วมของ LSA จาก 500,000 เส้นทางจะใช้ทรัพยากรจำนวนมากในเราเตอร์ของคุณ ตั้งชื่อ IGP อื่น ๆ (EIGRP, RIPv1 / 2, IS-IS, IGRP) และเรื่องราวเดียวกันเป็นจริง
มีบางกรณีที่ฉาวโฉ่ที่ผู้ให้บริการอินเทอร์เน็ตระดับ Tier-1 แจกจ่ายตาราง BGP ของพวกเขาไปยัง IGP ของพวกเขาโดยบังเอิญ ขณะนี้มีการใช้มาตรการตอบโต้ในโปรโตคอล IGP ( เช่นเดียวกับ OSPF ใน IOS ) เพื่อป้องกันการแจกจ่ายซ้ำจาก BGP ไปยัง OSPF ไม่ให้เกิดการหยุดทำงานครั้งใหญ่

² ตัวอย่างเส้นทางของ iBGP :

เพื่อให้เข้าใจถึงสาเหตุที่คุณอาจต้องการ iBGP ให้พิจารณารายการการกำหนดเส้นทางนี้เป็น 4.2.2.2 ...

R2>sh ip bgp 4.2.2.2
BGP routing table entry for 4.0.0.0/9, version 3146
Paths: (32 available, best #7, table Default-IP-Routing-Table)
... <!-- extra BGP RIB entries deleted -->
  7660 2516 3356, (aggregated by 3356 4.69.130.4)
    203.181.248.168 from 203.181.248.168 (203.181.248.168)
      Origin IGP, localpref 100, valid, internal, atomic-aggregate
      Community: 2516:1030
  3356, (aggregated by 3356 4.69.130.6)
    4.69.184.193 from 4.69.184.193 (4.69.184.193)
      Origin IGP, metric 0, localpref 100, valid, internal, atomic-aggregate, best
      Community: 3356:0 3356:3 3356:100 3356:123 3356:575 3356:2012
... <!-- extra BGP RIB entries deleted -->

มีเส้นทาง 32 เส้นทางที่จะต้องพิจารณา ... ในกรณีนี้ BGP เลือกที่จะไปที่ 4.0.0.0/9 ผ่าน 4.69.184.193 (สังเกตเห็นbestใต้รายการ RIB) ในกรณีนี้ BGP เลือกเส้นทางนี้เนื่องจากเส้นทางนี้มีรายการเส้นทาง AS ที่สั้นที่สุด อย่างไรก็ตามจะไม่แนะนำให้ใช้ทุกเส้นทางผ่าน AS3356 (ต่อกับ R1) บางคนอาจเป็นที่ต้องการจาก R3 (ผ่าน AS7660) iBGP ช่วยให้คุณมีความสามารถในการรู้ (ที่ R2) วิธีที่จะไปใช้เส้นทาง BGP ที่สั้นที่สุด

BGP route to 4.0.0.0/9 via                                              
NH: 4.69.184.193 [Path: 3356]                                  
  -------->                                                     

 eBGP w/ AS3356 }{              iBGP inside AS64000          }{   eBGP w/ AS7660

                 S1/0       S1/2   S2/1     S2/3   S3/2    S3/0
Peered w/ AS3356    +------+         +------+        +------+       Peered w/ AS7660
4.69.184.193 <------|  R1  |---------|  R2  |--------|  R3  |-----> 203.181.248.168
                    +------+         +------+        +------+
                                         | S2/0
                                         |

                                         ^
                                         ^
                                         | Ingress packet to 4.2.2.2
                                         |

R1, R2 และ R3 ได้รับการแบ่งเป็น iBGP อย่างสมบูรณ์ เมื่อ iBGP ประกาศเส้นทางต่อไปฮอปยังคงไม่เปลี่ยนแปลง หมายความว่าฉันต้องพกซับเน็ตสำหรับ 4.69.184.193 ใน OSPF ...

R2>sh ip route 4.69.184.193
Routing entry for 4.69.184.192/30
  Known via "ospf 100", distance 110, metric 65536, type intra area
  Last update from 192.0.2.109 on GigabitEthernet3/1, 1w0d ago
  Routing Descriptor Blocks:
  * 192.0.2.109, from 192.0.2.3, 1w0d ago, via Serial2/1
      Route metric is 65536, traffic share count is 1

R2>

ดังนั้นเมื่อแพ็กเก็ต 4.2.2.2 มาถึง R2 R2 จะส่ง Serial2 / 1 ออกมาเพราะนั่นคือสิ่งที่ iBGP บอกเราว่าการกระโดดครั้งต่อไปคืออะไร

— ไมค์เพนนิงตัน
แหล่งที่มา

ไม่แน่ใจว่าฉันเข้าใจส่วนนี้หรือไม่: 'ต้องใช้ iBGP เว้นแต่คุณจะยินดีแจกจ่ายเส้นทางทั้งหมดที่คุณได้เรียนรู้ผ่าน eBGP' หากเรามีเราเตอร์ eBGP สองเส้นเราเตอร์ A จะไม่ทราบเส้นทางที่เราเตอร์ B ได้เรียนรู้หรือในทางกลับกัน พวกเขาจำเป็นต้องแลกเปลี่ยนข้อมูลอย่างใดและโดยปกติจะใช้ iBGP คุณจะใช้ eBGP สำหรับเรื่องนี้อย่างไร ฉันไม่แน่ใจว่า eBGP สามารถทำให้ A และ B ทราบเส้นทางที่เราเตอร์ได้เรียนรู้ได้อย่างไร

— user4205580

คำสั่งที่คุณหมายถึงอนุมานว่าคุณมีบางส่วนที่ไม่ได้พูด eBGP สมมติว่าคุณไม่สามารถใช้ชีวิตกับเส้นทางเริ่มต้นไปสู่กระแสของ eBGP ได้ ณ จุดนี้คุณสามารถ: A) แจกจ่ายคำนำหน้า eBGP ลงใน IGP ของคุณ (โดยปกติจะเป็นแนวคิดที่ไม่ดี) หรือ B) ใช้ iBGP คำตอบของฉันใช้เวลาส่วนใหญ่อธิบายว่าทำไม iBGP ถึงมีประโยชน์

— Mike Pennington

10

IGP มักจะเป็น OSPF หรือ ISIS ซึ่งเป็นพื้นฐานของการเชื่อมโยงซึ่งทำให้เรามีข้อมูลทั้งหมดของเครือข่ายทุกคนรู้เครือข่ายจากมุมมองของทุกคนซึ่งช่วยให้ตัวเลือกการบรรจบกันที่น่าสนใจและตัวเลือกด้านวิศวกรรมจราจร

BGP นั้นเป็นระยะทางแบบเวกเตอร์ซึ่งรู้ว่ามีมุมมองที่ จำกัด มากในเครือข่ายโดยรวม BGP จัดการการกรองและการปรับเปลี่ยนข้อมูลเส้นทางได้เป็นอย่างดี

โปรโตคอลลิงค์สถานะค่อนข้างแพงเมื่อเทียบกับระยะทาง - เวกเตอร์มันจะค่อนข้างมีปัญหาในการปรับขนาดเป็น INET DFZ

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

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

— ytti
แหล่งที่มา

1

BGP เป็นโปรโตคอลเส้นทางเวกเตอร์ซึ่งเป็นไม่เหมือนกันเป็นระยะทางเวกเตอร์โพรโทคอ

— ไมค์เพนนิงตัน

3

Path vector เป็นกรณีเฉพาะของเวกเตอร์ระยะทาง สิ่งสำคัญคือต้องตระหนักว่าพวกเขามีความซับซ้อนและค่าใช้จ่ายคล้ายกันมากในขณะที่สถานะลิงก์แตกต่างกันโดยสิ้นเชิง จากหนังสือ BGP ของ Sam Halabi และ Danny McPhersons หน้า 98 'ส่วนนี้จะไม่สมบูรณ์หากไม่กล่าวถึงว่า BGP ตกอยู่ในหมวดหมู่เวกเตอร์ระยะทาง'

— ytti

2

Path vector นั้นคล้ายกัน แต่ยังคงเป็นอัลกอริธึมที่แตกต่างกัน คุณสามารถอ่านเพิ่มเติมเกี่ยวกับสิ่งนี้ได้ในหนังสือของ Danny McPherson และ Russ White, BGP เชิงปฏิบัติที่ตีพิมพ์ในปี 2004 ลิงค์มือถือ

— Mike Pennington

2

หน้าใดที่อ้างว่า BGP ไม่ใช่เวกเตอร์ระยะทาง

— ytti

2

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

— ytti

7

เหตุผลหนึ่งที่ฉันเห็นค่อนข้างบ่อยคือความชัดเจน: เส้นทางทั้งหมดจะดำเนินการภายในหนึ่งโปรโตคอลการกำหนดเส้นทาง (BGP), IS-IS, OSPF หรือ RIP จะใช้เฉพาะสำหรับ adjacency ด้วยเหตุนี้จึงไม่จำเป็นต้องกระจายเส้นทางจากโปรโตคอลเส้นทางหนึ่งไปยังอีกเส้นทางหนึ่ง

— Teun Vink
แหล่งที่มา

3

iBGP ไม่ได้ใช้สำหรับการจัดเส้นทางภายในจริงๆเราเตอร์ eBGP ทั้งหมดของคุณใช้เพื่อแชร์เส้นทางของพวกเขา

ตัวอย่าง: หากคุณดูด้วยเครือข่ายอื่น 3 เครือข่ายคุณต้องการให้เราเตอร์ eBGP ทั้งหมดของคุณรู้เส้นทางที่ได้รับจากคนอื่นเพื่อให้พวกเขาสามารถเผยแพร่ข้อมูลนั้นไปยังเพื่อนถ้าจำเป็น / จำเป็น คุณ)

— Remi Letourneau
แหล่งที่มา