[GTER] link aggregation

[Antonio Modesto]

Deve se levar em consideração também qual o algoritmo que está sendo
utilizado. Alguns switches vêm somente com suporte à utilização de
atributos da camada 2, como endereço mac de origem e destino, outros
conseguem utilizar atributos da camada 4 (src/dst port). No caso da
nossa rede onde o lagg é feito na rede de backbone, utilizar o endereço
mac de origem e destino somente é a mesma coisa que não usar. 

On
2014-08-30 1:36 am, Carlos Ribeiro wrote: 

> 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 [1]
> 
> 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 me
>> 
>>> ;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.
>> to se o hash tiver 16
buckets, aí melhora consideravelmente. P.S. quem trabalha com rádios de
longa distânci
>> 
>>> quote> desbalanceamento é usando alguma solução
de mux "proprietária" do fabricante do r&aacute
>> uote> Todos os
grandes fabricantes oferecem sistemas que garantem serialização do
tráfego na camada 1, com efici&eci
>> 
>>> ue algum canal esteja
degradado,
>> 2px solid; margin-left:5px; width:100%">coisa que o LAG
não faz! Carlos Ribeiro Em 29/08/2014 11:55, "Rodrigo Pedrosa"
<rodrigopa.uepb at gmail.com> escreveu: escreveu: poucas conexões
"pesadas", há o risco de saturar um link sem ocupar o outro. É
> 
> --
>
gter list https://eng.registro.br/mailman/listinfo/gter [2]

-- 




Links:
------
[1] http://www.telbrax.com.br
[2]
https://eng.registro.br/mailman/listinfo/gter