Obecne stadium rozwoju VXLAN jest dość wczesne, przez co protokół ten ma jeszcze pewne braki. Obecnie jedynymi stosami sieciowymi, które mogą aktywnie brać udział w tworzeniu sieci opartych na VXLAN są Cisco Nexus 1000V oraz Open Vswitch. Nie ma praktycznie żadnych fizycznych urządzeń sieciowych, które mogą pracować jako Virtual Tunnel Endpoint (VTEP). Jeśli będziemy chcieli wprowadzić routing L3, aby zapewnić komunikację między różnymi VXLAN-ami, trzeba zaprząc do tej pracy wirtualną maszynę.

Niestety, nie są dostępne również żadne wirtualne routery (wirtualne appliance), pozwalające natywnie na partycypację w VXLAN. Obecnie jedynym sposobem na umożliwienie wirtualnemu routerowi połączenia z różnymi VXLAN-ami jest podłączenie wirtualnych kart sieciowych NIC do appliance routera dla każdego z VXLAN-ów. To nie tylko kłopotliwe, ale może także mieć ograniczone zastosowanie z racji tego, że vSphere limituje obsługę wirtualnych kart sieciowych na wirtualną maszynę do 10. W skomplikowanym środowisku może to nie być wystarczające i trzeba będzie uruchamiać po kilka routerów appliance na osobnych wirtualnych maszynach.

Zobacz również:

• 5 priorytetów, które obniżają koszty chmury i usprawniają operacje IT

Poza niewątpliwą korzyścią w postaci braku zmian w konfiguracji fizycznej sieci, obecnie wykorzystanie VXLAN w tym przypadku jest nieco problematyczne.

Rozwiązanie 3: VLAN-y i wirtualny router

Ostatnie podejście polegało w teście na stworzeniu zduplikowanego zestawu VLAN na fizycznych urządzeniach sieciowych i skonfigurowaniu wirtualnej sieci drugiego centrum danych do komunikacji z nimi. Zamiast tworzyć nowy VRF na przełącznikach rdzeniowych, do routingu VLAN wykorzystano router virtual appliance. W porównaniu z poprzednim rozwiązaniem różnica w tym przypadku jest taka, że router nie musi pracować jako punkt końcowy VXLAN.

Skonfigurowano wirtualny router z pojedynczą wirtualną kartą sieciową, jako trunk dla VLAN - technika znana pod nazwą Virtual Guest Tagging (VGT) - element brakujący w układance VXLAN. Taka wirtualna karta sieciowa NIC może mieć skonfigurowanych wiele wirtualnych interfejsów (jeden dla każdego VLAN), co pozwala na pracę jako domyślna brama dla wielu różnych sieci. Taka konfiguracja może niestety mieć niewystarczającą wydajność w niektórych środowiskach produkcyjnych, ale dla testowego zupełnie wystarczy.

Kompromisowe, trzecie rozwiązanie nie jest wolne od wad, ale sam proces dojścia do niego wykazał ograniczenia nowej technologii, jaką jest VXLAN.

Pomimo pewnych problemów z wykorzystaniem VXLAN w ramach obecnej oferty produktowej, należy docenić jego potencjał. W implementacji Nexus 1000V Cisco wykorzystało połączenie API z vSwitchem, co pozwala zewnętrznym usługom na automatyczne tworzenie segmentów VXLAN. Obecnie taka możliwość jest wykorzystywana jedynie w połączeniu z VMware vShield Edge oraz vCloud Director do automatyzacji wdrażania instancji chmur publicznych i prywatnych. Pozostaje nam jedynie czekać, aż powstanie produkt, który wykorzysta tę możliwość do uruchomienia pełnego router virtual appliance i zintegrowania z Nexus 1000V czy innym programowym przełącznikiem. Wtedy rozwiązanie dynamicznego uruchamiania segmentów L2 i routingiem L3 będzie pełne.