Route-reflector - dystrybucja next-hop

Wiadomość

qrczak · #1

Witam,

Ćwiczę sobie wariant z wdrożeniem w sieci route-reflectora. W zasadzie wszystko działa fajnie, ale chyba trochę mi umknęła kwestia jak intepretowana jest informacja o adresie next-hop. Poniżej schemat labu:

Obrazek

Na routerze B3 sprawdzam sobie tablicę routingu i otrzymuję wynik:

Kod: Zaznacz cały

B3#sh ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 12 subnets, 3 masks
O        10.170.0.0/30 [110/3] via 10.170.123.2, 2d17h, GigabitEthernet0/2
                       [110/3] via 10.170.23.2, 2d17h, GigabitEthernet0/1
O        10.170.10.0/30 [110/2] via 10.170.123.2, 2d17h, GigabitEthernet0/2
O        10.170.11.0/30 [110/2] via 10.170.23.2, 2d20h, GigabitEthernet0/1
C        10.170.23.0/29 is directly connected, GigabitEthernet0/1
L        10.170.23.3/32 is directly connected, GigabitEthernet0/1
O        10.170.80.31/32 [110/3] via 10.170.23.2, 2d20h, GigabitEthernet0/1
O IA     10.170.80.32/32 [110/2] via 10.170.23.2, 2d20h, GigabitEthernet0/1
C        10.170.80.33/32 is directly connected, Loopback0
O        10.170.80.41/32 [110/3] via 10.170.123.2, 2d17h, GigabitEthernet0/2
O IA     10.170.80.42/32 [110/2] via 10.170.123.2, 2d17h, GigabitEthernet0/2
C        10.170.123.0/29 is directly connected, GigabitEthernet0/2
L        10.170.123.3/32 is directly connected, GigabitEthernet0/2
      172.20.0.0/32 is subnetted, 1 subnets
C        172.20.10.1 is directly connected, Loopback2
      192.168.31.0/32 is subnetted, 1 subnets
B        192.168.31.1 [200/0] via 10.170.80.31, 2d16h
      192.168.32.0/32 is subnetted, 1 subnets
B        192.168.32.1 [200/0] via 10.170.80.32, 2d16h
      192.168.33.0/32 is subnetted, 1 subnets
C        192.168.33.1 is directly connected, Loopback1
      192.168.41.0/32 is subnetted, 1 subnets
B        192.168.41.1 [200/0] via 10.170.80.41, 2d16h
      192.168.42.0/32 is subnetted, 1 subnets
B        192.168.42.1 [200/0] via 10.170.80.42, 2d16h
B3#

Na każdym routerze Loopback 0 służy za ID i source IP dla BGP oraz należy do OSPF. O Loopbacku1 na każdym routerze wie tylko BGP.
Sprawdzam trasę do Loopbacka 1 routera B1 i widzę, że next-hop wskazuje na jego Loopback 0. (Piąty wpis od dołu na wydruku)
To, że sam adres loopbacka 0 jest osiągalny wszędzie, to jasne. Ale skoro B3 ma ten IP jako next-hop, to jak będą adresowane ramki a jak pakiety do tego celu, skoro po drodze jest jeszcze B2? Czy B3 oryginalną informację o next-hop pobraną z BGP przeanalizuje ponownie jeszcze na podstawie bazy z OSPF, traktując Loopback B1 jako cel i dopiero next-hop dla tego celu (interface na B2 w stronę B3) ustawi jako destination w ramce ethernetowej? Czy router B2 będzie musiał ponownie powtórzyć tę operację ze sprawdzeniem najpierw w tablicy BGP a potem we wpisach uzyskanych od OSPF?

martino76 · #2

Witam,

Kod: Zaznacz cały

      
192.168.31.0/32 is subnetted, 1 subnets
B        192.168.31.1 [200/0] via 10.170.80.31, 2d16h

Tutaj outout pokazuje, ze 192.168.31.1 jest dostępne poprzez NH 10.170.80.31, wiec na B3 będziesz miał robiony recursive lookup

zobacz sobie

Kod: Zaznacz cały

show ip cef 192.168.31.1 detail

Zobacz sobie

link i poczytaj.

Pozdro,

qrczak · #3

Dzięki. Właśnie sam doszedłem do tego recursive table lookup

. Zapewne w linku, który podesłałeś znajdę odpowiedź na kolejne pytanie, ale jeszcze się tu tak głośno zastanowię - czy next-hop-self by default wszędzie na iBGP będzie sprawę upraszczał, czy też niesie za sobą jakieś nowe zagrożenia?

martino76 · #4

qrczak pisze:Dzięki. Właśnie sam doszedłem do tego recursive table lookup . Zapewne w linku, który podesłałeś znajdę odpowiedź na kolejne pytanie, ale jeszcze się tu tak głośno zastanowię - czy next-hop-self by default wszędzie na iBGP będzie sprawę upraszczał, czy też niesie za sobą jakieś nowe zagrożenia?

Z tego co ja wiem to iBGP nie zmienia NH, kiedy otrzymuje prefiks od eBGP i szczerze mówiąc nigdy nie spotkałem się z tym by ktoś próbował zmienić ten atrybut na iBGP, gdyż nie ma to moim zdaniem najmniejszego sensu. Kiedy eBGP rozgłasza prefiks do iBGP i używasz NH self na eBGP to zazwyczaj iBGP peer posiada wiedze o tym jak dostać się do NH poprzez właśnie IGP.

PS Nigdy nie testowałem czy można zmienić NH atrybut na iBGP i zastanawiam sie czy IOS pozwoli na taka zmianę.

Pozdro,

Cinek · #5

Mozesz na RR ustawic route-mapy ktora "manualnie" zmienia NextHop odbijanych prefixow. Czy ma to sens ? Jak to zwykle bywa w sieciach - zalezy co chcesz przez to osiagnac

martino76 · #6

Cinek pisze:Mozesz na RR ustawic route-mapy ktora "manualnie" zmienia NextHop odbijanych prefixow. Czy ma to sens ? Jak to zwykle bywa w sieciach - zalezy co chcesz przez to osiagnac

Chyba, że ktoś chce by RR uczestniczył actywnie w forwarding ale zazwyczaj RR jest poza forwarding path i sadze, że nie ma sensu by brał udział aktywnie w przekazywaniu pakietów, ale tak jak napisałeś wszystko zależy co chcesz zrobić.

horac · #7

Przeciez brak zmiany NH na RR w IBGP to zabezpieczenie przed tym zeby RR nie byl uzywany w data plane tylko control plane. Po co obciazac RR dodatkowo forwardowaniem ruchu.

Szczegolnym przypadkiem jest inter-AS option C, gdzie mozna ale nie trzeba zmieniac NH ale to dotyczy EBGP

lxs · #8

W ogole dla tego przypadku route-reflector nie pelni zadnej roli. RR jest rozwiazaniem, ktore omija potrzebe full mesha dla iBGP. Zamiast kazdy z kazdym jest kazdy z RR. Tutaj z RR czy bez, to kazdy ruter ma po jednej sesji sasiedzie.
Tak wlasnie dziala iBGP - routery rozwiazuja next-hopa przez protokol IGP (OSFP, EIGRP, static...)

I pytanie co chcesz osiagnac w tym cwiczeniu? Wlaczenie nexh-hop self dobre jest w przypadku jak chcesz wylaczyc synchronizacje, ale potrzebujesz wtedy wlasnie full-mesh i peeringu kazdy z kazdym. Jak dodasz RR, to uproscisz iBGP, co jest dobrym wyjsciem, ale caly ruch przechodzi przez router RR. Nie ma uniwersalnego optymalnego rozwiazania, bo to zalezy od architektury. Z tego co widzialem, to raczej inzynierowie staraja sie unikac iBGP jako wewnetrznego protokolu routingu, bo zwyczajnie nim nie jest.

qrczak · #9

Na razie zwyczajnie testuję sobie na sucho zachowanie RR i próbuję różne scenariusze, za chwilę przetestuję także dwa RR z różnymi cluster ID.

Co chcę osiągnąć w sieci produkcyjnej - dokładnie to do czego RR jest stworzony - zmniejszyć ilość relacji, bo do tej pory mam 8 routerów, a będzie więcej. Cóż, ktoś tak zaprojektował, więc z tym nie dyskutuję, ale chcę zaproponować konstruktywną alternatywę.

Sam RR na chwilę obecną nie wymaga nawet za bardzo szczególnego komentarza, bo wdrożenie wydaje się być proste, o ile IGP działa poprawnie.
Po lekturze linku poleconego przez martino76, zastanawiam się nad tematyką pośrednio z RR związaną - jaki wybrać IGP. Na razie mam tylko iBGP, bo jest full mesh, ale do RR będzie jakiś sensowny IGP potrzebny. I tu pojawiają się kolejne pytania:
- wykluczając zamknięte standardy - czy jest sens dobrać IGP w odniesieniu do najmniej elastycznego routera, czy trzymać się twardo założeń dla większości, a dla gorzej wyposażonych stosować redystrybucję? Konkretnie - widzi mi się IS-IS, choćby ze względu na ipv6, ale mam kilka urządzeń nieciscowych i nie obsługujących IS-IS, a jedynie OSPF.
- co z czasami zbieżności w iBGP, w zależności od użytego IGP? Czy to zawsze zależy wyłącznie od tego jaki BGP ma update delay, czy też któreś protokoły routingu działają proaktywnie i są w stanie informować o tym BGP? Np EIGRP?
- ogólnie - czy przejmować się tym, że OSPF wymagałby uruchomienia dwóch procesów, równolegle dla v4 i v6, czy to w ogóle nie jest temat jeśli chodzi o utylizację cpu i pamięci? (jak mówiłem, głównie transportowe point-to-point chcę tam zainstalować)

Itd...

horac · #10

Czasy zbierznosci zaleza od wielu rzeczy. Po pierwsze masz cos takiego jak BGP PIC, po drugie masz cos takiego jak FRR dla IGP i dla MPLS. Wszystkie te technolgie zapewniaja konwergencje ponizej sekundy. Pytanie tylko jaki jest cel twojej sieci. Co chcesz przez nia pchac, jaki ruch czy ruch wrazliwy na opoznienia jak video/voice czy same dane. Nie ma jednego uniwersalnego rozwiazania na wszystko.

Sprawa wyboru IS-IS i OSPF to kwestia wsparcia o ktorym pisales w twoim przypadku. Skoro czesc urzadzen nie wspiera ci IS-IS to chyba wybor jest oczywisty. Pomysl tylko jak zbydowac OSPF czy jako plaska area 2 co umozliwia lepszy MPLS-TE itp, czy z podzialem na area, gdzie bedzie wiecej kombinacji w zaleznosci od wymagan.

OSPFv3 tez wspiera ipv6 ale potrzebuje osobnego stosu. No i pomysl czy chcesz miec CORE z lat 2000 czy z 2015 opartego o MPLS i pozbyc sie zaleznosci topologii fizycznej w przypadku Route Reflectorow. Powinienes pozbyc sie BGPa z core i zostawic go tylko na brzegach i caly ruch ipv4 tunelowac MPLSem. Takie rozwiazanie pozowli ci pozniej dodac kolejne uslugi jak L3 VPN i L2 VPN (Kwestia kolejnego stosu protokolow na routerach PE). Routery P w srodku Core beda mialy jedynie LDP i IGP. Pomysl, przemysl i zrob

martino76 · #11

horac pisze: OSPFv3 tez wspiera ipv6 ale potrzebuje osobnego stosu

Nie wiem czy nie miałeś na myśli, ze wspiera również AF IPv4. Oryginalnie OSPFv3 wspierał tylko IPv6 ale po dodaniu wsparcia dla AF wspiera teraz również IPv4.

qrczak jeśli cześć urządzeń nie spiera IS-IS to tak jak napisał horac idź w stronę OSPF a rozwiązań jest kilka wszystko zależy od tego co chcesz osiągnąć i co będziesz chciał osiągnąć w przyszłości.

Pozdro,

qrczak · #12

W zasadzie największym niewspierającym jest firewall w stronę DMZ... tam się za wiele nie dzieje, więc jeszcze byłbym w stanie przełknąć redystrybucję w jednym miejscu.

horac · #13

martino76 pisze: Nie wiem czy nie miałeś na myśli, ze wspiera również AF IPv4. Oryginalnie OSPFv3 wspierał tylko IPv6 ale po dodaniu wsparcia dla AF wspiera teraz również IPv4.

Chodzilo to ze OSPFv3 jest kompletnie nowym protokolem, bo nie dalo sie upchac w dotychczasowe pakiety OSPFv2 wsparcia dla IPv6. IS-IS ma dual-stack ipv4/ipv6 i wszystko upchniete w TLV. Chyba ze cos sie zmienilo dla OSPFv3 i mam nie zaktualizowana baze danych.

qrczak pisze:W zasadzie największym niewspierającym jest firewall w stronę DMZ... tam się za wiele nie dzieje, więc jeszcze byłbym w stanie przełknąć redystrybucję w jednym miejscu.

Nie odpala sie IGP na firewallu. Takze to nie problem. W dodatku zawsze mozesz miec go w transparent i routing z glowy, jesli jego funkcja to tylko filtracja

qrczak · #14

horac pisze:Pomysl, przemysl i zrob

Z tym to trochę jest tak, że z jednej strony mogę mieć niezły budżet na sprzęt, a z drugiej, głównie z racji topologii niespecjalnie jest sens iść w MPLS. Nawet bym chciał, ale wydaje mi się to (na razie) strzelaniem do muchy z armaty.

Będę miał prawdopodobnie 2x asr9010, więc powinien być jeden porządny cluster. Warstwę dystrybucji mam praktycznie wyłącznie na switchach, więc też jakieś 903 albo 920 mogłyby je zastąpić. Ale tu właśnie pojawia się kwestia RR, którą obecnie obmyślam. Ruch głównie generują prywatni użytkownicy oraz garść biznesowych. Na razie koncepcja jest, by zachować topologię hub and spoke, choć ring jest jak najbardziej możliwy. Dla wyjątkowych przypadków biznesowych jest idea by dawać małe routery cisco jako ONT dla FTTH i ewentualny backup po docsis, stąd myślałem żeby dociągnąć iBGP także do klienta.

horac · #15

Rezygnujac z MPLS i chcac miec klaster RR musisz zadbac o odpowiednia topologie fizyczna. Najlepiej jak kazdy client mialby bezposrednio link do RR fizyczny. Nigdy nie dopusc by sesja od klienta do RR zapinala sie przez innego klienta bo awaria 1 spowoduje awarie obu a w skrajnych przypadkach petle.

Jako przyklad ze MPLS jest prawie zawsze dobrym rozwiazaniem podam ci swoj:

Jest sobie Data Center.. 2x Core n7k. Jes to srodowisko typu shared miedzy wielu klientow. Wszystko na VRFach + VDC. Z operatorem mam jedynie Inter-AS option A. Natomiast rozpatrujac skalowalnosc sesji iBGP + VRF + troubleshooting i utrzymanie tego zdecydowalem sie na sesje MPLS L3 VPN miedzy dwoma Nexusami. Po 1 dodanie kolejnego peera to bedzie kwestia skonfigurowania RR L3 VPN, po 2 ilosc sesji iBGP MP-BGP do przenoszenia prefiksow miedzy VRFami wynosi 1. Kazda kolejna sesja to bedzie L3 VPN albo do RR albo full-mesh co i tak ulatwia skalowalnosc w przeciwienstwie do 200-300 sesji IBGP per VRF. Nawet dodanie RR ipv4 i tak by wymagalo tyle samo sesji do RR od kazdego klienta i ograniczylo by jedynie full-mesh

Takze.. nigdy nie jest za malo urzadzen do MPLsa, to tylko technologia ktora moze badz nie musi znalesc zastsosowanie w okreslonym rozwiazaniu