Sesja bgp między dwoma route-reflektorami

Problemy związane z routingiem

Moderatorzy: mikrobi, aron, garfield, gangrena, Seba

Wiadomość
Autor
felix
wannabe
wannabe
Posty: 96
Rejestracja: 13 lis 2014, 21:46

Sesja bgp między dwoma route-reflektorami

#1

#1 Post autor: felix » 27 lis 2018, 00:20

Cześć. Interesuje mnie jakie jest prawidłowe podejście do tematu sesji bgp między routerami gdy mamy do dyspozycji tylko dwa porty. Zestawienie sesji jednym portem lub drugim portem będzie narażała nas na wiadome problemy w przypadku awarii któregoś z nich. Czy ogólnie stosowaną praktyką jest zestawienie dwóch sesji, czy uruchomienie protokołu igp, a dopiero na tym bgp ? Dzięki za podpowiedź.

lbromirs
CCIE
CCIE
Posty: 3971
Rejestracja: 30 lis 2006, 08:44

Re: Sesja bgp między dwoma route-reflektorami

#2

#2 Post autor: lbromirs » 27 lis 2018, 08:46

BGP nie uruchamia się na IGP. BGP wykorzystuje informacje z IGP lub routingu statycznego, żeby znaleźć trasę do sąsiada (a) oraz do next-hopów (b).

Co do RRów, sesje zestawia się między loopbackami a nie adresami na interfejsach fizycznych. Wynika to z chęci zapewnienia maksymalnej stabilności, a w środowiskach VPNowych również szczególnej roli równoważności router-id z miejscem generowania etykiet lub next-hopów. Dostępność interfejsów fizycznych nie ma wtedy takiego znaczenia - byleby jakaś była (chociaż jeden interfejs działający w domenie wewnętrznej do komunikacji z resztą routerów BGP).

felix
wannabe
wannabe
Posty: 96
Rejestracja: 13 lis 2014, 21:46

Re: Sesja bgp między dwoma route-reflektorami

#3

#3 Post autor: felix » 27 lis 2018, 10:00

Wszystko się zgadza i jest dla mnie znane i zrozumiałe, ale chciałem się dowiedzieć, czy są jakieś best practices mówiące, że lepiej jest użyć protokołu igp dla wskazania tras do sąsiadów, czy może dublowanie sesji i zestawienie ich z/do adresów obu interfejsów (bo jest taka możliwość jeżeli chodzi o L2). Nie dodałem jeszcze istotnej informacji, że między routerami znajdują się przełączniki, które mogą spowodować brak komunikacji między RR mimo podniesionych portów w kierunku routerów więc routing statyczny odpada, chyba że jakiś tracker z ipsla. Oba routery mają też pełne tablice routingu więc trochę mało optymalnie byłoby zestawiać jedną sesję via port1 i drugą sesję via port2.

Jak to robią CCIE ? :)

lbromirs
CCIE
CCIE
Posty: 3971
Rejestracja: 30 lis 2006, 08:44

Re: Sesja bgp między dwoma route-reflektorami

#4

#4 Post autor: lbromirs » 27 lis 2018, 11:15

No to jeszcze raz i od początku.

Po pierwsze, Route Reflector ma bardzo konkretną rolę w sieci. Nie stawia się RRa na pierwszym lepszym złomie ściągniętym z półki, bo może się to bardzo przykro zemścić. RR mają zwykle jeden interfejs do sieci, bo jeśli już dbasz o redundancje, dostawisz zaraz gdzieś obok drugiego RRa i ten jeden interfejs tak bardzo Cię nie boli (jego awaria).

Każdy z routerów (klientów RRa) będzie podłączony do obu RRów - żeby zapewnić redundancje.

Nikt normalny nie zrobi routingu statycznego wzajemnie na siebie pomiędzy RRami ani żadnych trackerów IP SLA... od tego jest routing. Podkładem dla BGP jest IGP... Są wyjątki od tej reguły (np. RFC 7938 ze wszystkimi konsekwencjami), ale nie dla typowej sieci wykorzystującej BGP tylko w sytuacjach, gdy "wiesz co robisz" (i wtedy nie zadajesz takich pytań).

Sesje zestawia się jedną, między loopbackami - już pisałem. Możesz ją sobie zabezpieczyć BFD, ale nikt tego nie robi - bo nie ma potrzeby. Każdy z klientów RRów utrzymuje sesje do przynajmniej dwóch, zapewniając redundancję w ten sposób. Ewentualny pad RRa nie jest w tej sytuacji tak bolesny, bo po pierwsze, dzięki istnieniu mechanizmów takich jak AddPath zachowujesz redundancję ścieżek od klienta RR do dowolnego prefiksu u siebie i poza własnym ASNem, a po drugie - RR podaje tylko trasy, a nie uczestniczy w forwardowaniu ruchu (jeśli to sieć MPLS/SR, jeśli zwykłe transportowe IPv4/IPv6 ten punkt trzeba dokładnie zweryfikować).

felix
wannabe
wannabe
Posty: 96
Rejestracja: 13 lis 2014, 21:46

Re: Sesja bgp między dwoma route-reflektorami

#5

#5 Post autor: felix » 27 lis 2018, 12:39

Dzięki za wyczerpującą odpowiedź, o to mi chodziło.

Kod: Zaznacz cały

Sesje zestawia się jedną, między loopbackami - już pisałem. Możesz ją sobie zabezpieczyć BFD, ale nikt tego nie robi - bo nie ma potrzeby. Każdy z klientów RRów utrzymuje sesje do przynajmniej dwóch, zapewniając redundancję w ten sposób. Ewentualny pad RRa nie jest w tej sytuacji tak bolesny, bo po pierwsze, dzięki istnieniu mechanizmów takich jak AddPath zachowujesz redundancję ścieżek od klienta RR do dowolnego prefiksu u siebie i poza własnym ASNem, a po drugie - RR podaje tylko trasy, a nie uczestniczy w forwardowaniu ruchu (jeśli to sieć MPLS/SR, jeśli zwykłe transportowe IPv4/IPv6 ten punkt trzeba dokładnie zweryfikować).
Mówimy o dwóch routerach u ISP ustawionych na brzegu sieci, są to routery transportowe posiadające pełne tablice Internetu, ale pełnią też funkcję RR dla sieci ISP, aby była łatwo skalowalna, a ruch wewnętrzny zamykał się między routerami agregującymi klientów i usługi. Sieć L2 jest zbudowana w ten sposób, że istnieje możliwość awarii sesji pomiędzy RR i jednoczesnej awarii sesji do części routerów będących klientami RR. W takiej sytuacji jeżeli pakiet zaadresowany do klienta A wróci przez router RR1 to ten może nie mieć trasy do tego klienta, bo nie ma sesji do drugiego RR i do routera na którym klient A jest agregowany. Można to nazwać sytuacją awarii w dwóch punktach sieci, ale w tej topologii L2 występuje ona łącznie. Zabezpieczenie L2 przez lacp jest w tym przypadku niemożliwe, ale routery mogą otrzymać komunikację L2 między interfejsami którymi są zestawione sesje do Internetu - stąd taki pomysł i szukam porady fachowców, którzy go zbesztają i pokażą słabe punkty.

Awatar użytkownika
konradrz
CCIE
CCIE
Posty: 347
Rejestracja: 23 sty 2008, 14:21
Lokalizacja: Singapore, SG
Kontakt:

Re: Sesja bgp między dwoma route-reflektorami

#6

#6 Post autor: konradrz » 27 lis 2018, 13:19

felix pisze:
27 lis 2018, 12:39
Sieć L2 jest zbudowana w ten sposób, że istnieje możliwość awarii sesji pomiędzy RR i jednoczesnej awarii sesji do części routerów będących klientami RR.
W sensie, wszyscy są wpięci w jeden słicz, i jak ten pieprznie to nikt nikogo nie widzi? :)
felix pisze:
27 lis 2018, 12:39
W takiej sytuacji jeżeli pakiet zaadresowany do klienta A wróci przez router RR1 to ten może nie mieć trasy do tego klienta, bo nie ma sesji do drugiego RR i do routera na którym klient A jest agregowany.
Zaraz, a ten router klienta A to nie miał sesji do obu RR?
Zaś tutaj masz przykłady, jak lepiej nie konfigurować (bo co pójdzie źle), a tu jak ładnie to robić. Jeśli już znałeś, to pardon.

felix
wannabe
wannabe
Posty: 96
Rejestracja: 13 lis 2014, 21:46

Re: Sesja bgp między dwoma route-reflektorami

#7

#7 Post autor: felix » 27 lis 2018, 14:03

Znałem, ale dzięki każda podpowiedź jest dobra, żeby nie robić czegoś na marne gdy na końcu może okazać się to klapą :)

Switche są 2, a połączenie między nimi jedno i to jest ból. Jeden rr podłączony do jednego switcha, drugi do drugiego. Routery klienckie rr również podłączone pod jeden lub drugi switch. Chciałbym to zrobić "ładnie" ale koszt drugiego łącza między switchami uniemożliwia mi to. Dlatego szukam jakiegoś bezpiecznego ominięcia kosztów, żeby mimo rozłączenia się przełączników ruch odbywał się w sposób niezakłócony. Pewnie mogłem od razu to napisać.

Awatar użytkownika
drake
CCIE
CCIE
Posty: 1442
Rejestracja: 06 maja 2005, 01:32
Lokalizacja: Dortmund, DE

Re: Sesja bgp między dwoma route-reflektorami

#8

#8 Post autor: drake » 27 lis 2018, 19:21

Jak ci ten link miedzy switchami L2 padnie, to juz nie bedzie drogo :) Zycie...
Never stop exploring :)

felix
wannabe
wannabe
Posty: 96
Rejestracja: 13 lis 2014, 21:46

Re: Sesja bgp między dwoma route-reflektorami

#9

#9 Post autor: felix » 27 lis 2018, 20:16

Ja to wiem, właściciel systemu też zna dobrze sytuację, ale sam wiesz jak jest. Chciałem mimo wszystko oszczędzić sobie roboty gdy prędzej czy później taka awaria się wydarzy. Albo sobie podaruję te kombinacje, albo uruchomię ospf`a i bgp na loopbackach. Pomiędzy routerami będzie nexthop-self więc chyba powinno to zadziałać jak należy jeżeli interfejsy udźwigną ruch. Dzięki za pomoc.

ODPOWIEDZ