[FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

[Marcelo Gondim]

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