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

Terça Setembro 15 16:02:15 BRT 2015

Em 15/09/2015 11:59, Marcelo Gondim escreveu:
> On 15-09-2015 11:41, Danilo Egea Gondolfo wrote:
>> On 09/15/2015 06:28, Marcelo Gondim wrote:
>>> Olá meus amigos,
>>>
>>> Não sei se sou azarado ou o que. Um ano atrás tive problemas com as 
>>> interfaces Intel X520-SR2 que do nada elas morriam e eu tinha que 
>>> ficar dando down e up pra elas voltarem à vida. Fiquei mais de 1 ano 
>>> com esse problema. Tentei as listas e cheguei à fazer até um PR e 
>>> nada. Um belo dia atualizei o router no STABLE e pronto, problema 
>>> resolvido. O que foi feito não faço ideia mas resolveu depois de 1 
>>> ano de sofrimento de ter trocado todo o hardware e achando que era 
>>> temperatura interna da X520-SR2.
>>>
>>> Patrick até tentou me ajudar nessa época mas o jeito foi deixar um 
>>> script testando e levantando a interface sempre que caía. Pura 
>>> gambiarra, coisa feia de se ver em um sistema. rsrsrsrsrs
>>>
>>> Estava eu usando o router funcionando no 10.1-STABLE r281235 e aí 
>>> então resolvi passar o mesmo para o FreeBSD 10.2-RELEASE-p2 devido 
>>> às melhorias da 10.1 para a 10.2 e mais uma vez me decepcionei com o 
>>> sistema.
>>>
>>> Eu tenho 2 laggs nesse router e depois que atualizei, quando chegava 
>>> no horário de pico e subia o tráfego nesses laggs, simplesmente meu 
>>> load subia pra 40.x à 53.x, minha sessão BGP de um desses laggs com 
>>> a operadora caía e levantava de 5 em 5 minutos me gerando grande 
>>> problema aqui no provedor.
>>>
>>> Nos logs ficavam aparecendo:
>>>
>>> /var/log/messages:Sep  9 19:21:43 rt01 kernel: igb5: Interface 
>>> stopped DISTRIBUTING, possible flapping
>>> /var/log/messages:Sep  9 19:21:44 rt01 kernel: igb4: Interface 
>>> stopped DISTRIBUTING, possible flapping
>>> /var/log/messages:Sep  9 19:27:01 rt01 kernel: igb5: Interface 
>>> stopped DISTRIBUTING, possible flapping
>>> /var/log/messages:Sep  9 19:27:01 rt01 kernel: igb4: Interface 
>>> stopped DISTRIBUTING, possible flapping
>>> /var/log/messages:Sep  9 19:29:13 rt01 kernel: igb5: Interface 
>>> stopped DISTRIBUTING, possible flapping
>>> /var/log/messages:Sep  9 19:29:14 rt01 kernel: igb4: Interface 
>>> stopped DISTRIBUTING, possible flapping
>>> /var/log/messages:Sep  9 19:46:10 rt01 kernel: igb5: Interface 
>>> stopped DISTRIBUTING, possible flapping
>>> /var/log/messages:Sep  9 19:46:11 rt01 kernel: igb4: Interface 
>>> stopped DISTRIBUTING, possible flapping
>>>
>>> Aí pensei comigo... estava tudo funcionando e não vou cometer o 
>>> mesmo erro que cometi com a X520-SR2. Voltei para o 10.1-STABLE 
>>> r281235 e pronto! Tudo voltou à funcionar como era antes. Assim fica 
>>> difícil confiar na estabilidade e robustez de um sistema. Só Deus 
>>> sabe agora quando que isso será resolvido no sistema. 1 ano? 2 anos? 
>>> Bem, vou começar à pensar em algo como Juniper porque pelo menos vou 
>>> poder cobrar de alguém quando isso acontecer. Uns anos atrás saí do 
>>> Linux para FreeBSD porque este resolveu meus problemas, coisas que o 
>>> Linux não me atendia mas que agora está me deixando chateado com 
>>> essas coisas. Saí do problema do ksoftirq do Linux para outros 
>>> problemas de instabilidade no FreeBSD.
>>>
>>> Querem ver outra coisa feia que desde o FreeBSD 10.0 existe e já tem 
>>> PR, já comentei na freebsd-stable? Tudo bem que pode não afetar o 
>>> sistema mas já acertaram na CURRENT faz tempo, pelo menos foi o que 
>>> me disseram na lista. É uma coisa feia demais para um sistema tão 
>>> bem trabalhado:
>>>
>>> Experimentem fazer:
>>>
>>> # ipfw table 100 add 0.0.0.0/8
>>>
>>> Agora o resultado:
>>>
>>>  # ipfw table 100 list
>>> ::/8 0
>>>
>>> iptables pode ser estranho ou difícil de aprender mas nunca vi algo 
>>> assim nele. Venho desde o FreeBSD 10.0 falando na lista sobre isso e 
>>> cá estamos no 10.2 e continua esse bug horrendo.
>>>
>>> Bem eu abri o PR sobre o problema do LACP e agora vamos ver quando 
>>> que isso vai ser resolvido porque ao meu ver isso é sério e muita 
>>> gente usa lagg no sistema e com certeza é um problema porque voltei 
>>> a versão e tudo normalizou. Fiquei 3 dias com esse problema me 
>>> ferrando, para não dizer outra coisa, aqui no provedor.
>>>
>>>  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203031
>>>
>>> Desculpem o desabafo mas puts essa me deixou chateado demais com o 
>>> sistema, ainda mais pela importância que ele tem para o meu negócio 
>>> hoje.
>>>
>>> Gondim
>>> -------------------------
>>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>>
>> Fala Gondim,
>>
>> esse tipo de problema é osso mesmo...
>>
>> Pelo que leio e ouço, esses problemas nas releases se devem a pelo 
>> menos duas coisas: boa parte dos desenvolvedores não usam FreeBSD em 
>> seus computadores principais (Mac!) (ouçam o adrian@ desabafando no 
>> bsdnow 101 sobre comer sua própria comida de cachorro) e boa parte 
>> dos que usam FreeBSD usam o CURRENT (tipo eu :P). Então nós mesmos 
>> acabamos não vendo os problemas que saem nas releases e acabamos não 
>> tendo a mesma experiência que os usuário tem, e isso está muito 
>> errado...
>>
>> Outra zica é que esses problemas as vezes são difíceis de se 
>> reproduzir, pelo pouco que olhei no google aqui parece que seu 
>> problema está relacionado com lagg + igb + condições de tráfego. As 
>> vezes se o cara não tiver acesso ao mesmo cenário fica foda achar o 
>> problema.
>>
>> Não sei qual é a sua política em relação a usar o CURRENT em produção 
>> (o próprio projeto FreeBSD usa) e também sei que é um transtorno 
>> enorme fazer testes em cenários como o seu, mas se um dia vc tiver 
>> uma máquina sobrando aí tenta rodar o CURRENT. Recentemente teve uma 
>> atualização nos drivers e1000 (o que inclui o if_igb) que vai ser 
>> mergeado no stable daqui uns dias também...
>>
>> Boa sorte aí. Espero que essas experiências ruins não destruam a 
>> visão que vc tem do FreeBSD.
> 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
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>
Gondim,

Já enfrentei problemas assim com agregação de interfaces e resolvi fazer 
o que o Danilo sugeriu e que vi muita gente da lista de usuários do FBSD 
internacional faz. Testa o CURRENT. Se resolver seu problema pode usar 
sem problemas. Tenho o CURRENT em produção há mais de um ano e nem 
parece que ele existe na rede. Por outro lado concordo com vc. Tem umas 
coisas meio estranhas mesmo e que acabam ficando sem solução por um bom 
tempo simplesmente porque ninguém acha que é bugou é dificil de 
reproduzir porque quem deveria resolver usa o CURRENT e o das vlans é um 
bom exemplo. Já cheguei até a analisar o código pra descobrir qual era o 
vínculo mas não consegui identificar nada. Enfim, apesar de todos estes 
'glitches' o FreeBSD continua sendo uma plataforma muito estável e de 
funcionamento absolutamene previsível. E cpm grandes chances de ao se 
reportar um PR ser atendido mais rapidamente.

[]s

Ricardo Ferreira