[FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
Marcelo Gondim
gondim em bsdinfo.com.br
Domingo Janeiro 24 12:18:40 BRST 2016
Em 14/10/2015 12:19, Marcelo Gondim escreveu:
> On 14-10-2015 06:07, Sergio Lopes wrote:
>> Estou usando o FreeBSD 10.1 com 2 interfaces de 1GB e estou com o
>> mesmo problema usando LACP
>>
>>
>> igb2: Interface stopped DISTRIBUTING, possible flapping
>> igb4: Interface stopped DISTRIBUTING, possible flapping
>>
>>
>> Cada vez que o problema ocorre o tráfego da interface de um sentido
>> comuta para outra interface, fazendo com que o usuário perceba uma
>> queda de 5 segundos.
>>
>> Quando mudo para roundrobin e removo o lacp do FreeBSD e do Switch ai
>> fica normal.
>>
> Repara também no load como que sobe. Tenta usar o 10.1-stable que to
> usando e vê se resolve seu problema:
>
> 10.1-STABLE r281235
>
>>
>>
>>
>>
>>
>> Vinícius Zavam escreveu:
>>> 2015-10-04 9:59 GMT-03:00 Marcelo Gondim<gondim em bsdinfo.com.br>:
>>>
>>>> On 21-09-2015 09:23, Marcelo Gondim wrote:
>>>>
>>>>> On 21-09-2015 08:27, Antonio Modesto wrote:
>>>>>
>>>>>> On 09/21/15 08:23, Antonio Modesto wrote:
>>>>>>
>>>>>>> On 09/17/15 15:22, Marcelo Gondim wrote:
>>>>>>>
>>>>>>>> On 17-09-2015 11:51, Luiz Otavio O Souza wrote:
>>>>>>>>
>>>>>>>>> 2015-09-15 11:59 GMT-03:00 Marcelo Gondim:
>>>>>>>>>
>>>>>>>>>> Opa Danilo,
>>>>>>>>>>
>>>>>>>>>> Pois é e a única coisa que tenho é a revisão que funciona
>>>>>>>>>> perfeito no
>>>>>>>>>> 10.1-stable. Não sei se é simples achar a mudança entre as
>>>>>>>>>> versões
>>>>>>>>>> que
>>>>>>>>>> saíram mas algo mudou nesse meio do caminho destruiu meu
>>>>>>>>>> cenário.
>>>>>>>>>>
>>>>>>>>>> Outra recente também que descobri e que sofri por muito mas
>>>>>>>>>> muito
>>>>>>>>>> tempo. Não
>>>>>>>>>> sei se lembram dessa thread [1] que abri em abril do ano
>>>>>>>>>> passado.
>>>>>>>>>> Sabe qual era a solução desse problema?
>>>>>>>>>>
>>>>>>>>>> Colocar um simples: gateway_enable="YES" no /etc/rc.conf
>>>>>>>>>>
>>>>>>>>>> Ou seja, mesmo colocando o net.inet.ip.forwarding=1 se você não
>>>>>>>>>> colocar essa
>>>>>>>>>> instrução no rc.conf e mandar criar uma vlan, simplesmente seu
>>>>>>>>>> roteamento
>>>>>>>>>> para completamente. Só reiniciando a máquina. Agora me diga
>>>>>>>>>> porque o
>>>>>>>>>> roteamento para de funcionar quando faço um ifconfig vlanX
>>>>>>>>>> create se
>>>>>>>>>> eu não
>>>>>>>>>> tiver o gateway_enable no rc.conf? Onde que isso está escrito?
>>>>>>>>>> Fiquei meses
>>>>>>>>>> com esse problema e agora não tenho mais.
>>>>>>>>>>
>>>>>>>>>> Pior é que os caras que me responderam isso na lista acham
>>>>>>>>>> que isso
>>>>>>>>>> não é um
>>>>>>>>>> bug. Só teve 1 que achou que era um bug. Não faz sentido
>>>>>>>>>> algum isso.
>>>>>>>>>> Podem fazer esse teste. Peguem um FreeBSD 10.x coloquem 2
>>>>>>>>>> interfaces
>>>>>>>>>> de rede
>>>>>>>>>> pra fazer o roteamento de um lado pra outro e setem umas
>>>>>>>>>> vlans. Sem o
>>>>>>>>>> parâmetro acima experimentem fazer um simples:
>>>>>>>>>>
>>>>>>>>>> # ifconfig vlan200 create
>>>>>>>>>>
>>>>>>>>>> Depois tentem pingar de uma rede pra outra. Não vai nem à
>>>>>>>>>> pau. Agora
>>>>>>>>>> se
>>>>>>>>>> colocarem o parâmetro acima no rc.conf vocês podem criar
>>>>>>>>>> vlans sem
>>>>>>>>>> problemas.
>>>>>>>>>>
>>>>>>>>>> São essas coisas que matam a gente.
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>> http://www.fug.com.br/historico/html/freebsd/2014-04/msg00154.html
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Opa Gondim,
>>>>>>>>>
>>>>>>>>> Nós entendemos e sabemos o quanto é frustante aguardar (sem um
>>>>>>>>> ETA
>>>>>>>>> definido) uma resposta ou uma correção nesses casos (eu também já
>>>>>>>>> estive nessa posição).
>>>>>>>>>
>>>>>>>>> É sempre importante lembrar que o projeto trabalha com
>>>>>>>>> voluntários, há
>>>>>>>>> muita pouca gente lá que é paga pra fazer algum serviço ou
>>>>>>>>> para ser
>>>>>>>>> responsável por determinada area, então mesmo com toda
>>>>>>>>> frustração é
>>>>>>>>> importante manter uma atitude positiva.
>>>>>>>>>
>>>>>>>>> Pessoas com a atitude positiva se relacionam melhor com a
>>>>>>>>> comunidade e
>>>>>>>>> se relacionando bem as pessoas vão se lembrar de você.
>>>>>>>>> Lembre-se, é
>>>>>>>>> tudo uma questão de como você interage com o projeto. O
>>>>>>>>> projeto esta
>>>>>>>>> sempre acompanhando as pessoas, todo contribuidor eventual é um
>>>>>>>>> possível desenvolvedor.
>>>>>>>>>
>>>>>>>>> Mesmo com todos esses problemas, eu aposto que você ainda tem
>>>>>>>>> muito
>>>>>>>>> mais chances de ter o seu problema resolvido no FreeBSD do que no
>>>>>>>>> mikrotik ou no Windows (mesmo os últimos dois sendo pagos),
>>>>>>>>> reporte um
>>>>>>>>> problema lá e depois me diga quando foram resolvidos ;-)
>>>>>>>>>
>>>>>>>>> Bom, quanto a esse problema do gateway_enable, esta correto,
>>>>>>>>> apenas
>>>>>>>>> adicionando o net.inet.ip.forwarding=1 não é o bastante para
>>>>>>>>> que o
>>>>>>>>> sistema funcione, existem casos onde os scripts rc vão
>>>>>>>>> reescrever essa
>>>>>>>>> sysctl e a única forma de você instruir os scripts para fazer
>>>>>>>>> a coisa
>>>>>>>>> certa é através da variável gateway_enable.
>>>>>>>>>
>>>>>>>>> O roteamento para de funcionar porque quando você cria a vlan
>>>>>>>>> ele seta
>>>>>>>>> a sysctl de volta pra 0, pode fazer o teste. Basta setar a sysctl
>>>>>>>>> novamente para tudo voltar a funcionar, não precisa reiniciar.
>>>>>>>>>
>>>>>>>>> Contribua com a documentação do projeto, deixe isso escrito e
>>>>>>>>> claro
>>>>>>>>> para que outras pessoas não tenham a mesma dificuldade.
>>>>>>>>>
>>>>>>>>> Grande LooS :)
>>>>>>>> Só desanima mas continuo na guerra rsrsrsrs
>>>>>>>>
>>>>>>>> Então pois é. Eu vi que a sysctl voltava pra 0 mas mesmo
>>>>>>>> setando pra 1
>>>>>>>> não voltava à funcionar. Uma doideira mesmo. Só voltava o
>>>>>>>> sistema quando
>>>>>>>> reiniciado e como estava em produção não deu pra fazer mais
>>>>>>>> testes,
>>>>>>>> infelizmente. Só achei estranho isso acontecer.
>>>>>>>> Não sei se ele altera alguma outra sysctl que seria o motivo de
>>>>>>>> parar.
>>>>>>>>
>>>>>>> Fala Gondim. Essa questão do sysctl realmente não acho que seja um
>>>>>>> comportamento exótico, já que não existe sentido em não ter o
>>>>>>> gateway_enable="YES" no rc.conf se você não precisa de
>>>>>>> roteamento. Agora
>>>>>>> esses problemas com o lagg realmente devem ser osso. Mal lhe
>>>>>>> pergunte, não
>>>>>>> seria viável usar interfaces 10G diretamente? Digo isso pois
>>>>>>> apesar de o
>>>>>>> lagg ser um recurso muito útil, acredito que ter interfaces boas
>>>>>>> com
>>>>>>> drivers bem testados seja mais recomendado para um ambiente
>>>>>>> crítico como o
>>>>>>> seu.
>>>>>>>
>>>>>> Corrigindo: Se você precisa de roteamento. =)
>>>>>>
>>>>> Bom dia Modesto,
>>>>>
>>>>> Sim essa semana eu vou passar os 3Gbps de IX-SP + 2Gbps Link IP
>>>>> Internexa
>>>>> para uma porta de 10GbE e um link de 2Gbps com a Level3 para a
>>>>> outra porta
>>>>> de 10GbE de uma Intel X520-SR2. Dessa forma eu mato 2 laggs que
>>>>> tenho. Pena
>>>>> que depois disso não vou mais saber se esse problema do lagg foi
>>>>> resolvido
>>>>> porque não terei mais nenhum lagg para checar. De qualquer forma
>>>>> deixei
>>>>> anotado a revisão do 10.1-stable que estava tudo funcionando, para
>>>>> o caso
>>>>> de algum dia eu voltar à precisar.
>>>>>
>>>>> Bom dia pessoal,
>>>> Egypcio sabe se recentemente descobriram algum problema que afetava a
>>>> performance do FreeBSD 10.2? Porque conversando com outro amigo meu
>>>> ele
>>>> também estava tendo problemas de performance e quando falei pra ele
>>>> usar o
>>>> 10.1-STABLE, que to usando, o problema dele acabou. Ou seja, to
>>>> achando que
>>>> esse meu problema está relacionado à performance geral do sistema.
>>>> Porque no último teste que fiz; quando eu ligava o servidor e
>>>> começava à
>>>> carregar o OpenBGP o load ia em 20.x até carregar tudo e depois ficava
>>>> dando problema com load alto. Com a versão 10.1-STABLE, que não
>>>> largo até
>>>> que isso seja resolvido, quando carrega o OpenBGP fica com load
>>>> baixo de no
>>>> máximo 4.x. Só aí já é claro um problema no sistema como um todo. Algo
>>>> mudou que afetou a performance dele.
>>>>
>>>> Sabe se recentemente descobriram e corrigiram algo nesse sentido?
>>>> Porque
>>>> sinceramente isso é coisa pra sair inclusive nota avisando e
>>>> alteração no
>>>> releng.
>>>>
>>>>
>>>> []'s
>>>> Gondim<https://www.fug.com.br/mailman/listinfo/freebsd>
>>>>
>>>
>>> gondim,
>>>
>>> isso daí é algo que, assim como você, eu também teria de sentar com
>>> tempo e
>>> calma pra escovar com ajuda de ferramentas de stress, benchmark e
>>> algumas
>>> RFC; 2544, por exemplo (se não me engano).
>>>
>>> "adota essa criança" e ajuda o projeto a identificar o que está ruim
>>> pra
>>> quem utiliza stable/10. quanto mais detalhes e informações forem
>>> coletadas
>>> e reportadas, melhor. certamente uma sugestão de correção com patches
>>> também ajuda. infelizmente eu não chego nem perto de ter como
>>> reproduzir o
>>> cenário (não tenho máquinas, nem infraestrutura, que estejam
>>> disponíveis
>>> pra isso).
E ae pessoal,
Retornando com essa thread pois descobri coisas novas à respeito do
problema. O problema não está no LACP porque nós retiramos o LACP e
colocamos tudo em interface de 10GbE X520-SR2.
O que parece é que algo mudou em relação ao cpu affinity entre a versão
10.1-STABLE que estou usando e as versões atuais.
Na versão 10.1-STABLE estou com o cpu affinity assim:
/usr/bin/cpuset -l 11 -x 300
/usr/bin/cpuset -l 10 -x 301
/usr/bin/cpuset -l 9 -x 302
/usr/bin/cpuset -l 8 -x 303
/usr/bin/cpuset -l 7 -x 304
/usr/bin/cpuset -l 6 -x 305
/usr/bin/cpuset -l 0 -x 306
/usr/bin/cpuset -l 1 -x 307
/usr/bin/cpuset -l 9 -x 308
/usr/bin/cpuset -l 5 -x 355
/usr/bin/cpuset -l 4 -x 356
/usr/bin/cpuset -l 3 -x 357
/usr/bin/cpuset -l 2 -x 358
/usr/bin/cpuset -l 1 -x 359
/usr/bin/cpuset -l 0 -x 360
/usr/bin/cpuset -l 5 -x 361
/usr/bin/cpuset -l 4 -x 362
/usr/bin/cpuset -l 3 -x 363
/usr/bin/cpuset -l 5 -x 364
/usr/bin/cpuset -l 4 -x 365
/usr/bin/cpuset -l 3 -x 366
/usr/bin/cpuset -l 2 -x 367
/usr/bin/cpuset -l 1 -x 368
/usr/bin/cpuset -l 0 -x 369
/usr/bin/cpuset -l 5 -x 370
/usr/bin/cpuset -l 4 -x 371
/usr/bin/cpuset -l 3 -x 372
Dessa forma está funcionando no 10.1-STABLE sem problemas e os idle dos
cores meio que balanceados. A máquina é um Dual Hexa Xeon e por isso tem
12 cores. Aí fiz uns testes e percebi o seguinte:
Problema 1: quando atualizo do 10.1-STABLE para o 10.2 ou 11 e jogo os
meus links para o router (+5Gbps de tráfego), os cores ficam totalmente
desbalanceados ou seja, uns ficam normais com 30% à 40% idle e outros
ficam com 5% à 8% idle. Isso sem mudar nada em nenhum arquivo, somente
atualizando o sistema e mantendo todas as configurações. Egypcio sabe se
houve alguma mudança que poderia ter mudado esse comportamento no cpu
affinity?
Problema 2: no sistema atual 10.1-STABLE descobri o seguinte: fui tentar
melhorar o balanceamento nos cores com o cpu affinity (cpuset) e quando
faço isso passo à ter perdas de pacotes nos links de dados. O que me
obriga à ter que reiniciar o sistema pra normalizar tudo. Ou seja mexeu
no cpu affinity, então reinicie porque senão pode dar zica e feia.
Doideira isso. Ou seja o problema não estava no link aggregation.
[]´s
Gondim
Mais detalhes sobre a lista de discussão freebsd