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

Sexta Setembro 18 17:37:34 BRT 2015

On 18-09-2015 15:30, Vinícius Zavam wrote:
> 2015-09-18 15:18 GMT-03:00 Marcelo Gondim <gondim em bsdinfo.com.br>:
>
>> On 18-09-2015 15:02, Vinícius Zavam wrote:
>>
>>> 2015-09-18 11:52 GMT-03:00 Marcelo Gondim <gondim em bsdinfo.com.br>:
>>>
>>> On 18-09-2015 11:06, Vinícius Zavam wrote:
>>>> 2015-09-17 19:20 GMT-03:00 Marcelo Gondim <gondim em bsdinfo.com.br>:
>>>>> 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.  :(
>>>>>>
>>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200169
>>>>> + https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189471
>>>>>
>>>>>
>>>>> Ih Egypcio to desde o 10.0 acompanhando esse bug, sempre vai sair uma
>>>>>
>>>> nova release mando e-mail pra freebsd-stable. hahahah acho que só vai ser
>>>> consertado o dia que o 11.x virar release.
>>>> Que por sinal o ipfw no 11.x ficou bem interessante mesmo.
>>>>
>>>> []'s
>>>> Gondim
>>>>
>>>> respondi vc com o link do commit feito pelo melifaro@ a poucos minutos
>>> lá
>>> na outra thread, sobre o ipfw.
>>>
>>> voltando às dificuldades que tu tens com lagg, também escovou as
>>> configurações do switch? parâmetros do ifconfig, para o lagg+interfaces?
>>> isso é importante.
>>>
>>>
>>> Então, essa lagg que tá dando esses paus mas que já to achando que pode
>> ser em outro lugar, é feita direto com um Juniper MX5. Lá eles tem outras
>> laggs com outras empresas e estão todas funcionando redondo. Só a nossa que
>> deu esse pau.
>>
>> Uma outra coisa que reparei; mas que acontece com a versão sem problemas e
>> com a versão problemática é o seguinte:
>>
>> Quando habilito sysctl net.link.lagg.lacp.debug=1 e olho no messages
>> pipocam e segundo em segundo isso aqui:
>>
>> Sep 18 15:15:10 rt01 kernel: igb4: lacpdu transmit
>> Sep 18 15:15:10 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0005)
>> Sep 18 15:15:10 rt01 kernel:
>> actor.state=3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
>> Sep 18 15:15:10 rt01 kernel:
>> partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0005)
>> Sep 18 15:15:10 rt01 kernel:
>> partner.state=3f<ACTIVITY,TIMEOUT,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
>> Sep 18 15:15:10 rt01 kernel: maxdelay=0
>> Sep 18 15:15:11 rt01 kernel: igb5: lacpdu transmit
>> Sep 18 15:15:11 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0006)
>> Sep 18 15:15:11 rt01 kernel:
>> actor.state=3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
>> Sep 18 15:15:11 rt01 kernel:
>> partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0004)
>> Sep 18 15:15:11 rt01 kernel:
>> partner.state=3f<ACTIVITY,TIMEOUT,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
>> Sep 18 15:15:11 rt01 kernel: maxdelay=0
>> Sep 18 15:15:11 rt01 kernel: igb4: lacpdu transmit
>> Sep 18 15:15:11 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0005)
>> Sep 18 15:15:11 rt01 kernel:
>> actor.state=3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
>> Sep 18 15:15:11 rt01 kernel:
>> partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0005)
>> Sep 18 15:15:11 rt01 kernel:
>> partner.state=3f<ACTIVITY,TIMEOUT,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
>> Sep 18 15:15:11 rt01 kernel: maxdelay=0
>> Sep 18 15:15:12 rt01 kernel: igb5: lacpdu transmit
>> Sep 18 15:15:12 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0006)
>> Sep 18 15:15:12 rt01 kernel:
>> actor.state=3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
>> Sep 18 15:15:12 rt01 kernel:
>> partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0004)
>> Sep 18 15:15:12 rt01 kernel:
>> partner.state=3f<ACTIVITY,TIMEOUT,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
>> Sep 18 15:15:12 rt01 kernel: maxdelay=0
>> Sep 18 15:15:12 rt01 kernel: igb4: lacpdu transmit
>> Sep 18 15:15:12 rt01 kernel: actor=(8000,00-1B-21-7B-EE-6C,01EB,8000,0005)
>> Sep 18 15:15:12 rt01 kernel:
>> actor.state=3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
>> Sep 18 15:15:12 rt01 kernel:
>> partner=(007F,28-8A-1C-55-B3-C0,0004,007F,0005)
>> Sep 18 15:15:12 rt01 kernel:
>> partner.state=3f<ACTIVITY,TIMEOUT,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
>> Sep 18 15:15:12 rt01 kernel: maxdelay=0
>>
>> Com a lagg que tenho com o PTT, que usa a igb6 e igb7, isso não acontece
>> ou acontece raramente. Poderia isso estar causando o load alto e o problema
>> na lagg quando usando o 10.2-release e o 10.2-stable?
>
> salvo engano, naquelas mesmas threads que enviei aqui já tinha um exemplo
> de config utilizado juniper. // tu estás a usar fastforwarding? seguiu
> algum manual para tuning adicional? páginas e manuais da juniper recomendam
> que tipo de configuração com freebsd/lagg?
Opa Egypcio,

O Juniper é da Operadora e por isso não tenho acesso.

>
> " 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
> receivemessagesfrom the switch, and only took a channel down if the link
> state wentdown. " :-)
>
>
Ummm mas será que o 10.1-STABLE ainda estava em optimistic?

Abrs,