Versão Imprimível
Olá comunidade !
Tenho uma duvida sobre bridge, na verdade tenho um tremendo receio em usar bridge, ela se comporta como um hub que repete tudo que entra para as demais portas, ou como um switch que trabalha com tabela ARP que encaminha o frame para a porta certa ?
A bridge é uma boa pratica usar bridge ou na maioria dos casos tem outra alternativa ?
Desde já agradeço !
Pela literatura, um switch é uma bridge multiportas, então sim, tanto o switch como a bridge trabalham na camada 2.
Um hub pelo mesmo conceito trabalha na camada 1.
* O amigo, somos quase vizinhos...
Um detalhe bobo: Fazer hub hoje sai muito mais caro que fazer switch!
Tem CI dedicado pra switch por preço tipo US$ 2 ou 3, um switch é basicamente um deles, componentes de alimentação, placas e jacks RJ45. Pra um hub vai um monte de componentes passivos, diodos, capacitores e resistores aos montes, o custo é bem maior, fora que vai os mesmos componentes pra alimentação, placa e jacks RJ45.
Então o que muita RB e roteador de mesa tem é um CI de switch entre as portas e o chipset, alguns firmwares tratam como "hardware aceleration" o ato de o chipset não se intrometer no trafego desse CI, o firmware deixa o CI operar como switch, mas se habilitar o "Software aceleration" o chipset passa a analizar cada pacote. Quando se habilita o isolamento de portas é isso também que ocorre, o software intercepta os pacotes do CI e define se vai repassar ou não.
RB's de muitas portas tem "grupos de portas", essas RB's de 10 portas tem coisa tipo 2 grupos de 5 (Com um CI de switch de 5 portas), e mais uma master port (Que vai direto ao chipset).
Problema de bridge é pessoal que coloca o servidor aqui, sobe cabo, passa por PTP, vai até outro radio, passa por outro PTP, passa por PTMP, e então chega no cliente. Esse trajeto todo é um problema. Mas uma bridge servidor>ptmp>cliente é tranquila, o problema é em rede grande.
qual seria uma solução melhor ? e que benefícios traria?Citação:
Postado originalmente por rubem
Ruben, não entendi muito bem o conceito de grupos de porta, elas barram broadcast ou algo do tipo ? ou somente domínio de colisão ? o acelerador por software seria uma vlan ?Citação:
RB's de muitas portas tem "grupos de portas", essas RB's de 10 portas tem coisa tipo 2 grupos de 5 (Com um CI de switch de 5 portas), e mais uma master port (Que vai direto ao chipset).
Rede grande precisa estar roteada, assim o roteador que atende o cliente é quem decide se vai jogar o pacote do cliente pro servidor ou não. Em caso de cliente cortado (Cancelado, pagamento atrasado) não terá tráfego inútil rodando pela bridge.Citação:
Postado originalmente por leosmendes
O problema de rede em bridge é ter dados irrelevantes circulando, numa rede pequena isso não incomoda, acho que a partir de uns 100 clientes começa a incomodar.
Sobre o que o software faz desconheço os detalhes a fundo, a parte que me toca é sobre os CI's usados, em RB's com muitas portas elas não se comunicam diretamente com a CPU, mas sim com um CI de switch.Citação:
Postado originalmente por josenunesti
A Mikrotik até tem uma tabela:
http://wiki.mikrotik.com/wiki/Manual..._Chip_Features
No exemplo que dei, a RB1100, ela tem um CI de switch, o AR8327, ele pode operar no layer 3, isso é o "hardware aceleration" que uns setup's trazem:
https://wikidevi.com/files/Atheros/s...27_AR8327N.pdf
Mas ele também pode operar como ponte, repassando todos os pacotes válidos das portas até a CPU (Que na RB1100 é um MPC8544, que só tem 2 portas ethernet nele: http://www.freescale.com/webapp/sps/...?code=MPC8544E , os CI's se comunicam provavelmente pelas entradas PCI-express)
Já RB menor tipo a RB750 tem as portas indo direto pra CPU, que é uma AR7240, que tem nativamente 1 wan e 4 lan: http://wiki.openwrt.org/_media/toh/t...ros.ar7240.pdf
O desempenho disso com digamos 4 wan não é grandes coisas (Não balanceia mais que uns 30 a 50Mbps) porque todo pacote é analisado via software, a CPU do chipset é que sofre.
O que quero frisar é que isso de "aceleração via hardware ou software" não é inovação, na aceleração via hardware ocorre o que sempre ocorreu, o CI opera como switch layer 2 típico, com possibilidade de escanear por uma porta os pacotes do outro, já com aceleração via software todos os pacotes de uma porta pra outra passam pelo software na CPU, o desempenho cai QUANDO a CPU está sobrecarregada, por isso não se usa algo tipo uma RB493AH como switch gerenciavel com 9 micros trafegando 100Mbps por porta, a CPU não dá conta, teria que ser algo tipo uma RB1200 ou 1100 pra uso grande.
Os melhores produtos tem um chipset de rede conectado na CPU via PCI-express, hoje se usa PCI-e 2.0, mesmo que seja em x1 isso são 4Gbps entre o CI e a CPU, se tiver 5 portas 10/100M tá tranquilo. Se a CPU tiver processamento adequado (Pra ter isso as RB's mais parudra tem processadores PowerPC) o software não terá problemas em rotear quase 100Mbps por porta sem muitos gargalos. Então o uso de software pra processar dados de rede só é problema em hardware fraco.
Enfim, os CI's de layer 3 que algumas RB's tem permitem umas inseguranças a meu ver, feature tipo descobrir rede é o que todo noob espera no Windows (Não sabem dar um \\192.168.1.3, precisam ver no Explorer, em Rede, os micros plugados no mesmo switch ou RB), então esses CI's permitem descoberta de outros dispositivos no mesmo CI, isso ajuda o noob que não sabe usar rede nos sistemas operacionais comuns, mas facilita a vida dos sniffers, você consegue capturar alguns pacotes. Não permite capturar TUDO como switch layer 2 permite (Até descobrir senha de MSN e cia), mas permite algumas coisas. Pra usuario comum isso não é problema (Só capturaria autenticação, mac, coisa pouca, não capturaria pacotes do usuario), então se quer um pouco mais de segurança use RB e não switch comum. Se não quer ter que mecher com RB use switch gerenciavel, eles também operam em layer 3, são mais simples de gerenciar.
Como a MK trata os dados na bridge (Se por L2 ou por L3) aí não sei ao certo, ela tem componentes pra L3 em quase toda RB, mas a definição de bridge é um switch l2 mesmo. O que quero focar é que mesmo tendo CI de switch em RB elas não permite sniffer nas portas se não tiver bridge, não é por ter um grupo de 5 portas no mesmo CI de switch que essas portas são inseguras entre sí, a insegurança só surge se colocar elas em bridge (E a insegurança é basicamente sniffer capturando pacote de rede pra pegar dados, o jeito de evitar isso é com roteamento, sem bridge, ou com isolamento de portas noutros sistemas operacionais).
mas para isto eu bloqueio todo o trafego que não seja pppoe na cpe do cliente, e ele viaja na velocidade da rede e somente é limitado no meu roteador central, a meu ver parecia a melhor solução e poupa processamento nos ptps...Citação:
Postado originalmente por rubem
Sobre as vantagens do roteamento, tem bastante coisa na web, uns resumos:
http://mum.mikrotik.com/presentation...nderson-br.pdf
e
http://mum.mikrotik.com/presentations/BR13/andrade.pdf
Dá pra ter uma rede em bridge decente, com encriptação e removendo clientes desativados (Sem pagto, cancelados), com bridge em VLAN ou OSPF caso tenha ptp cascateado , mas acho que o roteamento dá menos trabalho, fora que facilita o gerenciamento centralizado.
Citação:
Postado originalmente por rubem
é vou procurar saber mais sobre o assunto mas acho que no meu caso não se aplica ja que meu roteador esta em A, que só vê B, e B só vê A e C , C só vê B e D , e D só vê C ,E e F , mas F não vê E.. ou seja em resumo devido a topologia de terreno somente com pontos estratégicos consigo expandir a rede
olha este video talvez possa te ajudar:
https://www.youtube.com/watch?v=768i3V9ST48
Minicurso switches Huawei parte 3 - Tutoriais vídeo #02 - como configurar seu switch em L2
talvez este video te ajude:
https://www.youtube.com/watch?v=768i3V9ST48
Minicurso switches Huawei parte 3 - Tutoriais vídeo #02 - como configurar seu switch em L2