[GTER] RES: Balanceamento round robin LACP em swtichs HP 5500

Wed Feb 4 10:15:39 -02 2015

Se for uma agregação tipo multilink PPP, funciona sem problemas. No seu
caso não sei se entendi o cenário, parece que é algo "híbrido", mas tive
impressão que era multilink e portanto, deve ficar. Mas precisaria de mais
detalhes para ter certeza.

Carlos Ribeiro
Em 04/02/2015 09:24, "Leonardo Oliveira Ortiz" <leonardo.ortiz at marisolsa.com>
escreveu:

> Caros, vou engatar no assunto com outra questão....
>
> Em interfaces tunnel o load sharing per-packet também é um problema ?
>
> No caso, temos duas interfaces tunnel em um router locado da OI, uma
> interface tem como source um multilink e a outra uma interface serial,
> ambos os tuneis estão com load-sharing ativado....
>
> Att,
> Leonardo Oliveira Ortiz
> Departamento de TI
> (47) 3372.6112
> www.marisolsa.com.br
> "Marisol 50 anos. Felicidade é dividir a nossa história com você".
>
>
>
> -----Mensagem original-----
> De: gter-bounces at eng.registro.br [mailto:gter-bounces at eng.registro.br] Em
> nome de Shine
> Enviada em: quarta-feira, 4 de fevereiro de 2015 00:22
> Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> Assunto: Re: [GTER] Balanceamento round robin LACP em swtichs HP 5500
>
> Concordo. ECMP é L3, é controlado por protocolos em L3, independente de
> controladores externos.
>
> Não está claro no caso do Kalil se a aplicação dele é sobre L3 ou L2, mas
> acho que é claro que ele não precisa obrigatoriamente de roteamento. O que
> também me parece bem claro é que ele não consegue balancear igualmente o
> tráfego e por isso queria round robin.
> Não temos informação da quantidade de fluxos que ele tem, quanto mais
> fluxos, melhor fica o hashing. Mas ao balancear fluxos, o round robin não
> vai proporcionar um balanceamento de dados bruto ideal, pois cada fluxo tem
> particularidades de tamanhos de pacotes/frame distintos. Acho que o hashing
> baseado em um seed com esses dados de tráfego mais eficaz, só que esse
> hashing depende de amostragem. Maior a amostragem, melhor o hashing.
>
> Tanto port aggregation (LAG) como Openflow possuem mecanismos que avaliam
> o fluxo como um todo, não somente vendo o L2. Como é feito programando o
> ASIC do equipamento (ao menos nos equipamentos de ponta) uma vez
> programado, o fluxo é diretamente tratado por hardware, só mudando em caso
> de expiração do fluxo ou queda de link.
>
> A maioria das implementações de LAG usam 5 tuplas, os ASICS modernos são
> altamente programáveis. No caso de um ethernet puro, a única coisa que
> sobra mesmo é o src/dst mac, mas se souber o padrão do que vêm após o
> header é possível programar alguns ASICs para analisar e fazer engenharia
> de tráfego em cima desse padrão.
>
> O IP realmente domina a comunicação de dados, mas existe uma tendência a
> fazer overlay em alguns ambientes e aí existe a tendência de tunelamento em
> cima da camada IP e o caminho de balancear fica mais em ECMP ou análise de
> pacotes de maior nível. Particularmente eu acho que ECMP resolve e é mais
> padronizado nesses casos.
>
> Uma das coisas q vejo frequentemente no Openflow é o uso dele para
> offload, acho bem prático e flexível... mas isso é outra discussão. ;)
>
> Em 3 de fevereiro de 2015 20:34, Carlos Ribeiro <cribeiro at telbrax.com.br>
> escreveu:
>
> > Durval,
> >
> > De fato ECMP é L3. Mas na prática, os problemas se tornam semelhantes,
> > apesar das diferentes possibilidades técnicas.
> >
> > Eu conferi a documentação da HP e ela tem uma "pegadinha", pois fala
> > em ECMP com round robin, mas usa um hash com o endereço IP, ou seja...
> > não é round robin puro.
> >
> > Nesse sentido também é interessante notar que há implementações de
> > port aggregation que operam em L2 mas usam o hash de pacotes incluindo
> > até partes do header L3 (endereço IP) ou L4 (porta TCP). Não quer
> > dizer que ele faça roteamento, apenas que o chipset usa essa
> > informação diretamente dos pacotes IP. Não sei como ele faz com o
> tráfego que não é IP nesses casos...
> > (se é que sobra algo hoje em dia!!!).
> >
> > *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 3 de fevereiro de 2015 02:39, Durval Menezes <durval at tmp.com.br>
> > escreveu:
> >
> > > Prezados,
> > >
> > > On Mon, Feb 02, 2015 at 07:19:19PM -0200, Marcus Sandri wrote:
> > > [...]
> > > >              Por??m reafirmo que os HP 5500 possuem ECMP (utiliza
> > > > RR) e tamb??m suportam OpenFlow.
> > >
> > > Nunca usei o Openflow, mas... o ECMP nao atua somente em L3? Assim
> > > sendo, mesmo que se use a facilidade L3 da switch, acho que nao se
> > > aplica ao
> > caso
> > > que o Kalil perguntou, pois me parece claro que ele gostaria de
> > > trabalhar em L2.
> > >
> > > Um Grande Abraco,
> > > --
> > >   Durval Menezes (durval AT tmp DOT com DOT br,
> > > http://www.tmp.com.br/)
> > >
> > >
> > > > No caso de usar o OpenFlow, d?? pra emular algoritmos bem melhores
> > > > do que o RR, diminuindo a probabilidade de colis??o de hash. Creio
> > > > que a melhor solu????o seria testar a t??cnica do Rafael e
> > > > comparar o desempenho antes/depois. Se come??ar a ter perdas
> > > > significativas, sugiro apelar pro OpenFlow.
> > > >
> > > > > Pessoal,
> > > > >
> > > > > Em outro grande fabricante (leia Cisco), WRR e WRED s??o
> > > > > mecanismos
> > de
> > > > > scheduling entre filas e congestion avoidance, respectivamente.
> > > > > Ou
> > > seja,
> > > > > s??
> > > > > e somente QoS. E n??o RR entre canais L2/L3.
> > > > > N??o seria o mesmo caso da HP?
> > > > >
> > > > > J?? sobre o hashing dos etherchannels, os dois lados do channel
> > > > > n??o precisam ter a mesma estrat??gia de hashing. Uma boa
> > > > > escolha em cada um dos
> > > lados
> > > > > pode compartilhar a carga da maneira mais equilibrada (mas nunca
> > > iguais).
> > > > >
> > > > >
> > > > >
> > > > > Em 2 de fevereiro de 2015 18:11, Marcus Sandri <
> > > marcus.sandri at ufscar.br>
> > > > > escreveu:
> > > > >
> > > > >> Oi Carlos,
> > > > >>
> > > > >>      N??o ?? bem assim. Como esse problema ?? antigo, existem
> > > > >> novas implementa????es que melhoram o desempenho e est??o
> > > > >> habilitadas a
> > > operar
> > > > >> no switch HP 5500: "weighted round robin (WRR), weighted fair
> > queuing
> > > > >> (WFQ), weighted random early discard (WRED), weighted deficit
> > > > >> round robin (WDRR)". Al??m do mais, balanceamento n??o ir??
> > necessariamente
> > > > >> impactar na performance da rede. Acontece que isso depende de
> > > > >> uma rela????o entre a quantidade de fluxos que o RR ir??
> > > > >> balancear e a qualidade de sua implementa????o.
> > > > >>
> > > > >>
> > > > >> > Pessoal,
> > > > >> >
> > > > >> > A quest??o do round robin ?? simples. Se for tr??fego TCP/IP,
> > > > >> > como
> > > > >> 99.9999%
> > > > >> > do
> > > > >> > tr??fego hoje ??, round robin causar?? falhas de ordena????o
> > > > >> > de
> > > pacotes. O
> > > > >> > tamanho do problema depende da qualidade das pilhas TCP das
> > > > >> > duas
> > > > >> pontas,
> > > > >> > mas haver?? impacto de performance com certeza. ?? quest??o
> > > > >> > de
> > > saber se
> > > > >> vai
> > > > >> > ficar s?? ruim ou se vai ficar MUITO ruim.
> > > > >> >
> > > > >> > Quem quiser experimentar em redes reais, n??o deve ser
> > > > >> > dif??cil,
> > > seria
> > > > >> legal
> > > > >> > postar os resultados aqui depois.
> > > > >> >
> > > > >> > *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 2 de fevereiro de 2015 12:25, Marcus Sandri
> > > > >> <marcus.sandri at ufscar.br>
> > > > >> > escreveu:
> > > > >> >
> > > > >> >> Oi Kalil,
> > > > >> >>
> > > > >> >>           D?? uma olhada nesse documento anexo. Pag. 3.
> > > > >> >>
> > > > >> >>
> > > > >> >> *PS: Acabei de ver tamb??m na pag. 3 que por padr??o o HP
> > > > >> >> 5500
> > > suporta
> > > > >> >> diversos tipos de round robin:
> > > > >> >>
> > > > >> >> "weighted round robin (WRR), weighted fair queuing (WFQ),
> > weighted
> > > > >> >> random
> > > > >> >> early discard (WRED), weighted deficit round robin (WDRR)"
> > > > >> >>
> > > > >> >>
> > > > >> >> > Bom dia Marcus.
> > > > >> >> >
> > > > >> >> > Onde encontro documenta????o do HP 5500 mostrando isso?
> > > > >> >> >
> > > > >> >> > Tentei ver no documento que esta na Internet, oficial e
> > refente a
> > > > >> este
> > > > >> >> > equipamento, e n??o encontrei nada.
> > > > >> >> >
> > > > >> >> > Atenciosamente,
> > > > >> >> >
> > > > >> >> >
> > > > >> >> > 2015-02-01 21:38 GMT-03:00 Marcus Sandri <
> > > marcus.sandri at ufscar.br>:
> > > > >> >> >
> > > > >> >> >> Pode ser fluxos de protocolos L3, L4, como tamb??m em L2.
> > Como o
> > > > >> >> >> controlador ?? program??vel, ent??o voc?? consegue balancear
> > > > >> modificando
> > > > >> >> a
> > > > >> >> >> tupla que o round robin ir?? escalonar. Como exemplo, o
> > > > >> balanceamento
> > > > >> >> por
> > > > >> >> >> fluxos L3 & L4 utiliza a tupla-5 (IP_o, IP_d, Porta_o,
> > Porta_d,
> > > > >> >> >> Tipo_de_proto). Mas veja que se voc?? modificar a tupla para
> > > MAC, o
> > > > >> >> >> balanceamento ser?? em L2.
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >> > Mas isso ?? balanceamento de fluxos e n??o de frames
> > ethernet,
> > > > >> >> confere?
> > > > >> >> >> >
> > > > >> >> >> > Enviada do meu iPhone
> > > > >> >> >> >
> > > > >> >> >> >> Em 31/01/2015, ??s 21:31, "Marcus Sandri"
> > > > >> <marcus.sandri at ufscar.br
> > > > >> >
> > > > >> >> >> >> escreveu:
> > > > >> >> >> >>
> > > > >> >> >> >> ?? poss??vel com os HP 5500. N??o sei se no pr??prio
> > switch,
> > > mas
> > > > >> voc??
> > > > >> >> >> pode
> > > > >> >> >> >> usar o m??dulo OpenFlow dele
> > > > >> >> >> >> e rodar um controlador com round-robin (Anexa a
> > > especifica????o
> > > > >> do
> > > > >> >> SW).
> > > > >> >> >> >>
> > > > >> >> >> >> *Existe um problema j?? comentado que o round-robin
> possui
> > > > >> falhas.
> > > > >> >> Na
> > > > >> >> >> >> verdade isso acontece pelas colis??es no algoritmo hash.
> > > Ent??o,
> > > > >> ele
> > > > >> >> ??
> > > > >> >> >> >> muito
> > > > >> >> >> >> dependente da implementa????o. O bom ?? que com o
> OpenFlow,
> > > voc??
> > > > >> pode
> > > > >> >> >> usar
> > > > >> >> >> >> algumas implementa????es mais modernas (ex.: WRR (1)).
> > > > >> >> >> >>
> > > > >> >> >> >>
> > > > >> >> >> >>
> > > > >> >> >> >> (1) http://g33kinfo.com/info/archives/2657
> > > > >> >> >> >>
> > > > >> >> >> >>
> > > > >> >> >> >> --
> > > > >> >> >> >> Cheers,
> > > > >> >> >> >>
> > > > >> >> >> >> Marcus Sandri
> > > > >> >> >> >> Researcher (Msc.),
> > > > >> >> >> >> Department of Computing
> > > > >> >> >> >> UFSCar - Federal University of S??o Carlos
> > > > >> >> >> >>
> > > > >> >> >> >> dcomp.sor.ufscar.br/sandri
> > > > >> >> >> >> Skype: marcus.sandri
> > > > >> >> >> >>
> > > > >> >> >> >> --
> > > > >> >> >> >> gter list
> https://eng.registro.br/mailman/listinfo/gter
> > > > >> >> >> >
> > > > >> >> >> >
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >> --
> > > > >> >> >> Cheers,
> > > > >> >> >>
> > > > >> >> >> Marcus Sandri
> > > > >> >> >> Researcher (Msc.),
> > > > >> >> >> Department of Computing
> > > > >> >> >> UFSCar - Federal University of S??o Carlos
> > > > >> >> >>
> > > > >> >> >> dcomp.sor.ufscar.br/sandri
> > > > >> >> >> Skype: marcus.sandri
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >> --
> > > > >> >> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > >> >> >>
> > > > >> >> >
> > > > >> >> >
> > > > >> >> >
> > > > >> >> > --
> > > > >> >> > Atenciosamente,
> > > > >> >> > Kalil de A. Carvalho
> > > > >> >> >
> > > > >> >>
> > > > >> >>
> > > > >> >> --
> > > > >> >> Cheers,
> > > > >> >>
> > > > >> >> Marcus Sandri
> > > > >> >> Researcher (Msc.),
> > > > >> >> Department of Computing
> > > > >> >> UFSCar - Federal University of S??o Carlos
> > > > >> >>
> > > > >> >> dcomp.sor.ufscar.br/sandri
> > > > >> >> Skype: marcus.sandri
> > > > >> >>
> > > > >> >> --
> > > > >> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > >> >>
> > > > >> >
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Cheers,
> > > > >>
> > > > >> Marcus Sandri
> > > > >> Researcher (Msc.),
> > > > >> Department of Computing
> > > > >> UFSCar - Federal University of S??o Carlos
> > > > >>
> > > > >> dcomp.sor.ufscar.br/sandri
> > > > >> Skype: marcus.sandri
> > > > >>
> > > > >>
> > > > >> --
> > > > >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > >>
> > > > >
> > > >
> > > >
> > > > --
> > > > Cheers,
> > > >
> > > > Marcus Sandri
> > > > Researcher (Msc.),
> > > > Department of Computing
> > > > UFSCar - Federal University of S??o Carlos
> > > >
> > > > dcomp.sor.ufscar.br/sandri
> > > > Skype: marcus.sandri
> > > >
> > > >
> > > > --
> > > > 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