+ Responder ao Tópico



  1. #13

    Padrão Re: MSN caindo 2 links

    Galera,

    Se eu entendi direito o que nosso amigo anterior disse, toda vez que eu tiver uma situação de balancemaneto de link e juntamente com isto tiver o acesso a sites tipo banco, jogos, msn eu estou correndo o risco de perder a conexão?

    Se isto é verdade, como as operadoras de telecom trabalham? Depois que eu requisito uma página de banco por exemplo, mesmo eu tendo un unico link, como vc pode garantir que todas as transações que estou fazendo naquele momento estao saindo pelo mesmo caminho através da operadora? Se o que foi dito é verdade, "utilize rotas estaticas, pois é a unica solucao que conheço" entao toda teoria de protocolos de rotemaneto dinamico (OSPF, BGP) e balanceamento de carga foi por agua abaixo.

    Abraço


  2. #14

    Padrão Re: MSN caindo 2 links

    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.



  3. #15

    Padrão Re: MSN caindo 2 links

    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.
    Exatamente o que queria dizer... Outra coisa, as operadores não fazem NAT nos IP´s que são atribuídos aos seus links, ou seja, todos links (ADSL ou Full) recebem IP´s Válidos...

  4. #16

    Padrão Re: MSN caindo 2 links

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



  5. #17

    Padrão Re: MSN caindo 2 links

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

  6. #18

    Padrão Re: MSN caindo 2 links

    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.