Testando e validando Batman-adv
Para o teste e avaliação da plataforma batman-adv-admin desenvolvida foi criada uma rede constituída por 4 nós, sendo um dos nós configurado como nó servidor/gateway e os restantes 3 configurados como nós clientes. Neste artigo será apresentado a caracterização da rede implementada, o resultado dos testes efetuados, assim como algumas considerações finais.
Caracter da rede mesh implementada
A rede batman-adv foi implementada num ambiente residencial, para uso em interiores. Na Figura 54 pode-se observar a planta onde foram implementados 2 dos nós batman-adv.
A área da implementação dos 2 nós descritos na Figura 54, tem cerca de 130 m2 e localiza-se num apartamento. O objetivo de cobertura de sinal está representado pela linha vermelha e pela linha amarela, referentes ao nó servidor/gateway, e ao nó cliente, respetivamente. Os outros 2 nós clientes foram instalados no andar imediatamente superior a este, que se trata de um apartamento semelhante. Os nós foram posicionados sensivelmente na mesma localização apresentada na Figura 54, pretendendo de igual forma cobrir a área total do apartamento superior, que têm a mesma área, perfazendo uma cobertura total de aproximadamente 260 m2. Na Figura 55 apresenta-se a localização dos 4 nós, vista no mapa da plataforma de gestão criada. O nó servidor/gateway tem a borda branca. Os nós clientes têm a borda negra. No mapa, o cursor aponta para o nó cliente (no 2 – cliente), que se encontra no mesmo piso do nó servidor. Os outros 2 nós apresentados, encontram-se no piso superior. A rede batman-adv estende-se por 2 pisos.
O posicionamento dos nós foi decidido em função do nível mínimo de sinal recebido (RSL). O nó servidor/gateway batman-adv ficou posicionado no local onde termina a fibra ótica. O serviço fornecido pelo ISP apresenta como capacidade de transmissão 50 Mbps. A ligação do nó servidor/gateway batman-adv ao ISP é efetuada através do router já existente nesse local do apartamento, utilizando-se um cabo Ethernet, que liga a porta WAN do nó batman-adv servidor/gateway à porta LAN do router fornecido pelo ISP. O nó 2 encontra-se no mesmo piso do nó 1 (servidor). O nó 3 e nó 4 encontram-se no piso superior. O nó 3 não tem conetividade com o nó 1 (servidor/gateway), devido à distância e obstáculos existentes entre os dois. O nó 3 tem um AP agregado, que permite o acesso de clientes via wireless. Para o posicionamento dos nós foi utilizado o programa inSSIDer, de maneira a aferir o RSL mínimo para a receção de sinal.
Os traços contínuos representam ligações através de cabo. Os traços a tracejado representam ligações sem fios. Na tabela 7 apresenta-se a relação de nível de sinal (dbm) entre os nós da rede
Testes de desempenho
De maneira a garantir o RSL mínimo (-80 dbm) entre os routers, a distância máxima entre nós não pôde ser superior a cerca de 10 metros de comprimento em linha reta. A distância foi aferida tendo em conta o programa inSSIDer e em função dos obstáculos existentes no ambiente residencial testado, tendo sido registados os valores de nível de sinal entre nós apresentados na Tabela 7. Noutros ambientes residenciais terá de se ter em conta a perda do sinal em função do material de construção das paredes, assim como dos objetos que se encontram entre os nós, o que poderá fazer variar as distâncias entre os mesmos.
Teste de débito
Foi realizado o seguinte teste:
O nó que oferece melhor débito na rede mesh é o nó que está na fronteira da rede, ou seja o nó servidor/gateway. Este nó foi o escolhido, para a realização deste teste, por ser o que oferece melhor serviço em termos de débito.
Na rede “teste_1” efetuou-se um download de 4 GB utilizando para o efeito o nó servidor/gateway e um computador portátil, ligado através de cabo Ethernet. O tempo que demorou a fazer o download foi de 120 minutos para uma ligação de 50 Mbps fornecida pelo ISP. Extrapolando, se tivéssemos um serviço de 100 Mbps, demoraria cerca de 60 minutos a fazer o mesmo download e para um débito de 400 Mbps, atualmente o mais poderoso oferecido em Portugal, demoraria cerca de 15 minutos. Na Figura 57 apresenta-se este raciocínio, através da apresentação de um gráfico.
Tendo em conta que o script_check_nodes.php, entre outras coisas verifica se foi ultrapassado o valor de 4 GB referente aos contadores de downloads e uploads dos nós, teria o script de correr de 15 em 15 minutos, para uma velocidade de 400 Mbps oferecida pelo ISP. Isto de modo a garantir que interpretava corretamente o valor desses contadores, sem correr o risco de os contadores atingirem o seu limite 2 vezes consecutivas, entre verificações de script. Para a ligação utilizada (50 Mbps), o script teria de correr pelo menos de 120 em 120 minutos para evitar que isso acontecesse. No entanto o script corre de 20 em 20 minutos de maneira a enviar alertas se os nós estiverem mais de 30 minutos sem responder.
Teste de tempo de resposta
Outro teste realizado na rede “teste_1” consistiu em verificar o tempo que demora cada nó a responder ao script_check_nodes.php. O script_check_nodes.php solicita 13 respostas a cada nó (por exemplo o valor de ram, a lista dos vizinhos, etc.), assim como é o responsável pelo envio das notificações de alerta em caso de deficiência ou de mau desempenho de cada nó. Foram realizados 5 testes e registados os valores referentes aos tempos de resposta de cada nó. Nestes 5 testes estavam ligados apenas 2 utilizadores à rede. Na Tabela 8 apresenta-se os valores dos tempos de resposta dos nós:
Após 5 testes e estando a rede com 2 utilizadores apenas, verificou-se que para terminar o processo de recolha de dados para os 4 nós que constituem a rede, cada nó demora em média, cerca de 7 segundos a responder. No entanto não foi possível extrapolar para uma rede com muitos clientes, em virtude de não ter existido essa possibilidade. Contudo foi testado com 7 clientes ligados à rede e verificou-se que o tempo de verificação dos nós aumentou. Após vários testes, o valor médio de resposta por nó demorou cerca de 18 segundos, conforme se pode observar na Tabela 9.
Relativamente a esta questão não foi possível aferir o impacto real dos procedimentos de verificação do estado da rede num cenário real. A degradação da QoS aumenta com o número de clientes. Para se perceber melhor seriam necessários testes numa rede com mais utilizadores.
Teste de falha servidor/gateway
Foi testada uma outra arquitetura de rede mesh, usando novamente os 4 nós, conforme ilustrado na Figura 58. Alterou-se a arquitetura da rede para 2 nós servidores e 2 nós clientes. Ligaram-se os 4 nós e constituiu-se a rede batman-adv. Cada nó cliente escolheu automaticamente o nó servidor/gateway, de acordo com os critérios já referidos anteriormente.
Desligou-se um dos nós servidores/gateways e verificou-se que os nós clientes demoram cerca de 200 segundos a encontrar nova rota para o nó servidor/gateway remanescente. Durante esses 200 segundos os utilizadores da rede (ligados ao nó cliente, que ficou sem nó servidor) não conseguem aceder à internet. Só quando o gateway é excluído da lista existente no protocolo, é que os nós alteram/atualizam as rotas, o que implica um tempo de espera demasiado longo. Existe outro acontecimento que inviabiliza a mudança. Por exemplo, se o cabo que traz o sinal fornecido pelo ISP à porta WAN do servidor, se desconecta por algum acaso, o nó cliente nunca procurará uma nova rota. O servidor continua a atribuir IP ao nó cliente, mas não tem sinal vindo do ISP. Nesse caso o cliente não muda a rota, pois continua a ser servido pelo nó servidor/gateway. Este é um problema grave do protocolo batman-adv (ver solucão). Só poderá ser resolvido após a tomada de conhecimento do problema, pois não foi desenvolvido neste trabalho maneira de proceder à deteção da falha.
Testes de gestão de 2 redes independentes
Foram criadas duas redes independentes, constituídas por um nó servidor e um nó cliente. Ligaram-se essas duas redes a um switch, onde também se ligou o servidor onde reside a plataforma de gestão batman-adv-admin e verificou-se que a plataforma de gestão funcionou normalmente, independentemente do número de redes. Para se separar as duas redes, alterou-se o BSSID e a chave de encriptação de cada rede.
Teste de cobertura de sinal
Procedeu-se à montagem da rede batman-adv, conforme demonstrado na Figura 59.
Prolongou-se a extensão da rede, utilizando os 4 nós batman-adv, e verificou-se que por cada salto, a velocidade de download decresce em 50 %. Conforme se pode observar, a velocidade de download fornecida pelo ISP é de 50 Mbps. Após 4 saltos, essa velocidade foi reduzida a 3,13 Mbps, velocidade de download oferecida a um utilizador da rede via wireless.
Este teste mostra que não será possível estender os nós clientes, indefenidamente. No máximo poder-se-á estender a ramificação a 4 nós clientes, embora 3 seja o número ideal de nós clientes, de maneira a obter-se a velocidade de download para clientes sem fios de 3 Mbps, o que permite por exemplo, a visualização de vídeos na internet sem interrupções. Na Figura 60 é apresentada a solução proposta para este problema, para uma rede que seja servida com uma velocidade de download fornecida pelo ISP de 50 Mbps.
Cada nó servidor/gateway nunca deverá servir extensões de nós clientes com mais do que 3 saltos, de forma a garantir qualidade de serviço.
Considerações finais
Quanto a estatísticas de tráfego, utilização dos nós, etc., poder-se-á compilar a imagem de firmware LuCI, que integra o firmware OpenWRT, e que disponibiliza gráficos e valores individualizados de todas as interfaces do router. A contrapartida é o aumento do tamanho da imagem final. Como os routers usados na rede “teste_1”, apresentam uma capacidade razoável de memória ram e flash, a inclusão da interface LuCI não causaria qualquer problema de degradação de desempenho, podendo esses dados servirem para efeitos estatísticos.