VxLAN – przyczyny powstania i zasada działania

W dzisiejszym materiale porozmawiamy o technologii, która jakiś czas temu weszła przebojem na rynek sieciowy i teraz jest integralną częścią wielu wyrafinowanych i naprawdę potężnych produktów, z NSX-em od VMware i Cisco ACI na czele. Technologia ta to VxLAN. W tym materiale odpowiem na pytanie dlaczego potrzebne było powstanie tego protokołu i jaka jest zasada jego działania. Aby ta publikacja miała rozsądną długość, szczegóły techniczne oraz konfiguracja będą przedstawione w osobnym materiale.

Retrospektywa – jak było kiedyś?

Nasze rozważania na temat VxLAN’ów zacznę od retrospektywy, która pozwoli Ci lepiej zrozumieć dlaczego w ogóle taka technologia powstała. W świecie sieci komputerowych jest tak, że mamy do czynienia z bardzo szerokim zbiorem różnych technologii zwanych też protokołami. Każdy protokół jest tak naprawdę odpowiedzią na konkretny problem. Tak było np. w przypadku protokołu STP, który powstał jako odpowiedź na problem zapętlania się ruchu we wczesnych odsłonach sieci Ethernet.

STP rozwiązuje problem blokując nadmiarowe łącza:

STP w bardzo uproszczonej formie
STP w bardzo uproszczonej formie

Więcej o niuansach powstania STP i jego mechanizmach przeczytasz w książce Interconnections Second Edition Radii Perlman, będącej zresztą autorką STP. Fascynująca i bardzo ciekawa lektura, którą gorąco polecam.

Wróćmy tymczasem do naszej retrospektywy. Aby zrozumieć dlaczego powstała technologia VxLAN i jaki problem ona rozwiązuje przyjrzyjmy się szybko temu w jaki sposób ewoluowały sieci na przestrzeni ostatnich lat. Do dziś jest bardzo powszechne sztywne trzymanie się hierarchicznego, trzypoziomowego modelu sieci spopularyzowanego przez Cisco. Zgodnie z tym modelem sieć dzielimy na trzy warstwy: Core, Distribution oraz Access, a urządzenia sieciowe w każdej z tych warstw pełnią inne role i posiadają różne specyfikacje:

Trzypoziomowy model sieci. Linki L2 niebieskie, linki L3 pomarańczowe
Trzypoziomowy model sieci. Linki L2 niebieskie, linki L3 pomarańczowe

W mniejszych sieciach możemy scalić warstwy Core oraz Distribution w jedną i uzyskać tzw. Collapsed Core:

Collapsed core
Collapsed core

Pierwszą odsłoną sieci opartych o tego typu topologie są sieci z segmentacją ruchu na poziomie VLANów. Każdy VLAN stanowi osobną domenę rozgłoszeniową i tradycyjnie jest mapowany jeden do jednego z dedykowaną mu podsiecią. Możemy mieć na przykład więc do czynienia z VLANem 20 dla pracowników działu finansowego, mapowanym na podsieć 192.168.20.0/24. Jeżeli pracownicy tegoż działu znajdują się w różnych fizycznych lokalizacjach to naturalną koleją rzeczy jest rozciąganie VLANów pomiędzy poszczególnymi przełącznikami warstwy dostępowej:

Rozciąganie VLANów między przełącznikami dostępowymi
Rozciąganie VLANów między przełącznikami dostępowymi

Takie VLANy rozciągają się rzecz jasna przez przełączniki dystrybucyjne pełniące rolę bramy domyślnej. Wykorzystujemy również dodatkowe protokoły takie jak STP, VRRP lub HSRP. Problem jaki niesie ze sobą taki design jest następujący: usterka w jednej części sieci jest propagowana na wiele urządzeń ponieważ rozciągnęliśmy domeny rozgłoszeniowe.

Rozległe domeny rozgłoszeniowe powodują szeroką propagację usterek
Rozległe domeny rozgłoszeniowe powodują szeroką propagację usterek

Kolejnym problemem jaki można tu zaobserwować jest zwiększona ilość ruchu północ-południe, który nie jest czymś pożądanym. Szacuje się, że w sieciach kampusowych, a już zwłaszcza w sieciach typu data centre, około 80% ruchu to ruch relacji wschód-zachód (komunikacja między klientami, serwer do serwera, replikacje danych, migracje wirtualnych maszyn z użyciem VMotion itp). Trójpoziomowa topologia sieci wymusza dużą ilość dodatkowego ruchu północ-południe dla komunikacji oryginalnie będących ruchem wschód-zachód.

Ruch północ-południe i wschód-zachód w sieci
Ruch północ-południe i wschód-zachód w sieci

Ostatnim problemem z jakim mamy tu do czynienia jest obecność STP, którego generalnie czym mniej w sieci tym lepiej.

Retrospektywa – jak było wczoraj?

Problemy wymienione w poprzednim rozdziale następnie rozwiązano oferując kilka usprawnień. Największym z nich było rozciągniecie warstwy trzeciej aż do warstwy dostępowej topologii i wprowadzenie protokołów routingu w miejsce przestarzałego i problematycznego STP:

Trzypoziomowy model sieci. Linki L3 pomarańczowe
Trzypoziomowy model sieci. Linki L3 pomarańczowe

Zachowany nadal został trzypoziomowy model sieci, zwiększyła się natomiast konwergencja takiej sieci. Zmiana niosła za sobą konieczność przesunięcia bram domyślnych z warstwy dystrybucyjnej do warstwy dostępowej. Ponadto, koniecznością stało się stosowanie lokalnych VLANów, nie wykraczających swoim zasięgiem poza pojedynczy przełącznik warstwy dostępowej.

Rozwiązało to problem nazbyt propagujących się awarii i generalnie okazało się być znakomitym rozwiązaniem w znacznej części przypadków – wszakże mając cztery piętra w budynku i na każdym z nich pracowników działu finansowego, możemy stworzyć cztery osobne VLANy powiązane z czterema osobnymi podsieciami. Ruch pomiędzy tymi segmentami następnie możemy kontrolować za pomocą zapory sieciowej.

I wszystko byłoby pięknie gdyby nie to, że nadal mamy często do czynienia z aplikacjami/serwerami/technologiami, które wymagają możliwości komunikacji po warstwie drugiej w celu poprawnego działania. Topologia oparta w pełni o warstwę trzecią jest oczywistym pogwałceniem tego wymogu i w pewnym momencie staje się to bardzo problematyczne. Skala problemu staje się jeszcze bardziej wyraźna w środowisku Data Center gdzie przenoszenie wirtualnych maszyn z użyciem VMotion wymaga rozpinania warstwy drugiej pomiędzy różnymi urządzeniami sieciowymi. A co gdy mamy do czynienia z dostawcą usług internetowych, który dodatkowo musi jeszcze odseparować poszczególnych klientów? W tym momencie robi się już naprawdę trudno. No i nadal nie rozwiązaliśmy problemu dużej ilości ruchu północ-południe.

Stan obecny – jak jest dzisiaj?

Jak widać w poprzednich dwóch rozdziałach, rozwiązanie jednego problemu bardzo często rodzi kolejny i działa to niczym miecz obosieczny. Wprowadzając warstwę trzecią w niemalże całej topologii i eliminując STP uzyskano pozytywny rezultat jeśli chodzi o konwergencję i wydajność sieci. Straciła ona jednak na funkcjonalności. Zanim przejdziemy już do VxLANów, spójrzmy jeszcze na szybko na problem nadmiarowego ruchu północ-południe. Cisco rozwiązało ten problem cofając się aż do lat 50-tych XX wieku, kiedy to zaproponowano w sieciach telefonicznych topologię zwaną clos. Odchodzimy w tym momencie od trzypoziomowej hierarchii sieci na rzecz struktury dwupoziomowej. Składa się ona z przełączników spine oraz leaf, tworzących między sobą pełną siatkę połączeń warstwy trzeciej.

Topologia clos
Topologia clos

Warto zwrócić uwagę, że takich połączeń nie ma pomiędzy poszczególnymi spine’ami oraz leaf’ami. Urządzenia końcowe podłączamy do leaf’ów, tam też umieszczamy wszelkie połączenia na zewnątrz sieci, urządzenia typu IPS, zapory sieciowe itp.

Przełączniki spine pełnią natomiast rolę wysokoprzepustowego szkieletu sieci nazywanego fabryką (ang. fabric) [edycja: trzymajmy się nazywania wspomnianego szkieletu sieci jego angielskojęzycznym terminem – czyli fabric. Jak się okazuje polski termin “fabryka” jest dość kontrowersyjny. Więcej szczegółów na ten temat w komentarzach pod artykułem.]

Warto zwrócić uwagę na to, że naturalną konsekwencją takiego designu jest posiadanie tylko jednego przeskoku (ang. hop) w trakcie routowania ruchu pomiędzy poszczególnymi urządzeniami końcowymi. W ten oto sposób rozwiązano m.in. problem dużej ilości ruchu północ południe.

Dzięki topologii clos między hostami jest tylko jeden skok
Dzięki topologii clos między hostami jest tylko jeden skok

Co jednak z tą nieszczęsną i wszechobecną warstwą trzecią wchodzącą nam niejako klinem w wymóg rozpinania warstwy drugiej między różnymi przełącznikami (w przypadku sieci clos między leaf’ami)?

Tutaj właśnie wkracza do akcji VxLAN!

Czym jest VxLAN i jaki problem rozwiązuje?

VxLAN, czyli z angielskiego Virtual eXtensible Local Area Network jest protokołem stworzonym przez Cisco we współpracy z VMware oraz Aristą. Jest on dziś powszechnie implementowany w rozwiązaniach różnych vendor’ów, a to za sprawą standaryzacji (RFC 7348).

Gdybym miał określić złożoność tej technologii i odnieść ją do świata certyfikacji to bym powiedział, że zrozumienie zasady działania VxLAN jest zagadnieniem na poziomie CCNP. Pełne zrozumienie działania tego protokołu wymaga jednak wejścia przynajmniej całą jedną nogą i palcami drugiej w zagadnienia na poziomie CCIE. Głowa może zaboleć o czym się zresztą zaraz przekonamy.

VxLAN rozwiązuje problem konieczności rozpinania warstwy drugiej pomiędzy odległymi od siebie hostami. W zasadzie jest to dokładnie to co VxLAN robi – rozpina warstwę drugą pomiędzy hostami, wykorzystując do tego istniejącą sieć opartą głównie o warstwę trzecią. Brzmi skomplikowanie? Zaraz się wyjaśni nieco więcej.

Zacznijmy od przyjrzenia się sieci podkładowej (ang. underlay), czyli naszemu szkieletowi na bazie którego będziemy wdrażać VxLAN. Można również wymiennie stosować nazwę “sieć transportowa”. Underlay jest tak naprawdę bardzo prostą siecią, złożoną z urządzeń połączonych linkami warstwy trzeciej, a najczęściej spotykaną topologią jest opisany wcześniej clos. Do routingu w tej sieci wykorzystać możemy dobrze znane protokoły takie jak OSPF, EIGRP czy też IS-IS. Głównym zadaniem sieci podkładowej jest zapewnienie pełnej łączności między poszczególnymi przełącznikami dostępowymi / leaf’ami w topologii. W tak zaprojektowanej sieci zyskamy również na wykorzystaniu ECMP (Equal Cost Multi Path).

Sieć podkładowa w topologii clos
Sieć podkładowa w topologii clos

Nie mamy tutaj do czynienia z rozciąganiem VLANów, STP, trunkami czy nawet HSRP. Zamiast rozciągania VLANów będziemy natomiast rozciągali VxLANy. Brzmi podobnie? W dużym uproszczeniu VxLAN jest zbiorem tuneli łączących ze sobą poszczególne hosty należące do tej samej sieci (=VLANu) lecz zlokalizowane na różnych urządzeniach oddzielonych od siebie warstwą trzecią. Tunele te tworzą tzw. sieć nakładkową (overlay).

Sieć nakładkowa (ang. overlay)
Sieć nakładkowa (ang. overlay)

Warto zwrócić uwagę na to, że możemy w takiej sytuacji dokonywać zmian w sieci underlay zupełnie niezależnie od sieci overlay – dopóki pozostaje zachowana pełna łączność pomiędzy węzłami końcowymi sieci. Zajrzyjmy co się kryje pod maską tego rozwiązania.

Podstawowa zasada działania VxLAN

Zakładam, że VLANy są Ci znane. W enkapsulacji dot1q mamy do czynienia z dodatkową informacją, która jest wstawiana niejako klinem w nagłówek ramki ethernetowej. Informacja ta zawiera między innymi tag (VLAN ID) określający numer VLANu, do którego przynależy ramka. Na tag poświęcone jest 12 bitów, co daje nam możliwość ponumerowania 4095 VLANów (4096 możliwości, ale VLAN 0 jest wyłączony z użytku).

W przypadku VxLAN jest podobnie. Również mamy do czynienia z tagiem, który identyfikuje segment sieci, do którego przynależy dany host. Tag ten nazywamy VNI (VxLAN Network Identifier) i ma on aż 24 bity co pozwala nam na zaadresowanie aż 16 777 215 segmentów sieci! Jest to świetna informacja, zwłaszcza dla service provider’ów obsługujących duże ilości klientów.

VLAN ID vs VNI
VLAN ID vs VNI

Warto zwrócić w tym momencie uwagę, że sama technologia nazywa się co prawda VxLAN, ale wirtualne sieci jakie za jej pomocą tworzymy to nie VxLANy, a VNI! VNI nazywamy również bridge domain i można spotkać te terminy wymiennie.

W przypadku technologii VxLAN będziemy mieli do czynienia z dość złożoną enkapsulacją. W tym momencie należy wprowadzić pojęcie VTEP (Virtual Tunnel Endpoint). VTEP to nic innego jak interfejs (fizyczny lub wirtualny) na końcowym urządzeniu sieciowym (np. na przełączniku leaf lub na hypervisorze takim jak ESX czy Hyper-V). Interfejs ten posiada adres IP przynależny do naszej sieci podkładowej. Oczywiste jest więc, że sieć podkładowa dzięki działającemu tam routingowi będzie w stanie z powodzeniem przesyłać pakiety pomiędzy poszczególnymi VTEPami. VTEPy są ponadto powiązane z jednym lub więcej VNI w sieci nakładkowej. Widzimy zatem, że VTEPy są w pewnym sensie pomostem między siecią underlay a siecią overlay.

VTEP jako łącznik między siecią podkładową i nakładkową
VTEP jako łącznik między siecią podkładową i nakładkową

VTEPy przechodzą przez specjalny proces, w którym uczą się mapowania adresów MAC poszczególnych hostów z VTEPami pod którymi są one osiągalne. Właśnie to powoduje, że VTEP źródłowy wie jaki powinien być VTEP docelowy.

“Czy wiesz że….?”

Bardzo często wymienianą różnicą pomiędzy Cisco ACI a VMware NSX jest właśnie kwestia tego gdzie są zlokalizowane VTEPy. W przypadku ACI są one umieszczone na najbliższym przełączniku leaf (“gateway VTEP”). Jeżeli mamy do takiego przełącznika podłączony serwer ESX, na którym mamy dwie wirtualne maszyny znajdujące się w tej samej podsieci (tym samym VNI) to ruch między nimi będzie musiał odbywać się za pośrednictwem VTEPa. Oznacza to więc konieczność każdorazowego opuszczania hypervisora przez ramkę.

VMware NSX umieszcza natomiast VTEPy bezpośrednio w hypervisorze (“host VTEP”) co powoduje, że ten sam ruch co poprzednio nie będzie musiał opuszczać fizycznego hosta ESX w celu dostarczenia do docelowej VMki.

Przyjrzyjmy się teraz bliżej procesowi przesyłania ramki pomiędzy dwoma hostami. Dokonamy tego na przykładzie zaczerpniętym z materiałów źródłowych Cisco:

Źródło: cisco.com
Przykład enkapsulacji VxLAN, źródło: cisco.com

W powyższym przykładzie Host-A i Host-B znajdujące się w segmencie VxLAN 10 komunikują się ze sobą przy pomocy tunelu VxLAN pomiędzy VTEPem-1 a VTEPem-2. Zakładamy, że obie strony przeszły już przez proces uczenia się adresów i oba VTEPy znają mapowania między adresami MAC a VTEPami. Kiedy Host-A wysyła ruch do Hosta-B, tworzone są ramki Ethernet z adresem docelowym MAC-B i przesyłane są one do VTEPa-1. VTEP-1 posiada mapowanie adresu MAC-B do VTEPa-2, zatem przeprowadza na otrzymanych ramkach proces enkapsulacji VxLAN, dodając nagłówek VxLAN, UDP oraz zewnętrzny nagłówek IP. W zewnętrznym nagłówku IP, adresem źródłowym IP jest adres VTEPa-1, a adresem docelowym IP jest adres VTEPa-2. Następnie VTEP-1 przesyła pakiety do VTEPa-2 za pośrednictwem podkładowej sieci transportowej. Gdy VTEP-2 otrzymuje pakiety, deenkapsuluje on zewnętrzne nagłówki Ethernet, IP, UDP i VxLAN i przekazuje ramkę do Hosta-B bazując na oryginalnym docelowym adresie MAC w nagłówku Ethernet.

Konstrukcja nagłówka VxLAN i problem MTU

Nagłówek VxLAN jest bardzo prosty w budowie. Składa się tylko z czterech pól:

  • Pole 1: zarezerwowane na potrzeby przyszłych zastosowań, 8 bitów, wszystkie wyzerowane
  • Pole 2: VNI, 24 bity
  • Pole 3: zarezerwowane na potrzeby przyszłych zastosowań, 24 bity
  • Pole 4: flagi, 8 bitów ustawionych na 0 z wyjątkiem bitu trzeciego, który jest ustawiony na binarne 1 i oznacza poprawny nagłówek VxLAN

Można zatem policzyć, że nagłówek VxLAN ma łącznie aż 8 bajtów rozmiaru. Jeżeli doliczymy poszczególne nagłówki, które są dodatkowo dokładane w procesie enkapsulacji VxLAN to okaże się, że nasza oryginalna ramka urosła aż o 50 bajtów w przypadku IPv4 (70 bajtów w przypadku IPv6)! Na tę sumę składają się:

  • FCS usunięty z oryginalnej ramki: -4B
  • nagłówek VxLAN: +8B
  • nagłówek UDP: +8B
  • nagłówek IPv4: +20B (IPv6 +40B)
  • nagłówek Ethernet i nowy FCS: +18B

W takiej sytuacji zdecydowanie wykraczamy poza standardowe MTU i niesamowicie istotne jest włączenie jumbo frames na wszystkich urządzeniach sieci podkładowej! Jeżeli tego nie zrobimy to będziemy mieli do czynienia z fragmentacją co przełoży się na znaczne spadki w wydajności całego rozwiązania.

Na koniec spójrzmy jeszcze na konstrukcję całej zenkapsulowanej ramki VxLAN:

Konstrukcja ramki VxLAN
Konstrukcja ramki VxLAN

Trzeba przyznać, że jest tych pól całkiem sporo.

Uff… mam nadzieję, że udało Ci się wytrwać do tego miejsca 🙂 Tym sposobem dochodzimy do końca pierwszej części poświęconej VxLAN. Mam nadzieję, że Ci się spodobało? Jeżeli tak to daj znać w komentarzu, przy tworzeniu takich materiałów przyda się każda motywacja 🙂 W kolejnych materiałach przyjrzymy się w jaki sposób VTEP-y uczą się mapowań MAC-VTEP i zgłębimy jeszcze bardziej szczegółowo sposób w jaki działają VxLANy. Zachęcamy do subskrypcji naszego newslettera a na pewno nie przegapisz tych publikacji!

Jaki temat w Twojej opinii powinienem poruszyć po omówieniu VxLAN?

👊 Dziękujemy Patronom!

Materiał powstał dzięki wsparciu naszych Patronów. Spodobała Ci się ta publikacja i chcesz aby pojawiało się więcej takich treści? Wesprzyj “Na Styku Sieci” na Patronite.

🗳 Jak przydatna była ta publikacja?

Średnia ocena / 5. Ilość głosów:

Dziękuję za ocenę! Zapraszam Cię do obserwowania NSS w mediach społecznościowych!

Przykro mi, że ta publikacja okazała się być dla Ciebie nieprzydatna!

Uwaga: Twój głos będzie liczony tylko jeśli udzielisz feedbacku używając formularza poniżej.

author avatar
Damian Michalak

Network Consultant, Twórca Na Styku Sieci

Twój adres email nie zostanie opublikowany. Wszystkie pola są wymagane

Subscribe
Powiadom o
guest
25 Comments
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
Bartek

Mi się przydało -dzięki! Wpisuje stronę do ulubionych i czytam 🙂

Robert

Fajny tekst, bardzo przydatny – dzięki!

Mati

Jak vxlany mają się do sieci MPLS i tuneli VPLS/VPWS? Czy działanie nie jest tutaj bardzo podobne? Co przemawia na korzyść jednego rozwiązania, a co na korzyść drugiego? Zakładając, że urządzenia z których korzystamy wspierają zarówno MPLS L2VPN oraz VXLAN.

dawid

Tłumaczenia fabric
tkanina, materiał, budowla, struktura, materia, gmach, kadłub, masyw

Pewne wyrazy w różnych językach mają uogólnione znaczenie nie tłumaczące się na jeden jedyny wyraz w innym języku – czytając powyższy zestaw wyrazów z uruchomioną wyobraźnią chyba nie tak trudno znaleźć ten wspólny sens znaczeniowy i wybrać z polskich wyrazów najlepiej pasujący do konkretnego przypadku – tu, to moim zdaniem “struktura”.

Warto też zauważyć, że fabric nie ma nic wspólnego z factory, plant czy manufacture. Więc co za kretyn wymyślił fabrykę ?!?!?!?! A jak będziesz pisał artykuł o kryptografii to będziesz pisał o kurwach eliptycznych??

Damian Michalak

Moja reakcja na ostatnie zdanie – 😂. Dzięki za wywód Dawid 😁

Marcel

Przeczytałem artykuł pobieżnie tylko ale wydaje się, że znowu Cisco próbuje wymyślać koło od nowa nadając mu tylko inną nazwę.

Takie rozwiązania były stosowane w sieciach operatorskich w L2 i zapewne dalej są od ok 2008 roku. I o ile dobrze zrozumiałem zamysł tego VxLAN-u to jest to to samo co: TRILL, SPB, Q-in-Q, MAC-in-MAC i wszystkie inne technologie, które starają się przenieść protokół routingu do warstwy łącza danych.

Damian Michalak

Nie ulega wątpliwości, że (jak zawsze) trochę marketingu w tym jest 🙂 Owszem, cech wspólnych jest aż nadto i historia już nieraz zatoczyła koło.

czarek

VXLAN to zdecydowanie nie jest to samo co wymieniłeś. TRILL/FabricPath to MAC-in-MAC encapsulation, za to VXLAN to MAC-in-UDP. Ma ta tą zalete, że działa na standardowym sprzęcie i nie wymaga dedykowanych urządzeń

damianos56

Zauważyłem,że poziom merytoryczny publikowanych artykułów jest na coraz wyższym poziomie.
Pozdrawiam i czekam na więcej;)

Damian Michalak

Staramy się 🙂 Pozdrawiam!

Sławomir Buczek

Czy przy zastosowaniu VxLAN’ów da się na przełączniku leaf skonfigurować dany port tak, aby działał jako port trunkowy 802.1q – w celu przyłączenia do niego kolejnej fizycznej sieci, w której istnieje kilka VLAN’ów (np. sieci budynku “A”, gdzie sieć działa na Cisco z PVST), a następnie te Vlany przetransportować poprzez VxLAN’y (przełączniki leaf i spine) do innego przełącznika leaf na jego port skonfigurowany również jako trunk 802.1q, w celu podłączenia do niego kolejnej fizycznej sieci (np. w budynku “B”) tak, aby przetransportować wszystkie VLAN’y z budynku A do budynku B?

Budynek A i B to 2 sąsiednie budynki (oddziały) tej samej firmy. W każdym z nich jest istniejąca infrastruktura na przełącznikach Cisco, a połączenie pomiędzy budynkami to trunk na światłowodzie, styk z Internetem tylko w budynku A. Ważne jest to, że w obu budynkach obecnie występują te same Vlany dla różnych grup pracowniczych.

Upraszczając pytanie, czy VxLANy (na przełącznikach leaf i spine) można zastosować np. w szkielecie sieci, do którego będą podłączone inne sieci fizyczne (a nie urządzenia końcowe – hosty) tak, aby zastąpić klasycznego trunk’a pomiędzy budynkiem A i B własnie VxLAN’em?
Pytam, gdyż mam wiele VLAN’ów do “przerzucania” między różnymi budynkami i ograniczenia dot. max. ilości instancji Spanning-Tree (w przełącznikach gdzie funkcjonuje PVST), zaczynają mieć znaczenie.

Damian Michalak

Odpowiem krótko – tak, jest to możliwe i właśnie taki jest jeden z podstawowych use-zase’ów tego rozwiązania. Zachęcam do przelobowania tego na przykład w Eve-NG 🙂

Tomasz Pilny

Dobry tekst żeby się zaznajomić z nowością. Czekam na kolejną część.

Damian Michalak

Dzięki

Cirad

Świetny artykuł, bardzo chwali się nakreślenie rysu historycznego i tego, co stało za powstaniem VxLANów. Świetnie, że wszystko tłumaczysz od początku! Moim zdaniem można nawet jeszcze dogłębniej wyjaśniać pewne kwestie lub dodawać fragmenty konfiguracji omawianych rozwiązań z rzeczywistych ruterów. Ale może takie rzeczy kolejnej – bardziej szczegółowej części.
Jako kolejny temat do dogłębnej analizy przeprowadzonej od samego początku proponuję EVPN.

Damian Michalak

@@cirad:disqus Dzięki, cieszę się, że się spodobało. W następnej części planuję właśnie poruszyć EVPN i tam bez przykładów konfiguracji zdecydowanie się nie obędzie 🙂

Adam

Dzięki za ciekawy artykuł. Chętnie poczytałbym też o best practice związanych z wdrożeniem vxlan. Wskazówki na temat dobierania hardware i konfiguracji. Na jakie pułapki oprócz MTU uważać. Jakich problemów można się spodziewać przy migracji tradycyjnej (Core Distribution Access) sieci do wersji vxlan.

Damian Michalak

Dzięki @Adam, dopisane do listy potencjalnych tematów. Jestem wdzięczny za sugestię 🙂

Michał

Fabric to też tkanina… tak jak space-time fabric… i na pewno w tym kontekście jest to używanie a nie jakaś fabryka… dobrze zmyślasz… lol… Ale artykuł spoko… za dużo w Polszy chyba się kłania…

Damian Michalak

Z tym zmyślaniem to akurat pochopnie wycignięty wniosek! Pozwól, że wytłumaczę: odkąd tylko Cisco zaczęło używać angielskojęzycznego słowa “fabric” trzymałem się go kurczowo i nie pozwalałem sobie na jakieś wybiegi po polsku bo zwyczajnie brakowało dobrego tłumaczenia. Nigdy też mi osobiście nie przyszło do głowy aby używać słowa “fabryka”. Sytuacja się natomiast zmieniła odkąd w zeszłym roku na trzech kolejnych konferencjach Cisco usłyszałem właśnie określenie “fabryka”. Co więcej, słowa te padały z ust pre-sales’ów!

Jesteś natomiast już kolejną osobą, która mi na to zwróciła uwagę. Biję się więc w pierś i usuwam te, jak się okazuje, rażące spolszczenie. Jak widać nie ma zgody co do używania tego terminu w takiej formie więc może faktycznie, nie będę go propagował również i tu.

Dzięki @Michał!

Hiena

Zgadzam się z Michałem, iż Fabric odnosi się do tkaniny. Echo tego możemy zobaczyć w wytłumaczeniu nazwy oprogramowania Tungsten Fabric – chodzi o tkaninę zrobioną z tungstenu, która wytrzyma więcej niż cokolwiek innego 🙂 https://tungsten.io/opencontrail-is-now-tungsten-fabric/

Wojtek

Ta “fabryka” to jakiś koszmar jest. Gdyby mi to opowiadano u jakiegoś dystrybutora, przy kawie i ciastku, to bym chyba go wyśmiał. Ale jak słyszałem (tak jak Ty) to słowo z ust inżynierów polskiego oddziału Cisco, to mi się zrobiło słabo.
A przecież słowo “tkanina” nie dość, że jest poprawnym tłumaczeniem, to jeszcze ładnie oddaje istotę struktury.
Zwalczajmy “fabryki”, promujmy “tkaniny”! 😉

Damian

Czy jeżeli ACI Fabric to “tkanina” to czy można nazwać inżyniera ACI “przędzarzem”? 🤔 Taki luźny pomysł 😀 “Tkanina” faktycznie lepiej to oddaje, ale i tak nadal mi “nie leży na uchu”. Ja bym został przy angielskim “Fabric” i tyle 🙂

RiFF

Yeah, zajebisty artykuł . Fajnie że opisałeś to od początku , czekam na ciąg dalszy 😉

Damian Michalak

Temat na tyle ciężki, że dobrze jest na niego spojrzeć z perspektywy 🙂

Top