2008/8/29 c0re dumped <[EMAIL PROTECTED]> > Adalto, também peço desculpas a você e aos demais da lista pelo tom da > minha resposta. Não sei quanto aos outros , mas achei seu primeiro > quote em meu e-mail e logo depois no do Renato, bem arrogantes.
concordo que tenha parecido, não foi intencional a mesma coisa sobre o php la, o outro menino se sentiu ofendido infelizmente não tenho costume de por os "he he he" e "ha ha" e carinhas em e-mail o que o torna passível de má interpretação quando digo algo que não gostem rs > > > Mas nada justifica minha atitude. Novamente, desculpas a você e todos > os outros membros. nos excedemos mas acredito que já voltamos a contribuir para a qualidade desta > No nosso caso que usamos hardware Cisco, já tem uns 3 anos que não > temos nenhum downtime por conta de falha de hardware ou IOS nos > routers. Quando precisamos foi menos de 5 minutos entre a abertura do > chamado e a solução do problema, com o router 100% funcional. perfeitamente, não sugiro sob qualquer hipótese o equipamento, sistema e suporte profissional não se de qualidade, especialmente juniper por outro lado você contou com sorte, não houve problema elétrico já cansei de ver eprons cisco morrendo, e IOS corrompendo o IOS que é comprimido no momento do boot alias só o fato de ter o sistema comprimido já me causou motivos de problema fico feliz que tenhas dado sorte suficiente para ter esse profiling no meu caso prefiro não depender da sorte e ter fail-over de tudo o que eu sei que dependendo do ambiente, o custo de ter box de roteadores enormes redundante é proibitivo ao ponto de sabermos que até mesmo as maiores operadoras contam com a sorte e não dispõe de redundancia em muitos de seus POP > Trabalho com Free e UNIX há alguns anos e sei que pra certos problemas > mais cabeludos, por mais que se tenha experiência com o sistema, com a > ferramenta, com o hardware e tudo o mais, estes problemas demandam > tempo para serem resolvidos: procura nos logs, debuga o processo, > testa configuração A, testa configuração B, olha mensagens de erro no > console, procura no google, pergunta em ML... e por aí vai. por isso defendo que cada nova implantação deve ser testada antes de por em produção um processo de QAS mesmo que baseado em 1 ou 2 pessoas só, deve homologar não se sai juntando openvpn, placa aceleradora de crypto, quagga, e mahakeshis da vida sem testar antes cada solução deve ser testada antes o vantajoso é que criamos as soluções não dependemos se o fabricante fornece ou não veja a trabalheira da cisco para suporte ipv6 adequadamente... e veja os tuneis teredo padrão do windows vista gerando dores-de-cabeça mil para quem tem IOS ou CatOS com ipv6 habilitado na rede, ou ainda o horror que é comprar uma solução de análise de netflow da cisco (a mãe da tecnologia) e descobrir que a solução não analisa o flow gerado por alguns junipers porque este, só gera flow sampleado e alguns períodos de sampling são incompatíveis tudo tem seus pros e contras, como você mesmo disse e é natural que se o fabricante oferece um "produto", o mínimo que esperamos é que ele funcione façamos o mesmo com nossos recursos implantados > Você melhor que ninguém sabe que um cliente que acordou um contrato > pedindo X% de disponibilidade, não vai dar a mínima para o motivo do > problema, qualquer que seja ele. sem dúvidas e ele está certíssimo Como disse antes, existem casos e casos. Acredito que para quem tem > uma estrutura mais compacta e quer oferecer a melhor relação > custo/benefício ao cliente, a abordagem adotada por vc, pra citar um > exemplo, talvez seja a ideal. não acho minha estrutura compacta talvez seja, comparando à sua, é fato mas são 4 bordas bgp em 2 capitais diferentes, e são dezenas de clientes usando a solução de roteamento mencionada a distribuição da solução é muito fácil e organizada alias a maioria dos equipamentos eu criei uma pequena estrutura de provisionamento via scp, e portanto eu dispacho o equipamento, o cliente liga, e ele se auto-configura assim que detecta conectividade, se não detectar, a equipe de campo faz o check-list bem simples > Imagina eu trocar todos os meus CEs por PCs, botando um ou dois spares > pra cada. sim, imagino, foi o que eu fiz quando dispensamos cisco o TCO deixou o financeiro feliz da vida, e eu ainda mais por finalmente ter redundância plena > Imagina uma atualização de segurança pro OS ultra-mega-super > urgente que envolva uma nova compilação de kernel nesse caso fico feliz em não ter cisco, pois openbsd e freebsd tem response time de segurança muito mais adequados, e de olho aberto nos commit logs já podemos nos antecipar antes mesmo do adivisory ser lançado > Imagina uma queda de energia que danifique > o sistema de arquivos inviabilizando o boot na máquina. com memória flash montada RO, improvável precisaria ser um problema físico/elétrico caso em que nenhuma box fechada se porta diferente > Imagina que > tem que se trocar uma placa, mas a placa que vc comprou não funciona > pq ninguem fez um driver pra ela ainda seria exatamente a mesma coisa que comprar um módulo ether pra um chassis incompatível ou tendo versão incompatível do IOS: em ambos os casos a falha é na tomada de decisão e não no produto e pra lascar tudo, a placa > antiga não é mais fabricada... equivalente a precisar de um módulo para chassis antigo, ou módulo antigo para IOS antigo ter um hardware proprietário só torna tudo mais complicado porque as possibilidades de problema são as mesmas enquanto ter hardware convencional, você pode rapidamente conseguir outra placa compatível com o sistema, sem precisar negligenciar confiabilidade e na verdade o que costuma acontecer é você ter que trocar para um hardware melhor por exemplo, tirar uma `fxp` porque não é mais fabricada e colocar uma `em` enfim, são muitas variáveis a se > considerar quando se adota i386 numa rede desse porte. eu vejo mais vantagens do que desvantagens a desnvantagem é a menor vida útil de periféricos e também as partes móveis todas amenizadas amplamente com adoção de hardware de qualidade e se preferir com adoção de boards integradas pra implantação massiva, da até pra pedir pra uma FIC-Brasil da vida adaptar suas boards de thin client para maiore expansão e processamento se necessário for ainda pois comparando ao poder de processamento usualmente necessário as mesmas boards sem qualquer modificação atendem > Acredito ser pouco provável, mas se um dia a Cisco ou Juniper vierem a > ser seriamente ameçadas por i386, nesse ponto, penso que o mais provável é que tornem-se i386 (ou equivalente, amd64, etc) pois eles também sabem que a relação custo/benefício é melhor porém, isso leva tempo alias vários junipers são x86 já > No fim das contas o que os tomadores de decisão querem, é uma garantia > que caso alguma cagada aconteça, ela seja sanada o mais rapidamente > possível e que de preferência, ofereça muitas e muitas facilidades. concordo e pra isso já mencionei que há soluções aqui mesmo na lista já implantei ou instrui por telefone provedores inteiros a substituir cisco por mikrotik, inclusive fazendo bgp e pelo que sei continuam até hoje o provedor chegou a um tamanho X, a operadora resolveu entregar fast na porta do provedor, ele vai para uma solução baseada em hardware convencional isso é fato precise de bgp ou não devemos ter inumeros casos aqui como temos no gter > Eles não ligam se isso vai ser em Free, em Open, em Linux, em Cisco ou > Juniper. Eventualmente o fator preço pode ou não determinar a vitória > da solução X sobre a solução Y. concordo, tem que ter qualidade e viabilidade soluções baseadas em open source e hardware genérico podem ser assim é isso que tenho defendido apenas > Quanto a questão de aprender a mexer com a nova ferramenta > (i386+OS+Software que faz o roteamento) não acho seja um ponto tão > dificultador, pois como já diz o ditado, " a necessidade faz o homem". concordo e vou além, é muito mais fácil, a gama de documentação online, listas e historicos de listas e obter respostas direto dos desenvolvedores sem ter contratos grandes fechados, é só mais um fator favorável o indivíduo que fica fazendo route-map no cisco, vai amar fazer as mesmas coisas no openbgp ou openospf, simplesmente porque é mais inteligente o individuo que só souber openbgp e tiver q fazer no cisco ficará incomodado com a dificuldade desnecessária para alcançar objetivos simples e quem adotar tal solução consegue mais fácil, e provavelmente mais barato, free-lancers capacitados para mexer em open source, do que em cisco ou juniper, caso não tenha RH capacitado internamente > Se fossem usuários comuns, até seria um fator de peso, mas estamos > falando de técnicos. Basicamente a mensagem é: ou aprende ou tá > demitido. sim se conseguem aprender cisco e suas sintaxes não intuitivas que dirá de uma solução open source típica (não vale quagga) bom fds a todos ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
