Virtual Extensible LAN (od ang. Virtual eXtensible Local Area Network – VXLAN) – technologia wirtualizacji sieci służąca do tworzenia nakładkowych sieci warstwy 2 nad infrastrukturą warstwy 3. Protokół ten pozwala na przenoszenie ramek Ethernet przez sieć IP w sposób umożliwiający logiczną izolację wielu segmentów sieciowych w jednej domenie administracyjnej^[1].

VXLAN opisany jest jako dokument o charakterze informacyjnym, a nie jako standard internetowy. W abstrakcie dokumentu wskazano, że protokół odpowiada na potrzebę budowy sieci overlay w zwirtualizowanych centrach danych obsługujących wielu najemców, a także może być stosowany w sieciach dostawców usług chmurowych i w centrach danych przedsiębiorstw^[1].

Specyfikacja VXLAN została opublikowana przez IETF w sierpniu 2014 roku jako RFC 7348.^[1] W późniejszych dokumentach IETF protokół był omawiany w kontekście Ethernet VPN (EVPN) jako części architektury Network Virtualization Overlay (NVO). RFC 8365 opisuje EVPN jako rozwiązanie NVO oraz analizuje wpływ różnych metod enkapsulacji nad IP, w tym VXLAN, na płaszczyznę sterowania i procedury EVPN.^[2]

VXLAN wykorzystuje enkapsulację ramek Ethernet w datagramach UDP/IP. Urządzenie kończące tunel VXLAN nosi nazwę VTEP (VXLAN Tunnel End Point) i odpowiada za enkapsulację oraz dekapsulację ruchu^[1].

Każdy segment VXLAN identyfikowany jest przez 24-bitowy identyfikator VNI (VXLAN Network Identifier)(inne języki). Pozwala to na współistnienie do około 16 milionów segmentów VXLAN w tej samej domenie administracyjnej. Ramki należące do różnych segmentów VXLAN nie powinny się ze sobą komunikować^[1].

Zewnętrzny adres IP wskazuje VTEP realizujący enkapsulację, natomiast docelowy adres IP może być unicastowy albo multicastowy. W celu ułatwienia równoważenia obciążenia ECMP zaleca się wyznaczanie portu źródłowego UDP na podstawie skrótu pól pakietu wewnętrznego^[1].

W przypadku przesyłania ruchu rozgłoszeniowego (np. zapytań ARP), gdy docelowy adres MAC urządzenia końcowego nie jest jeszcze znany, proces mapowania i komunikacji w architekturze VXLAN przebiega w następujących krokach widocznych na schemacie:

1. Host A wysyła standardową ramkę rozgłoszeniową warstwy 2 do lokalnego punktu końcowego VTEP 1.
2. VTEP 1 enkapsuluje ramkę w pakiet IP, kierując go na adres grupy multicastowej powiązanej z danym VNI. Sieć podkładowa (underlay) dystrybuuje ten pakiet do wszystkich VTEP-ów w tej grupie (VTEP 2 i VTEP 3).
3. Urządzenia VTEP 2 i VTEP 3 odbierają pakiet, dekapsulują go, zapamiętują lokalizację Hosta A (adres IP urządzenia VTEP 1) i przekazują czystą ramkę do swoich lokalnych portów.
4. Host B odbiera zapytanie i przygotowuje odpowiedź.
5. Odpowiedź Hosta B jest przesyłana jako ruch jednokierunkowy (Unicast). VTEP 2 zna już lokalizację Hosta A z kroku 3, więc enkapsuluje ramkę i wysyła ją bezpośrednio na adres IP urządzenia VTEP 1, omijając mechanizm multicastu.
6. VTEP 1 odbiera pakiet unicastowy, uczy się lokalizacji Hosta B (VTEP 2), usuwa nagłówki i dostarcza czystą ramkę Ethernet bezpośrednio do Hosta A. Kolejne pakiety między tymi hostami są już przesyłane wyłącznie za pomocą bezpośrednich tuneli unicastowych.

Nagłówek VXLAN ma długość 8 bajtów. Zawiera pole Flags o długości 8 bitów; bit I musi mieć wartość 1, a pozostałe 7 bitów jest zarezerwowanych i musi być wyzerowanych podczas transmisji^[1].

Kolejnym polem jest 24-bitowy identyfikator VNI. Pozostałe pola zastrzeżone w nagłówku również muszą być wyzerowane podczas transmisji i ignorowane po odebraniu^[1].

Domyślny port docelowy UDP dla VXLAN to 4789. IANA zarejestrowała ten port dla usługi VXLAN, a RFC 7348 zaleca jego użycie jako wartości domyślnej, przy jednoczesnej możliwości konfiguracji innego portu w celu współdziałania ze starszymi implementacjami^[3][1].

RFC 7348 zaleca również, aby VTEP-y nie fragmentowały pakietów VXLAN. Sieć fizyczna powinna mieć takie MTU, aby uwzględniało ono narzut enkapsulacji^[1].

VXLAN został zaimplementowany przez wielu producentów sprzętu i oprogramowania. Dokumentacja jądra Linuksa opisuje implementację VXLAN jako urządzenie tunelowe, wskazując, że protokół działa nad UDP z pojedynczym portem docelowym oraz że obok implementacji w jądrze istnieje osobna implementacja dla Open vSwitch. Dokumentacja Linuksa podaje również, że węzeł VXLAN może uczyć się zdalnych adresów IP dynamicznie albo korzystać ze statycznie skonfigurowanych wpisów przekazywania^[4].

Open vSwitch dokumentuje VXLAN jako mechanizm overlay przenoszący sieć warstwy 2 przez istniejącą sieć warstwy 3. W dokumentacji dostępny jest także emulator VTEP (ovs-vtep), czyli narzędzie do symulowania punktów końcowych VXLAN w środowisku.^[5][6]

Cisco publikuje przewodniki konfiguracji VXLAN dla platform Nexus 9000 i opisuje wdrożenia VXLAN BGP EVPN w centrach danych. W dokumentacji Cisco znajdują się między innymi przykłady konfiguracji underlay, overlay, BGP EVPN oraz funkcji bezpieczeństwa związanych z VXLAN.^[7][8]

VXLAN został zaprojektowany jako odpowiedź na ograniczenia klasycznych sieci VLAN, zwłaszcza w środowiskach wielodzierżawnych i w dużych centrach danych. W RFC 7348 problem ten opisano w kontekście ograniczeń związanych z zakresami VLAN, spanning tree i rozmiarem tablic w przełącznikach typu top-of-rack.^[1]

Dla porównania, VLAN korzysta z 12-bitowego identyfikatora VID. RFC 4363 definiuje VLAN-ID jako 12-bitowy identyfikator używany w nagłówku VLAN Tag, a zakres wartości odpowiada identyfikatorom od 1 do 4094.^[9]

Do technologii pokrewnych należą NVGRE oraz Geneve. RFC 8365 analizuje VXLAN i NVGRE jako jedne z opcji enkapsulacji nad IP w architekturach EVPN.^[2]

Geneve jest opisywany w RFC 8926 jako protokół enkapsulacji zaprojektowany z myślą o zmieniających się wymaganiach sieci wirtualizacyjnych i stanowi dokument standardu Internet Standards Track(inne języki).^[10]

Rozszerzeniem związanym z VXLAN jest VXLAN-GPE (Generic Protocol Extension for VXLAN), opisane w dokumentach roboczych IETF. W dokumentach tych wskazano dodatkowe możliwości, takie jak obsługa wielu protokołów, sygnalizacja OAM, ingress-replicated BUM traffic(inne języki) oraz jawne wersjonowanie. Rejestr IANA przypisuje VXLAN-GPE port UDP 4790.^[11][12]

RFC 7348 wskazuje, że przenoszenie ruchu warstwy 2 przez mechanizm MAC-over-IP zwiększa powierzchnię ataku. W dokumencie opisano między innymi ryzyko podsłuchu, wstrzykiwania sfałszowanych pakietów oraz ataków typu denial-of-service^[1].

Wśród środków ograniczających ryzyko RFC 7348 wymienia kontrolę administracyjną nad wdrożeniem maszyn wirtualnych i VTEP-ów, mechanizmy takie jak 802.1X, wykorzystanie ACL opartych na pięciu polach oraz możliwość zabezpieczenia ruchu za pomocą IPsec^[1].

Do praktycznych ograniczeń należą również narzut enkapsulacji, konieczność odpowiednio dobranego MTU oraz zależność od funkcjonowania sieci underlay. W przypadku scenariuszy korzystających z multicastu istotne są także wymagania dotyczące prawidłowej konfiguracji ruchu rozgłoszeniowego^[1][2].

• Mahalingam, M. i in., Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks, RFC 7348, IETF, 2014.
• Sajassi, A. i in., A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN), RFC 8365, IETF, 2018.
• Boutros, S. i in., Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN), RFC 8971, IETF, 2021.
• Gross, J. i in., Geneve: Generic Network Virtualization Encapsulation, RFC 8926, IETF, 2020.
• Internet Assigned Numbers Authority, Service Name and Transport Protocol Port Number Registry.
• Virtual eXtensible Local Area Networking documentation — The Linux Kernel documentation
• Open vSwitch documentation, VXLANs.
• Cisco Systems, Cisco Nexus 9000 VXLAN BGP EVPN Data Center Fabrics Fundamental Design and Implementation Guide.