20T12 Co to jest EVPN?

W tym odcinku omawiam jak naprawić problem:

Co to jest EVPN?

Jeżeli interesuje Cię dowiedzenie się czym jest EVPN?

To jest odcinek dla Ciebie.

Przedstawiam najważniejsze zalety zastosowania EVPN.

Pokazuję jak automatycznie tworzone są tunele VXLAN oraz jak propagowana jest informacja o MAC adresach.

Więcej miejsc do posłuchania:

 

Transkrypcja filmu:

0:00:00.000,0:00:02.000

0:00:02.000,0:00:04.000
Cześć, witam Cię w dzisiejszym odcinku.
0:00:04.000,0:00:06.000
Dzisiaj opowiem, co to jest EVPN.

20T12 Co to jest EVPN?

0:00:06.000,0:00:08.000
W dużym skrócie, jeżeli chodzi
0:00:08.000,0:00:10.000
o EVPN to jest to technologia
0:00:10.000,0:00:12.000
do centrów przetwarzania danych
0:00:12.000,0:00:14.000
czyli do Data Center. Żeby zrozumieć,
0:00:14.000,0:00:16.000
jak ona działa, warto jest
0:00:16.000,0:00:18.000
zacząć od tego, jaki problem,
0:00:18.000,0:00:20.000
początkowo chcemy rozwiązać
0:00:20.000,0:00:22.000
a potem pokażę, jak ten EVPN
0:00:22.000,0:00:24.000
to implementuje. Zacznijmy
0:00:24.000,0:00:26.000
od opisania tutaj tego prostego
0:00:26.000,0:00:28.000
środowiska, w naszych centrach przetwarzania
0:00:28.000,0:00:30.000
danych, dzisiaj głównie
0:00:30.000,0:00:32.000
bazujemy na takim modelu tradycyjnym
0:00:32.000,0:00:34.000
czyli mamy przełączniki
0:00:34.000,0:00:36.000
dostępowe. W przypadku
0:00:36.000,0:00:38.000
Date Center, czyli Centrów przetwarzania danych
0:00:38.000,0:00:40.000
są to przełączniki top of the rack.
0:00:40.000,0:00:42.000
Do tych
0:00:42.000,0:00:44.000
przełączników mamy podłączone
0:00:44.000,0:00:46.000
oczywiście jakieś przełączniki szkieletowe,
0:00:46.000,0:00:48.000
czyli to są te na górze.
0:00:48.000,0:00:50.000

0:00:50.000,0:00:52.000
Pomiędzy tymi przełącznikami szkieletowymi
0:00:52.000,0:00:54.000
i dostępowymi mamy
0:00:54.000,0:00:56.000
spięte fizyczne połączenia,
0:00:56.000,0:00:58.000
które są  trunkiem, czyli
0:00:58.000,0:01:00.000
zawierają w środku wiele
0:01:00.000,0:01:02.000
vlanów. W tym przykładzie, żeby można było
0:01:02.000,0:01:04.000
to uprościć, pokazałem wam dwa
0:01:04.000,0:01:06.000
vlany, na każdym z dostępowych
0:01:06.000,0:01:12.000
switch czyli serwery, które są podpięte do top of the rack są tutaj
0:01:12.000,0:01:14.000
pokazane poniżej.
0:01:14.000,0:01:16.000
Każdy z tych kolorów, jest osobnym
0:01:16.000,0:01:18.000
vlanem. No i dzisiaj
0:01:18.000,0:01:20.000
segmentacje pomiędzy tymi maszynami
0:01:20.000,0:01:22.000
mamy wykonywaną bazując właśnie
0:01:22.000,0:01:24.000
na tradycyjnej konfiguracji
0:01:24.000,0:01:26.000
vlanów czyli konfigurujemy dany
0:01:26.000,0:01:28.000
vlan albo w trunku,
0:01:28.000,0:01:30.000
jeżeli ten serwer tutaj na dole
0:01:30.000,0:01:32.000
pokazany jest w formie
0:01:32.000,0:01:34.000
maszyny wirtualnej, czyli
0:01:34.000,0:01:36.000
jakiegoś wirtualizatora –
0:01:36.000,0:01:38.000
tak jest najczęściej więc ten
0:01:38.000,0:01:40.000
wirtrualizator ma połączenie już
0:01:40.000,0:01:42.000
po trunku z portem tego
0:01:42.000,0:01:44.000
przełącznika top of the rack.
0:01:44.000,0:01:46.000
Tak jest dzisiaj to realizowane najczęściej.
0:01:46.000,0:01:48.000
Natomiast nie rozwiązuje nam to
0:01:48.000,0:01:50.000
problemów związanych z Spanning Tree,
0:01:50.000,0:01:52.000
czyli oczywiście tutaj mając
0:01:52.000,0:01:54.000
te połączenia pomiędzy przełącznikami
0:01:54.000,0:01:56.000
dostępowymi a przełącznikami
0:01:56.000,0:01:58.000
szkieletowymi,
0:01:58.000,0:02:00.000
tutaj jest najczęściej więcej niż jedno
0:02:00.000,0:02:02.000
fizyczne połączenie, typowo są to dwa połącznia.
0:02:02.000,0:02:04.000
Na tym rysunku tego nie przedstawiałem,
0:02:04.000,0:02:06.000
ze względu na to, żeby nie komplikować
0:02:06.000,0:02:08.000
całej sytuacji tłumacząc,
0:02:08.000,0:02:10.000
natomiast tu musi działać jakiś mechanizm
0:02:10.000,0:02:12.000
zapobiegania pętlą.
0:02:12.000,0:02:14.000
Jeżeli patrzymy sobie na to co jest
0:02:14.000,0:02:16.000
najczęściej implementowane to dzisiaj
0:02:16.000,0:02:18.000
najczęściej implementowany jest link zagregowany 
0:02:18.000,0:02:20.000
czyli mówimy o połączeniu R2 pomiędzy
0:02:20.000,0:02:22.000
Top of the rack a tak naprawdę
0:02:22.000,0:02:24.000
najczęściej dwoma Top of the rack.
0:02:24.000,0:02:26.000
Implementacje, które najczęściej dzisiaj widzę
0:02:26.000,0:02:28.000
to są dwa top of the rack na szafę
0:02:28.000,0:02:30.000
i po jednym fizycznym połączeniu
0:02:30.000,0:02:32.000
10G, 40G a ostatnio
0:02:32.000,0:02:34.000
coraz częściej 100G
0:02:34.000,0:02:36.000
pomiędzy daną szafą i każdym
0:02:36.000,0:02:38.000
z tych przełączników dostępowych
0:02:38.000,0:02:40.000
a przełącznikiem szkieletowym.
0:02:40.000,0:02:42.000
Jak sobie tutaj popatrzycie
0:02:42.000,0:02:44.000
mielibyśmy te połączenia –
0:02:44.000,0:02:46.000
na chwilę je narysuje w ten sposób.
0:02:46.000,0:02:48.000
To są fizyczne
0:02:48.000,0:02:50.000
połączenia przedstawione. To tutaj
0:02:50.000,0:02:52.000
mamy agregację a tutaj
0:02:52.000,0:02:54.000
poniżej mamy najczęściej
0:02:54.000,0:02:56.000
drugi przełącznik
0:02:56.000,0:02:58.000
fizyczny, do którego
0:02:58.000,0:03:00.000
jest drugą nogą każdy z tych
0:03:00.000,0:03:02.000
serwerów podpięty. Te przełączniki
0:03:02.000,0:03:04.000
między sobą w szafie są
0:03:04.000,0:03:06.000
wirtualizowane i dzięki temu
0:03:06.000,0:03:08.000
jak mamy te połączenia –
0:03:08.000,0:03:10.000
może tu trochę
0:03:10.000,0:03:12.000
jaśniej to narysuję
0:03:12.000,0:03:14.000
aby było tak, że ten drugi tutaj
0:03:14.000,0:03:16.000
jest fizyczny przełącznik.
0:03:16.000,0:03:18.000
One są tutaj ze sobą
0:03:18.000,0:03:20.000
połączone najczęściej jakimś linkiem
0:03:20.000,0:03:22.000
wirtualizacyjnym i wtedy mamy
0:03:22.000,0:03:24.000
po jednym fizycznym linku o w ten
0:03:24.000,0:03:26.000
sposób spiętym
0:03:26.000,0:03:28.000
i tu mamy agregację
0:03:28.000,0:03:30.000
na poziomie warstwy drugiej.
0:03:30.000,0:03:32.000
Tak to się robi dzisiaj najczęściej, natomiast
0:03:32.000,0:03:34.000
ta topologia też w pewnych
0:03:34.000,0:03:36.000
scenariuszach przestaje się skalować.
0:03:36.000,0:03:38.000
Teraz popatrzcie sobie na
0:03:38.000,0:03:40.000
to jak w dzisiejszym świecie
0:03:40.000,0:03:42.000
tych Centrów przetwarzania danych
0:03:42.000,0:03:44.000
jest wykrywany dany
0:03:44.000,0:03:46.000
host czyli zakładamy, że podłączamy
0:03:46.000,0:03:48.000
nowy serwer. Jeżeli jest taki nowy serwer
0:03:48.000,0:03:50.000
podłączany do takiego vlanu
0:03:50.000,0:03:52.000
to oczywiście nie zna
0:03:52.000,0:03:54.000
mapowania w tablicy arpów
0:03:54.000,0:03:56.000
w związku z tym jeżeli pakiet idzie
0:03:56.000,0:03:58.000
tutaj w tą stronę do przełącznika
0:03:58.000,0:04:00.000
dostępowego i ma się
0:04:00.000,0:04:02.000
odnieść załóżmy do tego
0:04:02.000,0:04:04.000
niebieskiego serwera po drugiej stronie
0:04:04.000,0:04:05.980
o tutaj tego, to oczywiście
0:04:05.980,0:04:07.980
na tym przełączniku robi się
0:04:08.000,0:04:10.000
operacja czyli mapowanie
0:04:10.000,0:04:12.000
mac adresu do portu
0:04:12.000,0:04:14.000
tutaj mam na myśli
0:04:14.000,0:04:16.000
mac adres srcs
0:04:16.000,0:04:18.000
czyli ta informacja jest
0:04:18.000,0:04:20.000
zapisywana, że na tym fizycznym porcie
0:04:20.000,0:04:22.000
widzę niebieski serwer,
0:04:22.000,0:04:24.000
który ma mac adres
0:04:24.000,0:04:26.000
taki i taki. Następnie
0:04:26.000,0:04:28.000
jest sprawdzany ten
0:04:28.000,0:04:30.000
mac adres
0:04:30.000,0:04:32.000
docelowy
0:04:32.000,0:04:34.000

0:04:34.000,0:04:36.000
i ten mac adres
0:04:36.000,0:04:38.000
docelowy to jest mac adres
0:04:38.000,0:04:40.000
tutaj tego hosta
0:04:40.000,0:04:42.000
niebieskiego po prawej stronie.
0:04:42.000,0:04:44.000
Switch ten top of the rack
0:04:44.000,0:04:46.000
nie zna oczywiście mapowania
0:04:46.000,0:04:48.000
tego serwera
0:04:48.000,0:04:50.000
niebieskiego po prawej stronie, w związku z tym
0:04:50.000,0:04:52.000
jest wysyłane pytanie
0:04:52.000,0:04:54.000
Broadcast w górę sieci
0:04:54.000,0:04:56.000
jakie jest mapowanie pomiędzy
0:04:56.000,0:04:58.000
IP a mac adresem docelowym
0:04:58.000,0:05:00.000
bo IP ten serwer
0:05:00.000,0:05:02.000
niebieski po lewej stronie zna
0:05:02.000,0:05:04.000
natomiast mac adresu nie zna
0:05:04.000,0:05:06.000
i teraz ten duch idzie podcastem przez
0:05:06.000,0:05:08.000
przełączniki szkieletowe do
0:05:08.000,0:05:10.000
kolejnego szkieletowego i tu
0:05:10.000,0:05:12.000
podcastem na wszystkie porty
0:05:12.000,0:05:14.000
idzie m.in. do tego przełącznika
0:05:14.000,0:05:16.000
top of the rack i tutaj
0:05:16.000,0:05:18.000
ten przełącznik top of the rack ma
0:05:18.000,0:05:20.000
w swojej tablicy już
0:05:20.000,0:05:22.000
zapisane jaki jest
0:05:22.000,0:05:24.000
Mac vs IP
0:05:24.000,0:05:26.000
ten pakiet dalej
0:05:26.000,0:05:28.000
idzie tutaj do niebieskiego
0:05:28.000,0:05:30.000
tego serwera i ten
0:05:30.000,0:05:32.000
serwer niebieski odpowiada
0:05:32.000,0:05:34.000
arpem w drugą stronę
0:05:34.000,0:05:36.000
i ten serwer na dole tutaj odpowiada nam
0:05:36.000,0:05:38.000
z powrotem tą informacją na
0:05:38.000,0:05:40.000
arpa który został
0:05:40.000,0:05:42.000
z lewej strony wysłany, tutaj już
0:05:42.000,0:05:44.000
ta informacja jest zwracana
0:05:44.000,0:05:46.000
poprzez te wszystkie przełączniki
0:05:46.000,0:05:48.000
szkieletowe do przełącznika
0:05:48.000,0:05:50.000
top of the rack
0:05:50.000,0:05:52.000
tego po lewej stronie. No i tutaj
0:05:52.000,0:05:54.000
jest już zwracana do
0:05:54.000,0:05:56.000
hosta końcowego informacja
0:05:56.000,0:05:58.000
dotycząca mapowania mac adresu
0:05:58.000,0:06:00.000
z IP adresem.
0:06:00.000,0:06:02.000
Czyli od tego momentu, jeżeli te dwa
0:06:02.000,0:06:04.000
serwery niebieskie są w jednym
0:06:04.000,0:06:06.000
vlanie czyli w jednej warstwie drugiej
0:06:06.000,0:06:08.000
no to dostajemy mapowanie
0:06:08.000,0:06:10.000
na tym host końcowym
0:06:10.000,0:06:12.000
i ten host końcowy jest w stanie
0:06:12.000,0:06:14.000
unicastem już wysyłać dalej
0:06:14.000,0:06:16.000
informacje do serwera
0:06:16.000,0:06:18.000
z prawej strony. Czyli mamy mapowanie
0:06:18.000,0:06:20.000
za pomocą protokołu arp
0:06:20.000,0:06:22.000
na host tym z lewej
0:06:22.000,0:06:24.000
strony i podobnie jest na host
0:06:24.000,0:06:26.000
z prawej strony, czyli wtedy już
0:06:26.000,0:06:28.000
oba te hosty widzą się
0:06:28.000,0:06:30.000
na warstwie drugiej. To wykrywanie arpem
0:06:30.000,0:06:32.000
jest dość istotne ponieważ
0:06:32.000,0:06:34.000
podobny mechanizm zachodzi przy EVPN
0:06:34.000,0:06:36.000
i za chwilę do tego też
0:06:36.000,0:06:38.000
dojdziemy. No dobrze ale jak
0:06:38.000,0:06:40.000
nam w tej sytuacji EVPN może pomóc?
0:06:40.000,0:06:42.000
EVPN jest
0:06:42.000,0:06:44.000
technologią sieci nakładkowej.
0:06:44.000,0:06:46.000
Czyli zakładamy, że
0:06:46.000,0:06:48.000
mamy mieć pod spodem sieć,
0:06:48.000,0:06:50.000
która działa stabilnie, która działa
0:06:50.000,0:06:52.000
w oparciu o warstwę drugą
0:06:52.000,0:06:54.000
lub o warstwę trzecią.
0:06:54.000,0:06:56.000
To z punktu widzenia sieci nakładkowej
0:06:56.000,0:06:58.000
nie ma znaczenia. EVPN jest
0:06:58.000,0:07:00.000
tylko jedną z możliwości sieci
0:07:00.000,0:07:02.000
nakładkowych, natomiast
0:07:02.000,0:07:04.000
to co widzę dzisiaj na rynku, to to, że sieć
0:07:04.000,0:07:06.000
EVPN staje się
0:07:06.000,0:07:08.000
powszechna u różnych producentów sprzętu
0:07:08.000,0:07:10.000
a to oznacza, że
0:07:10.000,0:07:12.000
prawdopodobnie ta właśnie technologia
0:07:12.000,0:07:14.000
zagości u nas na dłużej.
0:07:14.000,0:07:16.000
Jeżeli sobie popatrzymy na to jak EVPN
0:07:16.000,0:07:18.000
czyli te sieci nakładkowe są tworzone
0:07:18.000,0:07:20.000
to na każdym z tych
0:07:20.000,0:07:22.000
przełączników dostępowych, czyli
0:07:22.000,0:07:24.000
top of the rack, one się nazywają w
0:07:24.000,0:07:26.000
terminologii EVPN leaf
0:07:26.000,0:07:28.000
czyli takimi liśćmi
0:07:28.000,0:07:30.000
a te szkieletowe na górze
0:07:30.000,0:07:32.000
nazywają się spine
0:07:32.000,0:07:34.000
czyli takimi drzewami.
0:07:34.000,0:07:36.000
Rola tych urządzeń jest różna
0:07:36.000,0:07:38.000
czyli te leaf -y
0:07:38.000,0:07:40.000
te przełączniki top of the rack
0:07:40.000,0:07:42.000
tradycyjnie, są miejscami
0:07:42.000,0:07:44.000
w których zaczynają i kończą się
0:07:44.000,0:07:46.000
tunele nakładkowe. W technologii
0:07:46.000,0:07:48.000
EVPN wykorzystuje się
0:07:48.000,0:07:50.000
tunele w oparciu o VX lany
0:07:50.000,0:07:52.000
jest to technologia związana
0:07:52.000,0:07:54.000
z tunelowaniem
0:07:54.000,0:07:56.000
pakietów w protokole UDP
0:07:56.000,0:07:58.000
i jedyne co potrzebujemy,
0:07:58.000,0:08:00.000
żeby ten pakiet
0:08:00.000,0:08:02.000
zatunelowany, czyli już
0:08:02.000,0:08:04.000
w pakiecie UDP przechodził, to jest
0:08:04.000,0:08:06.000
zapewnienie łączności IP
0:08:06.000,0:08:08.000
z zapewnieniem łączności na poziomie
0:08:08.000,0:08:10.000
podprotokołu czyli UDP.
0:08:10.000,0:08:12.000
Ja sobie popatrzycie jak tworzone są
0:08:12.000,0:08:18.000
te tunele, to oczywiście pierwszy z punktu widzenia administracyjnego zadanie to jest na poziomie tego leaf
0:08:18.000,0:08:20.000
powiązanie w tzw WNI
0:08:20.000,0:08:22.000
informacji jaki jest vlan
0:08:22.000,0:08:24.000
do danej instancji
0:08:24.000,0:08:26.000
czyli jeżeli konfiguracyjnie robimy
0:08:26.000,0:08:28.000
EVPN w naszym środowisku
0:08:28.000,0:08:30.000
serwerowym to dla każdego
0:08:30.000,0:08:32.000
połączenia tutaj
0:08:32.000,0:08:34.000
serwerowego czyli na tych leaf -ach
0:08:34.000,0:08:36.000
robimy takie mapowanie czyli
0:08:36.000,0:08:38.000
jaka instancja wirtualna
0:08:38.000,0:08:40.000
tej sieci nakładkowej jest związana z
0:08:40.000,0:08:42.000
z danym V-lan i to samo robimy oczywiście
0:08:42.000,0:08:44.000
po drugiej stronie
0:08:44.000,0:08:46.000
Teraz te spine
0:08:46.000,0:08:48.000
opowiadają za funkcję managment- ową
0:08:48.000,0:08:50.000
automatyzacji procesu
0:08:50.000,0:08:52.000
zostawiania tych tuneli czyli jeżeli mamy
0:08:52.000,0:08:54.000
powiązane ze sobą vlan-y
0:08:54.000,0:08:56.000
z instancjami
0:08:56.000,0:08:58.000
sieci nakładkowych i z leaf-a
0:08:58.000,0:09:00.000
tworzymy tunel
0:09:00.000,0:09:02.000
do drugiego leaf-a i oczywiście ten
0:09:02.000,0:09:04.000
tunel jest związany
0:09:04.000,0:09:06.000
z danym vlan-em i VNI
0:09:06.000,0:09:08.000
po lewej stronie i po prawej stronie.
0:09:08.000,0:09:10.000
Dzięki temu warstwa druga
0:09:10.000,0:09:12.000
patrząc na hosty
0:09:12.000,0:09:14.000
końcowe czyli te serwery
0:09:14.000,0:09:16.000
jest jakby widoczna jedynie
0:09:16.000,0:09:18.000
pomiędzy leaf-ami.
0:09:18.000,0:09:22.000
To też oznacza, że jeżeli patrzymy sobie na spine czyli te przełączniki korowe
0:09:22.000,0:09:24.000
one nie muszą wspierać wcale
0:09:24.000,0:09:26.000
VX lan, nie ma takiego wymagania,
0:09:26.000,0:09:28.000
to co muszą wspierać
0:09:28.000,0:09:30.000
to oczywiście muszą wspierać BGP
0:09:30.000,0:09:32.000
bo będzie tutaj część
0:09:32.000,0:09:34.000
kontrolna oparta o
0:09:34.000,0:09:36.000
multi protokół BGP – o tym
0:09:36.000,0:09:38.000
jeszcze za chwilę powiem. Natomiast to co jest
0:09:38.000,0:09:40.000
oprócz tego wymagane to to, żeby
0:09:40.000,0:09:42.000
miały informację o tych leaf – ach
0:09:42.000,0:09:44.000
czyli, żeby widziały całą topologię
0:09:44.000,0:09:46.000
z punktu widzenia controlplein
0:09:46.000,0:09:48.000
tak, żeby można było centralnie zarządzić
0:09:48.000,0:09:52.000
zestawianiem tych tuneli VX lan. Czyli uruchamiamy
0:09:52.000,0:09:54.000
BGP na korowych
0:09:54.000,0:09:56.000
przełącznikach czyli na spain -ach
0:09:56.000,0:09:58.000
one będą pracować w ramach
0:09:58.000,0:10:00.000
route reflector -ów czyli wszystkie
0:10:00.000,0:10:02.000
urządzenia leaf – owe
0:10:02.000,0:10:04.000
będą odpytywać za pomocą
0:10:04.000,0:10:06.000
BGP dane route reflector
0:10:06.000,0:10:08.000
o centralną informację
0:10:08.000,0:10:10.000
dotyczącą mac adresów
0:10:10.000,0:10:12.000
czyli jeżeli tutaj mamy spięte
0:10:12.000,0:10:14.000
VX lan-y pomiędzy przełącznikami,
0:10:14.000,0:10:16.000
tu mamy dwa przełączniki
0:10:16.000,0:10:18.000
leaf-owe w związku z tym
0:10:18.000,0:10:20.000
tutaj będą te tunele przechodziły w ten sposób.
0:10:20.000,0:10:22.000
Ale jeżeli tych przełączników –
0:10:22.000,0:10:24.000
a tradycyjnie tych przełączników będzie
0:10:24.000,0:10:26.000
dużo więcej w naszym ośrodku
0:10:26.000,0:10:28.000
przetwarzania danych – to oczywiście tych
0:10:28.000,0:10:30.000
tuneli VX lan będzie dużo więcej
0:10:30.000,0:10:32.000
i one będą się spinać w ramach
0:10:32.000,0:10:34.000
fullmesh-a
0:10:34.000,0:10:36.000
Na koniec jeszcze istotna jest informacja
0:10:36.000,0:10:38.000
bo już widzimy, że
0:10:38.000,0:10:40.000
nam te spine będą automatyzować
0:10:40.000,0:10:42.000
tworzenie tych tuneli VX lan
0:10:42.000,0:10:44.000
natomiast my musimy
0:10:44.000,0:10:46.000
administracyjnie przypisywać mapowanie
0:10:46.000,0:10:48.000
pomiędzy VX lan – em czyli tym
0:10:48.000,0:10:50.000
WNI a danym vlanem.
0:10:50.000,0:10:52.000
To co nam jeszcze ten BGP zapewnia
0:10:52.000,0:10:54.000
w ramach rozszerzenia
0:10:54.000,0:10:56.000
BGP MP-BGP
0:10:56.000,0:10:58.000
to jest możliwość przenoszenia
0:10:58.000,0:11:00.000
informacji o mac adresach. Czyli jak
0:11:00.000,0:11:02.000
patrzyliśmy sobie wcześniej jak działa
0:11:02.000,0:11:04.000
w tradycyjnym środowisku ten protokół
0:11:04.000,0:11:06.000
ARP – owy czyli mapowanie mac adresu
0:11:06.000,0:11:08.000
do adresu IP, podcastowanie tych
0:11:08.000,0:11:10.000
pakietów, tak żeby się dowiedzieć o
0:11:10.000,0:11:12.000
sąsiedzie w warstwie drugiej
0:11:12.000,0:11:14.000
tutaj działa to podobnie z tą różnicą,
0:11:14.000,0:11:16.000
że jeżeli nie znamy
0:11:16.000,0:11:18.000
tego hosta, czyli prześledźmy
0:11:18.000,0:11:20.000
jeszcze raz, tą samą wersję scenariusza.
0:11:20.000,0:11:22.000
Dodajemy nowego hosta po prawej stronie
0:11:22.000,0:11:24.000
– tego niebieskiego.
0:11:24.000,0:11:26.000
Ten po lewej stronie, nie zna jego
0:11:26.000,0:11:28.000
mac adresu, w związku z tym musi wysyłać
0:11:28.000,0:11:30.000
broadcast arpowy. Ten broadcast arpowy
0:11:30.000,0:11:32.000
będzie przesyłany
0:11:32.000,0:11:34.000
tutaj przez te wszystkie switch-e
0:11:34.000,0:11:36.000
za pomocą tego tunelu
0:11:36.000,0:11:38.000
VX lan – czyli w środku
0:11:38.000,0:11:40.000
tego tunelu będzie ten arp
0:11:40.000,0:11:42.000
szedł dla danego vlan -u
0:11:42.000,0:11:44.000
i dotrze tutaj do tego hosta końcowego
0:11:44.000,0:11:46.000
i ten host końcowy
0:11:46.000,0:11:48.000
odpowie oczywiście na to zapytanie
0:11:48.000,0:11:50.000
arp -owe w drugą stronę.
0:11:50.000,0:11:52.000
Pierwsza ścieżka
0:11:52.000,0:11:54.000
będzie szła broadcast-em
0:11:54.000,0:11:56.000
czyli dla wszystkich urządzeń w danych vlan-ie
0:11:56.000,0:11:58.000
będzie ten pakiet widoczny
0:11:58.000,0:12:00.000
powrotna ścieżka będzie szła już unicastem
0:12:00.000,0:12:02.000
i zostanie tutaj poinformowany
0:12:02.000,0:12:04.000
ten host końcowy o
0:12:04.000,0:12:06.000
mapowaniu pomiędzy mac adresem a IP
0:12:06.000,0:12:08.000
adresem. Co więcej, te przełączniki
0:12:08.000,0:12:10.000
leaf-owe również
0:12:10.000,0:12:12.000
sobie tak jak wcześniej
0:12:12.000,0:12:14.000
tradycyjne przełączniki
0:12:14.000,0:12:16.000
budują tą tablicę arp -ową
0:12:16.000,0:12:18.000
gdzie jest
0:12:18.000,0:12:20.000
powiązany mac i IP
0:12:20.000,0:12:22.000
ale również ta informacja jest
0:12:22.000,0:12:24.000
przekazywana tutaj do centralnego
0:12:24.000,0:12:26.000
control plein-u
0:12:26.000,0:12:28.000
przez tego właśnie
0:12:28.000,0:12:30.000
MP – BGP-a
0:12:30.000,0:12:32.000
i ten MP-BGP tą informacje mapowania
0:12:32.000,0:12:34.000
pomiędzy mac adresem a IP adresem
0:12:34.000,0:12:36.000
rozsyła automatycznie
0:12:36.000,0:12:38.000
do wszystkich leaf -ów
0:12:38.000,0:12:40.000
czyli jeżeli podłączymy w innym
0:12:40.000,0:12:42.000
miejscu nowy serwer –
0:12:42.000,0:12:44.000
załóżmy tutaj
0:12:44.000,0:12:46.000
i on będzie chciał się połączyć
0:12:46.000,0:12:48.000
do tego portu i wysłać
0:12:48.000,0:12:50.000
jakiś pakiet na adres
0:12:50.000,0:12:52.000
tego po prawej stronie
0:12:52.000,0:12:54.000
niebieskiego serwera to
0:12:54.000,0:12:56.000
ten leaf po lewej stronie – o ten
0:12:56.000,0:12:58.000
będzie miał
0:12:58.000,0:13:00.000
już informację w którym miejscu
0:13:00.000,0:13:02.000
ten mac adres jest, nawet
0:13:02.000,0:13:04.000
gdyby ten leaf nigdy nie brał
0:13:04.000,0:13:06.000
wcześniej udziału w komunikacji
0:13:06.000,0:13:08.000
arpowej i
0:13:08.000,0:13:10.000
nie otrzymał tego broadcast-a więc jeżeli
0:13:10.000,0:13:12.000
popatrzymy sobie na to
0:13:12.000,0:13:14.000
jak automatyzuje się informacja
0:13:14.000,0:13:16.000
o przekazywaniu informacji o mac adresie
0:13:16.000,0:13:18.000
pomiędzy leaf-ami
0:13:18.000,0:13:20.000
to jest to dużo bardzie zoptymalizowane
0:13:20.000,0:13:22.000
niż w przypadku zwykłego ethernetu
0:13:22.000,0:13:24.000
bo w przypadku zwykłego ethernetu
0:13:24.000,0:13:28.000
za każdym razem jak się pojawia nowy mac adres każde z urządzeń
0:13:28.000,0:13:30.000
musi się przez broadcast nauczyć
0:13:30.000,0:13:32.000
mapowania mac do IP
0:13:32.000,0:13:34.000
tutaj w przypadku tego MP- BGP
0:13:34.000,0:13:36.000
mamy tą centralną
0:13:36.000,0:13:38.000
funkcję mapowania informacji
0:13:38.000,0:13:40.000
o mac adresie do IP
0:13:40.000,0:13:42.000
przekazywaną przez MP-BGP
0:13:42.000,0:13:44.000
obsługiwaną na route reflectorze
0:13:44.000,0:13:46.000
czyli na spine
0:13:46.000,0:13:48.000
Na dzisiaj to wszystko jeżeli chodzi o
0:13:48.000,0:13:50.000
MP-BGP , EVPN
0:13:50.000,0:13:52.000
i to jak ze sobą te mechanizmy
0:13:52.000,0:13:54.000
współdziałają, jeżeli macie jakieś do tego
0:13:54.000,0:13:56.000
pytania to oczywiście piszcie w komentarzu,
0:13:56.000,0:13:58.000
tutaj bardzo pobieżnie
0:13:58.000,0:14:00.000
dotknąłem tematu np. VX lan
0:14:00.000,0:14:02.000
ale to nie ma potrzeby poruszania tego
0:14:02.000,0:14:04.000
wszystkiego w jednym odcinku.
0:14:04.000,0:14:06.000
Jeżeli coś szczególnie będzie was interesowało to oczywiście
0:14:06.000,0:14:08.000
dawajcie znać. Jeżeli chodzi
0:14:08.000,0:14:10.000
jeszcze na koniec o porównanie
0:14:10.000,0:14:12.000
dlaczego EVPN zaczyna się pojawiać
0:14:12.000,0:14:14.000
są takie problemy w dzisiejszych
0:14:14.000,0:14:16.000
ośrodkach przetwarzania danych, które są coraz
0:14:16.000,0:14:18.000
większe – że brakuje np ilości
0:14:18.000,0:14:20.000
vlan -ów – czyli jeżeli patrzymy sobie
0:14:20.000,0:14:22.000
na to tradycyjne środowisko
0:14:22.000,0:14:24.000
jest tych vlan -ów, identyfikatorów
0:14:24.000,0:14:26.000
vlan-ów jest za mało
0:14:26.000,0:14:28.000
4094 identyfikatory
0:14:28.000,0:14:30.000
jest po prostu niewystarczające dla
0:14:30.000,0:14:32.000
większych środowisk a to też oznacza, że
0:14:32.000,0:14:34.000
trzeba iść w stronę jakiegoś innego
0:14:34.000,0:14:36.000
rozwiązania i między innymi VX lany
0:14:36.000,0:14:38.000
takie rozwiązanie zapewniają
0:14:38.000,0:14:40.000
16 mln identyfikatorów
0:14:40.000,0:14:42.000
zapewnia wystarczającą ilość
0:14:42.000,0:14:44.000
identyfikacji w ramach
0:14:44.000,0:14:46.000
segmentacji różnych grup serwerów
0:14:46.000,0:14:48.000
które są dzisiaj w dużych ośrodkach
0:14:48.000,0:14:50.000
przetwarzania danych. No i kolejna rzecz,
0:14:50.000,0:14:52.000
która jest ciekawa i umożliwia
0:14:52.000,0:14:54.000
takie wykorzystanie sieci nakładkowych
0:14:54.000,0:14:56.000
to to, że sieć podkładowa
0:14:56.000,0:14:58.000
czyli ta podstawowa –
0:14:58.000,0:15:00.000
dzisiaj jest najczęściej analizowana w oparciu
0:15:00.000,0:15:02.000
o warstwę drugą, natomiast
0:15:02.000,0:15:04.000
w większych ośrodkach to też jest problem
0:15:04.000,0:15:06.000
nie skaluje się to zbyt dobrze
0:15:06.000,0:15:08.000
i można wykorzystując EVPN
0:15:08.000,0:15:10.000
stosować warstwę trzecią
0:15:10.000,0:15:12.000
czyli pomiędzy reaf a spaine
0:15:12.000,0:15:14.000
już nie musimy stosować wtedy
0:15:14.000,0:15:16.000
takich obejść problemu ze stp
0:15:16.000,0:15:18.000
czyli linku agregacyjnego np
0:15:18.000,0:15:20.000
tylko możemy zastosować routing
0:15:20.000,0:15:22.000
możemy tam mieć BGP,
0:15:22.000,0:15:24.000
możemy tam mieć OSPF-a i wtedy
0:15:24.000,0:15:26.000
dokładanie kolejnych leaf-ów do tego środowiska
0:15:26.000,0:15:28.000
czy kolejnych spinów jeżeli potrzeba
0:15:28.000,0:15:30.000
się dużo lepiej scaluje bo warstwy
0:15:30.000,0:15:32.000
trzeciej nasz mechanizm obsługi
0:15:32.000,0:15:34.000
wielościeżkowości jest dużo lepszy
0:15:34.000,0:15:36.000
przeliczania tras, zapobiegania pętlom
0:15:36.000,0:15:38.000
to działa dużo lepiej niż w warstwie drugiej
0:15:38.000,0:15:40.000
przynajmniej w klasycznym wykorzystaniu
0:15:40.000,0:15:44.000
ze stp a oczywiście  jakiś mechanizm zapobiegania pętlom
0:15:44.000,0:15:46.000
trzeba mieć, ze względu na to, że
0:15:46.000,0:15:48.000
zapętlenie w takich krytycznych środowiskach
0:15:48.000,0:15:50.000
i nie posiadanie zabezpieczenia
0:15:50.000,0:15:52.000
przed takim zjawiskiem, potrafi położyć
0:15:52.000,0:15:54.000
całą sieć albo dużą jej część.
0:15:54.000,0:15:56.000
Jeżeli macie też do jakiejś części
0:15:56.000,0:15:58.000
teoretycznej pytania, również
0:15:58.000,0:16:00.000
piszcie. Dziękuję wam dzisiaj za uwagę
0:16:00.000,0:16:02.000
i do zobaczenia w kolejnym odcinku.

%MCEPASTEBIN%