modified on 17 lis 2009 at 15:40 ••• 12 702 views

Routing Layer-2 dla sieci typu Mesh

Z MikroTik Wiki

  • Wymagania początkowe: wiesz czym jest WDS i do czego jest wykorzystywany
  • Wersje oprogramowania: 3.28+ (wcześniejsze wersje nie są kompatybilne)

Spis treści

Wstęp

HWMP+ jest MikroTikowym protokołem routingu warstwy 2 dla bezprzewodowych sieci siatkowych (mesh). Oparty jest o protokół Hybrid Wireless Mesh (HWMP) ze standardu IEEE 802.11s. Może być używany zamiast protokołów (Rapid) Spanning Tree w konfiguracjach sieci typu mesh aby zapewnić optymalny bezpętlowy routing (loop-free optimal routing).

Jednakże protokół HWMP+ nie jest kompatybilny z HWMP opisanym w IEEE 802.11s

Systemem dystrybucji używanym w Twojej sieci bezprzewodowej nie musi być Wireless Distribution System (WDS). Routing HWMP+ wspiera nie tylko interfejsy WDS ale także interfejsy ethernetowe w sieciach typu mesh. Możesz więc użyć prostego systemu dystrybucji opartym o ethernet, lub możesz łączyć łącza Ethernetowe i WDS!

Konfiguracja

/interface mesh

Konfiguracja interfejsów w sieci mesh.

admin-mac (MAC address, domyślnie: 00:00:00:00:00:00) -- administracyjnie przydzielony adres MAC, używany gdy ustawienie auto-mac jest wyłączone

arp (disabled | enabled | proxy-arp | reply-only; domyślnie: enabled) - konfiguracja address resolution protocol

'auto-mac (boolean, domyślnie: no) -- jeśli wyłączone, wartość z admin-mac będzie używana jako adres MAC interfejsu; w przeciwnym razie zostanie użyty adres portu jeśli porty są dostępne

hwmp-default-hoplimit (integer: 1..255) -- ilość maksymalnych skoków dla generowanych pakietów protokołu routingu; po przekroczeniu limitu pakiet HWMP+ zostanie odrzucony

hwmp-prep-lifetime (time, domyślnie: 5m) -- czas życia tras utworzonych z odebranych wiadomości PREP lub PREQ

hwmp-preq-destination-only (boolean, domyślnie: yes) -- określa, czy tylko odbiorca może odpowiedzieć na wiadomości HWMP+ PREQ

hwmp-preq-reply-and-forward (boolean, domyślnie: yes) -- określa, czy pośrednie węzły powinny przesyłać dalej wiadomośći HWMP+ PREQ po wysłaniu odpowiedzi. Użyteczne tylko gdy wyłączony jest parametr hwmp-preq-destination-only

hwmp-preq-retries (integer, domyślnie: 2) -- ile razy próbować wykryć ścieżke do adresu MAC zanim adres zostanie uznany za nieosiągalny

hwmp-preq-waiting-time (time, domyślnie: 4s) -- jak długo czekać na odpowiedź na pierwszą wiadomość PREQ. Czas oczekiwania kolejnych wiadomości PREQ rośnie ekspotencjalnie.

hwmp-rann-interval (time, domyślnie: 10s) -- jak czętso wysyłać wiadomości HWMP+ RANN

hwmp-rann-lifetime (time, domyślnie: 1s) -- czas życia tras stworzonych na podstawie wiadomości RANN

hwmp-rann-propagation-delay (number, domyślnie: 0.5) -- jak długo oczekiwać przez propagacją wiadomości RANN. Wartość wyrażona w sekundach.

mesh-portal (boolean, domyślnie: no) -- czy ten interfejs jest portalem do sieci typu mesh

mtu (number, domyślnie: 1500) -- maximum transmit units

name (string) -- nazwa interfejsu

reoptimize-paths (boolean, domyślnie: no) -- czy wysyłać okresowo wiadomości zapytania PREQ do znanych adresów MAC. Zalecane jest włączenie parametru gdy topologia sieci często się zmienia. Gdy nie odebrano odpowiedzi na zapytanie reoptymalizacji PREQ, określona ścieżka jest nadal przetrzymywana (dopóki nie ulegnie przedawnieniu).

/interface mesh port

Konfiuguracja portów interfejsu mesh.

hello-interval (time,domyślnie: 10s) -- maksymalny przedział czasu pomiędzy wysyłaniem wiadomości HWMP+ Hello. Używane tylko dla portów ethernetowych.

interface (interface name) -- nazwa interfejsu znajdującego się w sieci mesh

mesh (interface name) -- nazwa interfejsu do którego należy port

path-cost (integer: 0..65535; domyślnie: 10) -- koszt trasy do interfejsu, używane przez protokół routingu w celu określenia 'najlepszej' trasy

port-type (WDS | auto | ethernet | wireless) -- typ portu

  • auto - typ portu określany jest automatycznie w zależności od typu przynależnego interfejsu
  • WDS - interfejs Wireless Distribution System, coś w rodzaju bezprzewodowego łącza punkt-punkt. Zdalny adres MAC poznawany jest przy zestawianiu połączenia bezprzewodowego
  • ethernet - zdalne adresy MAC poznane przez wiadomości HWMP+ Hello lub z odebranych i forwardowanych pakietów
  • wireless - zdalne adresy MAC poznane poprzez dane połączeń bezprzewodowych

active-port-type (read-only, wireless | WDS | ethernet-mesh | ethernet-bridge | ethernet-mixed) -- typ używanego portu i jego stan

/interface mesh fdb

Zestaw informacji tylko do odczytu z Forwarding Database (FDB) interfejsu mesh.

mac-address (MAC address) -- adres MAC odpowiedniego wpisu w FDB

seq-number (integer) -- numer sekwencyjny używany przez protokół routingu w celu uniknięcia pętli

type (local | outsider | direct | mesh | neighbor | larval | unknown) -- typ wpisu FDB

  • local -- adres MAC należy do lokalnego routera, na którym znajduje się FDB
  • outsider -- adres MAC należy do urządzenia znajdującego się poza siecią typu mesh
  • direct -- adres MAC należy do interfejsu klienta bezprzewodowego znajdującego się w sieci mesh
  • mesh -- adres MAC należy do urządzenia osiągalnego przez sieć mesh; może należeć, lub nie należeć do sieci mesh
  • neighbor -- adres MAC należy do routera w sieci mesh sąsiadującego z naszym routerem
  • larval -- adres MAC należy do nieznanego urządzenia osiągalnego przez sieć mesh
  • unknown -- adres MAC należy do nieznanego urządzenia

mesh (interface name) -- nazwa interfejsu mesh dla którego istnieje ten wpis

on-interface (interface name) -- port mesh używany do forwardowania ruchu, coś jak wartość next-hop

lifetime (time) -- pozostały czas życie tego wpisu jeśli nie jest wykorzystywany do forwardowania pakietów

age (time) -- wiek wpisu FDB

metric (integer) -- parametr używany przez protokół routingu do określenia 'najlepszej' trasy

Dodatkowa konfiguracja bezprzewodowa

Użyj parametrów wds-default-cost i wds-cost-range bezprzewodowego interfejsu do kontroli metryki używanej przez protokół routingu. Koszt WDS będzie wykorzystany jako path-cost dla dynamicznie dodanych portów do interfejsu mesh.

Przykład

Image:mesh_ex1.jpg

W przykładzie wykorzystane są statyczne łącza WDS, które są dynamicznie dodawane jako porty mesh gdy stają się aktywne. Używane są dwie różne częstotliwości: jedna dla połaczeń między AP, druga pomiędzy klientami a ich AP, więc AP musi mieć przynajmniej dwa interfejsy bezprzewodowe. Oczywiście można użyć tej samej częstotliwości dla wszystkich połączeń, ale z powodów potencjalnych problemów z interfejsami wydajność może być bardzo mała.

Wpisz tą konfigurację we wszystkich AP:

/interface mesh add disabled=no
 
/interface mesh port add interface=wlan1 mesh=mesh1
 
/interface mesh port add interface=wlan2 mesh=mesh1
 
# interfejs używany do połączeń między AP
/interface wireless set wlan1 disabled=no ssid=mesh frequency=2437 band=2.4ghz-b/g mode=ap-bridge \
  wds-mode=static-mesh wds-default-bridge=mesh1
 
# interfejs używany do połączeń z klientami
/interface wireless set wlan2 disabled=no ssid=mesh-clients frequency=5180 band=5ghz mode=ap-bridge 
 
# statyczny interfejs WDS dla każdego AP z którym chcesz się połączyć
/interface wireless wds add disabled=no master-interface=wlan1 name=<descriptive name of remote end> \
  wds-address=<MAC address of remote end>

Ponieważ będzie użyty statyczny tryb WDS, tutaj znajduje się ręcznie dodany interfejs WDS. Jeśli używasz wds-mode=dynamic-mesh, wszystkie interfejsy WDS zostaną dodane automatycznie. Parametry frequency and band opisane tutaj służą tylko do utworzenia przykładowej konfiguracji; operacje protokołu w sieci mesh nie są przez nie ograniczane ani optymalizowane.

Uwaga: Być może chcesz zwiększyć parametr disconnect-timeout interfejsu bezprzewodowego aby zwiększyć stabilność protokołu.

W praktycznych konfiguracja powinieneś zwrócić uwagę na zabezpieczenie połączeń bezprzewodowych, używając /interface wireless security-profile. Dla uproszczenia nie pokazano tutaj tej konfiguracji.

Results on router A (there is one client is connected to wlan2):

[admin@A] > /interface mesh pr
Flags: X - disabled, R - running
 0  R name="mesh1" mtu=1500 arp=enabled mac-address=00:0C:42:0C:B5:A4 auto-mac=yes
      admin-mac=00:00:00:00:00:00 mesh-portal=no hwmp-default-hoplimit=32
      hwmp-preq-waiting-time=4s hwmp-preq-retries=2 hwmp-preq-destination-only=yes
      hwmp-preq-reply-and-forward=yes hwmp-prep-lifetime=5m hwmp-rann-interval=10s
      hwmp-rann-propagation-delay=1s hwmp-rann-lifetime=22s
 
[admin@A] > interface mesh port p detail
Flags: X - disabled, I - inactive, D - dynamic
 0    interface=wlan1 mesh=mesh1 path-cost=10 hello-interval=10s port-type=auto port-type-used=wireless
 1    interface=wlan2 mesh=mesh1 path-cost=10 hello-interval=10s port-type=auto port-type-used=wireless
 2  D interface=router_B mesh=mesh1 path-cost=105 hello-interval=10s port-type=auto port-type-used=WDS
 3  D interface=router_D mesh=mesh1 path-cost=76 hello-interval=10s port-type=auto port-type-used=WDS

Chwilowo FDB (Forwarding Database) jedynie zawiera informacje o lokalnych adresach MAC, węzłów nie należących do sieci mesh osiągalnych przez lokalny interfejs, oraz bezpośrednich sąsiadów w sieci mesh:

[admin@A] /interface mesh> fdb print
Flags: A - active, R - root
   MESH        TYPE     MAC-ADDRESS       ON-INTERFACE       LIFETIME     AGE
A  mesh1       local    00:0C:42:00:00:AA                                 3m17s
A  mesh1       neighbor 00:0C:42:00:00:BB router_B                        1m2s
A  mesh1       neighbor 00:0C:42:00:00:DD router_D                        3m16s
A  mesh1       direct   00:0C:42:0C:7A:2B wlan2                           2m56s
A  mesh1       local    00:0C:42:0C:B5:A4                                 2m56s
 
[admin@A] /interface mesh> fdb print detail
Flags: A - active, R - root
 A  mac-address=00:0C:42:00:00:AA type=local age=3m21s mesh=mesh1 metric=0
     seqnum=4294967196
 A  mac-address=00:0C:42:00:00:BB type=neighbor on-interface=router_B age=1m6s
    mesh=mesh1 metric=132 seqnum=4294967196
 A  mac-address=00:0C:42:00:00:DD type=neighbor on-interface=router_D age=3m20s
     mesh=mesh1 metric=79 seqnum=4294967196
 A  mac-address=00:0C:42:0C:7A:2B type=direct on-interface=wlan2 age=3m mesh=mesh1
     metric=10 seqnum=0
 A  mac-address=00:0C:42:0C:B5:A4 type=local age=3m mesh=mesh1 metric=0 seqnum=0

Sprawdź czy działa ping:

[admin@A] > /ping 00:0C:42:00:00:CC
00:0C:42:00:00:CC 64 byte ping time=108 ms
00:0C:42:00:00:CC 64 byte ping time=51 ms
00:0C:42:00:00:CC 64 byte ping time=39 ms
00:0C:42:00:00:CC 64 byte ping time=43 ms
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 39/60.2/108 ms

Router A musi najpierw trasę do Routera C, ponieważ ponieważ czas pinga jest dla niego znacznie większy. Teraz FDB zabiera także wpis dla 00:0C:42:00:00:CC, z trybem "mesh".

Sprawdź również czy działa resolving ARP poprzez ping poziomu IP:

[admin@A] > /ping 10.4.0.3
10.4.0.3 64 byte ping: ttl=64 time=163 ms
10.4.0.3 64 byte ping: ttl=64 time=46 ms
10.4.0.3 64 byte ping: ttl=64 time=48 ms
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 46/85.6/163 ms

Mesh traceroute

Istnieje polecenie mesh traceroute pozwalając na sprawdzenie tras używanych przez routing.

Na przykład, dla tej sieci:

[admin@1] /interface mesh> fdb print
Flags: A - active, R - root
   MESH        TYPE     MAC-ADDRESS       ON-INTERFACE       LIFETIME     AGE
A  mesh1       local    00:0C:42:00:00:01                                 7m1s
A  mesh1       mesh     00:0C:42:00:00:02 wds4               17s          4s
A  mesh1       mesh     00:0C:42:00:00:12 wds4               4m58s        1s
A  mesh1       mesh     00:0C:42:00:00:13 wds4               19s          2s
A  mesh1       neighbor 00:0C:42:00:00:16 wds4                            7m1s
A  mesh1       mesh     00:0C:42:00:00:24 wds4               18s          3s

Traceroute no 00:0C:42:00:00:12:

[admin@1] /interface mesh> traceroute mesh1 00:0C:42:00:00:12
ADDRESS           TIME         STATUS
00:0C:42:00:00:16 1ms          ttl-exceeded
00:0C:42:00:00:02 2ms          ttl-exceeded
00:0C:42:00:00:24 4ms          ttl-exceeded
00:0C:42:00:00:13 6ms          ttl-exceeded
00:0C:42:00:00:12 6ms          success

Opis protokołu

Tryb Reactive

Router A wants to discover path to C
Router C sends unicast response to A

W trybie reactive MWMP+ jest podobny do AODV (Ad-hoc On-demand Distance Vector). Wszystkie trasy odkrywane są na żądanie, poprzez zalewanie sieci wiadomością Path Request (PREQ). Węzeł docelowy lub router mający trasę do węzła docelowego odpowie wiadomością Path Response (PREP). Jeśli adres docelowy należy do klienta, AP do którego podłączony jest klient będzie służył jako proxy (tzn. osobiście odpowiada na PREQ).

Ten tryb najbardziej nadaje się dla mobilnych sieci, w których większość komunikacji odbywa się pomiędzy węzłami w sieci mesh.

Tryb Proactive

The root announces itself by flooding RANN
Internal nodes respond with PREGs

W trybie proactive niektóre routery skonfigurowane są jako portale. Ogólnie portal jest routerem mającym interfejsy do innych sieci, tzn. jest to punkt dostępu do sieci mesh.

Portale rozgłaszają swoją obecność poprzez zalewanie sieci wiadomościami Root Announcement (RANN). Wewnętrzne węzły odpowiadają wiadomością Path Registration (PREG). Wynikiem tego procesu są drzewa routingu z portalami jako korzeniami.

Trasy do portali służą jako domyślne trasy. Jeśli wewnętrzny router nie zna ścieżki do konkretnego celu, forwarduje wszystkie dane do najbliższego portalu. Portal wykryje trasę zamiast router, jeśli to konieczne. Następnie dane przejdą przez porta. Może to być routing niezbyt optymalny, chyba że dane kierowane są do samego portalu lub zewnętrznej sieci do której należy jeden z interfejsu portalu.

Tryb proactive najlepiej sprawdza się, gdy większość ruchu przechodzi przez wewnętrzne węzły i niektóre węzły portalowe.

Detekcja zmiany topologii sieci

Data flow path
After link disappears, error is propagated upstream


HWMP+ używa wiadomości Path Error (PERR) w celu informowania, że łącze zostało rozłączone. Wiadomość jest propagowana do wszystkich węzłów znajdującej się na trasie do źródła danych. Źródło po odebraniu PERR restartuje proces wykrywania trasy.

FAQ

Q. Jest to lepsze niż RSTP?

A. Daje Ci optymalny routing. RSTP służy tylko do uniknięcia pętli.

Q. Jak przebiega proces wyboru trasy?

A. Po procesie wykrywania trasy zawsze wybierana jest trasa z najlepszą metryką. Jest opcja w konfiguracji, która powoduje okresowe reoptymalizację znany tras.


Metryka trasy obliczana są jako suma metryk indywidualnych łączy.

Metryka łącza obliczana jest w ten sam sposób jak dla protokołu (R)STP:

  • Dla łączy ethernetowych metryka jest wpisywana statycznie (na przykład jak w OSPF).
  • Dla łączy WDS metryka jest dynamicznie aktualizowana w zależności od chwilowej przepustowości łącza, która jest zależna od siły sygnału bezprzewodowego i wybranej prędkości transmisji.

Obecnie protokół nie bierze pod uwagę wykorzystywanego pasma, ale w przyszłości może być i to używane.

Q. Jest to lepsze niż OSPF/RIP/routing warstwy 3?

A. Sieci WDS zazwyczaj są mostkowane (bridged), nie trasowane (routed). Zdolność do samokonfiguracji jest istotna w sieciach mesh; routing wymaga więcej konfiguracji niż mostkowanie. Oczywiście zawsze możesz uruchomić protokół routingu L3 na sieci mostkowanej, ale nie ma to większego sensu dla sieci typu mesh.
Uwaga: Ponieważ nie ma dostępnych rozwiązań multicastowych warstwy 2 w protokole mesh, lepiej jest unikać forwardowania ruchu multicastowego (poza OSPF) przez sieci mesh. Jeśli potrzebujesz OSPF, musisz skonfigurować sąsiadów OSPF NBMA aby używali unicastu zamiast multicastu.

Q. Jakie są wymagania sprzętowe?

A. Gdy poprawnie skonfigurowany, sam protokół używa dużo mniej zasobów niż (dla przykładu) OSPF.

Q. Jak HWMP+ działa razem z istniejącymi konfiguracjami mesh używającymi RSTP?

A. Wewnętrzna struktura sieci RSTP jest przezroczysta na protokołu mesh (ponieważ pakiety hello są forwardowane wewnątrz sieci RSTP). Mesh będzie widział ścieżkę pomiędzy dwoma punktami wejściowymi w sieci RSTP jako pojedynczy segment. Z drugiej strony, sieć mech nie jest przezroczysta dla RSTP, ponieważ pakiety RSTP hello nie są forwardowane wewnątrz sieci mech. (Od wersji 3.26, wcześniej tak nie było)

Uwaga: mogą wystąpić pętle routingu, gdy sieć mesh jest dołączona do sieci RSTP w jednym lub więcej miejscach!

Jeśli masz łącze WDS pomiędzy dwoma punktami dostępowymi, obydwa punkty muszą mieć taką samą konfigurację (jako porty w mesh na obu końcach, lub jako porty na obu końcach interfejsu mostkowego).

Możesz dołączyć interfejs mostkowy jako port mesh (np. abyś mógł używać firewall mostkowy).


Q. Czy mogę mieć wiele punktów wejściowych/wyjściowych z sieci?

A. Jeśli punkty skonfigurowane są jako portale (tzn. używany jest tryb proactive), każdy router w sieci mesh wybierze najbliższy mu portal i będzie forwardował do niego wszystkie dane. Portal będzie wykrywał trasę zamiast tego routera, jeśli zachodzi taka potrzeba.

Q. Jak kontorować lub filtrować ruch w sieci mesh?

A. W tej chwili jedynym sposobem jest użycie firewalla mostkowego. Stwórz interfejs mostkowy, umieść na nim interfejsy WDS lub Ethernetowe i umieść mostek na interfejsie mesh. Potem ustaw reguły firewall'a połączenia mostkowego.


Aby porównywać protokół MAC używany do enkapsulacji ruchu mesh, użyj numeru protokołu MAC 0x9AAA. Aby porównać ruch routingu mesh, użyj numer protokołu MAC 0x9AAB. Przykład:

interface bridge settings set use-ip-firewall=yes
interface bridge filter add chain=input action=log mac-protocol=0x9aaa
interface bridge filter add chain=input action=log mac-protocol=0x9aab

Możliwe jest tworzenie mieszanych konfiguracji mesh/bridge które nie będą działać (zobacz Przykład 1 z mostkiem zamiast switcha). Polecanym sposobem, który zawsze będzie działać jest stworzenie oddzielnych interfejsów mostkowych na każdy interfejs fizyczny; następnie dodaj wszystkie interfejsy mostkowe jako porty mesh.


Bardziej zaawansowane tematy

Wszyscy wiem jak łatwo utworzyć konfigurację mostkowania lub routingu warstwy 2 z błędami i jak trudno je debugować (W porównaniu z konfiguracjami routingu warstwy 3). Poniżej przedstawione jest kilka przykładów konfiguracji, które mogą powodować problemy. Unikaj ich!


Przykład 1: Switch ethernetowy w sieci mesh

Image:mesh_bad_ex1.jpg

Router A znajduje się poza siecią mesh, wszystkie pozostałe routery: wewnątrz. Dla routerów B, C, D wszystkie interfejsy są dodane jako porty mesh.'

Router A nie będzie mógł komunikować się z routerem C bezproblemowo. Problem pojawia się gdy router D przeznaczony jest jako router do Ethernetu; jeśli B spełnia tą rolę, wszystko jest dobrze. Głównym powodem wystąpienia problemu jest poznawanie adresu MAC na switchu ethernetowym.

Rozważ, co się stanie gdy router A chce wysłać coś do C. Zakładamy ze router A rozsyła dane przez jeden lub wszystkie interfejsy. W każdym bądź radzie, dane docierają do switcha. Switch nie wie nic o docelowym adresie MAC i przekazuje dane naraz do B i D.

Co się wtedy dzieje:

  1. B odbiera pakiet z interfejsu mesh. Ponieważ adres MAC nie jest lokalny dla B i B wie, że nie jest on wyznaczonym routerem dla sieci ethernetowej, po prostu ignoruje pakiet.
  2. D obiera pakiet z interfejsu mesh. Ponieważ adres MAC nie jest lokalny dla B i B wie, że jest on wyznaczonym routerem dla sieci ethernetowej, inicjuje proces wykrywanie trasy do C.

Po zakończeniu wykrywania trasy, D ma informację, że C jest osiągalny przez B. D enkapsuluje pakiet i przesyła spowrotem do sieci Ethernetowej. Enkapsulowany pakiet przesyłany jest przez switch, odbierany i przekazywany przez B i odbierany przez C. Na razie wszystko jest w porządku.

Teraz pewnie C odpowie na pakiet. Ponieważ B już wie gdzie A jest, dekapsuluje i prześle dalej pakiet z odpowiedzią. Ale taraz swich dowie się, że adres MAC routera C osiągalny jest przez B! Oznacza to, że następnym razem gdy przyjdzie coś z A zaadresowanego do C, switch prześle dane tylko do B. (A B oczywiście, zignoruje pakiet).

Gdyby B przejął rolę routera przeznaczonego dla ethernetu, wszystko byłoby dobrze, ponieważ ruch nie będzie musiał przechodzić przez switch ethernetowy dwa razy.

Rozwiązanie problemu: unikaj takiej konfiguracji lub wyłącz wykrywanie adresów MAC w switchu. Na wielu switchach nie jest to możliwe.

Również problem nie wystąpi gdy:

  • router A wspiera i jest ustawiony aby używał HWMP+;
  • lub switch ethernetowy jest zastąpiony routerem wsierającym HWMP+ i ma interfejsy ethernetowe dodane jako porty mesh.

Przykład 2: tryby bezprzewodowe

Rozważ taką konfigurację (niepoprawną):

Image:mesh_bad_ex2.jpg

Routery A i B znajdują się wewnątrz sieci mesh, routery C: poza. Na routerach A i B wszystkie interfejsy są dodane jako porty mesh.

nie jest możliwe stworzenie połączeń mostkowych przez wlan1 i wlan2 na routerze B. Powód jest oczywisty jeśli rozumiesz jak działa WDS. W komunikacji WDS używane są cztery adresy w ramce, ponieważ dla forwardowania bezprzewodowego musisz znać oba adresy pośrednich skoków, jak również nadawcę i ostatecznego odbiorcę. Komunikacja nie-WDS 802.11 ma tylko trzy adresy MAC w ramce. Dlatego nie jest możliwe forwardowanie przez wiele węzłów w trybie stacji.


Rozwiązanie problemu: w zależności od tego co chcesz osiągnąć:

  1. Jeśli chcesz aby router C służył jak repeater dla ruchu bezprzewodowego lub ethernetowego, ustaw łącze WDS pomiędzy routerem B i routerem C i uruchom protokół routingu mesh na wszystkich węzłach.
  2. W pozostałych przypadkach ustaw wlan2 na routerze B w trybie AP, a wlan na routerze C w trybie stacji.

Zobacz także: