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

[Marcelo Gondim]

On 17-09-2015 16:54, Marcelo Gondim wrote:
> On 17-09-2015 16:44, Vinícius Zavam wrote:
>> 2015-09-17 15:22 GMT-03:00 Marcelo Gondim <gondim em bsdinfo.com.br>:
>>
>>> 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.
>>>
>>> Abrs,
>>
>> gondim,
>>
>> certamente tu já deves ter visto algum desses conteúdos, mas ...
>>
>> + 
>> https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html
>> + https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967
>>
>> chegou a aplicar algumas das alterações sugeridas na thread da 
>> freebsd-net@,
>> ou na página do bugzilla pelos próprios desenvolvedores? // aqui, 
>> algumas
>> palavras do scottl@ na thread da lista freebsd-net:
>>
>> " The difference between FreeBSD 9.x and 10 is that in 9.x, it ran in
>> “optimistic” mode, meaning that it didn’t rely on getting receive 
>> messages
>> from the switch, and only took a channel down if the link state went 
>> down. "
>>
>> " The ‘flapping’ message is intentional, it points out that something is
>> wrong with heartbeat exchange with the switch. " 
>> (sys/net/ieee8023ad_lacp.c)
>>
>> [ ] ' s
>>
>>
> Opa Egypcio tranquilo?
>
> Então tava olhando o log das modificações do ieee8023ad_lacp.c e acho 
> que essa revisão [1] deve resolver o meu problema. Ela saiu esses 
> dias. Vou testar hoje à noite mas estou bem otimista em relação à 
> isso.  :)
>
> [1] https://svnweb.freebsd.org/base?view=revision&revision=287723
>
> Abrs,
> Gondim 
É não adiantou. Coloquei a stable mais recente e deu problema. O 
problema é tão sinistro que reparei o seguinte:

Quando está carregando as minhas sessões BGP com o 10.2-STABLE de ontem, 
o load fica em 14.x 15.x e com o pico de tráfego o load chega em 40.x 53.x
Com o 10.1-STABLE r281235 o load na carga do BGP fica em 4.x e no pico 
de tráfego fica em 8.x e 12.x. Teve alguma mudança que afetou 
absurdamente a performance do sistema. Agora o que mudou que degradou 
tanto isso é que não faço a menor ideia.  :(