20T16 Co To Jest SD-WAN – Routing

W tym odcinku pokazuję jak łączyć sieci programowalne SD-WAN z pozostałą klasyczną częścią infrastruktury.
👉Dynamiczna redystrybucja tras routingu.

Jak działa routing w SD-WAN?

Interesuje Cię odpowiedź na to pytanie?

To jest odcinek dla Ciebie.

Przedstawiam najważniejsze założenia redystrybucji routingu między sieciami SD-WAN i resztą infrastruktury.

Pokazuję jak automatycznie propagowana jest informacja o sieciach, w dynamicznym środowisku SD-WAN.

Dołącz do naszej strony fanów na Facebook:

Grupa na facebooku

Wersja podcast i transkrypcja HTML:
http://netadminpro.pl

#netadminpro_pl #sdwan

Więcej miejsc do posłuchania:

Spotify

 

Transkrypcja filmu:

0:00:01.640,0:00:04.420
Jeżeli interesuje Cię temat: jak łączyć sieci
0:00:04.420,0:00:06.640
SD-WAN-owe z sieciami klasycznymi.
0:00:07.120,0:00:10.240
Jak routing może przekazywać informacje
0:00:10.245,0:00:12.665
pomiędzy tymi dwoma różnymi światami.
0:00:12.980,0:00:14.620
To ten odcinek jest dla Ciebie.

Co To Jest SD-WAN –  RoutinG

0:00:15.420,0:00:18.160
Nazywam się Darek Koralewski i dzisiaj opowiem
0:00:18.160,0:00:21.580
o tym, jak łączyć routing pomiędzy rozwiązaniami
0:00:21.580,0:00:24.760
SD-WAN-owymi a klasyczną siecią
0:00:24.760,0:00:26.400
i routingiem L3.
0:00:26.845,0:00:29.965
Zacznijmy od tego, jak wygląda
0:00:29.965,0:00:33.520
połączenie tej lokalizacji zdalnej
0:00:33.700,0:00:36.840
przez wiele tuneli, które w SD-WAN-ie funkcjonują.
0:00:37.600,0:00:40.605
Czyli jak mamy sobie tutaj ten nasz komputer
0:00:40.605,0:00:44.540
I on chce wyjść, załóżmy na początku, do Internetu.
0:00:45.280,0:00:49.180
No to kieruje swój pakiet tutaj, na bramę.
0:00:49.680,0:00:52.660
Ta brama oczywiście, standardowo, jest domyślna.
0:00:52.660,0:00:55.200
No i tu, w zależności od naszej polityki,
0:00:55.260,0:00:58.000
ten ruch może wyjść lokalnie
0:00:58.000,0:01:00.255
do Internetu, czyli za NAT-a,
0:01:00.260,0:01:02.120
czyli może zostać zaNATowany
0:01:02.140,0:01:04.960
i wysłany tutaj do Internetu.
0:01:05.800,0:01:09.220
Jeżeli ruch jest kierowany do centrali.
0:01:09.220,0:01:11.575
Czyli tutaj w naszym przypadku będziemy mieli
0:01:11.580,0:01:13.500
sieć 10.10.10.x
0:01:14.280,0:01:17.900
No to oczywiście zostanie skierowany do tunelu.
0:01:18.500,0:01:20.400
Jak popatrzymy sobie na to
0:01:20.700,0:01:23.060
jakie tunele mamy tutaj dostępne
0:01:23.060,0:01:27.200
no to będziemy mieli dla każdego koncentratora VPN-owego
0:01:28.625,0:01:31.585
dostępne dwa tunele, bo mamy dwóch operatorów.
0:01:31.585,0:01:35.055
Czyli w sumie tych tuneli będziemy mieli 4.
0:01:36.060,0:01:39.880
Teraz pakiet, który będzie szedł do sieci 10.10.10,
0:01:39.880,0:01:41.800
będzie wychodził tutaj na bramę
0:01:41.865,0:01:44.695
do routera w lokalizacji.
0:01:44.920,0:01:48.020
A następnie według różnych algorytmów,
0:01:48.020,0:01:50.260
o których mówiłem w poprzednim odcinku,
0:01:50.260,0:01:52.660
będzie sterowany do danego tunelu.
0:01:52.860,0:01:55.260
Najczęściej wykorzystywany tryb
0:01:55.260,0:01:59.960
to jest per sesja, czyli dla danej sesji wybierany jest jeden z tuneli.
0:01:59.960,0:02:03.620
Załóżmy, że to będzie tunel, który prowadzi przez sieć MPLS-ową,
0:02:03.620,0:02:06.340
czyli będzie szedł tutaj w lewą stronę.
0:02:06.740,0:02:09.740
Dojdzie do tego koncentratora VPN-owego,
0:02:09.800,0:02:11.100
pierwszego.
0:02:11.400,0:02:15.120
No i tutaj, ten koncentrator powinien wiedzieć
0:02:15.460,0:02:17.540
na jakiejś podstawie,
0:02:17.540,0:02:22.280
gdzie ma wysłać pakiet do sieci 10.10.10.x
0:02:22.660,0:02:25.580
Oczywiście tutaj najczęściej stosujemy
0:02:25.800,0:02:29.900
protokół dynamiczny, czyli najczęściej OSPF
0:02:32.140,0:02:33.680
lub też BGP.
0:02:34.220,0:02:37.900
I wykorzystujemy ten dynamiczny protokół
0:02:37.900,0:02:40.880
do tego, żeby przekazywać informacje,
0:02:40.880,0:02:43.940
którym z połączeń powinien ten
0:02:43.940,0:02:45.780
pakiet zostać wysłany.
0:02:46.340,0:02:48.900
Więc na tej podstawie OSPF-a,
0:02:48.900,0:02:52.095
koncentrator VPN-owy wie, że powienien do routera głównego
0:02:52.095,0:02:54.325
w CPD wysłać ten pakiet.
0:02:55.440,0:02:59.200
Ten router główny to jest najczęściej firewall.
0:02:59.200,0:03:02.400
Często to nie jest jeden router,
0:03:02.400,0:03:04.380
tylko to są dwie strefy.
0:03:04.385,0:03:05.365
I to są klastry.
0:03:05.365,0:03:08.265
Więc tymbardziej bazują na dynamicznym routingu.
0:03:08.775,0:03:12.075
Albo mają bezpośrednie połączenie z daną siecią
0:03:12.080,0:03:14.320
farmy serwerów lub danego serwera.
0:03:14.320,0:03:18.480
W związku z tym wiedzą już, gdzie wysłać dany pakiet. Świetnie.
0:03:19.060,0:03:20.760
Teraz popatrzmy sobie
0:03:21.040,0:03:23.900
jak w drugą stronę ten proces powinien zadziałać.
0:03:23.900,0:03:26.585
Czyli ten serwer chce odpowiedzieć teraz
0:03:26.585,0:03:27.960
pakietem do lokalizacji.
0:03:28.140,0:03:32.600
Czyli wysyła pakiet do tego firewall-a centralnego.
0:03:32.840,0:03:36.900
I ten firewall powinien wiedzieć, na podstawie routingu,
0:03:37.420,0:03:39.120
w którą stronę skierować pakiet,
0:03:39.120,0:03:41.500
żeby ten pakiet doszedł do lokalizacji zdalnej.
0:03:42.060,0:03:44.795
Skąd ma wiedzieć ten router,
0:03:44.800,0:03:47.180
gdzie jest dostępna ta lokalizacja zdalna.
0:03:47.340,0:03:51.940
I tutaj jest ciekawy taki mechanizm, który można wykorzystać.
0:03:51.940,0:03:55.740
Mianowicie jak nawiązuje się tunel IPsec-owy,
0:03:56.160,0:03:58.360
to wykorzystywany jest
0:03:58.600,0:04:00.760
taki mechanizm, który
0:04:00.760,0:04:02.800
jest związany z protokołem IKE.
0:04:05.345,0:04:08.585
Ważne, żeby to był protokół IKE w wersji drugiej.
0:04:08.585,0:04:11.840
I w tym protokole jest możliwość
0:04:11.860,0:04:13.980
wysyłania informacji
0:04:13.980,0:04:16.620
dotyczących danej,
0:04:16.820,0:04:19.500
dynamicznie tunelu nawiązywanego
0:04:19.500,0:04:22.440
i sieci, która jest za tym tunelem dostępna.
0:04:22.440,0:04:24.800
Czyli mając tego typu mechanizm,
0:04:25.120,0:04:28.360
na VPNC pojawia się statyczny wpis routingowy,
0:04:28.680,0:04:32.060
który dotyczy sieci, które są związane
0:04:32.060,0:04:35.840
z tunelem IPsec-owym, nawiązanym do tego VPNC.
0:04:35.840,0:04:38.560
Do drugiego VPNC jest podobnie.
0:04:38.560,0:04:41.300
Czyli tutaj też pojawiają się statyczne wpisy
0:04:41.300,0:04:44.860
dla sieci, które są dostępne za tunelem.
0:04:44.860,0:04:47.100
poprzez mechanizm IKE
0:04:50.120,0:04:51.700
w wersji drugiej.
0:04:51.700,0:04:55.040
Ponieważ już wspomnieliśmy o tym, że
0:04:55.040,0:04:58.720
OSPF działa pomiędzy tym routerem centralowym, głównym,
0:04:58.740,0:05:00.340
najczęściej firewallem
0:05:00.960,0:05:04.720
a VPNC, zarówno VPNC 1 jak i 2.
0:05:04.725,0:05:07.765
To te trasy statyczne IKE,
0:05:07.765,0:05:11.200
które funkcjonują na koncentratorach VPNC
0:05:11.200,0:05:13.200
są redystrybuowane
0:05:13.860,0:05:17.620
do tego routera głównego, który
0:05:17.620,0:05:20.120
ma wtedy pełną tablicę routingu.
0:05:20.360,0:05:23.300
No i teraz jeżeli popatrzymy sobie na to,
0:05:23.300,0:05:25.980
jak pakiet wraca od serwera.
0:05:25.980,0:05:29.275
To bazując na tablicy routingu, która jest łącznie
0:05:29.280,0:05:31.420
z redystrybucją staticów IKE
0:05:31.420,0:05:34.340
dostępna na routerze głównym, na tym.
0:05:34.860,0:05:37.420
No to wtedy ten router główny wie,
0:05:37.440,0:05:41.320
do którego koncentratora dany pakiet wysyłać.
0:05:41.320,0:05:43.975
Czyli w tym przypadku będzie ten pakiet wracał
0:05:43.980,0:05:46.460
do tego samego koncentratora
0:05:46.460,0:05:50.180
a koncentrator będzie wysyłał tym samym tunelem.
0:05:50.480,0:05:53.380
Tak, żeby zachować symetryczność sesji.
0:05:53.380,0:05:56.080
Bo każdy firewall, który tutaj będzie działał
0:05:56.080,0:05:59.080
będzie miał wtedy dwukierunkową sesję
0:05:59.080,0:06:02.980
a na tym nam zależy, żeby to działało dwukierunkowo.
0:06:03.240,0:06:06.280
Wiec jeżeli ten pakiet dojdzie sobie tutaj do lokalizacji,
0:06:06.580,0:06:08.600
ten router ma już tę sieć lokalnie,
0:06:08.600,0:06:10.900
więc wyśle do tego komputera.
0:06:11.540,0:06:14.040
Mamy więc scenariusz, który
0:06:14.040,0:06:17.200
w pełni działa, bazując na redystrybucji
0:06:17.240,0:06:21.160
informacji o sieciach zdalnych, bazując na IKE v2.
0:06:21.500,0:06:25.280
Co się stanie, jeżeli będziemy mieli awarię.
0:06:25.820,0:06:28.155
Czyli teraz załóżmy,
0:06:28.160,0:06:30.540
że ulega awarii nam
0:06:30.940,0:06:32.600
koncentrator pierwszy.
0:06:32.880,0:06:36.380
I tutaj możemy, też dwie takie sytuacje wyróżnić.
0:06:36.500,0:06:38.480
Pierwsza sytuacja będzie taka, że
0:06:38.840,0:06:41.320
sam kontroler, czy ten koncentrator
0:06:41.500,0:06:43.795
będzie niedostępny.
0:06:43.800,0:06:46.700
Po prostu ulegnie awarii. Co się wtedy stanie?
0:06:47.620,0:06:49.640
Jeżeli popatrzymy sobie na OSPF-a,
0:06:50.360,0:06:52.760
no to przy awarii tego kontrolera
0:06:52.760,0:06:56.040
sąsiedztwo, które jest pomiędzy tym głównym
0:06:56.120,0:06:59.580
naszym routerem, czyli firewallem w centrali
0:06:59.585,0:07:02.425
a koncentratorem. To sąsiedztwo zniknie.
0:07:02.475,0:07:05.255
No bo po prostu nie ma tego urządzenia.
0:07:05.260,0:07:07.140
To jest jedna możliwość.
0:07:07.140,0:07:10.020
No i co się oczywiście z tym wiąże, znikną wszystkie trasy,
0:07:10.140,0:07:12.520
które były związane z redystrybucją
0:07:12.520,0:07:14.520
przez ten koncentrator.
0:07:14.560,0:07:18.140
Czyli, krótko mówiąc, ten firewall centralny
0:07:18.140,0:07:20.140
nie będzie miał żadnej trasy,
0:07:20.140,0:07:22.420
która prowadzi przez koncentrator właśnie uszkodzony.
0:07:22.580,0:07:25.220
Okej, a co się stanie, jeżeli
0:07:25.220,0:07:27.380
to nie koncentrator będzie uszkodzony,
0:07:27.500,0:07:30.180
a będzie awaria tylko tych
0:07:31.120,0:07:33.500
połączeń do Internetu i do MPLS-a.
0:07:34.560,0:07:37.540
No w takiej sytuacji, będziemy mieli nadal sąsiedztwo
0:07:37.540,0:07:40.680
pomiędzy routerem głównym, czyli firewallem
0:07:40.680,0:07:42.700
a koncentratorem.
0:07:42.700,0:07:45.320
Natomiast nie będziemy mieli żadnych tras IKE,
0:07:45.320,0:07:47.820
no bo nie będzie tuneli nawiązanych, tak?
0:07:47.825,0:07:50.765
Wszystkie uplinki będą niedostępne,
0:07:50.765,0:07:53.320
w związku z tym nie będzie statycznych wpisów,
0:07:53.320,0:07:56.860
które mogły być redystrybuowane do tego routera głównego.
0:07:58.580,0:08:01.400
I na tym firewall-u centralnym
0:08:01.540,0:08:04.040
w takiej sytuacji zostanie tylko
0:08:05.500,0:08:08.920
wpisy IKE z VPNC drugiego.
0:08:09.080,0:08:12.420
Czyli będziemy mieli tylko
0:08:12.620,0:08:15.060
2 tunele spięte z tą lokalizacją
0:08:15.060,0:08:19.100
i redystrybucja trasy, patrząc od strony serwera
0:08:19.100,0:08:20.820
tego tutaj w centrali,
0:08:20.820,0:08:25.400
będzie widoczna tylko przez VPNC 2.
0:08:25.400,0:08:27.740
Jakie jeszcze mamy możliwości
0:08:27.780,0:08:29.660
przekazywania informacji
0:08:29.660,0:08:32.520
i redystrybucji tej informacji routingowej
0:08:32.660,0:08:37.240
pomiędzy lokalizacjami a tą lokalizacją główną.
0:08:37.740,0:08:41.360
Jest jeszcze możliwość wykorzystania orkiestratora.
0:08:41.360,0:08:44.360
Orkiestrator to jest takie zabranie funkcji
0:08:44.360,0:08:47.655
informującej i w lokalizacji i w centrali
0:08:47.655,0:08:50.695
o trasach dostępnych z jednej i z drugiej strony.
0:08:50.700,0:08:53.140
Wyciągnięcie tej informacji centralnej
0:08:53.140,0:08:56.200
do takiego bytu, który jest zupełnie osobny.
0:08:56.320,0:08:59.480
Często się stosuje tego typu konstrukcje
0:08:59.740,0:09:02.220
w rozwiązaniach chmurowych
0:09:02.220,0:09:04.500
wtedy, kiedy mamy możliwość
0:09:04.620,0:09:07.400
podłączenia przez Internet
0:09:07.400,0:09:11.760
jakby control planu, czyli tego całego mechanizmu sterowania SD-WAN-em,
0:09:11.760,0:09:13.935
który jest gotowy w chmurze.
0:09:13.940,0:09:16.760
Wtedy możemy też centralnie z tej chmury
0:09:16.860,0:09:19.780
sterować trasami routingowymi, które
0:09:19.780,0:09:22.680
nam będą potrzebne do tego,
0:09:22.680,0:09:24.780
żeby połączyć centralę z lokalizacją.
0:09:24.900,0:09:28.840
Dzieje się tak. Jeżeli sobie podłączymy
0:09:29.100,0:09:31.360
orkiestrator do tej naszej sieci,
0:09:31.360,0:09:34.460
to ten orkiestrator będzie nam umożliwiał połączenie
0:09:34.460,0:09:40.120
pomiędzy orkiestratorem a każdym z tych koncentratorów VPN-owych.
0:09:42.880,0:09:45.300
To będzie takie kontrolne połączenie,
0:09:45.300,0:09:48.660
czyli cały czas jest nawiązywane połączenie pomiędzy orkiestratorem
0:09:48.660,0:09:50.100
a każdym z tych routerów.
0:09:50.320,0:09:53.340
I orkiestrator będzie wiedział,
0:09:53.340,0:09:56.340
w którym momencie został nawiązany tunel IPSEC-owy
0:09:56.345,0:09:59.485
i będzie również wiedział pomiędzy którą lokalizacją
0:09:59.485,0:10:02.565
a którym koncentratorem VPN-owym w centrali
0:10:02.565,0:10:04.940
te tunele są nawiązane.
0:10:04.940,0:10:10.180
W związku z tym, nie wykorzystujemy już wtedy mechanizmu IKE v2.
0:10:10.520,0:10:12.460
Tylko sam orkiestrator
0:10:12.660,0:10:15.735
nam realizuje tą funkcję, czyli jak
0:10:15.735,0:10:19.085
dowie się o tym, że tunele pomiędzy
0:10:19.085,0:10:23.340
lokalizacją – siecią 10.120.40.x
0:10:23.340,0:10:27.020
zostały nawiązane z VPNC 1 i z VPNC 2,
0:10:27.600,0:10:32.840
to w takiej sytuacji wyśle do poszczególnych
0:10:33.100,0:10:36.040
koncentratorów informację routingową.
0:10:36.560,0:10:40.420
Czyli w ten sposób orkiestrator będzie informował
0:10:40.740,0:10:42.660
te nasze kontrolery
0:10:42.800,0:10:46.060
czy koncentratory VPN-owe – VPNC
0:10:46.485,0:10:49.435
i koncentrator VPN-owy
0:10:49.440,0:10:52.100
czy branch router w lokalizacji
0:10:52.100,0:10:54.540
o tym, jakie sieci w poszczególnych miejscach są istotne.
0:10:54.740,0:10:59.720
Czyli tutaj się pojawi redystrybucja statyczna trasy
0:11:00.260,0:11:09.000
10.120.40.x
0:11:09.280,0:11:13.100
I tutaj też ta redystrybucja może się pojawić.
0:11:13.740,0:11:16.960
Jak zapobiegamy, żeby się jednocześnie nie pojawiła
0:11:16.965,0:11:18.585
z tą samą wagą.
0:11:18.905,0:11:22.225
No po prostu te redystrybucje będą miały przypisane
0:11:22.520,0:11:25.760
różne wartości co do kosztu,
0:11:25.760,0:11:28.940
czyli będą różnicowane w tablicy routingu.
0:11:28.940,0:11:31.320
Dopóki będzie funkcjonowała
0:11:31.320,0:11:34.040
trasa, która ma niższy koszt,
0:11:34.040,0:11:35.520
no to ta będzie preferowana,
0:11:35.645,0:11:38.095
jeżeli ruch będzie wysyłany
0:11:38.095,0:11:41.205
czy przekazywany od strony centrali.
0:11:41.720,0:11:45.020
Czyli ten orkiestrator nam tutaj załatwia
0:11:45.020,0:11:50.080
centralnie tą informację i dystrybucję tej informacji o routingu
0:11:50.220,0:11:52.260
pomiędzy lokalizacjami,
0:11:52.260,0:11:56.040
pomiędzy centralą, bo tutaj warto pamiętać,
0:11:56.640,0:11:58.640
że central może być więcej.
0:11:58.880,0:12:01.160
Czyli w rozwiązaniu SD-WAN-owym,
0:12:01.160,0:12:03.520
zwłaszcza jeżeli zaczynamy mówić o elementach,
0:12:03.520,0:12:06.320
które są takie chmurowe.
0:12:06.320,0:12:08.080
No to mówimy o takiej hybrydzie,
0:12:08.080,0:12:11.900
że część rzeczy mamy w centralnym ośrodku przetwarzania
0:12:12.400,0:12:14.240
w  naszym klasycznym modelu
0:12:14.640,0:12:17.900
a część tych danych mamy przetwarzane w chmurze.
0:12:17.900,0:12:22.700
Czyli na przykład w jakimś AWS-ie czy w innym ośrodku chmurowym.
0:12:22.860,0:12:25.640
No i potrzebujemy przekazać wtedy
0:12:25.640,0:12:29.740
tą informację routingową, w zależności od tego, które systemy mamy gdzie
0:12:29.900,0:12:33.355
W zależności od tego, jaka jest aktualnie sytuacja,
0:12:33.355,0:12:36.055
czy była jakaś awaria, które łącza są preferowane.
0:12:36.145,0:12:39.235
Tą całą politykę routingową budujemy sobie
0:12:39.240,0:12:43.540
w zależności od tego, jaki scenariusz mamy do zrealizowania.
0:12:43.900,0:12:46.895
Cała ta polityka oczywiście musi zawierać
0:12:46.900,0:12:50.340
taką koncepcję braku pojedynczego punktu awarii,
0:12:50.340,0:12:52.660
czyli w ramach dowolnej sytuacji,
0:12:52.660,0:12:54.380
gdzie ta awaria może nastąpić,
0:12:54.380,0:12:57.040
chcemy zapewnić automatyczne przełączenie się ruchu,
0:12:57.040,0:13:01.100
tak żeby niezależnie od tego, w którym miejscu ta awaria nastąpi,
0:13:01.340,0:13:04.795
nie było przerwy w usługach, które dostarczamy.
0:13:04.800,0:13:07.380
Jeżeli masz pytania do tego typu tematów,
0:13:07.380,0:13:09.860
to oczywiście pisz w komentarzu.
0:13:09.860,0:13:13.555
Jeżeli jest to dla Ciebie ciekawe to zostaw łapkę w górę.
0:13:13.560,0:13:18.400
Jest to dla mnie ważny sygnał, że ta treść jest dla Ciebie ciekawa.
0:13:18.500,0:13:21.840
Jeżeli masz jakieś inne pytania to oczywiście pisz do mnie,
0:13:21.840,0:13:25.180
czy na facebooku czy w komentarzach YouTuba, gdzie wolisz.
0:13:25.520,0:13:28.900
I widzimy się i słyszymy w kolejnym odcinku.
0:13:29.715,0:13:30.715
Cześć.

%MCEPASTEBIN%


Podobne wpisy

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *