[GTER] Balanceamento round robin LACP em swtichs HP 5500

[Lucas Willian Bocchi]

Shine

A implentação da pilha TCP/IP varia muito de sistema operacional para
sistema operacional. OS/2 e minix por exemplo são chatíssimos com essa
questão de recebimento de pacotes fora de ordem. Simplesmente a pilha
do sistema descarta e manda retransmitir. Uma vez peguei um problema
numa rede OS/2 que dei suporte que só pq os pacotes num router linux
não estavam vindo com o timestamp correto marcado a conexão toda era
derrubada.

Quanto a questão das routerboards que falaram aqui, é fato que quanto
maior o processamento maior a reordenação de pacotes. Existem regras
no mangle que também fazem o negócio se perder, mas isso é bug do
kernel que foi consertado em versões mais novas no linux. Os kernels
da versão 6.x tá bem atrás, 3.6.1 se não me engano.

Em 29 de janeiro de 2015 19:06, Shine <eshine at gmail.com> escreveu:
> Carlos,
>
> Realmente aprecio seu comentário. Estou bem ciente das consequências da
> inversão de pacotes e é exatamente por este motivo e das necessidades de
> alta performance em ethernet (ainda mais na escala >10G) que os ASICS
> atuais já implementam diretamente a agregação de portas em hardware com o
> hashing.
>
> Existem aplicações que não se importam com inversões de pacotes, apenas
> precisam de dado bruto de forma que a ordem não importa tanto, desde que
> exista. E inclusive rodando em cima de ethernet, nem camada IP é
> necessário. Ou seja, são fluxos únicos puros.
> Essas aplicações não se importam, mas ao mesmo tempo são exceções, então
> fazer balanceamento e redundância também se torna complexo. Pode-se criar a
> contingência criando redes em loop e fazendo controle de loop (STP), mas
> essa alternativa já é conhecida pela relativa baixa eficácia de
> convergência se comparado com soluções de link ativo-ativo.
> Então eu sugiro que ao invés de seguirmos adaptando a rede, adaptar a
> aplicação para o uso eficiente na rede. Embora traga um desenvolvimento
> adicional da aplicação, isso acaba beneficiando na padronização da
> comunicação da rede, assim o aplicativo não fica refém de uma estrutura de
> rede fechada.
>
> Espero ter esclarecido um pouco o que tinha em mente.
>
> Em 29 de janeiro de 2015 14:32, Carlos Ribeiro <cribeiro at telbrax.com.br>
> escreveu:
>
>> Shine,
>>
>> Só para deixar mais claro, o buraco é mais embaixo, pois "round robin" não
>> é adequado para TCP/IP, pois há sempre o risco de mudar a ordem de chegada
>> dos pacotes. Mesmo com as melhorias do TCP, incluindo retransmissão
>> seletiva, há impacto de performance se houver quebra da ordenação.
>>
>> Há equipamentos (ex: rádios N+1) que fazem o balanceamento com mecanismos
>> proprietários que preservam o ordenamento. Há também intercalamento a nível
>> de "bitstream" em tecnologias como 40 Gbps, mas isso está fora do alcance
>> do que se pode fazer em um switch ou roteador com os pacotes.
>>
>> *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 27 de janeiro de 2015 22:59, Shine <eshine at gmail.com> escreveu:
>>
>> > Kalil,
>> >
>> > Nos switches atuais é muito difícil ter um balanceamento LACP sem hashing
>> > baseado em protocolo. Muitos são ajustáveis, mas mesmo assim remover
>> tudo e
>> > virar round robin é improvável nos chips atuais. Se você achar um que
>> faça,
>> > possivelmente vai ter problemas quando precisar fazer upgrade para outros
>> > modelos mais modernos - a não ser que upgrade de rede não seja necessário
>> > no futuro, mas a maioria descarta essa possibilidade.
>> >
>> > Mesmo que não exista um protocolo IP, as switches vão usar mac-src,
>> mac-dst
>> > e proto para determinar o hashing. O que poderia ser feito é a aplicação
>> > gerar dois fluxos distintos (por exemplo portas tcp ou udp distintas ou
>> > mac-src/dst), assim ao chegar no switch ele seria balanceado.
>> >
>> >
>> > Em 26 de janeiro de 2015 18:04, Kalil de A. Carvalho <kalilac at gmail.com>
>> > escreveu:
>> >
>> > > Boa tarde Carlos.
>> > >
>> > > Muito obrigado pelo esclarecimento.
>> > >
>> > > Gostaria de fazer uma outra pergunta, ainda nesse mérito:
>> > >
>> > > E se esta comunicação ocorresse na camada dois, somente com quadros,
>> > ainda
>> > > permaneceria esse comportamento?
>> > >
>> > > Os pacotes ainda poderão sofrer como descrito?
>> > >
>> > > Atenciosamente,
>> > >
>> > >
>> > > 2015-01-26 16:34 GMT-03:00 Carlos Ribeiro <cribeiro at telbrax.com.br>:
>> > >
>> > > > Kalil,
>> > > >
>> > > > Não se deve nunca, em nenhum hipótese, fazer "round robin" simples de
>> > > > pacotes. Entendo os seus motivos para querer fazer isso, eu também
>> > > gostaria
>> > > > muito de fazer nos meus links, mas é importante que você entenda
>> porque
>> > > > isso não é possível, e nem mesmo desejável. E isso é geral, não é só
>> > com
>> > > > HP, mas com Cisco, Juniper, etc.
>> > > >
>> > > > Se você fizer distribuição "round robin", fatalmente terá situações
>> em
>> > > que
>> > > > os pacotes chegarão do outro lado fora de ordem. Pacotes fora de
>> ordem
>> > > > quebram a transmissão em TCP e confundem os controles de comunicação
>> > que
>> > > > usam UDP/RDP também, causando descartes de pacotes, retransmissões,
>> > etc.
>> > > > Isso acaba com a performance da rede.
>> > > >
>> > > > Existem duas situações que causam reordenação:
>> > > >
>> > > > 1) A primeira, e mais óbvia, é se os dois links tiverem tamanhos
>> > > > diferentes. Neste caso o delay de transmissão é diferente e isso pode
>> > > fazer
>> > > > com que um pacote que foi transmitido depois chegue antes ao destino.
>> > > >
>> > > > 2) A segunda situação, que não é tão óbvia e por isso "passa
>> batido", é
>> > > > quando você tem dois links idênticos, só que os pacotes variam de
>> > tamanho
>> > > > fortemente. Com milhões de pacotes passando, é absolutamente certo
>> que
>> > de
>> > > > vez em quando, você vai dar "azar" de colocar pacotes maiores em uma
>> > > > interface e menores na outra. Resultado: uma fila fica mais curta e
>> > > começa
>> > > > a andar mais rápido e os pacotes pequenos "passam na frente" dos
>> > grandes.
>> > > > Na hora que isso acontecer (e não se preocupe, vai acontecer
>> > > > "estatisticamente o tempo todo) dentro de uma conexão TCP ou pior
>> > ainda,
>> > > > com um fragmento IP, você terá um problema sério com perda de
>> > > performance.
>> > > >
>> > > > É por isso que os switches e roteadores tem vários algoritmos de
>> > > > distribuição de tráfego. É comum ter uma diferença variável, no
>> máximo
>> > da
>> > > > ordem de 10% a 15% entre os dois links, não mais do que isso. Mas
>> como
>> > > tudo
>> > > > é aleatório, você pode estar com uma distribuição pior. Mas não há o
>> > que
>> > > > fazer.
>> > > >
>> > > > Há soluções mais avançadas para isso, incluindo engenharia de
>> tráfego e
>> > > > certos tipos de "source routing" (como é o caso do PBR da Cisco). Mas
>> > são
>> > > > apenas para contornar situações específicas, e agregam mais
>> > complexidade
>> > > ao
>> > > > cenário.
>> > > >
>> > > > Espero ter ajudado...
>> > > >
>> > > > *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 26 de janeiro de 2015 11:17, Kalil de A. Carvalho <
>> > kalilac at gmail.com>
>> > > > escreveu:
>> > > >
>> > > > > Bom dia senhores.
>> > > > >
>> > > > > Estou trabalhando com dois swichs HP 5500 e  temos uma agregação
>> > usando
>> > > > > LACP entre eles.
>> > > > >
>> > > > > Para nossa realidade precisamos que o balanceamento seja round
>> robin.
>> > > > >
>> > > > > Foi tentada diversas combinações, como indicado no manual, source
>> > mac,
>> > > > > destination mac, ingress port etc mas em nenhuma resultou no que
>> > > > > esperávamos: distribuição igualitaria entre as portas.
>> > > > >
>> > > > > Pelo que pude entender quando se escolhe source  mac, a porta que
>> > > > aprender
>> > > > > o caminho com este mac ficara sempre recebendo por ela. Idem
>> > > destination
>> > > > > mac.
>> > > > >
>> > > > > É isso mesmo ou entendi errado?
>> > > > >
>> > > > > É possível fazer isso que queremos, round robin, nestes
>> equipamentos?
>> > > > >
>> > > > > Atenciosamente,
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Atenciosamente,
>> > > > > Kalil de A. Carvalho
>> > > > > --
>> > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
>> > > > --
>> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > Atenciosamente,
>> > > Kalil de A. Carvalho
>> > > --
>> > > 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