Bridge ou roteado - a velha discussão

[araujoprog]

Vejo muitos comentários sobre "coloca em bridge pois o mikrotik não aguenta", pois bem vamos lá. Quando se dimensiona um equipamento de rede você tem que se preocupar com alguns detalhes técnicos, o principal deles é a capacidade de processamento de pacotes e não a velocidade do processador em si, pois um processador de 200MHz pode processar pacotes mais rápido que um de 600MHz, se o mesmo for projetado exclusivamente para isso. Depois de entender as especificações do hardware que tem em mãos é hora de planejar a instalação/configuração do mesmo, vale lembrar que access points baseados em RouterOS contém duas partes básicas, uma é o sistema base onde roda o sistema operacional (RouterBoard, PC, Alix....) e outra é a parte de transceptor (cartões R52H, CM9, CM10, XR2, XR5...), sabendo disso é interessante "casar" as duas partes para que se tenha o melhor desempenho possível, depois de escolher a parte física do AP é hora de configurar a parte lógica, como deverá funcionar propriamente dito. Falarei brevemente de dois modos de funcionamento mais comuns de AP baseados em RouterOS, "Bridge" e "Roteador".

Bridge - Uma bridge trabalha na camada 2 (modelo OSI), claro que no RouterOS há como aplicar algumas regras na bridge em níveis mais altos, mas ai ela deixa de ser bridge, de acordo com o conceito. Da forma com que a bridge trabalha, todo o trafego deve ser tratado em um roteador central, limite de banda, descarte de pacotes, regras de firewall, enfim todo o trafego passa de modo transparente para ser tratado adiante, agora imagine um ponto de acesso remoto onde há um backhall de transporte (ponto a ponto) todo o trafego desnecessário está passando por ele até chegar ao roteador central para ser tratado, fora outros transtornos como broadcast, em uma rede em bridge um único cliente tem o "poder" de diminuir o rendimento de todos os outros mesmo em outras "torres" somente com broadcast, fora outros problemas que podem ocorrer com rede em bridge, no meu ponto de vista eu só trabalharia com access point em bridge se tivesse um switch layer 3 logo atrás do mesmo para "filtrar" todos os problemas relatados.

Roteador - Um roteador trabalha na camada 3 (modelo OSI, há roteadores que podem trabalhar até a camada 7, é o caso do RouterOS). O modo Roteador trás alguns benefícios como descentralização da rede e diminuição dos pontos de falha, fora a superação dos malefícios que a bridge acarreta, imagine um cliente que está gerando broadcast excessivo, o mesmo ficará restrito somente ao seu ponto de roteamento, o backhall fica livre de trafego indesejável pois é possível aplicar regras no próprio ponto de acesso, ficou claro a minha preferência.

Problemas relatados pelos donos de provedores:

"Rotear causa processamento alto": Como eu disse o roteador trabalha na camada 3, se um cliente estiver ruim ele vai gerar retransmissão, correção de erro, e será usado o processamento do ponto de acesso para executar este procedimento.

"No modo bridge aguenta mais clientes": Expliquei anteriormente que são duas partes que formam o access point, o que determina a quantidade de clientes que se pode ou não colocar em uma única interface é a tecnologia do meio físico no caso a grande maioria utiliza 802.11b que trafega 11mbps (no meio físico) com a sobrecarga de protocolo o trafego útil cai para 4mbps na melhor das condições, sabendo disso é só fazer as contas de acordo com os planos comercializados.

Hoje em dia estão sendo comercializados placas base cada vez mais compactas e com poderosos processadores, então eu me preocuparia menos com o "processamento" e mais com a configuração adequada da rede.

Eu poderia estender o tópico mas paro por aqui, isso não é um tutorial de como deve ser tua rede, mas sim um alerta para que muitos planejem melhor, pois temos condições de fornecer serviços de qualidade excepcional apenas com o que temos nas mãos sem precisar investir milhões como fazem os grandes operadores.

PS. Qualquer dúvida estou a disposição.

[fernandofiorentinn]

Bridge só em casos especificos, afinal de contas prq uma Rb teria um poderoso firewall embutido nela?

[dmnetcatende]

e muito interessante seu post, eu estou nessa situação.

ponto 1 ------2 Adsl 8mb ip 192.168.x.x e o outro 192.168.x.x tambem de 8mb
ponto 2 ------ torre com rb 433ah 3 interfaces wireless, uma recebe o link e as outras mandam cada uma pra uma cidade onde em cada cidade dessa tem uma rb 433 fazendo roteamento pra os clientes,

tentei montar uma bridge pra cada cidade dessa eu usar um adsl, mas nao deu certo, dai tive q rotea a rb do ponto 2, mas onde veio o pro, so posso usar 1 adsl de cada vez, gostaria de saber se tem como mesmo a rb estando roteada usar um adsl em cada cidade ????

[lipeiori]

Prefiro brigde.

[MaxAdriano]

muito bom, é um ponto a se analizar...

[dmnetcatende]

uma vez fui fazer um link pra um provedor e fiz o seguinte,
os radios eram todos ap 5000 ovislink, no ponto dois onde recebia o link eu liguei um switch no radio e os outros radios no switch(todos em bridge), dai da pra colocar cada cidade em um adsl, mas no mikrotik to esperando uma soluçao

[rubensk]

Bridge ou roteado é uma discussão diferente de usar firewall ou não. Ambos podem ter firewall ligado ou não. Há também uma terceira opção que é MPLS que tem numa rede roteada uma performance quase tão boa quanto bridge.

Com a capacidade de processamento limitada de uma Routerboard, as 5 possibilidades tem sim bastante diferença. Já com PC AP isso não faz muita diferença.

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

[rubensk]

Você pode controlar banda por MAC mesmo com roteamento. Basta oferecer os IPs daquela subnet por DHCP, e usar RADIUS (/ip dhcp server use-radius yes); o endereço MAC vai para o servidor RADIUS. Você pode ou usar a resposta RADIUS para criar uma regra de banda na Routerboard que atende aquele segmento, ou rodar um ação no servidor RADIUS que programe essa regra em outro lugar.

Quando você diz dividir IPs em classes, isso não é necessário... você pode dividir em subnets menores. O quanto se perde de IPs em subnets de tamanho apropriado é pouco, e aceito como justificativa para se pedir mais IPs.

[Josue Guedes]

Cara, a questão do Radius vem a complicar a coisa mesmo. É o unico jeito? Não ocorre o repasse de MAC naturalmente?

[rubensk]

Cara, a questão do Radius vem a complicar a coisa mesmo. É o unico jeito? Não ocorre o repasse de MAC naturalmente?

Não. A missão de roteadores é exatamente trocar o MAC de cada pacote; eles trocam o MAC origem pelo MAC próprio, e o MAC destino pelo do próximo hop de roteamento.

[araujoprog]

e muito interessante seu post, eu estou nessa situação.

ponto 1 ------2 Adsl 8mb ip 192.168.x.x e o outro 192.168.x.x tambem de 8mb
ponto 2 ------ torre com rb 433ah 3 interfaces wireless, uma recebe o link e as outras mandam cada uma pra uma cidade onde em cada cidade dessa tem uma rb 433 fazendo roteamento pra os clientes,

tentei montar uma bridge pra cada cidade dessa eu usar um adsl, mas nao deu certo, dai tive q rotea a rb do ponto 2, mas onde veio o pro, so posso usar 1 adsl de cada vez, gostaria de saber se tem como mesmo a rb estando roteada usar um adsl em cada cidade ????

Tem sim amigo, você pode fazer isso por rota ou pra ficar melhor ainda através de VLAN.

[araujoprog]

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.

[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.

[araujoprog]

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.

[rubensk]

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.

[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.

[rubensk]

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.

[agpnet]

Pessoal, a melhor maneira de centralizar tudo por aqui foi: Utilizar PPPoE, tudo em bridge, nas bridges usar filtros para passar somente pppoe-discovery e pppoe-session, assim não há nenhum broadcast, tentativas de scan no backbone (firewall e controle de banda centralizados), servidor de backup com as mesmas regras do principal (talvez até um hardware menos poderoso para quebrar o galho enquanto o principal esta off), notei que as rb´s não dão trabalho de manutenção quando em bridge, estou estudando como usar freeradius para liberar access-list da rb também.

Desta maneira, retirei toda a sobrecarga de rede do meu backbone e a latência da rede caiu bastante, pois nesta estrutura foi possível implantar um esquema de QOS (ainda estou aprimorando, pois tenho algumas dúvidas não sanadas), cache-full apenas com algumas regras (imaginem ter que repetir as regras de qos e cache em cada rb, qual é o custo de performance), o uso do processador do servidor central, com controle de banda, qos, firewall, pppoe etc...etc... etc... com +- 100 pessoas online não passa de 5% de pico e 2~3% constantes.


Eu exponho aqui minha opinião pessoal e experiência profissional, definitivamente BRIDGE.

[Josue Guedes]

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.

Deu uma pesquisado sobre o que você disse, esse broadcast ai pode ser bloqueado, com filtros nas portas 135-139, certo? Uma filtro na bridge resolve. O que você me diz?