[GTER] link aggregation

Mon Sep 1 11:56:55 -03 2014

Bom dia, Carlos.

Concordo que é crucial o monitoramento dos rádios.
Na aplicação que trabalhei as frequências eram licenciadas, e os rádios
monitorados em tempo integral (nível elevado de SLA).

Compartilhei a dica, pois muitos desconhecem que é possível implementar
balanceamento no LACP com números ímpar de interfaces agregadas. Envolve
apenas uma matemática simples. ;)

Queria aproveitar para elogiar sua empresa (TELBRAX).Já tinha ouvido falar
antes, e conhecido através do website.
Tive o prazer de conhecer a equipe pessoalmente, e também assistir sua
apresentação, no último evento da ABRANET.

Abraços!

Wladimir

Em 30 de agosto de 2014 01:36, Carlos Ribeiro <cribeiro at telbrax.com.br>
escreveu:

> 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
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>