WDS em PtMP

Boa noite amigos,
realizando algumas pesquisas, vi que essa questão de habilitar o WDS ou não é bem dividia, uns dizem que desabilitar melhora a performance do cliente, outros dizem que tem que habilitar no AP e CPE, porém não encontrei resultados concretos de quem desabilitou e obteve melhor performance...
...O fato que é sempre usei em meus APs e Clientes, nunca tive problemas, mas tmb nunca carreguei com muitos clientes meus paineis, mas agora montei 1 painel TI com Rocket TI, e migrei bastante clientes para apenas ele, e estou tendo problemas para entregar a banda contratada... talvez possa ser uma interferência, ainda não fiz os testes ao certo!!! Porém me surgiu essa dúvida...
Ativar ou não WDS?
Irá melhores meus clientes ele habilitado ou desabilitado?

Eu não entendi porque você vai habilitar o WDS na CPE no cliente.
WDS seria mais para fazer um ponto de repetição do sinal. E mesmo nestes casos há limite de pontos para não degradar o desempenho.

Creio que WDS não é o indicado para atender o cliente final.

Na CPE do cliente nós usamos a função Cliente ISP ou Station que recebe o sinal do AP e faz roteamento para a rede interna do cliente. Desta forma separa sua rede da rede do cliente. Acho que é a forma que dá melhor desempenho, pois diminui muito o broadcasting na rede.

WDS basicamente libera a passagem de dados do layer 3 do pacote, lá fica o cabeçalho completo, com dados de um PPPoE digamos.
https://www.google.com.br/search?q=camadas+osi

Se usar PPPoE, ou usa WDS, ou usa VPLS, ou Radius. É mais fácil simplesmente ativar o WDS.

Se não usa PPPoE (Amarra IP e mac adress, digamos), os dados extras que vem no layer 3 não tem tanta utilidade, talvez esse pequeno aumento pese hora que chegar nuns 100 clientes num mesmo AP, mas provavelmente o chipset de RF vai virar uma lesma com 40 clientes conectados (Porque gerar e ler um pacote de wifi é muito mais pesado que simplesmente ver 2 ou 3 dados no cabeçalho), talvez num concentrador isso pesaria mais, mas os concentradores são mais parudos que os AP's, talvez acima de uns 300 clientes simultâneos num concentrador tipo RB1100AHx2 isso pese.

eu uso wds no ap e na estação, não sei se está correto também, sei que com uma antena no cliente com wds ativo eu consigo fazer 2 ou mais roteadores na casa do cliente autenticar com usuário e velocidade diferente.

Aqui ativamos WDS apenas no AP, isso pq usamos autenticação PPPoe. Na época do ipxmac não era habilitado.

Isso reforça o que o @rubem acabou de dizer.

Citação:

---

Postado originalmente por RODRIGOQUATI

eu uso wds no ap e na estação, não sei se está correto também, sei que com uma antena no cliente com wds ativo eu consigo fazer 2 ou mais roteadores na casa do cliente autenticar com usuário e velocidade diferente.

---

E dai na CPE do cliente voce ativa como AP+WDS?

Se a CPE do cliente faz a discagem PPPoE (station), o dado extra no cabeçalho sai dela mesma, não "passa por ela", se ela está com WDS ativo tanto faz (Pode ser station, ou station+wds), mas precisar não precisa.

Mas se a CPE do cliente está como bridge, com a discagem no PC do cliente (Tipo em 1995, um discador combina bem com num desktop bege rodando Win95 ou Win98), aí tem que ativar WDS na CPE do cliente, ou usa modo station+wds ou usa bridge e vai na aba ativar o wds.


Ou seja, só precisa WDS ativo onde o layer3 "passa", onde a discagem pppoe passa. Não precisa ativar wds nem onde ela sai nem onde ela chega (Se o AP fosse também o concentrador).

@1929 isso mesmo, eu deixo tudo em wds, mas o cliente discar com 2 ou três roteadores você tem que deixar a cpe em bridge e não fazer Pppoe com a cpe e depois fazer com os roteadores novamente, daí não dá certo. Você pode fazer isso quando tem 2 clientes que são vizinhos de muro, coloca a antena na casa de um "em bridge" seguido de um switch saindo um cabo para cada casa e pode fazer o pppoe em cada casa, abraço. @rubem não sei se o que eu disse é a mesma coisa que vc disse, mas tentei explicar do modo mais fácil.

é como disse o Rubem, precisar não precisa.... e eu vou mais longe. Será que isso não sobrecarrega a rede? Não é afirmação, mas uma dúvida real.

Trabalhar com CPE em bridge sobrecarrega a rede... aumenta consideravelmente o broadcasting foi o que notamos quando começamos.

E no seu caso Rodrigo, o AP na torre vai estar com o WDS ativado. Se for um Ubiquiti que tem pouco espaço para cadastrar MACs só 6, como faria? No Mikrotik a lista me parece sem limites. Mas mesmo um AP que faz wds com 3 ou mais APs em outras torres, já dá problemas.

Aqui o uso é em Hotspot e APs nas torres e servidor mikrotik concentrando... Nos clientes CPEs roteadas, nada em bridge. E mesmo assim ainda vasa um pouco de tráfego de broadcasting. Se estive tudo em bridge seria o caos.

Citação:

---

Postado originalmente por ab5x2

@1929, qual versão do AirOS que você está usando? Estou indagando isso pois aqui também tenho um setor onde as CPEs são todas em bridge, estou usando WDS e tenho mais de 15 clientes nesse AP+WDS. E não notei esse limite.

---

Não uso mais, Só uso com CPE cliente e roteada. Mas quando usava Ubiquiti como AP, ao configurar como AP+WDS aparecia 6 caixas para cadastrar MACs. Hoje pode ser que tenha mudado isso.
Mas ainda continuo achando que WDS não é para atender o cliente final. Para isso o melhor é configurar a CPE como roteadam separando sua rede da rede do cliente. E como tal o WDS não teria função.
Quando começamos eu contratei uma pessoa para configurar o Mikrotik e ele fez isso, deixou os clientes em bridge. Depois quando começamos a mexer resolvemos passar tudo par roteado...

CPE em bridge, com um roteador wifi fazendo a discagem, isso não gera muito pacote extra.

Mas... se a CPE está em bridge, e quem disca é um Windows comum de usuário, o Windows vai mandar pra rede (E vai passar reto pela CPE, e chegar no concentrador) os pacotes de procura na rede, procurando outros computadores, procurando impressoras, o inútil antivírus vai tentar escanear alguma coisa, o maldito Windows Media Player vai "oferecer" os dados DLNA (O default é o dlna server dele ativo né?), enfim, aí sim gera um monte de pacotes na rede.

Quando tem um roteador qualquer entre o PC do usuário (Seja Windows, Android, ou linux pra usuário leigo cheio de facilidades que vivem fuçando novos dispositivos na rede tipo Ubuntu), os pacotes INÚTEIS gerados por esses sistemas param nesse roteador. Quando ele não existe, está tudo em bridge, e tem um discador dos ano 90 no desktop ou notebook do usuário, todo esse tráfego vai até o concentrador PPPoE. O concentrador não vai responder eles, claro, mas... isso é dado que ocupa a etapa de RF do AP da torre! (Se ocupasse só a CPE tava tranquilo)

Ter só 2 ou 3 usuários assim é tranquilo. O problema é quando tem toda a rede assim, vivendo em 1990 com discadores nos desktops, só de deixar um Windows típico (Com tudo no default) ligado, sem nenhum usuário na frente, é fácil chegar em 4GB de consumo na semana, isso é tráfego de inutilidades tipo atualização de AV e WinUpdate, mas também tem uma boa parte que é broadcasting de serviços que EM TESE facilitam a vida do usuário (Procurando impressoras, procurando outros Windows, procurando dispositivos uPnP em geral, enfim, é o sistema fuçando a rede pra achar sozinho as coisas pro usuário leigo que não sabe encontrar nada).


Sobre o WDS aumentar o tráfego na rede, é muito pouco, isso se a CPE está em station+wds, ou se ela está em bridge mas quem faz a discagem é um roteador wifi na casa do cliente (E eu também já fiz muito disso, colocar uma CPE pra 2 ou 3 clientes, mas cada um com o roteador wifi discando, o roteador roteia (Não diga!) esses pacotes de broadcasting gerados pelos equipamentos do usuário, e esses dados não passam dele pra rede do provedor).

Num hotspot ou ip&mac, o tamanho extra num cabeçalho é de alguns bytes, pesar isso pesa, mas se a CPE do cliente tem MTU 1480 ao invés de 1472 também ocorre uns bytes a mais, e se for 1472 ao invés de 1480 (Ou 1480 ao invés de 1492) ocorre mais pacotes sendo quebrados em 2 pra caber, o peso existe mas... como políticos corruptos se defendem, "eu tô errado mas ele ali também está". Tem várias coisas que "desperdiçam" uns bytes extras, eliminar todas da rede dá trabalho (Um coisa a fazer seria diminuir o MTU em todos os desktops, notebooks, tablets e smartphones do usuário, configuração que alguns nem tem), e esse peso só faz diferença pra muitas centenas de usuários num concentrador, fora que não existe tráfego constante na internet, se fosse digamos 400 clientes com tráfego constante (24x7!) de 1Mbps, otimizar isso talvez permitiria 410 clientes assim. Na prática o tráfego varia tanto que quando o concentrador está superlotado esses ajustes fariam efeito na média, não nos picos de tráfego que deixariam tudo lento pros usuários.

(E o tráfego extra no AP no caminho também não é problema, um cliente com CCQ de 95% perde pacotes (Se não perdesse nada seria 100%), e um pacote de 1500 bytes sendo reenviado pesa o mesmo que 375 pacotes com cabeçalho com 4 bytes a mais (Por ativar WDS a toa). Nesse caso, quem tem CCQ de 95% não vai perder 1 em cada 375 pacotes, e sim algo tipo 1 em cada 37, ou seja, no AP o vilão da perda de desempenho com certeza será outro, não o WDS)

ok, entendido...
Eu sempre leio que CPE roteada é o ideal... Se vai bem com WDS ativado no cliente, tudo bem...
Mas pergunto: WDS foi feito para isso?

WDS foi feito pra "repetição não-universal" repassar todo o cabeçalho, e pra roteador passar o cabeçalho pra não perder dado de Vlan e PPPoE mesmo, mata 2 caixas d'agua com um coelho...

Uma repetição pura não faz nada na parte de RF, só repassa todo pacote vindo ou indo do/pro Mac X ou Y, é fácil fazer um ataque DOS nele, mas uma bridge com WDS faz a negociação wifi entre os 2 lados mas mantém o cabeçalho do pacote na parte de TCP.
(Mexe no cabeçalho na parte de wifi, mas não no layer3)

Wifi tem as sincronias e cia, tem todo o preambulo do pacote, uma repetição não é tão simples, e se você repetir tudo cegamente esse equipamento trava fácil e deteriora completamente a rede (Porque o AP recebe de volta o pacote que ele enviou), o tipo de repetição que funciona é algo tipo bridge, que mexe no cabeçalho da parte de wifi, mas usa a mesma chave negociada com o AP (Chave que existe com ou sem senha na rede, na repetição o repetidor não negocia essa chave, mas ele só troca dado com o cliente que usar a chave certa).

Muitos anos atrás os sistemas operacionais não futricavam na rede, não ficavam escaneando tudo 10x a cada segundo, podia usar bridge que não teria problema, só se roteava onde era necessário MESMO. Hoje o tráfego inútil é gigante, não dá pra usar bridge como se usava em 2000. Um padrão "de hoje" provavelmente faria 2 modos, um WDS pra repetições wifi, e algo pra simplesmente repassar todo o layer 3 do cabeçalho mesmo fazendo algum roteamento. Mas a quase 20 anos atrás uma bridge era tranquila, não precisava se preocupar com roteamento passando autenticação porque não tinha motivo pra fazer isso. Hoje tem.

Sim, Arthur é o wds mesmo foi o corretor aqui do cell, apaguei o post sem querer.

@rubem, vamos ao contrário, já ouvi falar que o WDS quando aplicado tem uma perda de performance no enlace pois o mesmo não trabalha muito bem com agregação de frame, poderia nos darmos um norte sobre o por quê?? Desde já agradeço.

Correto, agregação de frame é basicamente juntar pacotes, mas o pacote é composto pelo dado do usuário e o cabeçalho. Juntar dado do usuário (O payload) é fácil, mas juntar cabeçalho complica, as vezes tem byte só pra preencher espaço que é comido num lado mas o outro lado não o coloca de volta e isso gera erro de checksum.

Quem tenta juntar digamos 4 pacotes de usuário num mesmo cabeçalho, acaba gerando esse erros. Quem junta os 4 pacotes inteiros (Mesmo que os 4 cabeçalhos pareçam iguais) tá tranquilo.

Agregar MSDU é juntar o payload de todos os pacotes, digamos que o WhatsApp mandou 4 pacotes pro servidor, uma agregação de MSDU vai juntar os 4 porque leu um cabeçalho igual nos 4, vai fazer isso aqui:

Anexo 63828

O que a MK faz é agregar o pacote com cabeçalho e tudo, nem lê direito o que tem no cabeçalho mas agrega tudo, ou seja, agrega os MPDU inteiro, digamos:

Anexo 63829



A parte de wifi como um todo, saído de um MK com agregação de MPDU ativo, seria digamos:
Anexo 63830

Esse começo chamado de OFDM PHY é o que chamo de preambulo e parte de sincronia (O nome preambulo é coisa de A e B na verdade), esse começo é feito em rate de 6Mbps, com modulação BPSK diferencial, altamente legível até no pior cenário, por isso a sincronia não cai (Não deixa de ver o SSID) mas pode perder pacote assim mesmo, um 64QAM precisa sinal alto pra ser legível, mas o BDSK diferencial do preambulo é legível com qualquer sinal baixo.

No outro lado tudo é dividido e cada pacote segue seu caminho separado do outro, como se nada tivesse acontecido.

Em N se permitiu a agregação de MSDU e de MPDU. E agregando MSDU se gasta processamento pra caramba, rádio de torre de celular faz isso porque são parudos, mas se botar um processador MIPS de US$ 8 de RB pra fazer isso é certeza de erro em 2 ou 3 bits a cada 2 ou 3 pacotes, gera muito erro de checksum depois.

Agregando MPDU o único problema do WDS ativo e seu cabeçalho maior é... ter uns bytes a mais pra transmitir, ocupar uns bytes a mais na ram e tal. A MK faz isso porque é uma tarefa mais simples, pega os pacotes como estão, e só junta, não analisa muita coisa, não divide eles. É bem diferente de agregar MSDU, ia precisar ler cada cabeçalho, comparar, juntar só o payload e pegar só o cabeçalho de um deles, juntar tudo e mandar.

Se agregar MPDU dá desempenho ruim com WDS, aí não sei. Sei que dá delay maior em rede de curta distância, atrapalha VOIP com server a 1ms de distância justamente porque cada pacote que chega não é enviado na hora, o pacote chega, é juntado em numeros tipo 3 até 60, e enviado em rajadas longas. Alias, como é uma transmissão longa, quem tem CCQ ruim e variando não pode fazer isso senão perde muito pacote quando dá uma variada pra pior, se a agregação foi de 20 pacotes, e der uma variação piorando o sinal por X milisegundos, vai ter que reenviar tudo isso de novo depois. É tipo a fila que o NV2 cria, enfileirar e analisar pacote, ao invés de enviar tudo misturado conforme chega, melhora o throughput (Que se mede POR SEGUNDO) mas pior o delay de cada pacote.

Numa comunicação entre 2 Xeon da vida, interligados via fibra, pode botar pra agregar MSDU tranquilo, eles tem processamento de sobra pra fazer isso sem erro. Em equipamento mais pobre é melhor agregar MPDU, e... talvez esses bytes a mais do WDS pesem caso a RB agregue os 64 pacotes de limite e façam isso pra 40 usuários. Mas pro tipo de comunicação que fazemos, onde banda importa mais que delay (Digo, delay extra de 5ms não é problema), essa demora extra não é problema.

@rubem, mais uma vez bela explicação, nunca que eu ia construir um raciocínio desse, então por exemplo se eu envio um mensagem do Waths, Arquivo, etc... Vamos supor de 900Bytes ai ele envia dividido em partes ex: 900/3=300 então o o MSPU ia só agregar e ia fazer um checksum no pacote após isso ele envia para o seu destino, diferente do RouterOS ele juntar o pacote mal faz a leitura do pacote e automaticamente já envia ao destino. Rubem lendo um pouco a fundo existe alguns casos que para completa o cabeçalho pode colocar informações em branco só para completar o cabeçalho ou seja add com dados complementares??? Desde já agradeço.

É aquela coisa, se você tem 1 byte pra transmitir, vai ter 20 bytes numa parte do cabeçalho (Layer1), 20 no outro, 20 e poucos no outro, de modo que dá pra dizer que o MPDU terá pelo menos 64 bytes. O MSDU lá dentro terá acho que 46 bytes. Se ocorre uma quebra de pacotes (Por um MTU muito pequeno nalgum trecho), se o pedaço "quebrado" for de 10 bytes, vai ter esses 64 bytes a mais (Além dos 10 B quebrados) circulando por bobeira.

Ainda que agregasse MSDU, seriam 46 bytes a mais, mas não seria certo chamar isso de pacote inflado, o dado no cabeçalho é clonado de algum lugar. O pacote é aumentado de 10 pra digamos 74 bytes, mas é aumentado por cabeçalhos obrigatórios, alguns dados nuns cabeçalhos são aleatórios (Se não me engano o numero da vlan é. Não é 000 porque 000 é um numero válido de vlan, é randomizado e a diferença é que o destino simplesmente descarta esse dado porque ele não tem uma tabela de destinos pras vlan's) que eu saiba pra dificultar sniffers ou decriptação, se você pega um pacote agregado com cabeçalho legível, e sabe que na posição X e Y está a vlan 000 em todos os cabeçalhos, você tem um ponto de partida mais sólido que se esse local tiver números randômicos.

Fora os bits de paridade nos pacotes. Alguns ID's são feitos com bits apenas, pra demarcar começo e fim disso ou daquilo míseros 4 bits iguais resolve. Mas o pacote tem checksum gerado com bytes, ou seja, o pacote precisa ter bits múltiplos de 8 (octetos), se o pacote tiver digamos 603 bits, ele precisa ser inflado até 608 bits, que formará 76 bytes. Mas isso é muito pouco dado a mais, nem 1 byte, não faz nem cócegas no tráfego inútil que antivírus e atualizações diversas geram.