[GTER] Balanceamento round robin LACP em swtichs HP 5500

Tue Feb 3 02:06:18 -02 2015

Carlos,

Eu entendo seu ponto de vista, mas tente ir mais devagar... está havendo
uma confusão de load-sharing de frames ethernet /pacotes IP e fluxos. São
coisas totalmente distintas.

Openflow não faz hashing per frame/packet, mas sim per flow. Então ele vai
usar o algoritmo do chip para mandar o flow por um link ou outro. A
distribuição dos fluxos pode ser round robin ou outro, mas não per packet.
O OF não suporta e nem faria sentido em escala.
Em um caso de flow único, isso cai no mesmo problema que apontei
originalmente, não tem como fazer balanceamento round robin de frames por
link, os chips modernos não suportam mais isso.

Em 2 de fevereiro de 2015 21:21, Carlos Ribeiro <cribeiro at telbrax.com.br>
escreveu:

> 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
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>