Re: Bridge é hub ou switch
Citação:
Postado originalmente por
leosmendes
qual seria uma solução melhor ? e que benefícios traria?
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.
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.
Citação:
Postado originalmente por
josenunesti
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 ?
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.
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).
Re: Bridge é hub ou switch
Citação:
Postado originalmente por
rubem
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.
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...
Re: Bridge é hub ou switch
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.
Re: Bridge é hub ou switch
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
Re: Bridge é hub ou switch
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