[GTER] link aggregation

Carlos Ribeiro cribeiro at telbrax.com.br
Sat Aug 30 01:36:49 -03 2014 

Wladimir,

Você tem razão em um ponto: se o balanceamento for inerentemente
"desequilibrado" (caso de LAGs que não sejam potências de dois, como 2, 4
ou 8), podemos aproveitar esse desbalanceamento para otimizar o uso de
links de rádio que já estejam modulando a taxas diferentes.

O problema é que esse tipo de comportamento é muito dinâmico, especialmente
em rádios com ACM. Então existe sempre o risco de que um enlace que esteja
modulando em velocidade máxima encontre uma interferência e caia de
velocidade. Se você não estiver monitorando em cima, pode criar o pior dos
mundos: pegar uma das portas com mais tráfego pelo balanceamento, e jogar
em um enlace que esteja rodando com taxa inferior ao desejado. Como o hash
tem um caráter aleatório, os clientes reclamarão de perda de pacotes
igualmente aleatória, e há o risco de ficar procurando o problema por horas
sem imaginar que pode ser uma falha desse tipo.

Eu pessoalmente prefiro manter as coisas simples: usar sempre que possível
um número adequado de links (1, 2, 4 ou 8); e se tiver que usar um número
ímpar, distribuir o tráfego de outra forma, como por exemplo, publicando
VLANs diferentes, ou apontando rotas específicas para cada enlace. O
resultado tende a ser mais previsível.

*Carlos Ribeiro*
*Sócio*
Cel: +55 (31) 9303-3366
Tel: +55 (31) 3305-5620
Geral: +55 (31) 3305-5600
cribeiro at telbrax.com.br
www.telbrax.com.br


Em 29 de agosto de 2014 18:24, Wladimir Pereira <wladnery at gmail.com>
escreveu:

> Boa noite, Rodrigo.
>
>
> Balanceamento com número ímpar é bem aproveitado quando a capacidade de
> transmissão de dados de cada enlace apresenta números distintos (típico de
> aplicação com rádios), mesmo sabendo que elas três possuem portas gigabit
> (por exemplo).
>
> O balanceamento ocorre em 8 filas, então temos:
> Enlace 1: 300Mbps (3 pacotes sorteados)
> Enlace 2: 300Mbps (3 pacotes sorteados)
> Enlace 3: 200Mbps (2 pacotes sorteados)
>
> Quando as 8 filas do balanceamento se encerrar (neste caso, no Enlace 2), o
> processo se iniciará novamente a partir da primeira porta (ID) agregada.
>
> Apliquei isso aí na prática, com resultado conforme planejado.
>
>
> PS: Importante observar quais enlaces (capacidades) utilizarão quais
> portas/IDs no switch.
>
>
>
>
>
> Abs.,
>
>
> Wladimir
>
>
> Em 29 de agosto de 2014 16:14, Carlos Ribeiro <cribeiro at telbrax.com.br>
> escreveu:
>
> > O impacto depende do número de buckets da implementação do hash. Mesmo
> com
> > oito buckets, que é um caso comum, os três canais ficam com peso 3/3/2,
> que
> > é bem melhor que o 2/2/2/1/1 de cinco canais. Talvez por isso você não
> > tenha notado tanta diferença.
> >
> > Agora, imagina o pior caso com 7 canais... Um dos canais entope com os
> > outros seis a meia carga... Dá quase na mesma que um LAG de quatro
> canais.
> > Exceto se o hash tiver 16 buckets, aí melhora consideravelmente.
> >
> > P.S. quem trabalha com rádios de longa distância precisa levar isso a
> > sério, e o único jeito de garantir não ocorra esse tipo de
> desbalanceamento
> > é usando alguma solução de mux "proprietária" do fabricante do rádio.
> Todos
> > os grandes fabricantes oferecem sistemas que garantem serialização do
> > tráfego na camada 1, com eficiência máxima dos canais, e alguns conseguem
> > até balancear tráfego corretamente mesmo que algum canal esteja
> degradado,
> > coisa que o LAG não faz!
> >
> > Carlos Ribeiro
> > Em 29/08/2014 11:55, "Rodrigo Pedrosa" <rodrigopa.uepb at gmail.com>
> > escreveu:
> >
> > > Senhores, utilizo em vários locais 03 interfaces agregadas e nunca tive
> > > problema de desbalaceamento.
> > >
> > > Att., Rodrigo.
> > >
> > >
> > > Em 29 de agosto de 2014 04:56, Carlos Ribeiro <cribeiro at telbrax.com.br
> >
> > > escreveu:
> > >
> > > > É isso mesmo! Tendo 5 interfaces, com 8 buckets de hash, você terá 3
> > > > interfaces com 2 buckets e 2 interfaces com um bucket só. Dá
> exatamente
> > > > 25%/25%/25%/12.5%/12.5%, ou seja, duas interfaces terão só metade do
> > > > tráfego.
> > > >
> > > > Carlos Ribeiro
> > > > Em 28/08/2014 23:52, "Rodrigo Augusto" <rodrigo at 1telecom.com.br>
> > > escreveu:
> > > >
> > > > > Gente, muito obrigado! A explanacao de voces bate exatamente com
> meu
> > > > > cenario..
> > > > > 5 interfaces agregadas... Algumas delas chegam a picos de
> 1gb(978mb)
> > e
> > > > > duas delas nao chegam a mais de 500mb.... Vou corrigir para 8
> > > > interfaces...
> > > > > Mais uma vez, muito obrigado!
> > > > >
> > > > > Enviado via iPhone 
> > > > > Grupo Connectoway
> > > > >
> > > > > > Em 28/08/2014, às 22:07, Carlos Ribeiro <cribeiro at telbrax.com.br
> >
> > > > > escreveu:
> > > > > >
> > > > > > Vamos lá:
> > > > > >
> > > > > > 1. É comum que o limite seja de 8 portas, mas há implementações
> com
> > > > > números
> > > > > > menores (ex: 4 interfaces) ou se não me falha a memória, até
> > maiores
> > > > (mas
> > > > > > não achei um doc aqui agora para provar).
> > > > > >
> > > > > > 2. O número de interfaces agregadas pode ser arbitrário, porém,
> se
> > > não
> > > > > for
> > > > > > potência de dois, isso pode levar ao desequilíbrio de tráfego no
> > > > sistema
> > > > > e
> > > > > > a um maior desbalanceamento do tráfego. Isso ocorre porque o
> > > > > balanceamento
> > > > > > é feito por meio de um "hash", acelerado por hardware. Em algumas
> > > > > > implementações existe uma tabela fixa com um número
> pré-determinado
> > > de
> > > > > > entradas (ex: 8 entradas, ou 16 entradas). A tabela mapeia cada
> > valor
> > > > de
> > > > > > hash para um membro do grupo.
> > > > > >
> > > > > > Exemplo: supondo uma tabela de balanceamento de 8 entradas, para
> > dois
> > > > > links
> > > > > > a tabela fica assim (50% para cada link):
> > > > > >
> > > > > > 1  1
> > > > > > 2  1
> > > > > > 3  1
> > > > > > 4  1
> > > > > > 5  2
> > > > > > 6  2
> > > > > > 7  2
> > > > > > 8  2
> > > > > >
> > > > > > Se forem quatro links, dá 25% para cada um:
> > > > > >
> > > > > > 1  1
> > > > > > 2  1
> > > > > > 3  2
> > > > > > 4  2
> > > > > > 5  3
> > > > > > 6  3
> > > > > > 7  4
> > > > > > 8  4
> > > > > >
> > > > > > Agora, se forem 3 links, fica desbalanceado, com 37,% do tráfego
> > nos
> > > > > links
> > > > > > 1 e 2, e 25% no link 3:
> > > > > >
> > > > > > 1  1
> > > > > > 2  1
> > > > > > 3  1
> > > > > > 4  2
> > > > > > 5  2
> > > > > > 6  2
> > > > > > 7  3
> > > > > > 8  3
> > > > > >
> > > > > > 3) Finalmente, lembre-se que o bom aproveitamento de um conjunto
> de
> > > > link
> > > > > > aggregation depende da boa distribuição do tráfego entre origens
> e
> > > > > destino
> > > > > > distintas. Se o tráfego for muito concentrado ou se houverem
> poucas
> > > > > > conexões "pesadas", há o risco de saturar um link sem ocupar o
> > > outro. É
> > > > > > sempre conveniente reservar um "fator de ineficiência" na conta
> do
> > > link
> > > > > > aggregation. O valor exato depende da estatística e da
> distribuição
> > > do
> > > > > > tráfego, mas o certo é que nunca se pense em usar 100% do link.
> > > > > > Simplesmente não funciona e causa problemas de descarte de pacote
> > > meio
> > > > > > "aleatórios" e que podem passar "batido" sem que ninguém entenda
> > > > porquê.
> > > > > >
> > > > > >
> > > > > > *Carlos Ribeiro*
> > > > > > *Sócio*
> > > > > > Cel: +55 (31) 9303-3366
> > > > > > Tel: +55 (31) 3305-5620
> > > > > > Geral: +55 (31) 3305-5600
> > > > > > cribeiro at telbrax.com.br
> > > > > > www.telbrax.com.br
> > > > > >
> > > > > >
> > > > > > Em 28 de agosto de 2014 20:46, Rodrigo Augusto <
> > > > rodrigo at 1telecom.com.br>
> > > > > > escreveu:
> > > > > >
> > > > > >> Boa noite..
> > > > > >> E sabido que ha alguns limites para cada interface agregada(
> ate 8
> > > > > >> interfaces de 1gb por exemplo, nao sei se genericamente para
> todas
> > > as
> > > > > >> plataformas) tenho a seguinte duvida: so devemos agregar
> > interfaces
> > > em
> > > > > >> pares ou pode ser em numeros impares tambem?!
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> Enviado via iPhone 
> > > > > >> Grupo Connectoway
> > > > > >> --
> > > > > >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > > > --
> > > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > >
> > > > > --
> > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

More information about the gter mailing list