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

Sergio Lopes sergio em fontech.com.br
Quarta Outubro 14 06:07:50 BRT 2015


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.






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).
>
> [ ] ' s
>
>




Mais detalhes sobre a lista de discussão freebsd