+ Responder ao Tópico



  1. Citação Postado originalmente por Josue Guedes Ver Post
    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.

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



  3. Citação Postado originalmente por Josue Guedes Ver Post
    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.

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



  5. Citação Postado originalmente por rubensk Ver Post
    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?






Tópicos Similares

  1. Respostas: 2
    Último Post: 26-09-2014, 10:41
  2. Mikrotik com Modens Roteados, Bridge ou tanto faz ?
    Por davidmilfont no fórum Redes
    Respostas: 6
    Último Post: 30-03-2014, 20:30
  3. Respostas: 0
    Último Post: 22-02-2014, 16:27
  4. Cliente em Bridge ou Roteado?
    Por wesleydialmeida no fórum Redes
    Respostas: 8
    Último Post: 17-04-2013, 08:23
  5. Modem "VDSL" em Bridge ou Roteado com RB433UAH ?
    Por davidmilfont no fórum Redes
    Respostas: 5
    Último Post: 02-05-2012, 10:59

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L