[GTER] Balanceamento round robin LACP em swtichs HP 5500

Mon Feb 2 21:21:53 -02 2015

Marcus,

Não se deve usar round robin com TCP/IP, posso te afirmar. A configuração é
aceita e suportada mas não é uma boa idéia, e não é o default da maioria
dos fabricantes.

Apesar do nome sugerir que ECMP é feito só com round robin, as
implementações de ECMP tem suporte para dois modos. Em Cisco fala-se "per
packet" e "per destination", em Juniper é "hashed" e "round robin". O
método round robin/per packet foi implementado primeiro mas caiu em desuso.
Uma das fontes de confusão é que no caso do multilink PPP, isso não é um
problema, porque o MLPPP faz controle de sequenciamento de pacotes e
reordena antes de entregar os dados do grupo agregado.

Segundo a documentação da HP:

http://www.hp.com/rnd/support/manuals/pdf/release_06628_07110/Bk2_Ch6_IP.pdf

"IP load sharing: A feature that enables the router to balance traffic to a
specific destination across multiple equal-cost paths. Load sharing uses a
simple round-robin mechanism and is based on destination address. Note:
Load sharing is sometimes called Equal Cost Multi Path (ECMP). "

(veja que ele fala que é round-robin mas que também é baseado no
destination address, ou seja, é o per-destination da Cisco).

Segundo a documentação da Cisco:

http://www.cisco.com/en/US/products/hw/modules/ps2033/prod_technical_reference09186a00800afeb7.html

"Per-packet load balancing guarantees equal load across all links, however
potentially the packets may arrive out-of-order at the destination as
differential delay may exist within the network."

Segundo a documentação da Juniper:

http://www.juniper.net/techpubs/en_US/junose13.3/topics/task/configuration/ecmp-load-share-round-robin-configuration.html

"ECMP uses the round-robin mode when you have configured all interfaces in
the set to round-robin. Otherwise, ECMP defaults to hashed mode because
round-robin mode can cause reordering of packets. You must explicitly
ensure that the possible reordering is acceptable on all the member
interfaces by setting them to round-robin mode."

Outra fonte interessante:

http://www.plexxi.com/2013/08/ecmp-its-not-all-equal-or-even-normal/#sthash.YPpAq0ia.dpbs

"The key to ECMP is the calculation that determines which of the next hops
to use. And its achilles heel at the same time. ECMP assumes that the best
utilization of multiple links towards a destination is the most even spread
of flows across all of them. The most basic calculation takes the source
and destination IP address from the packet, performs some hash calculation
(very simple because it needs to be performed for every packet at extremely
high packet rates), normalizes the result to the amount of next hops, then
uses that next hop."

e mais adiante...

"(In the above I am totally ignoring the possibility of sending traffic
across all equal cost links in a packet by packet round robin fashion. It
creates a pretty good distribution, but many TCP implementations and
applications are extremely sensitive to out of order packets and as a
result anything that can result in re-ordering of packets is a big no no.
Still. In 2013.)"

*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 19:19, Marcus Sandri <marcus.sandri at ufscar.br>
escreveu:

> Srs,
>
>              Nos HPs WRR e WRED correspondem sim a QoS, erro meu.
>              Porém reafirmo que os HP 5500 possuem ECMP (utiliza RR) e
> também suportam OpenFlow. 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
>