Więcej

    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 🙂 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 🙂

    A Ty, widzisz zastosowanie technologii VXLAN w Twojej sieci?

    🗳 Jak przydatna była ta publikacja?

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

    Brak ocen. Bądź pierwszy!

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

    Przykro nam, ż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.

    Jak możemy poprawić tę publikację?

    Damian Michalak
    Network Consultant, Twórca Na Styku Sieci

    30 KOMENTARZE

    guest
    30 - Ilość komentarzy
    Sortuj wg najstarszych
    Sortuj wg najnowszych Sortuj wg najlepszych
    Inline Feedbacks
    View all comments
    RiFF

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

    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…

    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\”! 😉

    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.

    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.

    Tomasz Pilny

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

    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.

    damianos56

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

    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.

    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ń

    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??

    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.

    Robert

    Fajny tekst, bardzo przydatny – dzięki!

    Bartek

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

    Pavlo

    Damian kiedy powstanie część druga artykułu o VXLAN ?

    Przygotowujesz się do certyfikacji CCNA?

    Zapisz się na nasz NSSletter, a co tydzień we wtorek rano otrzymasz porcję sieciowej wiedzy oraz porady dotyczące certyfikacji.

    Uzupełniając powyższe pole wyrażasz zgodę na otrzymywanie od GetGoodNet Damian Michalak z siedzibą we Wrocławiu newslettera zawierającego treści edukacyjne. Zgodę możesz wycofać w każdym czasie.

    NSS na Social Media

    1,611FaniLubię
    72ObserwującyObserwuj
    133ObserwującyObserwuj
    1,220SubskrybującySubskrybuj

    Najnowsze artykuły

    spot_img

    Może Cię też zainteresować...

    30
    0
    Co sądzisz na temat tej publikacji? Zostaw proszę komentarzx
    ()
    x