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

[Marcelo Gondim]

On 15-09-2015 22:08, Giovanni Tirloni wrote:
> On 09/15/2015 06:28 AM, Marcelo Gondim wrote:
>> 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
>
> Ola Marcelo,
>
>  Não sei até que ponto você está disposto a investigar esse problema, 
> mas se puder voltar para o 10.2 e iniciar a maquina em verbose mode 
> [1], pode ser que outras mensagens ajudem a elucidar esse problema.
>
>  Você poderia enviar a saída do ifconfig das interfaces ixb/lagg, a 
> configuração do link aggr switch, as informações físicas da interface 
> (pciconf -lv) e de boot (egrep ´(lagg|igb)' /var/run/dmesg.boot)?
>
>  Desde a 10.1-RELEASE, o driver igb teve muitas mudanças. É difícil 
> dizer exatamente o que pode ter causado essa regressão sem mais detalhes.
>
> [1] - 
> https://www.freebsd.org/doc/handbook/boot-introduction.html#boot-init
Opa Giovanni,

É complicado eu fazer isso pois o router segura a Internet de 4 cidades. 
São quase 4.5Gbps de tráfego e mais de 20.000 assinantes.
Se eu fizer isso vou ter muitos cancelamentos tendo em vista que já 
fiquei uns 3 dias apresentando esse problema e achando que era uma das 
Operadoras de trânsito. Não posso colocar um ambiente desse em testes, 
infelizmente.

Por isso informei a revisão que estava usando sem problemas, para tentar 
ajudar à descobrir o que foi alterado nesse espaço de tempo e que possa 
estar causando isso.
Com relação ao fato de que o próprio pessoal do projeto usa o FreeBSD 
11, eu vejo isso como um grande erro. O current deveria ser testado sim 
mas antes de mais nada deveria ser usado a versão de produção que é a 
10.x e torná-la mais estável e robusta ainda. Somente usando o sistema, 
é que se encontram as falhas.

Para mim os nomes deveriam ser diferentes então: STABLE deveria se 
chamar TESTING, RELEASE de UNSTABLE e o CURRENT de RELEASE. Ouvi muito 
sobre a organização em que é feito o sistema. A versão 8.x na qual 
comecei à ver FreeBSD era excelente e me ajudou bastante. Mas 
sinceramente nesses últimos anos me deparo com algumas coisas que parece 
coisa de "universitário" mesmo. Me lembra o RouterOS da Mikrotik onde 
mexem em uma coisa e estraga outra e vai mexendo e tentando acertar.

As versões de produção deveriam ser a mais rock solid possível, ainda 
lembro dessa frase. No entanto cada vez que atualizo para uma release, 
algo acontece e coisas param de funcionar ou passam à funcionar meia 
boca. Mesmo acontecendo essas coisas faço a minha parte que é abrir um 
PR e mandar e-mail para as listas freebsd-stable ou freebsd-net mas sem 
evolução do problema.

Mesmo com todos esses problemas o FreeBSD ainda é o sistema que aguenta 
e segura o meu tráfego e gostaria de vê-lo melhorar cada vez mais. 
Continuar levantando essa bandeira mas é preciso que o pessoal do core 
ou alguém lá acorde para esses problemas. Hoje minha realidade é a seguinte:

- Ficar fazendo testes com o sistema em produção, derrubando os 
assinantes até descobrir onde está o problema.
- Esperar que alguém passe pelo mesmo problema e consiga reproduzir o 
erro para que seja corrigido em algum momento virando uma MFC.
- Mudar para STABLE e ficar atualizando o source de tempo em tempo, 
torcendo para que alguém descubra algo errado e corrija. Como foi meu 
caso com a X520-SR2.
- Mudar para o CURRENT e ficar correndo riscos mas pelo jeito é o que o 
Projeto FreeBSD está usando em produção.
- Aprender à programar em C, estudar o código do source, corrigir e 
disponibilizar o patch.
- Contratar um programador C para estudar o problema e resolver.
- Investir uma grana em Juniper MX5.

Não estou vendo muitas opções boas mas são essas aí.
Estou muito desanimado com o sistema mas agora tenho que manter até onde 
eu consiga.

[]'s
Gondim