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

Shine eshine at gmail.com
Wed Feb 4 23:11:13 -02 2015 

Embora você faça load sharing per-packet, os seus túneis passam por cima de
links distintos, não há balancing, ao menos na parte que foi enviada eu não
vejo isso.

O TCP precisa reordenar os pacotes quando os recebe fora de ordem e isso
degrada a performance do host (quando não gera mais problemas de
instabilidade em implementações mais frágeis da pilha, conforme relatado
por alguns colegas), então usar load-sharing per-destination pode salvar
algumas dores de cabeça.

Em 4 de fevereiro de 2015 13:40, Leonardo Oliveira Ortiz <
leonardo.ortiz at marisolsa.com> escreveu:

> Segue a config abaixo, mas resumindo:
>
> interface Serial0/1/1 + Multilink + Tunnel + IP Load Sharing per-Packet
> interface Serial 0/1/0 + Tunnel + IP Load Sharing Per-Packet
>
>
> interface Tunnel1
> bandwidth 2048
>  ip address 192.168.254.1 255.255.255.252
>  ip load-sharing per-packet
>  ip flow ingress
>  ip flow egress
>  ip tcp adjust-mss 1400
>  load-interval 30
>  qos pre-classify
>  keepalive 10 3
>  tunnel source 192.168.0.6
>  tunnel destination xxxxx
> !
> interface Tunnel2
> bandwidth 2048
>  ip address 192.168.254.5 255.255.255.252
>  ip load-sharing per-packet
>  ip flow ingress
>  ip flow egress
>  ip tcp adjust-mss 1400
>  load-interval 30
>  qos pre-classify
>  keepalive 10 3
>  tunnel source  - Multilink1 -
>  tunnel destination xxxx
> !
> !
> interface Multilink1
> bandwidth 2048
>  ip address xxxx
>  ip load-sharing per-packet
>  load-interval 30
>  ppp multilink
>  ppp multilink group 1
>  service-policy input IN
>  service-policy output OUT_EBT
> !
> interface Serial0/1/0
> bandwidth 2048
>  no ip address
>  ip load-sharing per-packet
>  encapsulation frame-relay IETF
>  load-interval 30
>  no fair-queue
>  frame-relay traffic-shaping
>  frame-relay lmi-type ansi
> !
> interface Serial0/1/0.100 point-to-point
>  bandwidth 2048
>  ip address 192.168.0.6 255.255.255.252
>  ip load-sharing per-packet
> !
> interface Serial0/1/1
> bandwidth 2048
>  no ip address
>  ip load-sharing per-packet
>  encapsulation ppp
>  load-interval 30
>  fair-queue
>  ppp multilink
>  ppp multilink group 1
>
>
>
> Desculpe o off no assunto, rs.
>
> -----Mensagem original-----
> De: gter-bounces at eng.registro.br [mailto:gter-bounces at eng.registro.br] Em
> nome de Carlos Ribeiro
> Enviada em: quarta-feira, 4 de fevereiro de 2015 10:16
> Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> Assunto: Re: [GTER] RES: Balanceamento round robin LACP em swtichs HP 5500
>
> 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
> --
> 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