[GTER] Balanceamento de carga
Rubens Kuhl Jr.
rubens at email.com
Wed Sep 8 16:51:54 -03 2004
Desde que seja multi-chassis-multi-link-PPP, pode funcionar... se os dois
link terminam no mesmo equipamento e esse equipamento morre, não há
redundância.
Rubens
----- Original Message -----
From: "Rafael Marcelino Koike" <r.koike at terra.com.br>
To: "Rubens Kuhl Jr." <rubens at email.com>; "Grupo de Trabalho de Engenharia e
Operacao de Redes" <gter at eng.registro.br>; <edgar at ig.com.br>
Sent: Wednesday, September 08, 2004 11:29 AM
Subject: Re: [GTER] Balanceamento de carga
> Se for para ter links independetes acho que seria mais simples entao usar
> MPPP.
>
> Voce tem redundancia e balanceamento automaticamente.
>
>
> ----- Original Message -----
> From: "Rubens Kuhl Jr." <rubens at email.com>
> To: <edgar at ig.com.br>; "Grupo de Trabalho de Engenharia e Operacao de
Redes"
> <gter at eng.registro.br>
> Sent: Wednesday, September 08, 2004 10:46 AM
> Subject: Re: [GTER] Balanceamento de carga
>
>
> > > > O pacote vai para todos os dispositivos, e eles combinam uma
> estratégia
> > de
> > > > balanceamento entre si.
> > > > Exemplo: todo hash de IP origem/IP destino que seja par é tratado
pelo
> > A, e
> > > > todo ímpar pelo B.
> > > Entendi, quer dizer q poderia tratar a rede com um grupo multicast de
> > > gateway para a ida.
> > > No universo dos ISPs fornecedores do link como ficaria a rota de
> > > retorno, ja q nao temos divulgacao nenhuma de rota? Ou mesmo q o ISP
> > > divulgasse a rota ele faria o ajuste? Queria ver algo transparente,
sem
> > > envolvimento do ISP para implementar essa tecnica.
> >
> > Não existe. Sem envolvimento do ISP, o jeito é ter links independentes,
> > fazer balanceamento por sessão entre os links e NAT condicional
(garantir
> > que o tráfego saindo por um link tenha IP origem desse link). O que pode
> > inclusive ser feito com ISPs diferentes, o que melhora a disponibilidade
> > ainda mais.
> >
> > Se você quer redundância com balanceamento e seu ISP não tem, troque
para
> um
> > que tenha...
> >
> > > > Prioridade do VRRP: o dispositivo primário tem uma certa prioridade,
o
> > > > secundário menor. Na ausência do primário, o secundário assume as
> > funções
> > > > daquele gateway. O que eu descrevi é a idéia de que um dispositivo
> baixe
> > sua
> > > > prioridade numa outra interface (que seria o uplink) em função da
> queda
> > de
> > > > outra interface (ou perda da eleição VRRP nela)
> > > Certo, mas isso nao balanceia o retorno de pacotes.
> >
> > VRRP não faz balanceamento... o que descrevi apenas estabelece simetria
de
> > tráfego.
> >
> >
> > Rubens
> >
> > --
> > GTER list https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
More information about the gter
mailing list