Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
Em quarta-feira, 16 de setembro de 2015, Marcelo Gondim < gon...@bsdinfo.com.br> escreveu: > > É 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. É muita loucura deixar todo esse tráfego somente em 1 router. Devia ter, pelo menos, mais um... e cada um deles deve suportar sozinho todo o tráfego, para caso um caia (ou você precise reiniciar). > - Investir uma grana em Juniper MX5. No patamar de tráfego que você está, já devia estar no seu planejamento de curto prazo, ainda mais se você é provedor. -- Eduardo Schoedler -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
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 Abraços, Giovanni - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [Off-Topic] Retornar versão definida do Firebird em consultas ao banco.
Adiel, boa noite. Recomendo que monitore os Logs do firebird no momento da abertura do seu sistema, dependendo do nível de verbose do log poderá olha se é onde ele censulta essa informação da versão, pois pode ser que seu sistema esteja com essa informação da versão no próprio executável. Também é possível ver o que o sistema consulta no banco usando o tcpdump, se nos Logs do firebird e no tcpdump não ver o sistema consultando isso no banco de dados é porque foi feito direto no executável. Eu também entendo que se existe esta regra tão mandatória no sistema, não é por nada, o sistema deve precisar de algum recurso específico dessa versão, que não imagino qual seria, mas me atrevo a dizer que não seria inteligente pelo lado do programador fazer essa amarração direto no executável, sem uma razão muito especial, descartando claro que não foi feito de propósito. On Tuesday, September 15, 2015, Adiel de Lima Ribeiro < adiel.netad...@gmail.com> wrote: > > > >> >> Adiel de Lima Ribeiro escreveu: >> >>> Bom dia lista! >>> Imagino que isso seja Off-Topic. >>> Seguinte: Tenho um sistema funcionando em cima de Firebird 2.5.3 faz um >>> tempo. >>> Este sistema precisa ser atualizado, mas a nova versão aceita apenas o >>> Firebird 2.5.2. >>> Na inicialização do sistema ele faz algum tipo de consulta ao banco e >>> fecha o sistema por causa da versão do Firebird que não é a 2.5.2. >>> Existe alguma maneira de eu modificar alguma tabela do Firebird para que >>> seja retornado o valor 2.5.3 quando o sistema fizer esta consulta pela >>> versão? >>> Não sou programador, mas existe alguma maneira de interceptar este >>> tráfego e modificar o valor retornado? >>> É um sistema bem simples, imagino que seja uma consulta simples também. >>> Utilizo o FreeBSD 10, que tem o Firebird 2.5.3 como padrão, até tentei >>> forçar a instalação do 2.5.2 com o pkg, mas sem sucesso. >>> Há como eu extrair o ports do FreeBSD 9 e tentar compilar o Firebird >>> 2.5.2 no FreeBD 10? >>> Obrigado. >>> >>> >> >> >> >> >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > > -- > Cordialmente, > Adiel de Lima Ribeiro > (31) 8961-5984 > Pós Graduação em Administração de Redes Linux > MCSA - Microsoft Certified Systems Administrator > > On 09/15/2015 08:52 AM, Sergio Lopes wrote: > >> Adiel, >> >> Na máquina com FreeBSD 9 >> >> # pkg create firebird- >> >> Substitua o pela versão, para listar os pacotes instalados rode o >> comando pkg info >> >> Será gerado um arquivo algo como firebird-.txz >> >> Copie o arquivo para a máquina com FreeBSD 10 >> >> Remova o pacote antigo >> >> E para instalar rode na máquina com FreeBSD 10 >> >> # pkg add firebird-.txz >> >> Tente e poste para nós o resultado. >> > > Tranquilo Sérgio, farei este e mais testes. > Mas em teoria, se sua dica funcionasse, eu teria conseguido instalar o > Firebird 2.5.2 do ftp do FreeBSD 9 no FreeBSD 10 com o pkg, certo? > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- [Luzivan ;] "O caminho do sucesso está sempre em construção" - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] FreeBSD-10.2-STABLE + snort + snorby
Olá pessoal, tudo bem?Estou começando a me aventurar com snort.Está funcionando o snort, barnyard jogando pro mysql, blz.Porém estou apanhando demais pra instalar o snorby...Já alterei o fonte do snorby pra aceitar ruby21, já instalei tudo que é ruby do ports rsrsrs.mas continua empacandoAlguém aí usa o snorby com o FreeBSD-10.2-STABLE pra me dar alguma luz? Por último ele não ta conseguindo criar o banco de dados, parece erro de algum SQL.Fico pensando se vale a pena utiliza-lo, muitos erros me deixa com medo de não ser estável ou deixar alguma brecha. Bem, qq ajuda agradeço. Até! -- Thiago Andrighetti de Pádua - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] ATENCAO - Regras da Lista - LEMBRETE
Esta é uma mensagem automática, enviada periodicamente para a lista como lembrete de quais são e onde encontrar as regras de boa conduta. Para bom uso desta lista, É fundamental que você tenha lido, compreendido e concordado com as regras. Caso ainda nao as tenha lido, reserve um tempinho para esta tarefa. Para evitar a inclusão das regras neste e-mail e poupar alguns kilobytes mensais repetitivos em Vssa. caixa postal, este lembrete refere-se apenas à URL onde encontrar as regras: https://www.fug.com.br/mailman/listinfo/freebsd Conheça-as, por gentileza. -- FUG-BR: Grupo Brasileiro de Usuarios de FreeBSD Desde 1999, espalhando o BSD http://www.fug.com.br adm...@fug.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
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
[FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
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
Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
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
[FUG-BR] [Off-Topic] Retornar versão definida do Firebird em consultas ao banco.
Bom dia lista! Imagino que isso seja Off-Topic. Seguinte: Tenho um sistema funcionando em cima de Firebird 2.5.3 faz um tempo. Este sistema precisa ser atualizado, mas a nova versão aceita apenas o Firebird 2.5.2. Na inicialização do sistema ele faz algum tipo de consulta ao banco e fecha o sistema por causa da versão do Firebird que não é a 2.5.2. Existe alguma maneira de eu modificar alguma tabela do Firebird para que seja retornado o valor 2.5.3 quando o sistema fizer esta consulta pela versão? Não sou programador, mas existe alguma maneira de interceptar este tráfego e modificar o valor retornado? É um sistema bem simples, imagino que seja uma consulta simples também. Utilizo o FreeBSD 10, que tem o Firebird 2.5.3 como padrão, até tentei forçar a instalação do 2.5.2 com o pkg, mas sem sucesso. Há como eu extrair o ports do FreeBSD 9 e tentar compilar o Firebird 2.5.2 no FreeBD 10? Obrigado. -- Cordialmente, Adiel de Lima Ribeiro (31) 8961-5984 Pós Graduação em Administração de Redes Linux MCSA - Microsoft Certified Systems Administrator - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [Off-Topic] Retornar versão definida do Firebird em consultas ao banco.
Adiel, Na máquina com FreeBSD 9 # pkg create firebird- Substitua o pela versão, para listar os pacotes instalados rode o comando pkg info Será gerado um arquivo algo como firebird-.txz Copie o arquivo para a máquina com FreeBSD 10 Remova o pacote antigo E para instalar rode na máquina com FreeBSD 10 # pkg add firebird-.txz Tente e poste para nós o resultado. Adiel de Lima Ribeiro escreveu: Bom dia lista! Imagino que isso seja Off-Topic. Seguinte: Tenho um sistema funcionando em cima de Firebird 2.5.3 faz um tempo. Este sistema precisa ser atualizado, mas a nova versão aceita apenas o Firebird 2.5.2. Na inicialização do sistema ele faz algum tipo de consulta ao banco e fecha o sistema por causa da versão do Firebird que não é a 2.5.2. Existe alguma maneira de eu modificar alguma tabela do Firebird para que seja retornado o valor 2.5.3 quando o sistema fizer esta consulta pela versão? Não sou programador, mas existe alguma maneira de interceptar este tráfego e modificar o valor retornado? É um sistema bem simples, imagino que seja uma consulta simples também. Utilizo o FreeBSD 10, que tem o Firebird 2.5.3 como padrão, até tentei forçar a instalação do 2.5.2 com o pkg, mas sem sucesso. Há como eu extrair o ports do FreeBSD 9 e tentar compilar o Firebird 2.5.2 no FreeBD 10? Obrigado. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [Off-Topic] Retornar versão definida do Firebird em consultas ao banco.
Adiel de Lima Ribeiro escreveu: Bom dia lista! Imagino que isso seja Off-Topic. Seguinte: Tenho um sistema funcionando em cima de Firebird 2.5.3 faz um tempo. Este sistema precisa ser atualizado, mas a nova versão aceita apenas o Firebird 2.5.2. Na inicialização do sistema ele faz algum tipo de consulta ao banco e fecha o sistema por causa da versão do Firebird que não é a 2.5.2. Existe alguma maneira de eu modificar alguma tabela do Firebird para que seja retornado o valor 2.5.3 quando o sistema fizer esta consulta pela versão? Não sou programador, mas existe alguma maneira de interceptar este tráfego e modificar o valor retornado? É um sistema bem simples, imagino que seja uma consulta simples também. Utilizo o FreeBSD 10, que tem o Firebird 2.5.3 como padrão, até tentei forçar a instalação do 2.5.2 com o pkg, mas sem sucesso. Há como eu extrair o ports do FreeBSD 9 e tentar compilar o Firebird 2.5.2 no FreeBD 10? Obrigado. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Cordialmente, Adiel de Lima Ribeiro (31) 8961-5984 Pós Graduação em Administração de Redes Linux MCSA - Microsoft Certified Systems Administrator On 09/15/2015 08:52 AM, Sergio Lopes wrote: Adiel, Na máquina com FreeBSD 9 # pkg create firebird- Substitua o pela versão, para listar os pacotes instalados rode o comando pkg info Será gerado um arquivo algo como firebird-.txz Copie o arquivo para a máquina com FreeBSD 10 Remova o pacote antigo E para instalar rode na máquina com FreeBSD 10 # pkg add firebird-.txz Tente e poste para nós o resultado. Tranquilo Sérgio, farei este e mais testes. Mas em teoria, se sua dica funcionasse, eu teria conseguido instalar o Firebird 2.5.2 do ftp do FreeBSD 9 no FreeBSD 10 com o pkg, certo? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
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
