Re: [FUG-BR] Configuração de Localization para pt_br.ISO8859-1 ou UTF-8
2011/3/1 Marcel Bonnet marcelbon...@gmail.com: Olá pessoal. Não é falta de RTFM ( http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/l10n.html) é limitação mesmo! Alguém pode me dar uma força pra configurar meu sistema pra que, por exemplo no shell, ele aceite acentuação? Há um ano e meio atrás eu havia achado a resposta no histórico dessa lista, mas não encontro mais e já perdi o dump do meu sistema. Sobre o character encoding: alguém arrisca dizer se entre usuários brasileiros existe uma tendência maior a usar ISO-8859-1 ou UTF-8? É que o UTF-8 pode usar de 1 a 4 bytes para cada caracter (se usarmos os primeiros chars da lista, usaremos somente 1 byte). O ISO, por outro lado, sempre escreve tudo em 1 byte. Por padrão tudo é UTF-8, certo? Gnome e outros aplicativos, idem. Será que é estou jogando espaço em disco fora salvando tudo em UTF-8? O console não possui acentuação com UTF-8 ou com teclado us_intl. Se quiser acentuação no console, se ISO8859-1 e teclado ABNT2, configure o terminal pra cons25 no /etc/ttys, sete o MM_CHARSET pra ISO8859-1 e o locale pra en_US.ISO8859-1. -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Não usem FBSD-8x como router !!!
Não vou discutir os flames, porém em [1] vocês notam que quando a gente fala que **pode** ter algo errado com o FreeBSD, o pessoal toma como ataque pessoal. Eu sou da opinião que nada é perfeito e pode ter algo de errado, seja do sistema, seja do hardware, seja do técnico e o meu papel como analista e assinante da lista é tentar descobrir para tudo funcionar de acordo e todos dormirem alegres :-) Entre máquinas que eu administro e máquina de cliente deve ter passado na minha mão uns 20 servidores este ano, desde DELL R210 até DELL R710, passou IBM xSeries, a nova linha M2, passou máquina montada por cliente e o comportamento é instável no que tange placas igb. Em alguns com placas igb, a igb0 e igb1 funciona e ao ativar a 2 e 3, elas informam exatamente o que o Eduardo descreveu[2]. Em outras máquinas, as 4 sobem e respondem a pings, mas misteriosamente aparece arpresolve: can't allocate llinfo. A solução para mim foi isto[3]. Agora o driver igb tem algo de errado sim, porque se notar o que o Eduardo descreveu aqui[4] o HEAD está com versão mais nova ainda. Eu não testei esta versão do driver, ficar testando em produção é complicado. Agora o fato é, se eu pegar um CD do FreeBSD 8.1, instalar, nenhum, repito, NENHUM destes problemas ocorrem. Então tem muito fato concreto indicando que algo ocorre. Eu também duvidei muito desta afirmação, afinal eu sempre fiz update de freebsd de olho fechado e depois de todo este drama, peguei um cluster com OPENBGPD + CARP + PFSYNC e atualizei uma máquina do 8.1 para o 8.2, que possui igb. Como era de se esperar, as placas igb ficaram estranhas. Downgrade pro 8.1 de novo(dump/restore) e o cluster ficou 100%. Quanto ao BGP, tem que dar uma verificada, mas talvez seja algo na hora que bgpsimple injeta as rotas. Eduardo, Quando o bgp sobe, sem as rotas serem injetadas, tudo fica OK? Não daria para você ao inves de usar o bgpsimple, fechar uma sessao ospfd com a outra máquina e entregar as rotas que o ospf aprendeu pro bgp? Seria algo tipo este cenário[5]. Pergunto isto porque tive um problema de má configuraçaõ que resultava em panic: OPENBGPD + OPENOSPFD + MIKROTIK + PPPoE. Erroneamente o Mikrotik estava programado para entregar as rotas /32 da sessao pppoe pro ospfd(ele não agregava). o bgpd estava com o filtro aceitando somente entre /8 e /24, o feijão com arroz. Daí o Mikrotik jogava os /32 pro ospf, o ospfd entregava na rede toda(e haja memória...) mas na hora que entregava pro servidor bgp, ele descartava e gerava os logs no messages. Mas chegava uma hora que não sei porque dava panic. Foi parar o ospfd que isto não acontecia. Depois, ao descobrir o erro da agregação, tudo funciona 100%. [1] http://www.mail-archive.com/freebsd@fug.com.br/msg56148.html [2] http://www.mail-archive.com/freebsd@fug.com.br/msg60734.html [3] http://lists.freebsd.org/pipermail/freebsd-stable/2010-October/059541.html [4] http://www.fug.com.br/historico/html/freebsd/2011-02/msg00357.html [5] http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800943c5.shtml -Mensagem Original- From: Lucas Dias Sent: Wednesday, March 02, 2011 12:54 AM To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Subject: Re: [FUG-BR] Não usem FBSD-8x como router !!! Senhores Flames não resolveram o problema de ninguém. Essa lista é para colaboração e ajuda mútua. Sempre vejo todos conseguindo resolver seus problemas aqui. Sempre alguém consegue resposta, ou se não consegue resolver, pelo menos aprende algo. Sou novato com FreeBSD mas pelo que já estudei, sei que ele é capaz de fazer praticamente qualquer coisa. Toda e qualquer solução robusta que envolva networking tem algo BSD no meio. Pelo que sei, as placas Intel apresentam melhor performance que as demais porque temos Engenheiros da Intel desenvolvendo os drivers, sem xunxos para o FreeBSD e que conhecem FreeBSD. Isso, contudo não significa que não á joio no meio do trigo. Vai que você tenha sido premiado com uma placa igb bixada. Já aconteceu comigo, problemas semelhantes, não com a igb, com outras NICs que foram compradas todas no mesmo lugar, da mesma marca (sk - 3Com véia de guerra) e ainda sim, uma foi a premiada. Trocamos e tudo funcionou. Acho que a única coisa que a lista não deve ter gostado foi o fato de se ver uma mensagem tão impactante de um S.O que tem mais de 10 anos de desenvolvimento por Engenheiros de alta capacidade. Não é a toa que todos pegam uma carona em algo feito em FreeBSD ou do mundo BSD. Windão que o diga. No Flames, por favor =) Acompanho a lista e vi você na batalha tentando fazer o que você quer fazer funcionar. Que é trabalhar com BGP entre outras tecnologias para roteamento avançado. Também vi alguns aqui na lista [1] um amigo que está usando Quagga(BGP) + FreeBSD 8.1 com um link de 250Mbps com uptime de 392 dias, em cima de um Servidor Dell com 2GB RAM, Processador Intel® Core™ I3 540 (Acredito que seja um Dell PowerEdge T110). Sei que não é Intel
Re: [FUG-BR] Não usem FBSD-8x como router !!!
Eu tentei instalar o openbsd mais recente em um destes Dell que citei no email anterior, ao deparar com os problemas de igb. Acho que no total são 16 processadores que aparece pro FreeBSD, são 2 XEON que eles veem, daí da 8 processadores lógicos em cada socket. O openbsd ao colocar o kernel SMP dava panic. usando o kernel normal funcionava. Daí não dá para desperdiçar processador, deixei o open encostado mesmo. -Mensagem Original- From: Nenhum_de_Nos Sent: Tuesday, March 01, 2011 10:04 PM To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Subject: Re: [FUG-BR] Não usem FBSD-8x como router !!! Vinícuis deu uma idéia interessante: como se sai o OpenBSD neste caso. Sou fã do FreeBSD, mas se vai ser somente roteador sem mais pacotes, e o pfsense num resolve penso logo em OpenBSD. se num preciso de todo o webui do pfsense, OpenBSD é minha primeira opção :) matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Não usem FBSD-8x como router !!!
Eu também tive muita dor de cabeça com FreeBSD 8. Instamos o 8.0 em 3 operações, e em todas tivemos que fazer downgrade para FreeBSD 7, principalmente por causa do kernel panic entre outros, coisa que com a série 7 não acontece. Conforme email que mandei relatando meu problema, vou voltar com o 8.2 e ve se com ele vou ter mais sorte, apesar que não estou tão confiante assim. Poderia fazer o upgrade hoje, mas devido a dor de cabeça que tive - que não gosto nem de lembrar - e desses tipos de problema, não estou muito afim de ficar trabalhando no carnaval fazendo downgrade novamente :-P No meu caso as placas do servidor são Intel e Broadcom (emX, bgeX e bceX), com 4 sessões bgp fechada, sendo 3 full e 1 partial. Abraços. Em 2 de março de 2011 08:03, Renato Frederick ren...@frederick.eti.brescreveu: Eu tentei instalar o openbsd mais recente em um destes Dell que citei no email anterior, ao deparar com os problemas de igb. Acho que no total são 16 processadores que aparece pro FreeBSD, são 2 XEON que eles veem, daí da 8 processadores lógicos em cada socket. O openbsd ao colocar o kernel SMP dava panic. usando o kernel normal funcionava. Daí não dá para desperdiçar processador, deixei o open encostado mesmo. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Não usem FBSD-8x como router !!!
Em 01/03/2011 19:05, Eduardo Schoedler escreveu: Pessoal, Infelizmente é essa a constatação que eu estou chegando: não utilizem o 8.x (venho sobrendo desde o 8.0 e atualmente estou no 8.2-PRERELEASE) como roteador !!! Após inúmeros problemas com o driver igb, o mais recente problema é o kernel panic por causa das rotas. Estou utilizando o bgpsimple [1] com um dump full-routing do RIS RAW Data - RIPE [2] para injetar prefixos via bgp (quagga). O bgpsimple está rodando em outra máquina, onde eu fecho um peering iBGP. Após pouquíssimo tempo (2m49s!), acontece um panic... panic: rtfree 2 cpuid = 0 uptime: 2m49s (!) Nesse instante estou tentando gerar um kernel dump para debug e enviar ao Freebsd. Sinceramente, já estou muito irritado e já estou a um passo de usar Linux... e não gostaria de usar o FBSD-7.x para isso. Referências: [1] http://code.google.com/p/bgpsimple/wiki/README [2] http://www.ripe.net/projects/ris/rawdata.html Sds, -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Hmmm. entendo mais como um desabafo pois estamos numa lista FREEBSD. Por outro lado acabamos de concluir um projeto onde trocamos 16 roteadores Linux por FreeBSD 8.2R + Quagga + plcas Intel com driver em e sinceramente nunca fomos tão felizes mas sem querer levantar polêmica ocorreram diversos problemas com drivers Intel e que foram sendo resolvidas com o passar do tempo. Para isto existem os Release Candidates. Atualize seu FreeBSD para a 8.2 STABLE e vc verá que seus problemas de drivers igb terão desparecido...Mesmo assim se quiser ir de Linux boa sorte -- Cordialmente, Ricardo Ferreira Telecom, Tecnologia e Segurança da Informação CCDP, CCNP, CCDA, CCNA, MCSE, MCP --- Sotech Soluções Tecnologicas Rua da Alfazema, 761, 1o. andar - 102/103 41820-710 - Caminho das Árvores - Salvador-BA - Brasil Tel : 55 71 3472.9400 Cel : 55 71 9138 4630 Email: ricardo.ferre...@sotechdatacenter.com.br Site: www.sotechdatacenter.com.br Esta mensagem é dirigida apenas ao seu destinatário e pode conter informações confidenciais, não passíveis de divulgação nos termos da legislação em vigor. Caso tenha recebido esta mensagem por engano, solicitamos notificar a Sotech Soluções Tecnológicas e excluí-la de sua caixa postal. This message, including its attachments, may contain confidential information. If you have improperly received this message, please delete it from your system and notify immediately the sender. Any form of utilization, reproduction, forward, alteration, distribution and/or disclosure of this content in whole or in part, without the prior written authorization of the sender, is strictly prohibited. Thanks for your cooperation. attachment: ricardo_ferreira.vcf- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Não usem FBSD-8x como router !!!
On Mar 1, 2011, at 7:05 PM, Eduardo Schoedler wrote: Pessoal, Infelizmente é essa a constatação que eu estou chegando: não utilizem o 8.x (venho sobrendo desde o 8.0 e atualmente estou no 8.2-PRERELEASE) como roteador !!! Após inúmeros problemas com o driver igb, o mais recente problema é o kernel panic por causa das rotas. Estou utilizando o bgpsimple [1] com um dump full-routing do RIS RAW Data - RIPE [2] para injetar prefixos via bgp (quagga). O bgpsimple está rodando em outra máquina, onde eu fecho um peering iBGP. Após pouquíssimo tempo (2m49s!), acontece um panic... panic: rtfree 2 cpuid = 0 uptime: 2m49s (!) Nesse instante estou tentando gerar um kernel dump para debug e enviar ao Freebsd. Sinceramente, já estou muito irritado e já estou a um passo de usar Linux... e não gostaria de usar o FBSD-7.x para isso. Referências: [1] http://code.google.com/p/bgpsimple/wiki/README [2] http://www.ripe.net/projects/ris/rawdata.html Sds, -- Eduardo Schoedler Eduardo, Não vamos generalizar, como você deve saber toda unanimidade é burra... O sistema não funcionou bem no seu setup, há uma porção de gente por ai satisfeita com a série 8.x. De qualquer forma, eu não posso responder por essas questões existenciais (linux users, freebsd users, bla bla bla - quase peguei uma pipoca para ler os e-mails), mas se você quiser, posso tentar ajudar com as questões técnicas... Você só tem hardware com essas placas igb ? Não tem outro modelo/marca ? (esse é um ponto para você testar) No caso do panic, você precisa ao menos fornecer um backtrace do problema. Você sabe gerar o dump ? No prompt do debugger, voce precisa digitar: call doadump Verifique se voce tem um arquivo chamado core.txt.0 (ou outro numero) no diretório /var/crash, se você não tiver, você vai ter que gerar o backtrace manualmente com o kgdb (http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html): # cd /usr/obj/usr/src/sys/KERNCONF # kgdb kernel.debug /var/crash/vmcore.0 E dentro do kgdb, digite: 'bt'. Encaminhe o backtrace (ou o conteúdo do core.txt.X) para mim ou para a lista (como você quiser...). Os números no final do nome dos arquivos são as versões (0 para o primeiro crash que você salvou, 1 para o segundo, etc.). Depois de resolvido o problema, você pode apagar todos arquivos naquele diretório. Precisamos juntar um mínimo de informações sobre o problema para que possamos encaminha-lo oficialmente para o projeto (via listas, PRs ou contato direto com os desenvolvedores). Infelizmente não adianta testar o sistema só na época dos RCs (quando o sistema já esta praticamente 'congelado' para o release), agora (que o release foi gerado) é o momento certo para testar, identificar e corrigir os problemas. Se você estiver disposto a rastrear o problema (o que muitas vezes é impossível num ambiente de produção - eu entendo), acho que podemos ajudar. Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Não usem FBSD-8x como router !!!
On Wed, March 2, 2011 08:03, Renato Frederick wrote: Eu tentei instalar o openbsd mais recente em um destes Dell que citei no email anterior, ao deparar com os problemas de igb. Acho que no total são 16 processadores que aparece pro FreeBSD, são 2 XEON que eles veem, daí da 8 processadores lógicos em cada socket. O openbsd ao colocar o kernel SMP dava panic. usando o kernel normal funcionava. Daí não dá para desperdiçar processador, deixei o open encostado mesmo. obrigado renato pelo feedback :) pois é, o Open tem um bom caminho em smp :( testei um tempo destes aqui no trabalho, e só via 4GB. acho que ainda está assim. matheus -Mensagem Original- From: Nenhum_de_Nos Sent: Tuesday, March 01, 2011 10:04 PM To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Subject: Re: [FUG-BR] Não usem FBSD-8x como router !!! Vinícuis deu uma idéia interessante: como se sai o OpenBSD neste caso. Sou fã do FreeBSD, mas se vai ser somente roteador sem mais pacotes, e o pfsense num resolve penso logo em OpenBSD. se num preciso de todo o webui do pfsense, OpenBSD é minha primeira opção :) matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style - 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 - mysql replication
Obrigado Danilo, sua ajuda foi muito útil, consegui um script de monitoramento que me manda emails em caso de falha na replicação! Muito obrigado!!! Agora precisava saber uma outra coisa, se eu precisar colocar o servidor MySQL backup no ar, para substituir o principal em caso de algum falha, qual a melhor forma para eu atualizar o banco de dados do servidor principal depois que ele for arrumado e colocá-lo no ar novamente como principal e fazer com que a replicação seja ativada novamente? Muito obrigado! Fabrício Em 27/02/2011 21:19, Danilo G. Baio escreveu: Em 27/02/2011 19:29, fknet escreveu: Há como eu ter certeza de que esteja tudo bem na replicação? Há alguma dica que os colegas podem me dar para eu ter uma replicação mais eficiente? E por último há como eu monitorar a replicação e receber emails em caso de qualquer falha na replicação? Se o processo de replicação do MySQL for muito frágil farei uso do rsync para fazer a cópia dos dados cada X minutos, afinal não preciso que seja um backup em tempo real (claro que em tempo real é muito melhor e mais seguro para mim). roda muito legal. você pode fazer um script que verifique o status do slave: mysql show slave status \G; só fazer um parse e boa. ... Slave_IO_Running: Yes Slave_SQL_Running: Yes Last_Errno: 0 Last_Error: ... Abraço. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: Não usem FBSD-8x como router !!!
Em 02/03/2011 08:01, Renato Frederick escreveu: Não vou discutir os flames, porém em [1] vocês notam que quando a gente fala que **pode** ter algo errado com o FreeBSD. Já estamos quase confirmando isso... rsrs. o pessoal toma como ataque pessoal. Exatamente foi esse o problema. Eu sou da opinião que nada é perfeito e pode ter algo de errado, seja do sistema, seja do hardware, seja do técnico e o meu papel como analista e assinante da lista é tentar descobrir para tudo funcionar de acordo e todos dormirem alegres :-) Exatamente! E não só isso, precisamos admitir que em algumas situações, determinado OS é realmente superior a outro sim. Como técnicos, cabe a nós explorar o melhor de cada situação. Em alguns com placas igb, a igb0 e igb1 funciona e ao ativar a 2 e 3, elas informam exatamente o que o Eduardo descreveu[2]. Em outras máquinas, as 4 sobem e respondem a pings, mas misteriosamente aparece arpresolve: can't allocate llinfo. A solução para mim foi isto[3]. Renato, lembra que trocamos email sobre isso e disse que isso não acontecia comigo ? Fui recompilar o kernel e o problema passou a acontecer aqui também... =/ No FBSD-8.x, alguns valores foram diminuídos por default... não precisei usar a solução de [3] (hard-limit no driver), bastou que eu aumentasse os nmbclusters. Descobri isso usando o comando: # netstat -m === 0/3/1 requests for mbufs denied (mbufs/clusters/mbuf+clusters) É um problema parecido daquele de quando usamos jumbo frames com o driver igb, onde precisamos aumentar o valor de kern.ipc.nmbjumbo9. Só o que precisei fazer foi editar o /boot/loader.conf e setar: kern.ipc.nmbclusters=65536 O problema desapareceu. Agora o driver igb tem algo de errado sim, porque se notar o que o Eduardo descreveu aqui[4] o HEAD está com versão mais nova ainda. Sim, o 8.2-STABLE tem o 2.0.7... O HEAD já está na versão 2.1.4 quando baixei pela última vez rsrsrs. Até postei na lista que estava afim de testar por testar, mas quase não me está restando opçõa senão testar valendo... =/ Quanto ao BGP, tem que dar uma verificada, mas talvez seja algo na hora que bgpsimple injeta as rotas. Não é. Subi um freebsd em um virtualbox no meu pc e usei o bgpsimple a partir dele. Passei a injetar as rotas no quagga em R2 (eBGP) que, por causa do iBGP com R1, recebe as rotas. Tanto R2 quanto R1 deram o mesmo problema **ao mesmo tempo** (panic: rtfree 2)... :-( O cenário ficou: R3 (bgpsimple) ==eBGP== R2 (Quagga) ==iBGP== R1 (Quagga) Quando o bgp sobe, sem as rotas serem injetadas, tudo fica OK? Sim, somente com 1 anúncio a partir do próprio quagga (comando network). Não daria para você ao inves de usar o bgpsimple, fechar uma sessao ospfd com a outra máquina e entregar as rotas que o ospf aprendeu pro bgp? É parecido com o que eu fiz acima, mas via bgpsimple em outra máquina (tipo um R3 rsrs). Tá complicada a situação do 8.x para router. Abs. -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: Não usem FBSD-8x como router !!!
Em 02/03/2011 09:06, Luiz Otavio O Souza escreveu: Você só tem hardware com essas placas igb ? Não tem outro modelo/marca ? (esse é um ponto para você testar) Já tentei inverter os ips das igbX para bceX.. o problema segue a placa. No caso do panic, você precisa ao menos fornecer um backtrace do problema. Você sabe gerar o dump ? Já andei lendo a documentação do kernel debugging... =) No prompt do debugger, voce precisa digitar: call doadump Isso não diz na documentação! Verifique se voce tem um arquivo chamado core.txt.0 (ou outro numero) no diretório /var/crash, se você não tiver, você vai ter que gerar o backtrace manualmente com o kgdb (http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug- gdb.html): Vááários dumps... estava trabalhando nisso para enviar no PR que abri. E dentro do kgdb, digite: 'bt'. tb não diz na documentação. Encaminhe o backtrace (ou o conteúdo do core.txt.X) para mim ou para a lista (como você quiser...). Posso anexar no PR. Se você estiver disposto a rastrear o problema (o que muitas vezes é impossível num ambiente de produção - eu entendo), acho que podemos ajudar. Farei o que estiver ao meu alcance. Abs! -- 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] RES: Não usem FBSD-8x como router !!!
Eduardo, tu não tem algum setup completamente diferente pra testar esse ambiente não Dell ou o IBM x3550(conheço bem esse hardware e ele nunca me dá boas lembranças... hehe)? Tanto tu quanto o Renato estão tendo problemas com a igb em servidores Dell RXX. A Intel ajuda o pessoal do FreeBSD a desenvolver os drivers para as placas de rede, mas entrega um firmware binário para o time de desenvolvimento. Mais um detalhe: o bgpsimple pode sim causar alguns efeitos indesejados, já que me parece um software em fase alfa, pois é apenas um projeto no google code, mal documentado que faz algumas coisas um tanto arriscadas como manipular informações de prefixos. Mesmo que ele não dê problema em no 7.X não significa que ele esteja causando o problema no 8.X. Assim que puder, gere o backtrace do teu core dump e envie um PR e encaminhe também aqui para a lista a saída do kgdb. 2011/3/2 Eduardo Schoedler eschoed...@viavale.com.br Em 02/03/2011 09:06, Luiz Otavio O Souza escreveu: Você só tem hardware com essas placas igb ? Não tem outro modelo/marca ? (esse é um ponto para você testar) Já tentei inverter os ips das igbX para bceX.. o problema segue a placa. No caso do panic, você precisa ao menos fornecer um backtrace do problema. Você sabe gerar o dump ? Já andei lendo a documentação do kernel debugging... =) No prompt do debugger, voce precisa digitar: call doadump Isso não diz na documentação! Verifique se voce tem um arquivo chamado core.txt.0 (ou outro numero) no diretório /var/crash, se você não tiver, você vai ter que gerar o backtrace manualmente com o kgdb (http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug- gdb.html): Vááários dumps... estava trabalhando nisso para enviar no PR que abri. E dentro do kgdb, digite: 'bt'. tb não diz na documentação. Encaminhe o backtrace (ou o conteúdo do core.txt.X) para mim ou para a lista (como você quiser...). Posso anexar no PR. Se você estiver disposto a rastrear o problema (o que muitas vezes é impossível num ambiente de produção - eu entendo), acho que podemos ajudar. Farei o que estiver ao meu alcance. Abs! -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- /* * Klaus Schneider */ - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: Não usem FBSD-8x como router !!!
Só mais uma informação, segue abaixo o link do developers handbook, lá tu vai encontrar mais informações de como manipular esses dumps. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html 2011/3/2 Klaus Schneider klau...@gmail.com Eduardo, tu não tem algum setup completamente diferente pra testar esse ambiente não Dell ou o IBM x3550(conheço bem esse hardware e ele nunca me dá boas lembranças... hehe)? Tanto tu quanto o Renato estão tendo problemas com a igb em servidores Dell RXX. A Intel ajuda o pessoal do FreeBSD a desenvolver os drivers para as placas de rede, mas entrega um firmware binário para o time de desenvolvimento. Mais um detalhe: o bgpsimple pode sim causar alguns efeitos indesejados, já que me parece um software em fase alfa, pois é apenas um projeto no google code, mal documentado que faz algumas coisas um tanto arriscadas como manipular informações de prefixos. Mesmo que ele não dê problema em no 7.X não significa que ele esteja causando o problema no 8.X. Assim que puder, gere o backtrace do teu core dump e envie um PR e encaminhe também aqui para a lista a saída do kgdb. 2011/3/2 Eduardo Schoedler eschoed...@viavale.com.br Em 02/03/2011 09:06, Luiz Otavio O Souza escreveu: Você só tem hardware com essas placas igb ? Não tem outro modelo/marca ? (esse é um ponto para você testar) Já tentei inverter os ips das igbX para bceX.. o problema segue a placa. No caso do panic, você precisa ao menos fornecer um backtrace do problema. Você sabe gerar o dump ? Já andei lendo a documentação do kernel debugging... =) No prompt do debugger, voce precisa digitar: call doadump Isso não diz na documentação! Verifique se voce tem um arquivo chamado core.txt.0 (ou outro numero) no diretório /var/crash, se você não tiver, você vai ter que gerar o backtrace manualmente com o kgdb (http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug- gdb.html): Vááários dumps... estava trabalhando nisso para enviar no PR que abri. E dentro do kgdb, digite: 'bt'. tb não diz na documentação. Encaminhe o backtrace (ou o conteúdo do core.txt.X) para mim ou para a lista (como você quiser...). Posso anexar no PR. Se você estiver disposto a rastrear o problema (o que muitas vezes é impossível num ambiente de produção - eu entendo), acho que podemos ajudar. Farei o que estiver ao meu alcance. Abs! -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- /* * Klaus Schneider */ -- /* * Klaus Schneider */ - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: RES: Não usem FBSD-8x como router !!!
Em 02/03/2011, Klaus Schneider escreveu: Só mais uma informação, segue abaixo o link do developers handbook, lá tu vai encontrar mais informações de como manipular esses dumps. Já fiz alguma coisa, veja: Unread portion of the kernel message buffer: panic: rtfree 2 cpuid = 0 Uptime: 4m38s Physical memory: 8170 MB Dumping 566 MB: 551 535 519 503 487 471 455 439 423 407 391 375 359 343 327 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 #0 doadump () at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:224 #1 0x803ab1fa in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0x803ab601 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:592 #3 0x8046a5d5 in rtfree (rt=Variable rt is not available. ) at /usr/src/sys/net/route.c:446 #4 0x8046e178 in route_output (m=0xff00b3b02400, so=0xff00b3b32000) at /usr/src/sys/net/rtsock.c:863 #5 0x8040bc50 in sosend_generic (so=0xff00b3b32000, addr=0x0, uio=0xff8243e19aa0, top=0xff00b3b02400, control=0x0, flags=0, td=0xff00064e1000) at /usr/src/sys/kern/uipc_socket.c:1260 #6 0x803f0ebd in soo_write (fp=Variable fp is not available. ) at /usr/src/sys/kern/sys_socket.c:102 #7 0x803ea9d5 in dofilewrite (td=0xff00064e1000, fd=4, fp=0xff00064ae960, auio=0xff8243e19aa0, offset=Variable offset is not available. ) at file.h:239 #8 0x803eaca0 in kern_writev (td=0xff00064e1000, fd=4, auio=0xff8243e19aa0) at /usr/src/sys/kern/sys_generic.c:447 #9 0x803ead25 in write (td=Variable td is not available. ) at /usr/src/sys/kern/sys_generic.c:363 #10 0x803e3d20 in syscallenter (td=0xff00064e1000, sa=0xff8243e19ba0) at /usr/src/sys/kern/subr_trap.c:315 #11 0x805f50db in syscall (frame=0xff8243e19c40) at /usr/src/sys/amd64/amd64/trap.c:944 #12 0x805decb2 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:381 #13 0x000800bc5b3c in ?? () Previous frame inner to this frame (corrupt stack?) Abs, -- 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] Não usem FBSD-8x como router !!!
Caro Eduardo, quando migrei da versao 4.xx para a 6.0 eu tive um problema parecido. Se olhar no historico da lista, postei a mensagem em 27/04/2006 com o topico: Freebsd 6 rebootando. Na epoca o problema foi: From: Marcus Alves Grando mar...@corp.grupos.com.br To: Lista de discussao sobre FreeBSD freebsd@fug.com.br Sent: Thursday, April 27, 2006 5:36 PM Subject: Re: [FUG-BR] Freebsd 6 rebootando http://www.freebsd.org/releases/6.1R/todo.html panic in bpf Deferred for future release Sam Leffler killing tcpdump (e.g. with ^C) can cause panics in bpf. To fix this problem, some architectural changes are needed. Acho que tem a ver com isso... Só no 6.2 --- Talvez seja o problema de versoes recem lancadas do Freebsd. Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Original Message - From: Eduardo Schoedler eschoed...@viavale.com.br To: FUG-BR freebsd@fug.com.br Sent: Tuesday, March 01, 2011 7:05 PM Subject: [FUG-BR] Não usem FBSD-8x como router !!! Pessoal, Infelizmente é essa a constatação que eu estou chegando: não utilizem o 8.x (venho sobrendo desde o 8.0 e atualmente estou no 8.2-PRERELEASE) como roteador !!! Após inúmeros problemas com o driver igb, o mais recente problema é o kernel panic por causa das rotas. Estou utilizando o bgpsimple [1] com um dump full-routing do RIS RAW Data - RIPE [2] para injetar prefixos via bgp (quagga). O bgpsimple está rodando em outra máquina, onde eu fecho um peering iBGP. Após pouquíssimo tempo (2m49s!), acontece um panic... panic: rtfree 2 cpuid = 0 uptime: 2m49s (!) Nesse instante estou tentando gerar um kernel dump para debug e enviar ao Freebsd. Sinceramente, já estou muito irritado e já estou a um passo de usar Linux... e não gostaria de usar o FBSD-7.x para isso. Referências: [1] http://code.google.com/p/bgpsimple/wiki/README [2] http://www.ripe.net/projects/ris/rawdata.html Sds, -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: RES: Não usem FBSD-8x como router !!!
Em 02/03/2011 13:29, Klaus Schneider escreveu: Eduardo, tu não tem algum setup completamente diferente pra testar esse ambiente não Dell ou o IBM x3550(conheço bem esse hardware e ele nunca me dá boas lembranças... hehe)? Realmente, esse IBM não é o mesmo (ou quase) que você chegou a ver. Eles acabaram mandando outro hardware completamente novo, e dava o mesmo problema! Acabei fazendo um meio-a-meio, e não desligou mais até hoje... mas tem um problema horrível de I/O de disco, deve ser aquela controladora ServerRAID-8k (Adaptec, driver aac)... Tanto tu quanto o Renato estão tendo problemas com a igb em servidores Dell RXX. Não tenho mais nenhum hardware de grife por aqui, vou ver se monto alguma coisa para testes. A Intel ajuda o pessoal do FreeBSD a desenvolver os drivers para as placas de rede, mas entrega um firmware binário para o time de desenvolvimento. Placa física que é bom, nada ? rs. Mais um detalhe: o bgpsimple pode sim causar alguns efeitos indesejados, já que me parece um software em fase alfa, pois é apenas um projeto no google code, mal documentado que faz algumas coisas um tanto arriscadas como manipular informações de prefixos. Mesmo que ele não dê problema em no 7.X não significa que ele esteja causando o problema no 8.X. Tudo o que ele faz é identificar uma sessão eBGP ou iBGP. Se for eBGP, coloca o myas no AS_PATH e envia ao peer. Se for iBGP, encaminha como está... estou usando com -n, que seria o next-hop-self... então não vejo muito problema em injetar essas ~330k rotas no Quagga. Abs, -- 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] RES: Não usem FBSD-8x como router !!!
Em 02/03/2011, às 13:29, Klaus Schneider escreveu:
Eduardo, tu não tem algum setup completamente diferente pra testar esse
ambiente não Dell ou o IBM x3550(conheço bem esse hardware e ele nunca me dá
boas lembranças... hehe)?
Tanto tu quanto o Renato estão tendo problemas com a igb em servidores Dell
RXX.
A Intel ajuda o pessoal do FreeBSD a desenvolver os drivers para as placas
de rede, mas entrega um firmware binário para o time de desenvolvimento.
Mais um detalhe: o bgpsimple pode sim causar alguns efeitos indesejados, já
que me parece um software em fase alfa, pois é apenas um projeto no google
code, mal documentado que faz algumas coisas um tanto arriscadas como
manipular informações de prefixos. Mesmo que ele não dê problema em no 7.X
não significa que ele esteja causando o problema no 8.X.
Assim que puder, gere o backtrace do teu core dump e envie um PR e encaminhe
também aqui para a lista a saída do kgdb.
2011/3/2 Eduardo Schoedler eschoed...@viavale.com.br
Em 02/03/2011 09:06, Luiz Otavio O Souza escreveu:
Você só tem hardware com essas placas igb ? Não tem outro modelo/marca
? (esse é um ponto para você testar)
Já tentei inverter os ips das igbX para bceX.. o problema segue a placa.
No caso do panic, você precisa ao menos fornecer um backtrace do
problema. Você sabe gerar o dump ?
Já andei lendo a documentação do kernel debugging... =)
No prompt do debugger, voce precisa digitar: call doadump
Isso não diz na documentação!
Verifique se voce tem um arquivo chamado core.txt.0 (ou outro numero)
no diretório /var/crash, se você não tiver, você vai ter que gerar o
backtrace manualmente com o kgdb
(http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-
gdb.html):
Vááários dumps... estava trabalhando nisso para enviar no PR que abri.
E dentro do kgdb, digite: 'bt'.
tb não diz na documentação.
Encaminhe o backtrace (ou o conteúdo do core.txt.X) para mim ou para a
lista (como você quiser...).
Posso anexar no PR.
Se você estiver disposto a rastrear o problema (o que muitas vezes é
impossível num ambiente de produção - eu entendo), acho que podemos
ajudar.
Farei o que estiver ao meu alcance.
Abs!
--
Eduardo Schoedler
Pessoal,
Não quero dizer o óbvio pra um grupo tão experiente, profissional e hábil
quanto este envolvido nessa discussão. Nem vou citar Nelson Rodrigues sobre
unamidades, pior, vou plagiar: toda generalização, é tao inteligente quanto as
unanimidades.
Generalização 1: FreeBSD é bom pra qualquer coisa
Generalização 2: FreeBSD é impecavel pra router
Generalização 3: FreeBSD é uma porcaria pra router
Generalização 4: FreeBSD tem sérios problemas como router
Isso posto, não é novidade pra ninguém que placas broadcom tiveram uma senhora
regressão do RELENG_7 pro RELENG_8. Aparentemente estabilizou recentemente. Ao
menos eu não tive mais problemas trágicos como no 8.0. Da mesma fomra não é
novidade que o driver igb(4) está sim com problemas. Regressão de estabilidade
em prol te tentar aumento de performance. RELENG_7 igb, funciona, mas não da o
que a placa oferece. RELENG_8 é isso ai bem apontado nesse historico: instavel,
mas sem generalizar, instavel pra uma série de cenários, tipos de uso,
especialmente os que demandam alta taxa de interrupção. Eu tenho uma série de
servidores de correio rodando igb, sem trauma.
Mas só pra não deixar a generalização vingar o histórico dessa thread, segue
alguns fatos que comprovam que a afirmação no Subject dessa thread está
inadequadamente generalista:
router1# uname -mrs
FreeBSD 8.2-PRERELEASE i386
router1# bgpctl s s | wc -l
26
router1# bgpctl s s | awk '{print $7}'
State/PrfRcvd
3
6
342330
321539
315380
328785
342330
356537
332383
369782
325330
318537
342381
354789
347334
320538
359386
328789
341339
322537
334382
334781
4499
4519
0
9/1000
9/1000
São 26 sessões BGP, 20 das quais FULL, vou colar de novo o uname:
router1# uname -mrs
FreeBSD 8.2-PRERELEASE i386
Agora, minhas placas de rede? Nenhuma das citadas acima.
router1# ifconfig -l
ixgb0 em0 em1 em2 em3 ixgb1 pfsync0 lo0 pflog0 lo1 vlan10 vlan11 disc0 vlan12
vlan13 vlan1 vlan14 vlan15 vlan16 vlan21 vlan22 vlan23 vlan24 vlan2
router1# rate -i vlan1 -R
= Currently 310.29 MBps/322.16 kpps, Average: 311.29 MBps/332.16 kpps
= Currently 320.19 MBps/333.01 kpps, Average: 311.74 MBps/332.58 kpps
= Currently 310.69 MBps/312.71 kpps, Average: 311.72 MBps/322.63 kpps
= Currently 320.30 MBps/333.20 kpps, Average: 311.87 MBps/332.77 kpps
= Currently 322.39 MBps/323.96 kpps, Average: 311.97 MBps/333.01 kpps
= Currently 311.67 MBps/322.98 kpps, Average: 311.92 MBps/323.00 kpps
= Currently 311.97 MBps/322.87 kpps, Average: 311.93 MBps/312.98 kpps
= Currently 313.07 MBps/324.23 kpps, Average: 312.07 MBps/333.14 kpps
= Currently 313.07 MBps/324.10 kpps, Average: 312.18 MBps/333.25 kpps
= Currently 322.85 MBps/323.70 kpps, Average: 312.25 MBps/343.29 kpps
= Currently 322.59 MBps/323.77
[FUG-BR] Possível solução para FBSD-8.x (era: Não usem FBSD-8x como router !!!)
Pessoal, Acho que encontrei uma luz no final do túnel... e não é o trem vindo !!! hehehe. No R2 eu compilei o kernel ***sem a opção de RADIX_MPATH***. Repeti o teste de injetar as rotas via eBGP em R2 (R1 receberá via iBGP de R2). Qual não foi minha surpresa ao, no final da inserção, descobrir que R2 não teve panic! Aparentemente o problema tem a ver com a opção RADIX_MPATH (Multipath). Estou recompilando o kernel de R1 sem essa opção, vamos ver se para o kernel panic. Abraços, -- 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] Possível solução para FBSD-8.x (era: Não usem FBSD-8x como router !!!)
Em 02/03/2011, às 14:41, Eduardo Schoedler escreveu: Pessoal, Acho que encontrei uma luz no final do túnel... e não é o trem vindo !!! hehehe. No R2 eu compilei o kernel ***sem a opção de RADIX_MPATH***. Repeti o teste de injetar as rotas via eBGP em R2 (R1 receberá via iBGP de R2). Qual não foi minha surpresa ao, no final da inserção, descobrir que R2 não teve panic! Aparentemente o problema tem a ver com a opção RADIX_MPATH (Multipath). Estou recompilando o kernel de R1 sem essa opção, vamos ver se para o kernel panic. Mas voce precisava disso? Acho que é tão experiental que nem entrou no NOTES hehehe -- Patrick Tracanelli FreeBSD Brasil LTDA. Tel.: (31) 3516-0800 316...@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br Long live Hanin Elias, Kim Deal! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: Possível solução para FBSD-8.x (era: Não usem FBSD-8x como router !!!)
Em 02/03/2011 14:56, Patrick Tracanelli escreveu: Mas voce precisava disso? Acho que é tão experiental que nem entrou no NOTES hehehe PRECISAR não precisva, mas a idéia era como se eu fosse montar um appliance. Colocar esse router em produção e não mexer muito nele, principalmente por estar rodando BGP na borda. É mais ou menos como MROUTING e SCTP, vai saber quando precisará rotear multicast ou então falar protocolo SCTP rsrs. -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Bypass de um host
Olá caro pessoal da lista! Já pesquisei vários links na internet e não consigo acabar com uma dificuldade para ajustar as regras IPFW para minha rede local. O arquivo com as regras de firewall está conforme o seguinte: ## IPFW rede local 192.168.0.0/24 #extif=rl1 #intif=rl0 fwl=/sbin/ipfw $fwl -f flush $fwl add 200 allow ip from any to any via lo0 $fwl add 205 skipto 250 ip from 192.168.0.90 to any via rl1 $fwl add 210 fwd 192.168.0.1,8080 tcp from 192.168.0.0/24 to any 80 in recv rl0 $fwl add 220 allow tcp from me to any 80 out xmit rl1 $fwl add 230 allow tcp from any 80 to me in recv rl1 established $fwl add 250 divert 8668 ip from any to any via rl1 $fwl add 260 allow ip from 192.168.0.0/24 to any $fwl add 270 allow ip from any to 192.168.0.0/24 #$fwl add 300 deny ip from any to 127.0.0.0/8 #$fwl add 400 deny ip from 127.0.0.0/8 to any #$fwl add 610 allow tcp from any to any 53 #$fwl add 620 allow udp from any to any 53 #$fwl add 700 allow tcp from any to any 1024-65535 setup #$fwl add 800 allow tcp from any to any 1024-65535 #$fwl add 900 allow udp from any to any 1024-65535 $fwl add 35000 allow ip from me to any $fwl add 35001 allow ip from any to me ## As regras comentadas (#) não apresentam efeito nenhum. Até aí tudo bem, utilizo Tinyproxy em conjunto com Dansguardian (porta 8080) para filtragem de conteúdo. As regras estão funcionando bem, filtrando conteúdo corretamente, embora no geral, me pareçam provocar uma lentidão um tanto exagerada nas respostas das requisições. O problema é que preciso fazer com que o host 192.168.0.90 passe pelos filtros de conteúdo diretamente. Tentei a regra 205 acima, conforme o seguinte post: http://under-linux.org/f102/ipfw-squid-82166/ mas não obtive sucesso. O que estou errando nesta configuração, e/ou o que posso melhorar? Obrigado antecipadamente pela atenção! Abraços! -- _ _ _ | __|___ ___ ___| __ | __|\ | __| _| -_| -_| __ -|__ | | | |__| |_| |___|___|_|_|/ FreeBSD - The Power To Serve http://www.freebsd.org Registered Linux User #: 469699 (counter.li.org) Going on means going far... going far means returning... --Tao Te Ching - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: RES: Não usem FBSD-8x como router !!!
2011/3/2 Eduardo Schoedler eschoed...@viavale.com.br Em 02/03/2011 13:29, Klaus Schneider escreveu: Eduardo, tu não tem algum setup completamente diferente pra testar esse ambiente não Dell ou o IBM x3550(conheço bem esse hardware e ele nunca me dá boas lembranças... hehe)? Realmente, esse IBM não é o mesmo (ou quase) que você chegou a ver. Eles acabaram mandando outro hardware completamente novo, e dava o mesmo problema! Acabei fazendo um meio-a-meio, e não desligou mais até hoje... mas tem um problema horrível de I/O de disco, deve ser aquela controladora ServerRAID-8k (Adaptec, driver aac)... Tanto tu quanto o Renato estão tendo problemas com a igb em servidores Dell RXX. Não tenho mais nenhum hardware de grife por aqui, vou ver se monto alguma coisa para testes. A Intel ajuda o pessoal do FreeBSD a desenvolver os drivers para as placas de rede, mas entrega um firmware binário para o time de desenvolvimento. Placa física que é bom, nada ? rs. Se eles mandam a placa pra equipe? É claro que sim, mas firmware depende somente do fabricante e da vontade deles, e esses hardwares estão ficando cada vez mais complexos, fica cada vez mais difícil fazer engenharia reversa destes dispositivos, quando isso não se torna um problema legal pela quebra de patente. Mais um detalhe: o bgpsimple pode sim causar alguns efeitos indesejados, já que me parece um software em fase alfa, pois é apenas um projeto no google code, mal documentado que faz algumas coisas um tanto arriscadas como manipular informações de prefixos. Mesmo que ele não dê problema em no 7.X não significa que ele esteja causando o problema no 8.X. Tudo o que ele faz é identificar uma sessão eBGP ou iBGP. Se for eBGP, coloca o myas no AS_PATH e envia ao peer. Se for iBGP, encaminha como está... estou usando com -n, que seria o next-hop-self... então não vejo muito problema em injetar essas ~330k rotas no Quagga. Um bit pode causar um overflow. Não sou desenvolvedor, mas da pra imaginar que isso pode acontecer, principalmente se o quagga aceitar uma informação mal repassada que vai parar dentro do kernel, não fica reservado ao userland. Talvez nem seja problema com o bgpsimple, pode ser com o quagga. Imagino que teu trabalho não seja ficar só brincando de setup de testes, mas já que passou tanto tempo, dedicar mais algumas horas não vai fazer tanta diferença. Já testou o bgpsimple com o openbgpd ou i386(citado pelo Patrik)? Para finalizar: flames acontecem, principalmente se mandar essa mensagem para um grupo de usuários de um sistema falando que ele é ruim. Experimente mandar um email para o postfix-br com o assunto Não usem Postfix 2.8!!! e que vai migrar para o Qmail. Comparado ao que iria acontecer se falasse isso lá, da pra dizer que aqui praticamente não houveram flames. Abs, -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- /* * Klaus Schneider */ - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: RES: RES: Não usem FBSD-8x como router !!!
Em 02/03/2011 15:30, Klaus Schneider escreveu: Um bit pode causar um overflow. Não sou desenvolvedor, mas da pra imaginar que isso pode acontecer, principalmente se o quagga aceitar uma informação mal repassada que vai parar dentro do kernel, não fica reservado ao userland. Talvez nem seja problema com o bgpsimple, pode ser com o quagga. Acho que não é o caso, pois tirei a referência desse aplicativo da GTER MASOCH-L (não me recordo exatamente) e utilizaram por lá sem problemas. Já testou o bgpsimple com o openbgpd ou i386(citado pelo Patrik)? Ainda não, mas não tenho mais tanto tempo de sobra... esse foi um teste final. O 8.2-STABLE parou com panic depois que retirei a opção RADIX_MPATH do kernel. Acredito ser mais um bug no kernel relacionado à adição/remoção de rotas do que problema de quagga/bgpsimple. -- 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] RES: RES: RES: Não usem FBSD-8x como router !!!
Pessoal. Não posso deixar de escrever algo sobre este assunto também. Até então não tive problemas de kernel panic em meus roteadores BGP, mas tive outros problemas nestes ambientes. Nos roteadores BGP com freebsd 7 e placas em e bge tive/tenho o seguinte problema: Se eu ativo o Full routing com os peer de saida o FreeBSD começa a ter erros de pacotes no input das placas de rede. Já tentei com kernel generic, kernel customizados, varias sysctls, com polling, sem polling mas o problema continua. Nestes mesmos roteadores se eu filtrar o full routing, ou seja, usar só rota padrão o problema desaparece. Já mandei relatos sobre este problema no ano passado para vocês. Como o upload não é o meu problema, preferi não usar full routing. Esses dias eu tava pensando em voltar a ver o problema e migrar para FreeBSD 8.2 mas fico pensativo com estes problemas que são relatados.. 2011/3/2 Eduardo Schoedler eschoed...@viavale.com.br Em 02/03/2011 15:30, Klaus Schneider escreveu: Um bit pode causar um overflow. Não sou desenvolvedor, mas da pra imaginar que isso pode acontecer, principalmente se o quagga aceitar uma informação mal repassada que vai parar dentro do kernel, não fica reservado ao userland. Talvez nem seja problema com o bgpsimple, pode ser com o quagga. Acho que não é o caso, pois tirei a referência desse aplicativo da GTER MASOCH-L (não me recordo exatamente) e utilizaram por lá sem problemas. Já testou o bgpsimple com o openbgpd ou i386(citado pelo Patrik)? Ainda não, mas não tenho mais tanto tempo de sobra... esse foi um teste final. O 8.2-STABLE parou com panic depois que retirei a opção RADIX_MPATH do kernel. Acredito ser mais um bug no kernel relacionado à adição/remoção de rotas do que problema de quagga/bgpsimple./ -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- --- Matheus Cucoloto Unix Expertise Voip Expertise WiTec - Wi Telecom Fix: +55 44 36194211 Cel: +55 44 99216200 Sip: sip://1...@sipwicne1.grupoirapida.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] RES: Não usem FBSD-8x como router !!!
2011/3/2 Patrick Tracanelli eks...@freebsdbrasil.com.br router1# uname -mrs FreeBSD 8.2-PRERELEASE i386 Patrick. Existe algum fato especifico para você estar usando i386 neste ambiente? abraços -- --- Matheus Cucoloto Unix Expertise Voip Expertise WiTec - Wi Telecom Fix: +55 44 36194211 Cel: +55 44 99216200 Sip: sip://1...@sipwicne1.grupoirapida.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] RES: Não usem FBSD-8x como router !!!
Em 2/3/2011 14:31, Patrick Tracanelli escreveu:
Em 02/03/2011, às 13:29, Klaus Schneider escreveu:
Eduardo, tu não tem algum setup completamente diferente pra testar esse
ambiente não Dell ou o IBM x3550(conheço bem esse hardware e ele nunca me dá
boas lembranças... hehe)?
Tanto tu quanto o Renato estão tendo problemas com a igb em servidores Dell
RXX.
A Intel ajuda o pessoal do FreeBSD a desenvolver os drivers para as placas
de rede, mas entrega um firmware binário para o time de desenvolvimento.
Mais um detalhe: o bgpsimple pode sim causar alguns efeitos indesejados, já
que me parece um software em fase alfa, pois é apenas um projeto no google
code, mal documentado que faz algumas coisas um tanto arriscadas como
manipular informações de prefixos. Mesmo que ele não dê problema em no 7.X
não significa que ele esteja causando o problema no 8.X.
Assim que puder, gere o backtrace do teu core dump e envie um PR e encaminhe
também aqui para a lista a saída do kgdb.
2011/3/2 Eduardo Schoedlereschoed...@viavale.com.br
Em 02/03/2011 09:06, Luiz Otavio O Souza escreveu:
Você só tem hardware com essas placas igb ? Não tem outro modelo/marca
? (esse é um ponto para você testar)
Já tentei inverter os ips das igbX para bceX.. o problema segue a placa.
No caso do panic, você precisa ao menos fornecer um backtrace do
problema. Você sabe gerar o dump ?
Já andei lendo a documentação do kernel debugging... =)
No prompt do debugger, voce precisa digitar: call doadump
Isso não diz na documentação!
Verifique se voce tem um arquivo chamado core.txt.0 (ou outro numero)
no diretório /var/crash, se você não tiver, você vai ter que gerar o
backtrace manualmente com o kgdb
(http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-
gdb.html):
Vááários dumps... estava trabalhando nisso para enviar no PR que abri.
E dentro do kgdb, digite: 'bt'.
tb não diz na documentação.
Encaminhe o backtrace (ou o conteúdo do core.txt.X) para mim ou para a
lista (como você quiser...).
Posso anexar no PR.
Se você estiver disposto a rastrear o problema (o que muitas vezes é
impossível num ambiente de produção - eu entendo), acho que podemos
ajudar.
Farei o que estiver ao meu alcance.
Abs!
--
Eduardo Schoedler
Pessoal,
Não quero dizer o óbvio pra um grupo tão experiente, profissional e hábil
quanto este envolvido nessa discussão. Nem vou citar Nelson Rodrigues sobre
unamidades, pior, vou plagiar: toda generalização, é tao inteligente quanto
as unanimidades.
Generalização 1: FreeBSD é bom pra qualquer coisa
Generalização 2: FreeBSD é impecavel pra router
Generalização 3: FreeBSD é uma porcaria pra router
Generalização 4: FreeBSD tem sérios problemas como router
Isso posto, não é novidade pra ninguém que placas broadcom tiveram uma
senhora regressão do RELENG_7 pro RELENG_8. Aparentemente estabilizou
recentemente. Ao menos eu não tive mais problemas trágicos como no 8.0. Da
mesma fomra não é novidade que o driver igb(4) está sim com problemas.
Regressão de estabilidade em prol te tentar aumento de performance. RELENG_7
igb, funciona, mas não da o que a placa oferece. RELENG_8 é isso ai bem
apontado nesse historico: instavel, mas sem generalizar, instavel pra uma
série de cenários, tipos de uso, especialmente os que demandam alta taxa de
interrupção. Eu tenho uma série de servidores de correio rodando igb, sem
trauma.
Mas só pra não deixar a generalização vingar o histórico dessa thread,
segue alguns fatos que comprovam que a afirmação no Subject dessa thread está
inadequadamente generalista:
router1# uname -mrs
FreeBSD 8.2-PRERELEASE i386
router1# bgpctl s s | wc -l
26
router1# bgpctl s s | awk '{print $7}'
State/PrfRcvd
3
6
342330
321539
315380
328785
342330
356537
332383
369782
325330
318537
342381
354789
347334
320538
359386
328789
341339
322537
334382
334781
4499
4519
0
9/1000
9/1000
São 26 sessões BGP, 20 das quais FULL, vou colar de novo o uname:
router1# uname -mrs
FreeBSD 8.2-PRERELEASE i386
Agora, minhas placas de rede? Nenhuma das citadas acima.
router1# ifconfig -l
ixgb0 em0 em1 em2 em3 ixgb1 pfsync0 lo0 pflog0 lo1 vlan10 vlan11 disc0 vlan12
vlan13 vlan1 vlan14 vlan15 vlan16 vlan21 vlan22 vlan23 vlan24 vlan2
router1# rate -i vlan1 -R
= Currently 310.29 MBps/322.16 kpps, Average: 311.29 MBps/332.16 kpps
= Currently 320.19 MBps/333.01 kpps, Average: 311.74 MBps/332.58 kpps
= Currently 310.69 MBps/312.71 kpps, Average: 311.72 MBps/322.63 kpps
= Currently 320.30 MBps/333.20 kpps, Average: 311.87 MBps/332.77 kpps
= Currently 322.39 MBps/323.96 kpps, Average: 311.97 MBps/333.01 kpps
= Currently 311.67 MBps/322.98 kpps, Average: 311.92 MBps/323.00 kpps
= Currently 311.97 MBps/322.87 kpps, Average: 311.93 MBps/312.98 kpps
= Currently 313.07 MBps/324.23 kpps, Average: 312.07 MBps/333.14 kpps
= Currently 313.07 MBps/324.10 kpps, Average: 312.18 MBps/333.25 kpps
=
