[GTER] Combinação mais estavel para usar Quagga: CentOS ou Ubunto?

[Renato Frederick]

Esqueci o post, segue ele


http://www.fug.com.br/historico/html/freebsd/2009-05/msg00061.html


> Renato Frederick <mailto:renato at frederick.eti.br>
> 16 de janeiro de 2015 23:59
> Evandro, esquece o quagga! Usa o openbgpd.
> Sintaxe prá quem usa cisco é um inferno, parece mais que tô editando o 
> BIND, mas na internet tem exemplo e rapidinho você pega o jeito.
>
> O post do Luiz Gustavo lá na FUG, diz tudo sobre quagga. A partir da 
> minha última mensagem na conversa, em 2009 que o quagga deu um pau com 
> ASN de 32bits e tive 4 ISP ligando para mim ao mesmo tempo, não 
> trabalho mais com este produto.
>
> A úlcera do meu estômago devia ser chamada de quagga.
>
> []s
>
> Evandro Nunes <mailto:evandronunes12 at gmail.com>
> 16 de janeiro de 2015 21:10
>>> Evandro,
>>>
>>> Não sei qual foi a última vez que você utilizou o
>> Quagga, mas acho que está exagerando um pouco com relação ao Quagga,
>> pelo menos com relação às versões atuais. Utilizamos o Quagga + FreeBSD
>> ha mais de um ano e até hoje não sofremos com nenhum bug ou travamento.
>>
>
> sempre que sofri com os bugs mais sérios, era linux ou BSDRP.
> quando fui pra freebsd ja foi openbgp mas com bsdrp hoje mesmo tive 2
> problemas.
> mas mesmo com bsd vamos a lista de problemas só entre ontem e hoje:
>
> 1) acabei de ter que dar um cease em um anuncio vindo da Intelig porque
> existiam "rotas presas".
> 2) outro problema, em uma sessão com um cisco, ficou variando de OPEN pra
> IDLE, um cease e tudo funcionou.
> 3) uma rota com um AS de 4-byte fechando com 23456 com um cisco velho,
> sessão estava de pe por semanas mas caiu, ao voltar parou de aceitar 23456
> no OPEN, dizia AS inaceitável. reload, cease, tudo de direito foi feito mas
> só voltou a funcionar quando matei o daemon e reiniciei. ou seja sem motivo
> pra parar. sem motivo pra voltar com restart do daemon mas não voltar com
> reload ou cease. só pode ser bug, por deus né rsss.
>
> todos esses erros foram em um bsdrp 1.52, ou seja quagga 0.99.22 e freebsd
> 10-stable
> sei que tem bsdrp 1.53 e 1.54 mas nesse escritório não tive a oportunidade
> de migrar.
> quando migrar não será pra outra coisa que não openbgp.
>
> infelizmente não é o caso de exageros nem experiência passada com algo
> velho.
> o trauma prévio persiste. meu quagga sempre da zebra (kkk acho que gostei
> do trocadilho infame).
>
> o que noto claramente é que quagga sobre freebsd é muito mais estável no
> que diz respeito entre interações RIB e FIB, por exemplo ter rota na RIB
> mas não ir pra FIB ou continuar na FIB mesmo quando a rota já não existe
> mais na RIB foram comportamentos que só tive em linux e nunca em freebsd.
> ja outros bugs, estão ai.. (ou pelo menos estão aqui).
>
> <maldade>
> vai me dizer que voce nunca deu um restart, um cease, sem razão de ser mas
> depois de dar algo que não funcionava com reload voltou a funcionar no
> quagga? rss se isso nunca aconteceu com você duvido que seja quagga kkkk
> </maldade>
>
>
>> Tudo bem que nosso cenário não é complexo, somos trânsito de alguns ASes
>> e possuímos peering com alguns upstreams e PTT, nada demais. Outra
>> coisa, realizei alguns testes com o Quagga, Bird e OpenBGPD que se
>> baseava em receber uma tabela de rotas full (500K+), aplicar alguns
>> filtros e injetar as rotas no kernel (FreeBSD). O consumo de cpu do bird
>> se mostrou muito inferior ao OpenBGPD e ao Quagga, inserindo as rotas na
>> FIB em tempo bastante aceitável, pelo menos para esse cenário.
>
>
> pois é.
> ou seja comportamento exatamente oposto do que o lucas teve.
> eu também sempre notei o bird mais rápido e mais eficiente em termos de cpu.
> sem reclamação nesse sentido.
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
> Antonio Modesto <mailto:modesto at isimples.com.br>
> 16 de janeiro de 2015 17:01
>
>
> On 2015-01-16 11:50 am, Evandro Nunes wrote:
>
>> 2015-01-16 3:04
> GMT-02:00 Fernando Frediani<fhfrediani at gmail.com>:
>>> Excelente
> email Lucas, Acho que esta discussão está além de interessante, muito
> parecendo com um Fla X Flu. Vários comentários defendendo os pontos que
> deram certo e os problema encontrados, o que é claro sempre vão variar
> de ambiente para ambiente. A melhor resposta na minha opinião sobre a
> melhor combinação para se usar é sempre "depende". Depende de uma série
> de fatores. Citando os principais: - Linux X FreeBSD - Tem pessoal
> in-house com conhecimento adequado para administrar algum deles ? Entao
> vai com o que voce tiver mais skills e livre-se do primeiro problema.
> Particularmente acredito que com os Kernels mais novos do Linux pouca
> diferença faz se é Linux ou FreeBSD. Pode até haver uma diferença ou
> outra é claro, talvez 'ainda' na questão de forward, não sei, mas no
> geral e pra maioria dos casos de uso aqui os dois funcionariam de
> maneira excelente.
>> não. linux não melhorou.
>> está ai o facebook
> correndo atrás do rabo pra tentar melhorar o kernel
>> linux, que é o que
> eles conhecem e dominam dentro do facebook. quando
>> compraram o
> whatsapp e tentaram colocar linux, o whatsapp ficou
>> indisponível e o
> linux não deu conta. acompanhando o blog do devops do
>> facebook estava
> la, dentre os problemas, o bom e velho problema de softirq
>> consumindo
> toda CPU possível. enquanto no freebsd, comportamento diferente
>> e a
> taxa de interrupção com aumento gradativo dentro da taxa de consumo do
> hardware projetado.
>> resultado, whatsapp continua freebsd pra sempre ou
> até que o facebook
>> consiga melhorar a pilha IP do Linux para, nas
> palavras deles ao abrir vaga
>> pro emprego "pelo menos próximo do
> freebsd". ou que resolvam por a mão no
>> bolso e gastar 4x mais hardware
> com linux comparando com freebsd. algo
>> possível em uma server farm
> como de um serviço como whatsapp mas mais
>> difícil no caso que estamos
> tratando, roteamento bgp.
>> recentemente em uma filial nossa na
> região de barão geraldo (campinas), com
>> kernel 3.14 atuando apenas
> como gateway e firewall + vpn, sem bgp/ospf, ou
>> seja meia dúzia de
> rotas estáticas + padrão, o linux engoliu com seu
>> softirq tudo que um
> Xeon de 4 core de 3.2Ghz tinha a oferecer com tráfego
>> de 350Kpps
> (pacotes grandes, chegando a 1.8Gbit/s). como nessa filial a
>> equipe é
> reduzida não colocamos freebsd vanilla mas sim pfSense, um FreeBSD
>> que
> uma equipe existente não precisa aprender de forma súbita. de novo
> mesma historia: mesmo hardware e mesmos serviços e o FreeBSD (pfSense)
> se
>> comportou excepcionalmente melhor, interrupt com picos de 30% de
> CPU e load
>> average bonitinho na zona de conforto.
>>
>> esse ponto se
> fosse pra atuar como um guia, eu acho que seria:
>> - vai rotear até
> 1Gbit/s? Linux OK. FreeBSD recomendado.
>> - vai rotear 1-2Gbit/s? muito
> cuidado com Linux, evite excesso ou uso de
>> iptables, escolha bem a
> máquina e Linux será viável. FreeBSD recomendado.
>> - vai rotear
> 2Gbit/s? com Linux você terá que ter recurso humano MUITO BOM
>> pra
> tunar, começando por recompilar kernel e tirar recursos que diminuem a
> performance do encaminhamento de pacote, tuning de linux, e outras
> melhorias (acompanhar blogs e histórico da lista do vyatta é o melhor
> caminho pra ter um Linux tunado pra roteamento), e tenha em mente que
> usar
>> Linux vai consumir mais recurso de hardware, portanto vai ter um
> ROI mais
>> longo e TCO maior. resumindo menor eficiência no consumo do
> hardware
>> existente. FreeBSD mais que recomendado.
>>
>> - recurso
> humano sabe linux? ok começa com linux se o ambiente não for
>> acima de
> 2Gbit/s e manda o recurso humano aprender freebsd com o tempo, se
> antecipando.
>> - recurso humano sabe linux e bsd? vai de freebsd
>> -
> recurso humano não sabe nada? aprende freebsd primeiro, deixa linux
> pra
>> depois ou pra outras funções na sua rede
>>
>>> - Quagga x BIRD x
> OpenBGP - Tem pessoal familiar com linha de comando Cisco ? Então usa
> Quagga. Tem algum bug específico que te preocupa, que não foi corrigido
> até a versão disponível na distribuição que você vai usar ? Qual o
> status do desenvolvimento e os commits no código ? Cada um desses tem
> suas vantagens e desvantagens. Por exemplo: Eu acho o pfSense um
> excelente sistema, é baseado em FreeBSD, mas o Quagga dele não tem
> suporte a BGP então pra mim não dá pra usar pra qualquer coisa que
> envolva BGP. Por outro lado o VyOS também excelente sistema, é Linux,
> roda Kernel mais recente e usa Quagga, mas por exemplo se for usado com
> um hardware específico (Server-U), pode não se aproveitar do Netmap ou
> de algumas vantagens de se utilizar algumas placas de rede específicas.
> Que tamanho é seu ambiente ? Faz diferença pra você ?
>> nossa ai é
> difícil hein.
>> mandar o cara pesquisar se tem bug que te afeta pra usar
> quagga é decidir
>> pegar a estrada esburacada e via simples, pra evitar
> pagar o pedágio da
>> estrada boa de via dupla.
>>
>> nesse caso o pedágio
> é abrir mão da sintaxe cisco-like.
>> vale a pena pagar esse preço? algo
> que diz que a manutenção do carro, os
>> riscos e a falta de
> tranquilidade de optar pela estrada esburacada acabará
>> ficando mais
> caro que pagar o pedágio.
>> acho que da pra simplificar.
>> como
> OpenBGP é uma coisa "bsd", se deu pra rodar bsd, vai de OpenBGP.
> simples assim. não é cisco-like mas é juniper-like e muito mais simples
> de
>> manter e eventualmente migrar.
>> mas se a opção foi linux ai eu
> resumiria essa proposta de "guia" da
>> seguinte forma:
>>
>> - vai usar
> muito filtro, ser transito pra muita gente? esquece bird, senão
>> vc vai
> infartar. vai de quagga e boa sorte. ou vai de vyos/bsdrp se não
> quiser contar com a sorte.
>> - você quer apenas estar no mundo com
> seu provedor e precisa de BGP pq vc é
>> ASN mas tem 1, 2, 3 saídas
> apenas: vai de bird na boa se cisco-like e
>> juniper-like não forem
> requisitos. esse é um cenário simples mas que
>> representa mais de 80%
> dos ISP com ASN que conheço. simples não quer dizer
>> pequeno, conheço
> provedores de amigos que dou apoio que tem mais de 2Gbit/s
>> contando
> apenas 1 perna de upstream + PTT.
>> Quagga - Como o Lucas mencionou,
> não é por acaso que o Vyatta/VyOS e
>> EdgeRouter usam Quagga. Se nao me
> engano eles tem até versão própria. BIRD - Ass
>>> ix usam BIRD. Cada
> um para a sua especificidade, os PTTs é mais questão de performance e
> pra Route Servers, ja no Netflix é outro uso específico relacionado a
> entrega de conteúdo.
>>> - Quagga insisto no ponto: não se engane,
> não caia na fé / crença / esperança, que VyOS e afins usam quagga. eles
> usam algo derivado do quagga mas muito
>> em todas essas melhorias voltam
> pro quagga nem mesmo como patches extra-oficiais (que voce poderia
> aplicar na mão mas não merged ainda). quagga é uma evolução do zebra e
> boa parte do que era ruim no zebra continua no quagga. claro hoje é
> muito melhor mas a chance do seu quagga "dar zebra" hehe ainda é forte.
> comigo deu todas as zebras possíveis. com o lucas só algumas. ou seja,
> de novo, boa sorte. - OpenBGP: único problema, no freebsd, auth MD5 é um
> patch a parte, depende de TCP_MD5 no kernel; por outro lado você não
> precisa de md5 e md5 não te traz nenhuma vantagem real então poupe-se;
> se quer confidencialidade de verdade tunela ipsec. - BIRD: vide acima
>
>> Evandro,
>>
>> Não sei qual foi a última vez que você utilizou o
> Quagga, mas acho que está exagerando um pouco com relação ao Quagga,
> pelo menos com relação às versões atuais. Utilizamos o Quagga + FreeBSD
> ha mais de um ano e até hoje não sofremos com nenhum bug ou travamento.
> Tudo bem que nosso cenário não é complexo, somos trânsito de alguns ASes
> e possuímos peering com alguns upstreams e PTT, nada demais. Outra
> coisa, realizei alguns testes com o Quagga, Bird e OpenBGPD que se
> baseava em receber uma tabela de rotas full (500K+), aplicar alguns
> filtros e injetar as rotas no kernel (FreeBSD). O consumo de cpu do bird
> se mostrou muito inferior ao OpenBGPD e ao Quagga, inserindo as rotas na
> FIB em tempo bastante aceitável, pelo menos para esse cenário.
> outros daemons da vida, chorp, exa, desconheço e não posso opinar. --
> gter list https://eng.registro.br/mailman/listinfo/gter [1]
>
> Evandro Nunes <mailto:evandronunes12 at gmail.com>
> 16 de janeiro de 2015 11:50
> 2015-01-16 3:04 GMT-02:00 Fernando Frediani<fhfrediani at gmail.com>:
>
>> Excelente email Lucas,
>>
>> Acho que esta discussão está além de interessante, muito parecendo com um
>> Fla X Flu. Vários comentários defendendo os pontos que deram certo e os
>> problema encontrados, o que é claro sempre vão variar de ambiente para
>> ambiente.
>> A melhor resposta na minha opinião sobre a melhor combinação para se usar
>> é sempre "depende". Depende de uma série de fatores. Citando os principais:
>>
>> - Linux X FreeBSD - Tem pessoal in-house com conhecimento adequado para
>> administrar algum deles ? Entao vai com o que voce tiver mais skills e
>> livre-se do primeiro problema. Particularmente acredito que com os Kernels
>> mais novos do Linux pouca diferença faz se é Linux ou FreeBSD. Pode até
>> haver uma diferença ou outra é claro, talvez 'ainda' na questão de forward,
>> não sei, mas no geral e pra maioria dos casos de uso aqui os dois
>> funcionariam de maneira excelente.
>>
>
> não. linux não melhorou.
> está ai o facebook correndo atrás do rabo pra tentar melhorar o kernel
> linux, que é o que eles conhecem e dominam dentro do facebook. quando
> compraram o whatsapp e tentaram colocar linux, o whatsapp ficou
> indisponível e o linux não deu conta. acompanhando o blog do devops do
> facebook estava la, dentre os problemas, o bom e velho problema de softirq
> consumindo toda CPU possível. enquanto no freebsd, comportamento diferente
> e a taxa de interrupção com aumento gradativo dentro da taxa de consumo do
> hardware projetado.
> resultado, whatsapp continua freebsd pra sempre ou até que o facebook
> consiga melhorar a pilha IP do Linux para, nas palavras deles ao abrir vaga
> pro emprego "pelo menos próximo do freebsd". ou que resolvam por a mão no
> bolso e gastar 4x mais hardware com linux comparando com freebsd. algo
> possível em uma server farm como de um serviço como whatsapp mas mais
> difícil no caso que estamos tratando, roteamento bgp.
>
> recentemente em uma filial nossa na região de barão geraldo (campinas), com
> kernel 3.14 atuando apenas como gateway e firewall + vpn, sem bgp/ospf, ou
> seja meia dúzia de rotas estáticas + padrão, o linux engoliu com seu
> softirq tudo que um Xeon de 4 core de 3.2Ghz tinha a oferecer com tráfego
> de 350Kpps (pacotes grandes, chegando a 1.8Gbit/s). como nessa filial a
> equipe é reduzida não colocamos freebsd vanilla mas sim pfSense, um FreeBSD
> que uma equipe existente não precisa aprender de forma súbita. de novo
> mesma historia: mesmo hardware e mesmos serviços e o FreeBSD (pfSense) se
> comportou excepcionalmente melhor, interrupt com picos de 30% de CPU e load
> average bonitinho na zona de conforto.
>
> esse ponto se fosse pra atuar como um guia, eu acho que seria:
>
> - vai rotear até 1Gbit/s? Linux OK. FreeBSD recomendado.
> - vai rotear 1-2Gbit/s? muito cuidado com Linux, evite excesso ou uso de
> iptables, escolha bem a máquina e Linux será viável. FreeBSD recomendado.
> - vai rotear 2Gbit/s? com Linux você terá que ter recurso humano MUITO BOM
> pra tunar, começando por recompilar kernel e tirar recursos que diminuem a
> performance do encaminhamento de pacote, tuning de linux, e outras
> melhorias (acompanhar blogs e histórico da lista do vyatta é o melhor
> caminho pra ter um Linux tunado pra roteamento), e tenha em mente que usar
> Linux vai consumir mais recurso de hardware, portanto vai ter um ROI mais
> longo e TCO maior. resumindo menor eficiência no consumo do hardware
> existente. FreeBSD mais que recomendado.
>
> - recurso humano sabe linux? ok começa com linux se o ambiente não for
> acima de 2Gbit/s e manda o recurso humano aprender freebsd com o tempo, se
> antecipando.
> - recurso humano sabe linux e bsd? vai de freebsd
> - recurso humano não sabe nada? aprende freebsd primeiro, deixa linux pra
> depois ou pra outras funções na sua rede
>
>
>> - Quagga x BIRD x OpenBGP - Tem pessoal familiar com linha de comando
>> Cisco ? Então usa Quagga. Tem algum bug específico que te preocupa, que não
>> foi corrigido até a versão disponível na distribuição que você vai usar ?
>> Qual o status do desenvolvimento e os commits no código ? Cada um desses
>> tem suas vantagens e desvantagens.
>> Por exemplo: Eu acho o pfSense um excelente sistema, é baseado em FreeBSD,
>> mas o Quagga dele não tem suporte a BGP então pra mim não dá pra usar pra
>> qualquer coisa que envolva BGP. Por outro lado o VyOS também excelente
>> sistema, é Linux, roda Kernel mais recente e usa Quagga, mas por exemplo se
>> for usado com um hardware específico (Server-U), pode não se aproveitar do
>> Netmap ou de algumas vantagens de se utilizar algumas placas de rede
>> específicas. Que tamanho é seu ambiente ? Faz diferença pra você ?
>>
>
> nossa ai é difícil hein.
> mandar o cara pesquisar se tem bug que te afeta pra usar quagga é decidir
> pegar a estrada esburacada e via simples, pra evitar pagar o pedágio da
> estrada boa de via dupla.
>
> nesse caso o pedágio é abrir mão da sintaxe cisco-like.
> vale a pena pagar esse preço? algo que diz que a manutenção do carro, os
> riscos e a falta de tranquilidade de optar pela estrada esburacada acabará
> ficando mais caro que pagar o pedágio.
>
> acho que da pra simplificar.
> como OpenBGP é uma coisa "bsd", se deu pra rodar bsd, vai de OpenBGP.
> simples assim. não é cisco-like mas é juniper-like e muito mais simples de
> manter e eventualmente migrar.
> mas se a opção foi linux ai eu resumiria essa proposta de "guia" da
> seguinte forma:
>
> - vai usar muito filtro, ser transito pra muita gente? esquece bird, senão
> vc vai infartar. vai de quagga e boa sorte. ou vai de vyos/bsdrp se não
> quiser contar com a sorte.
>
> - você quer apenas estar no mundo com seu provedor e precisa de BGP pq vc é
> ASN mas tem 1, 2, 3 saídas apenas: vai de bird na boa se cisco-like e
> juniper-like não forem requisitos. esse é um cenário simples mas que
> representa mais de 80% dos ISP com ASN que conheço. simples não quer dizer
> pequeno, conheço provedores de amigos que dou apoio que tem mais de 2Gbit/s
> contando apenas 1 perna de upstream + PTT.
>
>      Quagga - Como o Lucas mencionou, não é por acaso que o Vyatta/VyOS e
>> EdgeRouter usam Quagga. Se nao me engano eles tem até versão própria.
>>      BIRD - Assim como não é por acaso que grandes Pontos de Troca de
>> Tráfego no mundo assim como Netflix usam BIRD. Cada um para a sua
>> especificidade, os PTTs é mais questão de performance e pra Route Servers,
>> ja no Netflix é outro uso específico relacionado a entrega de conteúdo.
>>
>
> - Quagga insisto no ponto: não se engane, não caia na fé / crença /
> esperança, que VyOS e afins usam quagga. eles usam algo derivado do quagga
> mas muito melhor... e nem todas essas melhorias voltam pro quagga nem mesmo
> como patches extra-oficiais (que voce poderia aplicar na mão mas não merged
> ainda). quagga é uma evolução do zebra e boa parte do que era ruim no zebra
> continua no quagga. claro hoje é muito melhor mas a chance do seu quagga
> "dar zebra" hehe ainda é forte. comigo deu todas as zebras possíveis. com o
> lucas só algumas. ou seja, de novo, boa sorte.
>
> - OpenBGP: único problema, no freebsd, auth MD5 é um patch a parte, depende
> de TCP_MD5 no kernel; por outro lado você não precisa de md5 e md5 não te
> traz nenhuma vantagem real então poupe-se; se quer confidencialidade de
> verdade tunela ipsec.
>
> - BIRD: vide acima
>
> outros daemons da vida, chorp, exa, desconheço e não posso opinar.
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
> Fernando Frediani <mailto:fhfrediani at gmail.com>
> 16 de janeiro de 2015 03:04
> Excelente email Lucas,
>
> Acho que esta discussão está além de interessante, muito parecendo com 
> um Fla X Flu. Vários comentários defendendo os pontos que deram certo 
> e os problema encontrados, o que é claro sempre vão variar de ambiente 
> para ambiente.
> A melhor resposta na minha opinião sobre a melhor combinação para se 
> usar é sempre "depende". Depende de uma série de fatores. Citando os 
> principais:
>
> - Linux X FreeBSD - Tem pessoal in-house com conhecimento adequado 
> para administrar algum deles ? Entao vai com o que voce tiver mais 
> skills e livre-se do primeiro problema. Particularmente acredito que 
> com os Kernels mais novos do Linux pouca diferença faz se é Linux ou 
> FreeBSD. Pode até haver uma diferença ou outra é claro, talvez 'ainda' 
> na questão de forward, não sei, mas no geral e pra maioria dos casos 
> de uso aqui os dois funcionariam de maneira excelente.
>
> - Quagga x BIRD x OpenBGP - Tem pessoal familiar com linha de comando 
> Cisco ? Então usa Quagga. Tem algum bug específico que te preocupa, 
> que não foi corrigido até a versão disponível na distribuição que você 
> vai usar ? Qual o status do desenvolvimento e os commits no código ? 
> Cada um desses tem suas vantagens e desvantagens.
> Por exemplo: Eu acho o pfSense um excelente sistema, é baseado em 
> FreeBSD, mas o Quagga dele não tem suporte a BGP então pra mim não dá 
> pra usar pra qualquer coisa que envolva BGP. Por outro lado o VyOS 
> também excelente sistema, é Linux, roda Kernel mais recente e usa 
> Quagga, mas por exemplo se for usado com um hardware específico 
> (Server-U), pode não se aproveitar do Netmap ou de algumas vantagens 
> de se utilizar algumas placas de rede específicas. Que tamanho é seu 
> ambiente ? Faz diferença pra você ?
>
>     Quagga - Como o Lucas mencionou, não é por acaso que o Vyatta/VyOS 
> e EdgeRouter usam Quagga. Se nao me engano eles tem até versão própria.
>     BIRD - Assim como não é por acaso que grandes Pontos de Troca de 
> Tráfego no mundo assim como Netflix usam BIRD. Cada um para a sua 
> especificidade, os PTTs é mais questão de performance e pra Route 
> Servers, ja no Netflix é outro uso específico relacionado a entrega de 
> conteúdo.
>
> Portanto não adianta escolher um que te dá uma vantagem que pareça 
> atraente se pouca diferença vai fazer pra você não dia a dia e você 
> acabar penando pra administrar. Afinal de contas nesse tópico 
> especificamente não é um sistema que podemos falar pro usuário esperar 
> um pouco que o sistema já volta.
>
> Abraços.
> Fernando
>
>
>
> -- 
> gter list    https://eng.registro.br/mailman/listinfo/gter