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.
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.
Odpowiedzi:
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?
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).
1 Skalowalność :
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.
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ą.
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.
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)