Bridge ou roteado - a velha discussão

Citação:

Postado originalmente por Josue Guedes

Olha, estou até tendo um debate sobre isso em um outro tópico, e já fiz testes aqui, e fica claro que o roteamento deixa a rede mais "presa", contudo isso foi uma experiência comigo aqui, e estou para testar novamente.

Agora, tem umas coisas que uso, e ainda não achei jeito de fazer usando roteado. Uma delas é controle de banda, não me agrada muito a ideia de controlar banda dos clientes na RB, até mesmo porque aqui é controlado por mac, e dessa maneira consigo aproveitar uma faixa de IP pequena usando DHCP. Isso é a minha birra. Ai deixo a pergunta, pois ainda não testei:

Mesmo usando roteamento, eu terei o repasse de MAC até o servidor?

Se sim, para min será uma solução, pois poderei continuar controlando a banda por MAC.

Uma outra desvantagem que vejo em rotear a rede, é a divisão dos IP em classes tendo assim um disperdício de Ip´s. O que vocês me dizem?

É inegável que a complexidade da rede sobe com roteamento (e também com o tamanho da rede).
1 - Mas qual o problema em se controlar banda na própria RB?
2 - Usando o Radius como o amigo falou em um tópico a facilidade de gerir os clientes sobe muito.
3 - Desperdício de IP??? Você é AS (Autonomous System)? Caso não seja está trabalhando com NAT e neste caso tem a sua disposição milhares de ips (um numero muito grande mesmo na faixa de bilhões de IPs) então onde estaria o desperdicio?

Imagine você criando uma subclasse para cada interface wireless da tua rede, só de olhar os relatórios do radius você saberia onde o cliente se conecta sem precisar de mais detalhes, não vejo como desperdicio, mas como beneficio.

A questão dos Ip´s, é que tenho uma classe pequena aqui, entende, e tá difícil conseguir uma maior. Sempre que se divide alguns se perdem, e no caso do roetamento entre as torres a faixa será divida para cada uma, certo?

Mikrotik tem um bom controle de banda, mais prefeiro fazer o controle em HTB, acho mais seguro, já vi muito relatos de P2P furar o controle de banda do Mikrotik, no HTB isso nunca aconteceu. Mais de fato não sei se isso ainda ocorre.

Sobre Radius, sinceramente não usei ainda, tenho que estudar, por isso perguntei se há outra maneira. E é o que vou fazer, estudar sobre Radius.

Grato a todos.

Citação:

Postado originalmente por Josue Guedes

A questão dos Ip´s, é que tenho uma classe pequena aqui, entende, e tá difícil conseguir uma maior. Sempre que se divide alguns se perdem, e no caso do roetamento entre as torres a faixa será divida para cada uma, certo?

Você não precisa levar um IP válido a cada torre, pode fazer um NAT em um roteador central ou de borda.

Citação:

Postado originalmente por Josue Guedes

A questão dos Ip´s, é que tenho uma classe pequena aqui, entende, e tá difícil conseguir uma maior. Sempre que se divide alguns se perdem, e no caso do roetamento entre as torres a faixa será divida para cada uma, certo?

Mikrotik tem um bom controle de banda, mais prefeiro fazer o controle em HTB, acho mais seguro, já vi muito relatos de P2P furar o controle de banda do Mikrotik, no HTB isso nunca aconteceu. Mais de fato não sei se isso ainda ocorre.

Sobre Radius, sinceramente não usei ainda, tenho que estudar, por isso perguntei se há outra maneira. E é o que vou fazer, estudar sobre Radius.

Grato a todos.

O Mikrotik é tão baseado em kernel Linux quanto sua máquina com outra distro e HTB. Se o controle depende de algo que identifica o cliente e não da aplicação que ele está usando, não vai ter P2P que fure...

Uma maneira de preservar o MAC em rede roteada é usar tunelamento EoIP, mas isso é bem custoso para a CPU da Routerboard, e um fator que exige licença maior do Mikrotik... eu não acho que o controle via RADIUS seja um ônus tão grande assim para o imenso ganho que se tem abolindo a propagação de broadcasts na rede.

Algo a lembrar de broadcasts é que eles são sempre transmitidos na pior modulação habilitada, que pode ser 1 Mbps se 802.11b estiver habilitado, ou 6 Mbps para só 802.11g ou 802.11a. Rotear sem ligar o conntrack é o jeito mais eficiente de acabar com eles... seria possível filtrá-los em bridge também, mas isso gasta mais do processador por exigir a verificação de umas 4 regras de ebtables.

A questão do Broadcast não tenho aqui, pois os clientes recebem Ip com máscara /32, por DHCP, e são autenticados com Senha individual, WPA2/AES. Já temos em 400 clientes, e ainda não tivemos problemas, mais procuro sempre saber o que há de melhor. Estarei fazendo testes baseados nas sujestão dos amigos.

Citação:

Postado originalmente por Josue Guedes

A questão do Broadcast não tenho aqui, pois os clientes recebem Ip com máscara /32, por DHCP, e são autenticados com Senha individual, WPA2/AES. Já temos em 400 clientes, e ainda não tivemos problemas, mais procuro sempre saber o que há de melhor. Estarei fazendo testes baseados nas sujestão dos amigos.

Se seus cliente usam Windows, você tem sim questões de broadcast... é default do Windows gerar broadcasts de protocolos de rede Microsoft.

Todo broadcast que é gerado em IP é transmitido como broadcast de Ethernet e/ou Wi-Fi, e vai ser transmitido em baixa modulação.

A separação que você fez apenas faz com que os broadcasts dos usuários não se misturem, o que de fato gera mais broadcast (as máquinas Windows competindo para ser master browser, por exemplo). Ela é muito positiva em fazer os clientes não se atrapalharem, mas não muda o fato de que sua estrutura de rádio está sendo utilizada para tráfego inútil que não é limitado no serviço do usuário por ser descartada pelo seu servidor de controle de banda após ter transitado pelo rádio.