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

Leonardo Oliveira Ortiz leonardo.ortiz at marisolsa.com
Wed Feb 4 08:16:08 -02 2015 

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

More information about the gter mailing list