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
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
