+ Responder ao Tópico



  1. Citação Postado originalmente por PatrickBrandao
    Acho otima a ideia, gostaria de encontrar algo estável.
    Tomara que nao entrem crianças que nem sabem o que é iproute2 na discução, isso acaba com os topicos fixos.

    Uma curiosidade minha é que tem produtos no mercado (hardware) que prometem fazer balanceamento e usam kernel linux. Queria saber como eles fazem.
    BGP4...

  2. Citação Postado originalmente por PatrickBrandao
    Amigo,

    você nao entendeu o proposito da discução. Quando o balanceamento é feito dentro
    de AS's nao importa o caminho por onde o pacote vai ou volta, ele permanece inalterado.

    Estamos lidando com casos em que existem links de diferentes operadoras e há NAT, assim se o pacote muda de link o campo origem do pacote ip muda, ocasionando queda de conexão, já que o TCP é orientado a VC com ip.

    Queremos uma solução pra isso. Assim poderemos agregar varios links adsl, circuitos, etc... num mesmo servidor e somar suas bandas de forma estável.
    Patrick,

    Mesmo um AS têm vários links de várias operadoras senão não seria um AS. O que eles usam são protocolos de roteamento avançado... Eu tentei estudar BGP4 mas acaba sendo bem complicado e eu quase não tenho tempo. Por isso pensei em bonding entre as interfaces...



  3. Eu entendo o BGP4, OSPF, RIP e mais um montão e não é neles que está a solução.

    Se recebermos dois links de operadores diferentes e dermos ips validos para os clientes, nos só poderiamos balancear o UPLOAD, o DOWNLOAD teria que ser balanceado pelas operadoras, trocando rotas com os protocolos que cada uma usa (primeiro problema, ex.: a telemar nao vai aceitar trocar rotas para um unico cliente em comum com a embratel, nem sonha em pedir, segundo problema: elas podem usar protocolos diferentes).

    Se recebemos dois links, um Velox e um Speedy, por exemplo, teremos que dar ip privado (192.168, 172.16 ate 172.31, 10) e fazer NAT.

    clientes
    |
    |
    gateway (ppp0: 200.1.2.3) ---------> speedy
    (ppp1: 201.5.4.1) ----> velox

    O problema está aqui:
    Se o pacote sair pelo speed, o host remoto vai estabelecer uma conexão com 200.1.2.3, se no meio da conversa não houver dados (o cliente mudou de link, a conexão será em breve finalizada por timeout) e vier dados do ip 201.5.4.1, o host remoto não vai aceitar, ele nao tem nada a tratar com 201.5.4.1 (ele vai responder um Tcp: reset) e a conexão será finalizada. O host remoto espera que 201.5.4.1 inicie um handshake (http://pt.wikipedia.org/wiki/TCP), algo que não vai acontecer pois o host cliente (nosso cliente mesmo) ja iniciou a conexão e para ele só precisa trocar dados.

    Eu consegui amenizar esse problema aumentando o tempo de vida da rota no cache (o que evita que as regras de rotas sejam reprocessadas e um novo gateway seja selecionado).


    #!/bin/sh

    setoption(){
    # define opcoes de rotas no kernel
    option=$1
    value=$2
    echo $value > /proc/sys/net/ipv4/route/$option
    }


    # alterar valores sysctl
    # opcoes default

    echo " - Reset kernel option"
    setoption error_burst 1250
    setoption error_cost 250
    setoption gc_elasticity 8
    setoption gc_interval 60
    setoption gc_min_interval 0
    setoption gc_min_interval_ms 500
    setoption gc_thresh 512
    setoption gc_timeout 300
    setoption max_delay 10
    setoption max_size 8192
    setoption min_adv_mss 256
    setoption min_delay 2
    setoption min_pmtu 552
    setoption mtu_expires 600
    setoption redirect_load 5
    setoption redirect_number 9
    setoption redirect_silence 5120
    setoption secret_interval 600

    # opcoes alteradas

    setoption gc_elasticity 86400
    setoption gc_interval 86400
    setoption gc_min_interval 86400
    setoption gc_min_interval_ms 3600
    setoption gc_thresh 5120
    setoption gc_timeout 86400
    setoption max_delay 60
    setoption max_size 1215752191
    setoption min_adv_mss 256
    setoption min_delay 3600
    setoption secret_interval 6000


    O efeito colateral é consumo de memoria, e se o processador não for bom (500mhz pra baixo), acima de 10 megabytes de tráfego a coisa fica negra depois de um tempo.

    Agora, vamos centrar o nosso foco em resolver esse problema, pois se conseguirmos fazer que isso acima funcione, qualquer outro tipo de implementação com links irá funcionar.

  4. Patrick,

    Relamente, esqueci do fato que existe o NAt para sua rede interna ou até mesmo clinets de um provedor menor. No caso as operadoras não realizam NAT pois são todos IP´s públicos.

    Desculpe ter comparado alhos com bugalhos, mas realmente havia me esquecido do fator NAT.



  5. rapaz eu faco o balanceamento aqui baseado no wiki de nataniel e deu certo downlaod grandes nao cai talz na questao bancos eh so amarrar o dominos pra sair somente pelo mesmo link e ja msn amarre a porta 1863 e por ai assim aqui ja show... e depois colocar um script pingando de 10 em 10 segundos 3 sites principais eu aqui coloquei, uol, terra e meu link principal. quando os 3 falharem eh so mudar a roda do pacotes rescrevendo o "ip ro" eu faco assim e ta um show mesmo 1 dos link caindo o resto nao para...






Tópicos Similares

  1. Respostas: 40
    Último Post: 19-03-2012, 06:26
  2. msn caindo sempre...
    Por Skylinelan no fórum Redes
    Respostas: 6
    Último Post: 15-10-2007, 18:04
  3. Respostas: 7
    Último Post: 06-10-2007, 22:53
  4. Problema com MsN caindo no PPPoE
    Por marcotuliothor no fórum Redes
    Respostas: 13
    Último Post: 29-06-2007, 11:51
  5. Msn Caindo
    Por fabianojean no fórum Redes
    Respostas: 11
    Último Post: 21-08-2006, 09:35

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L