Po co używać iBGP w systemie autonomicznym, jeśli protokoły IGP spełniają potrzebę komunikacji wewnętrznej

22

Czy ktoś może wyjaśnić, dlaczego potrzebujemy iBGP dla tras, gdy mamy protokoły IGP (OSPF, RIP) do komunikacji wewnętrznej w AS?

Przeczytałem wiele artykułów i książek, ale nie mogłem znaleźć odpowiedzi.

użytkownik2720323
źródło

Odpowiedzi:

26

Czy ktoś może mi wyjaśnić, jaka jest potrzeba komunikacji IBGP na trasach, gdy mamy protokoły IGP (OSPF, RIP) do komunikacji wewnętrznej?

  • Skalowalność 1 : Wyobraź sobie, że otrzymujesz 500 000 tras EBGP w więcej niż jednej lokalizacji 2 i musisz wpływać na punkt wyjścia na trasę w twoim AS. BGP może obsłużyć o wiele więcej tras niż protokoły IGP. W związku z tym iBGP jest wymagany, chyba że chcesz redystrybuować wszystkie trasy, których nauczyłeś się za pośrednictwem eBGP
  • Egzekwuj granice zaufania / kontroli: BGP ma więcej sposobów filtrowania rówieśników niż IGP (do kontrolowania tego, co reklamujesz i otrzymujesz).

  • Elastyczne struktury danych (nieco podobne do poprzedniego kulą): wspólnoty BGP , BGP Rozbudowane społeczności , lokalnych pref , etc ... te sprawiają BGP atrakcyjnym sposobem realizacji niestandardowych zasad routingu wewnątrz własnego systemu autonomicznego (przy użyciu IBGP).

Jak ze wszystkim są kompromisy; skalowalność, kontrola i elastyczność, którą zyskujesz dzięki iBGP, oznacza, że ​​jest to wolniejszy protokół konwergencji niż IGP (ogólnie).


Uwagi końcowe:

1 Skalowalność :

  • Używasz BGP, ponieważ nie chcesz przenosić całej tabeli routingu internetowego w IGP (tj. W moim przypadku OSPF) ...
  • OSPF nie został zaprojektowany do obsługi wielu tysięcy tras w internetowych tabelach BGP ... jeśli spróbujesz użyć OSPF do tego celu, spowoduje to uszkodzenie sieci. Na przykładzie OSPF wymagania przetwarzania / zalewania LSA z 500 000 tras zużywają zbyt wiele zasobów w routerach. Nazwij dowolny inny IGP (EIGRP, RIPv1 / 2, IS-IS, IGRP) i ta sama historia jest prawdziwa.
  • Zdarzały się notoryczne przypadki, w których dostawca ISP poziomu 1 przypadkowo redystrybuował swoją tabelę BGP do swojej IGP (nawet gdy stolik internetowy był niewielkim ułamkiem jego obecnej wielkości) i powodował poważne awarie. Środki zaradcze zostały wdrożone w protokołach IGP ( takich jak ten dla OSPF w IOS ), aby zapobiec powodowaniu poważnej awarii przez redystrybucję z BGP do OSPF.

2 Przykład routingu iBGP :

Aby zrozumieć, dlaczego możesz chcieć iBGP, rozważ ten wpis dotyczący routingu w 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 -->

Do rozważenia są 32 ścieżki ... W tym przypadku BGP wybrał wersję 4.0.0.0/9 przez 4.69.184.193 (zwróć uwagę bestna wpis RIB). W tym przypadku BGP wybrał tę opcję, ponieważ ta trasa ma najkrótszą listę ścieżek AS. Jednak nie wszystkie trasy będą preferowane przez AS3356 (dołączony do R1). Niektóre mogą być preferowane poza R3 (przez AS7660). iBGP daje możliwość poznania (w R2), którą drogą wybrać najkrótszą ścieżkę 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 i R3 mają pełne oczka iBGP. Gdy iBGP ogłasza trasę, następny przeskok pozostaje niezmieniony . Oznacza to, że muszę nosić podsieć dla 4.69.184.193 w 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>

Tak więc, gdy pakiet dla 4.2.2.2 dociera do R2, R2 wysyła go na Serial2 / 1, ponieważ tam iBGP mówi nam, że jest następny przeskok.

Mike Pennington
źródło
Nie jestem pewien, czy rozumiem tę część: „iBGP jest wymagany, chyba że jesteś skłonny do redystrybucji wszystkich tras poznanych przez eBGP”. Jeśli mamy dwa graniczne routery eBGP, router A nie będzie wiedział, jakie trasy nauczył się router B, i odwrotnie. Muszą jakoś wymieniać informacje, co zwykle odbywa się za pomocą iBGP. Jak wykorzystasz do tego eBGP? Nie jestem pewien, w jaki sposób eBGP może uświadomić A i B trasy, których nauczył się drugi router.
user4205580
Oświadczenie masz na myśli zakłada, że masz jakieś głośniki non-eBGP. Zakładając, że nie możesz po prostu żyć z domyślnymi trasami do swoich up-streamów eBGP, w tym momencie możesz: A) redystrybuować prefiksy eBGP w swoim IGP (zwykle zły pomysł) lub B) używać iBGP. Moja odpowiedź przez większość czasu wyjaśnia, dlaczego iBGP jest przydatny.
Mike Pennington
10

IGP zwykle jest oparty na stanie łącza OSPF lub ISIS, co daje nam wszystkie informacje o sieci, każdy zna sieć z punktu widzenia każdego, co pozwala na bardzo interesujące opcje konwergencji i inżynierii ruchu.

BGP jest zasadniczo wektorem odległości, zna bardzo ograniczony obraz całej sieci. BGP bardzo dobrze radzi sobie z filtrowaniem i modyfikowaniem informacji o routingu.

Protokół stanu łącza jest dość drogi w porównaniu do wektora odległości, skalowanie go do rozmiaru INET DFZ byłoby dość problematyczne.

Tak więc powodem, dla którego mamy jedno i drugie, jest to, że w obrębie jednej konkretnej sieci mamy wystarczająco niską złożoność, aby obsłużyć ją za pomocą protokołu stanu łącza, który pozwala nam uzyskać wszystkie zalety wysokiego stopnia znajomości sieci.
Ponieważ jednak nie skaluje się do rozmiaru Internetu, potrzebujemy innej sieci, aby połączyć te wyspy o stanie łącza.

Możesz w swojej sieci przenosić wszystkie prefiksy (w tym klienta) w IGP, ale będzie to miało negatywny wpływ na wydajność IGP, podczas gdy wszystkie zalety konwergencji i TE można uzyskać po prostu przenosząc adresy sprzężenia zwrotnego podstawowych routerów. Dodanie prefiksów klienta do IGP tylko pogarsza wydajność sieci, czyniąc IGP niepotrzebnie złożoną.

iti
źródło
1
BGP to protokół wektora ścieżki , który nie jest tym samym, co protokół wektora odległości
Mike Pennington,
3
Wektor ścieżki jest zasadniczo szczególnym przypadkiem wektora odległości. Ważne jest, aby zdać sobie sprawę, że są one bardzo podobne pod względem złożoności i kosztów, podczas gdy stan łącza jest zupełnie inny. Z książki BGP Sama Halabiego i Danny'ego McPhersonsa, strona 98 „Ta sekcja nie byłaby kompletna bez wspomnienia, że ​​BGP należy do kategorii wektora odległości”
ytti
2
Wektor ścieżki jest podobny, ale wciąż inny algorytm. Możesz przeczytać więcej na ten temat w książce Danny'ego McPhersona i Russa White'a, Practical BGP , opublikowanej w 2004 r. Link do telefonu komórkowego
Mike Pennington
2
Która strona twierdzi, że BGP nie jest wektorem odległości?
ytti
2
Ścieżka AS jest wektorem odległości. Tak, możesz manipulować wyborem ścieżki opcjonalnie również przy użyciu innych parametrów. Więc Sam i Danny dodają, że jest to wektor ścieżki oprócz bycia wektorem odległości, całkowicie podzielam ich pogląd na ten temat. To może być fajny sposób na wypicie kufla, aby spierać się w tej sprawie, ale mało konstruktywny.
ytti
7

Jednym z powodów, które widziałem dość często, jest klarowność: wszystkie trasy są prowadzone w ramach jednego protokołu routingu (BGP), IS-IS, OSPF lub RIP są używane tylko dla zapewnienia sąsiedztwa. W rezultacie nie ma potrzeby redystrybucji tras z jednego protokołu routingu na inny.

Teun Vink
źródło
3

iBGP nie jest tak naprawdę używany do routingu wewnętrznego, jest używany przez wszystkie routery eBGP do udostępniania tras.

Np .: Jeśli korzystasz z 3 innych sieci, chcesz, aby wszystkie routery eBGP znały trasy odebrane przez inne, aby mogły rozpowszechniać te informacje w razie potrzeby / potrzeby (otwierając w ten sposób możliwość korzystania z tranzytu przez Twojego partnera) ty)

Remi Letourneau
źródło