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

Terça Setembro 15 11:59:51 BRT 2015

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