Wirtualne sieci lokalne[1] to już chyba standard w sieciach każdej wielkości (chodzi oczywiście o sieci komputerowe, no i może o sieci jednak większe od sieci domowych). Mój ulubiony hypervisor - Xen - daje co najmniej dwie możliwości podejścia do tematu łączenia hostowanych maszyn wirtualnych z konkretnymi sieciami vlan[3]. Pierwsze zgodne z "Unix philosophy" - "Write programs that do one thing and do it well"[2] - czyli w tym przypadku należy to rozumieć jako: Xen nie jest od TEGO, więc Xen nic tu nie pomoże. Drugie, trochę mniej zasadnicze, wykorzystujące do przygotowania odpowiedniej konfiguracji interfejsów sieciowych zmodyfikowany skrypt network-bridge, wchodzący w skład standardowej instalacji Xen-a. Osobiście uważam, że bardziej eleganckie jest podejście pierwsze (szczególnie przy wykorzystaniu "nowszej" składni niż opisana w art.[3], której przykład można znaleźć w art.[4]) , ale niestety w większości przypadków wykorzystuję "szybsze" podejście drugie - jednak mam nadzieję, że to się zmieni :) Tak naprawdę wykorzystuję pewną "wariację" podejścia drugiego, zamiast modyfikować skrypt własnoręcznie wykorzystuję skrypt znaleziony kiedyś w sieci (dawno, dawno temu) pod adresem: http://renial.net/repository/perma/xen/network-bridge-vlan, artykuł opisujący wykorzystanie skryptu znajduje się tutaj:
http://renial.net/weblog/2007/02/27/xen-vlan (swoją drogą jest to ostatni, w sumie z dwóch, artykułów na tym blogu - http://renial.net/weblog, szkoda, zważywszy że ten jest całkiem udany). Zanim przejdę dalej krótko jeszcze wspomnę o rozwiązaniu "hybrydowym" (przynajmniej tak mi to wygląda): http://www.pixelchaos.net/2008/07/16/vlan-bridging-in-xen/, czyli możliwości uzyskania żądanego efektu mamy sporo i każdy może wybrać najbardziej mu odpowiadający sposób - świat GNU z pewnością nie jest liniowy :)
Wracając do skryptu network-bridge-vlan[5] (link również powyżej) - jest w nim jedna rzecz która mnie zastanawia. Przy zalecanej modyfikacji skryptu network-bridge[3] (druga z metod opisanych na Xen wiki, o których wspomniałem powyżej) autor nic nie wspomina o adresacji (w sensie adresów MAC) "vlan-owych" interfejsów sieciowych, z tego co widzę po przeglądnięciu modyfikacji, zostanie zachowane standardowe działanie skryptu network-bridge, które spowoduje przypisanie oryginalnego adresu MAC fizycznego interfejsu sieciowego wszystkim jego utworzonym instancjom (zarówno tworzonym przez polecenia brctl jak i vconfig). Autor skryptu network-bridge-vlan zmienia jednak tę politykę w 128 linii skryptu zapisując polecenie:
ip link set ${vlandev} address ee:ff:ff:ff:ff:ff
Niby nic, a jednak moim zdaniem komenda ta wnosi trochę niepotrzebnego zamieszania. Mamy tutaj przypisanie do vlan-owego interfejsu adresu MAC "ee:ff:ff:ff:ff:ff" - najpierw zauważmy jedną rzecz - jak podaje wikipedia[6] drugie 'e' ma szczególne znaczenie: 0xe binarnie to: 1110, a znak (binarna cyfra) drugi od prawej określa czy:
- adres jest globalny
- adres jest lokalny
- tak naprawdę nie to ma dla mnie największe znaczenie, ale warto o tym wspomnieć, bo ewidentnie intencją autora było, aby określić MAC adres interfejsu jako "lokalny". Wszystko będzie pięknie działać dopóki temu vlan-owemu interfejsowi w systemie hosta (dom0) nie przypiszemy adresu ip (nazwijmy ten adres IP1) w sieci, w której istnieje drugi serwer fizyczny z Xen-em, wykorzystujący skrypt network-bridge-vlan, i posiadający adres ip (nazwijmy go IP2) przypisany do vlan-owgo interfesju w dom0 :) Fakt, trochę trzeba tych warunków spełnić, ale jak już je spełnimy to czekają nas oczywiste problemy sieciowe w komunikacji z tymi dwoma adresami ip (IP1 i IP2) - przecież mamy ten sam adres MAC (ee:ff:ff:ff:ff:ff) przypisany do dwóch interfejsów z różnymi adresami ip!
No dobrze, ale przecież to "lokalny" MAC adres (ee:ff:ff:ff:ff:ff), wiec dlaczego wykorzystuję go jako globalny? Moja wina, autor widocznie nie przewidział (nie pomyślał o tym), że vlan-owym interfejsom w dom0 będę chciał przypisywać adresy ip. Oczywiście tak, ja się zgadzam, że to najprawdopodobniej JA staram się zrobić coś wbrew założeniu, a nie że jest to błąd w skrypcie, ale nie mogę zrozumieć korzyści jakie dodanie tej komendy przyniosło - po prostu żadnych nie widzę. Pomijając tę komendę w skrypcie (wymazując ją) zyskujemy idealne rozwiązanie dla każdej z sytuacji - vlan-owy interfejs zyskuje MAC adres interfejsu fizycznego (OUI), nie przeszkadza mu to w komunikacji lokalnej, oraz umożliwia bezproblemową komunikację globalną! :) Czyli naprawiamy nasze problemy sieciowe w komunikacji z adresami IP1 i IP2 poprzez usunięcie tej linii ze skryptu.
Zastanawia więc, co autor miał na myśli? Postaram się go zapytać :). Oczywiście jeżeli ktoś z czytających znalazł by powód/korzyści z wymuszenia przypisania adresu ee:ff:ff:ff:ff:ff vlan-owym interfejsom to bardzo proszę o komentarz lub kontakt. Ja w używanej przez siebie wersji skryptu network-bridge-vlan stawiam jednak na początku tej linii znak komentarza.
[1] http://pl.wikipedia.org/wiki/Wirtualna_sie%C4%87_lokalna
[2] http://en.wikipedia.org/wiki/Unix_philosophy
[3] http://wiki.xen.org/wiki/Xen_Networking#VLANs
[4] http://www.syneus.net/debian-xen-networking-vlan
[5] http://renial.net/repository/perma/xen/network-bridge-vlan
[6] http://en.wikipedia.org/wiki/MAC_address