Więcej

    FlexConnect vs local mode

    spot_img

    Dobrze zaprojektowana sieć pozwoli spełnić wszelkie wymagania klienta oraz ograniczyć wykorzystanie zasobów i koszty po stronie operatora sieci. W przypadku sieci bezprzewodowych na przeciw siebie stają przede wszystkim dwie jakże różne metody wdrożenia – FlexConnect i Local Mode. W tym artykule przedstawiam Ci sposób działania i cechy obu sposobów.

    Przepływ ruchu w sieci bezprzewodowej

    Sieć bezprzewodowa w środowisku Enterprise może składać się z tysięcy Access Pointów. W takim przypadku szczególnie ważne jest choćby częściowe zautomatyzowanie konfiguracji i ułatwienie zarządzania całą infrastrukturą Wi-Fi. W tym celu można wykorzystać WLAN Controller (w skrócie nazywany WLC), który jest centralnym punktem dowodzenia siecią bezprzewodową.

    W dużym skrócie działa to tak:

    • instalujemy WLAN Controller w naszej sieci,
    • na WLC tworzymy domyślną konfigurację dla Access Pointów,
    • instalujemy Access Pointy,
    • Access Pointy łączą się specjalnym tunelem z WLC i pobierają domyślną konfigurację,
    • Access Pointy działają zgodnie z otrzymaną konfiguracją,
    • wszelkie zmiany konfiguracji wykonujemy tylko na WLC.

    W takim środowisku pojawia się bardzo ważna kwestia – przepływ ruchu danych z i do użytkowników bezprzewodowych. Zgodnie z nomenklaturą Cisco w sieci korzystającej z WLAN Controllera możemy wyróżnić dwie metody wdrożenia – FlexConnect i Local Mode. Na szczęście wielu innych producentów sprzętu również dostarcza podobne funkcjonalności, które po prostu kryją się pod innymi nazwami. Dlatego też obie metody przedstawię w sposób jak najmniej uzależniony od modelu sprzętu, skupiając się głównie na idei obu rozwiązań. Zatem do dzieła!

    Local Mode

    W tym trybie w pełni wykorzystujemy potencjał i możliwości WLAN Controllera. Jest to naturalny wybór ze względu na prostotę implementacji i samej idei tego rozwiązania. U wielu producentów był on dostępny jako pierwszy i jednocześnie domyślny tryb działania Access Pointów.

    Architektura sieci WLAN z użyciem WLAN Controllera wydziela dwa rodzaje ruchu związanego z siecią bezprzewodową:

    • ruch kontrolny i zarządzania – wszelka komunikacja pomiędzy WLC i Access Pointem, która pozwala sterować jego pracą i zbierać statystyki, ponadto ruch związany z uwierzytelnianiem użytkowników Wi-Fi itp.,
    • ruch danych – faktyczny ruch danych z i do użytkowników bezprzewodowych.

    W trybie Local Mode oba rodzaje ruchu przesyłane są specjalnym tunelem pomiędzy Access Pointem i WLAN Controllerem. Taką sytuację obrazuje poniższy rysunek:

    Przepływ ruchu w trybie Local Mode
    Przepływ ruchu w trybie Local Mode

    Access Point zarządzany jest z poziomu WLAN Controllera, więc cały ruch kontrolny i zarządzania wysyłany jest specjalnym tunelem pomiędzy nimi (linia czerwona). Dodatkowo pokazany został przepływ danych pomiędzy użytkownikiem A i użytkownikiem B (linia fioletowa).

    „Czy wiesz że…?”

    W przypadku Cisco tym specjalnym tunelem jest CAPWAP, czyli otwarty protokół wykorzystujący datagramy UDP. Pośród rozwiązań innych producentów można spotkać tunele GRE, a także protokoły własnościowe spełniające taką samą rolę co CAPWAP.

    Ale zanim dojdzie do komunikacji między użytkownikami to muszą się oni podłączyć do Wi-Fi. Za przykład weźmy sieć zabezpieczoną mechanizmem dot1x. W takim przypadku Access Point przesyła całą komunikację w ramach uwierzytelniania do WLAN Controllera, który pełni rolę autentykatora i przesyła zapytania do serwera RADIUS w imieniu użytkownika. Podobnie będzie to wyglądać w sieci zabezpieczonej PSK, w tym sensie, że Access Point tylko prześle komunikację dalej do WLAN Controllera. Różnica polegać będzie na tym, że zapytania dotrą tylko do WLC, który zdecyduje o ich zaakceptowaniu bądź odrzuceniu.

    Po udanym podłączeniu do sieci bezprzewodowej użytkownicy mogą rozpocząć komunikację między sobą. Przykładem może być zwykły ping od użytkownika A do użytkownika B. Jak widzisz na powyższym rysunku, mimo że obaj klienci podłączeni są do tego samego Access Pointa to ruch musi zostać wysłany do WLC i dopiero wtedy określana jest jego faktyczna destynacja. Stanie się tak nawet wtedy gdy obaj klienci podłączeni są do tego samego SSID. Mówiąc wprost możemy odstawić na bok szczegóły dotyczące sieci, VLANów i routingu. Najistotniejszą kwestią jest fakt, że wszelki ruch wysyłany jest do WLC, a Access Point oprócz pełnienia roli punktu dostępu do sieci staje się wyłącznie pośrednikiem danych.

    Na styku sieci LAN z Access Pointem sytuacja jest stosunkowo prosta. Cały ruch z AP do WLC wysyłany jest przy użyciu VLANu managementowego Access Pointa, możemy zatem użyć port accessowy. Przykładowa podstawowa konfiguracja na Switchu Cisco może wyglądać następująco:

    Switch#show running-config interface Gi1/0/1
     switchport mode access
     switchport access vlan 10    !Mgmt Access Pointa w VLAN 10

    Przejdźmy zatem do plusów i minusów takiego rozwiązania. Myślę, że większość z nich sama nasuwa się na myśl.

    Zalety

    • Prostota implementacji i wdrożenia – odpowiedni VLAN i sieć dla użytkowników musi znajdować się tylko w miejscu podłączenia WLC do LANu (lub na samym WLC). Dodatkowo dzięki temu wszystkie Access Pointy, nawet ze zdalnych lokacji, mogą oferować użytkownikom adresy z tej samej puli.
    • Pełna kontrola ruchu – odgrodzenie ruchu użytkowników bezprzewodowych od pozostałej części sieci, które szczególnie przyda się w przypadku tworzenia sieci Wi-Fi dla Gości. Więcej o koncepcji i architekturze Guest Wi-Fi przeczytasz w tym artykule.
    • Możliwość pełnego wykorzystania funkcjonalności WLC – niektórzy producenci w ramach WLC oferują dodatkowo wbudowaną funkcjonalność firewalla. Warunek jego użycia jest taki, że ruch musi przechodzić przez WLAN Controller.

    Wady

    • Niska wydajność – przykład z rysunku powyżej dobitnie pokazuje, że nie jest to rozwiązanie optymalne pod względem wydajności.
    • Wysoka utylizacja WANu – w przypadku, gdy Access Pointy ze zdalnych lokacji muszą wysyłać ruch do WLC.
    • Single Point of Failure – utrata WLC skutkuje całkowitą utratą Wi-Fi, konieczność wdrożenia redundantnych kontrolerów.

    Jak już wspomniałem, w zależności od vendora ten tryb działania można nazwać na wiele sposobów, oto niektóre z nich:

    • Local Mode – tryb lokalny z punktu widzenia WLAN Controllera.
    • Tunnel Mode – tryb tunelowany, bo ruch leci dedykowanym tunelem pomiędzy Access Pointem i WLC.
    • Centrally Switched – przełączany centralnie, czyli na WLC.
    • Bridged at WLC – przełączany na WLC.

    FlexConnect

    W celu zniwelowania problemów wynikających z wad poprzedniego trybu zaproponowano podejście o nazwie FlexConnect, które bardzo szybko zyskało popularność. Ponownie mamy do czynienia z dwoma rodzajami ruchu i ponownie używamy Access Pointów działających z WLAN Controllerem. Dlatego też ruch kontrolny i zarządzania pozostaje bez zmian. Natomiast przepływ ruchu danych jest kompletnym przeciwieństwem do trybu Local Mode.

    „Czy wiesz że…?”

    FlexConnect to nazwa używana przez Cisco. Co ciekawe, początkowo używano określenia REAP (Remote Edge Access Point), następnie H-REAP (Hybrid Remote Edge Access Point), by ostatecznie zmienić je na FlexConnect. Faktem jest także, że kolejne formy nazewnictwa wnosiły pewne zmiany w niuansach technicznych tego trybu.

    Poniższy rysunek przedstawia przepływ obu rodzajów ruchu korzystając z metody FlexConnect:

    Przepływ ruchu w trybie FlexConnect
    Przepływ ruchu w trybie FlexConnect

    Ponownie zaczynamy od momentu podłączenia użytkowników do sieci i już na tym etapie dostrzegamy różnicę. Oprócz metody uwierzytelniania centralnego znanej z trybu Local Mode, możliwe jest wybranie opcji uwierzytelniania lokalnego. W takim przypadku, korzystając z mechanizmu dot1x dla zabezpieczenia dostępu do sieci to Access Point staje się autentykatorem i komunikuje się z serwerem RADIUS w imieniu użytkownika. Dzięki temu komunikacja na etapie uwierzytelniania nie musi przechodzić przez WLC.

    Po udanym podłączeniu do sieci bezprzewodowej użytkownicy mogą rozpocząć komunikację między sobą. Za przykład ponownie może posłużyć zwykły ping od użytkownika A do użytkownika B. Różnica jest widoczna na pierwszy rzut oka – ruch nie musi iść do WLAN Controllera. Oczywiście bardzo istotne jest to, między jakimi sieciami bezprzewodowymi odbywa się komunikacja i jak są one skonfigurowane. Powyższy rysunek przedstawia sytuację, w której obaj użytkownicy podłączeni są do tego samego SSID skonfigurowanego w trybie FlexConnect – wtedy Access Point może sam przekierować ramkę do odbiorcy. W przypadku komunikacji między różnymi SSID działającymi w trybie FlexConnect konieczne może być skorzystanie z routingu, co w większości przypadków równać się będzie wysłaniu ruchu do lokalnego Routera lub Core’a.

    Na styku sieci LAN z Access Pointem sytuacja jest tym razem nieco trudniejsza. Ruch kontrolny i zarządzania między AP i WLC wysyłany jest nadal przy użyciu VLANu managementowego Access Pointa. Natomiast ruch użytkowników wysyłany jest od razu do LANu (bez użycia tunelu), zazwyczaj jako ramka otagowana dedykowanym VLANem. W związku z tym konieczne będzie użycie trunka. Przykładowa podstawowa konfiguracja na Switchu Cisco może wyglądać następująco:

    Switch#show running-config interface Gi1/0/1
     switchport trunk native vlan 10       !Mgmt Access Pointa w VLAN 10
     switchport trunk allowed vlan 10,50   !Ruch użytkowników w VLAN 50
     switchport mode trunk

    Przejdźmy zatem do plusów i minusów takiego rozwiązania.

    Zalety

    • Wysoka wydajność – ruch nie musi być wysyłany do WLC, może podążyć najkrótszą drogą do celu.
    • Niska utylizacja WANu – w przypadku Access Pointów na zdalnych lokacjach ruch nie wykorzystuje łącza WAN tak długo jak cel znajduje się lokalnie.
    • Możliwa redundancja na poziomie AP – niektórzy producenci oferują możliwość działania Access Pointów nawet po utracie połączenia z WLC. W tym przypadku szczególnie istotne może być wybranie metody lokalnego uwierzytelniania dla użytkowników.

    Wady

    • Trudniejsza implementacja i wdrożenie – wymagane jest dostarczenie odpowiedniego VLANu i dedykowanej sieci do każdego Access Pointa. Dodatkowo każdemu AP trzeba wskazać konfiguracyjnie do jakiego VLANu ma wrzucać użytkowników z danego SSID.
    • Trudniejsze utrzymanie serwisu – łatwa możliwość pomyłki, nieprzepuszczenie VLANu pomiędzy Switchami itp.
    • Brak oddzielenia od reszty sieci – nie mamy możliwości użycia standardowego rozwiązania dla Guest Wi-Fi.

    W zależności od vendora ten tryb działania można nazwać na wiele sposobów, oto niektóre z nich:

    • FlexConnect / REAP / H-REAP – nomenklatura Cisco.
    • Bridge Mode – w domyśle jako przeciwieństwo Tunnel Mode.
    • Locally Switched – przełączany lokalnie, czyli na AP.
    • Bridged at AP – przełączany na AP.

    Przedstawione tryby przepływu ruchu w sieci bezprzewodowej są przeciwstawne pod względem możliwych zalet i wad ich wdrożenia. Nie jest jednak powiedziane, że musisz rezygnować z jednego z nich. Zwyczajowym rozwiązaniem stosowanym przez wielu producentów jest wybieranie trybu działania per SSID. Oznacza to tyle, że ten sam Access Point może jednocześnie rozgłaszać dane SSID w trybie Local Mode, i inne SSID w trybie FlexConnect.

    Z jakiego trybu korzystasz częściej i dlaczego? Dostrzegasz jakieś inne zalety bądź wady?

    🗳 Jak przydatna była ta publikacja?

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

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

    Łukasz Kowalski
    Network Architect, Współtwórca Na Styku Sieci

    7 KOMENTARZE

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

    wydaje się że podejście w stylu FlexConnect jest bardziej przyszłościowe, już teraz widzimy że cisco prezentuje model wlc 9800, który jest umieszczony wirtualnie w chmurze, wcześniej takie rozwiązania miał np. Aerohive, czy nawet Meraki (ale to nie jest rozwiązanie enterprise). Jednak nie zgodzę się co do podanych wad, ponieważ: konfiguracja po stronie LANu może i jest trudniejsza ale nie demonizował bym tak tego podpunktu ponieważ sieci WLAN obecnie są integralną częścią sieci LAN więc najczęściej (bazując na moim doświadczeniu) sprawa wygląda tak że mamy przełącznik do którego i tak są doprowadzone odpowiednie VLANy (dla Hostów podłączonych po kablu) wiec jedyne co musimy zrobić to stworzyć interface TRUNK na tych portach na których mamy podpięte AP (co nie powinno sprawiać problemu). A co do problemu, związanego z sieciami Guest to najprościej rozwiązać ten problem wywalaniem tych userów do oddzielnego VLANu i logicznie oddzielić inne SSID dla nich. dodam jedynie że moje wiedze bazuje na głównie na doświadczeniach z wdrożeń Aerohive Networks (zdecydowana większość wdrożeń jakie wykonałem bazowała na tym producencie).

    Patryk

    Dzięki

    Moim zdaniem warto, uważam że mogę Ci dość rzeczowo opisać wady i zalety tego vendora ale nie tutaj, (forum publiczne) jeżeli chcesz proszę odezwij się na mojego maila, może urodzi się ciekawa dyskusja 🙂 ten producent zaczyna mieć coraz więcej do powiedzenia i to nie tylko w naszym kraju.

    Ale o jakich przypadkach dokładnie mówimy? Zazwyczaj mamy tak że u klienta typu enterprise jest open space, mampy tam powiedzmy 30 hostów końcowych do których jest kabel podciągnięty, klient chce się przesiąść na WiFi bo wygodniej więc podpinamy mu te 2-3 AP a VLAN dla pracowników jest już zrobiony (przecież hosty łączące muszą wpadać do tego samego wora), aczkolwiek problem leży bardziej na integracji z AD, Radiusem, itp. bo jednak musimy wiedzieć kto jest kim.

    Największy problem jest wtedy jak klient ma przełączniki które są nie zarządzane, to wtedy leżymy…

    A co do dostępu dla Gości to ja jestem zwolennikiem nie dawania niczego poza wyjściem do internetu na takiej sieci, więc tak VLAN idzie prosto do Firewalla…(i z takimi wdrożeniami miałem styczność)

    Prawda jest taka że wszystko zależy od klienta końcowego, jego specyfiki, przyzwyczajeń, zasobów portfela 😉 ale nie da się nie zauważyć trentu przenoszenia warstwy managementowej poza sieć i nie mówię tu tylko o przenoszeniu WLC.

    Swoje zdanie opieram tylko i wyłącznie na moim doświadczeniu zawodowym, może za rok dwa zmienię zdanie 🙂

    Patryk

    Rozumiem…
    Ja nie twierdzę że rozwiązanie bez kontrolerowe jest leprze, po prostu jest to ciekawa opcja, ale sporo osób jej unika z powodu braku chęci.
    Pozdrawiam, i czekam na więcej artykułów związanych z tematyką WiFi.

    Czarek

    Naprawdę świetnie przedstawiony problem i rozwiązanie – w komentarzach ciekawa dyskusja mogąca być uzupełnieniem treści 🙂 ale…. prowadząc polskiego bloga (świetnie wam idzie), poziom techniczny musi iść za polskim słownictwem, nie po to posiadamy polski słownik języka technicznego, aby na siłę kopiować angielskie słówka, tylko dlatego, że tak łatwiej… a potem powstają takie potworki kujące w oczy jak: \”managementowego\”, czy \”autentykatorem\”… M.Rej miał naprawdę racje 🙂

    Sprawdź swoją wiedzę z CCNA

    Otrzymuj nasz cotygodniowy mailing "Czwartest" i sprawdź swoją wiedzę rozwiązując wyzywające zadania z zakresu certyfikacji CCNA. Dasz radę?

    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
    134ObserwującyObserwuj
    1,220SubskrybującySubskrybuj

    Najnowsze artykuły

    spot_img

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

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