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

[Giovanni Tirloni]

On 09/16/2015 01:42 AM, Marcelo Gondim wrote:
> 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.

Faz sentido. Bom, essas informações que eu solicitei, se você puder colocar no 
PR, com certeza vai ser útil para quem olhar depois.

> 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.

O código do 10.1 foi colocado em freeze dia 5/Set/2014. Já o 10.2 entrou em 
freeze dia 3/Jul/2015. Teoricamente, tudo que foi comitado entre essas datas 
esta no 10.2-RELEASE.

https://www.freebsd.org/releases/10.1R/schedule.html
https://www.freebsd.org/releases/10.2R/schedule.html

Você pode ver os commits aqui: 
https://github.com/freebsd/freebsd/commits/0d9fe1a380ad3917e8371b95095da61774318853/sys/dev/e1000/if_igb.c

Fazer a investigação pelo código apenas com as mensagens de "stopped 
distributing" vai ser quase impossível.


> 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.

Os desenvolvedores precisam estar na última versão. É lá que entram códigos 
novos, que vão ser testados, modificados e depois feito o backport para a STABLE.

Se o projeto usa CURRENT em alguns servidores de produção, tem alguém assumindo 
esse risco. Tem que ter muita fé que nada vai quebrar e/ou um sistema de testes 
robustos. Do contrário quando a sua máquina CURRENT pifar, não adianta ir chorar 
as pitangas nas listas :)

Eu não recomendo colocar CURRENT em produção apesar de todas as anedotas de que 
não dá problema que normalmente eu ouço. É melhor criar um ambiente de testes, 
rodar STABLE/RELEASE nele e tentar reproduzir o problema.

Já rodei CURRENT em produção? Já, na época do 5-CURRENT eu queria muito usar o 
pf porque ele tinha funcionalidades que eu precisava. Assumi o risco junto ao 
cliente e tive alguns panic's com certeza. Vai de cada caso... se você já está 
sofrendo com releases que são supostamente estáveis, pela lógica não tem como 
dizer que um codebase que sofre muito mais mudanças como o CURRENT vai te trazer 
mais previsibilidade. Semana que vem sai um patch de segurança e você vai 
aplicar ele e mais 200 milhões de linhas de código que você nem sabe pra que 
serve? Não recomendo...


> 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.

Entendo a frustração. Infelizmente é um problema universal da área de TI que a 
qualidade do que a gente faz parece coisa de voodoo as vezes. Acho que nesse 
caso o buraco é mais embaixo, e não é exclusividade do FreeBSD.

> 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.

Por experiência própria, se você incluir o máximo de informação que puder, fica 
mais fácil de alguém olhar o PR/email e tentar descobrir o que pode ser. Se 
ficar muito numa bate-volta de perguntas e respostas, os voluntários tem outras 
coisas pra fazer e vão deixar de lado.

> 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.

Minha sugestão é achar uma forma de fazer os testes em um ambiente separado. 
Talvez simulando o trafego, fazendo port mirroring e verificando como essa 
maquina se comporta, etc. Testar em produção é complicado mesmo :)

Abraços,
Giovanni