Re: [FUG-BR] WHATS UP GOLD
Creio que a melhor opção é o colega fazer um laboratório e testar os produtos citados aqui, além do whats up. Tenho clientes com praticamente todas as ferramentas citadas aqui. Alguns preferem uma por ser gratuita e ter equipe para configurar e manter; OUtros preferem whats up que é instalável e configurável em meia dúzia de cliques; Outros usam ambos e por aí vai. Tecnicamente falando, todos são excelentes opções, fazem muito bem o trabalho. Se for avaliar soluções comerciais em seu teste, não se esqueça das ferramentas de gerenciamento da SolarWinds[1], são bacanas também [1]: www.solarwinds.com -- From: Wanderson Tinti wander...@bsd.com.br Sent: Tuesday, April 20, 2010 6:14 PM To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Subject: Re: [FUG-BR] WHATS UP GOLD Em 20 de abril de 2010 17:29, Marcos Kurten Michels kur...@matrix.com.brescreveu: Pesssoal, alguém já usou este programa www.whatsupgold.com ? Se sim, quanto custou ? Vale a pena ou o nagios é a melhor opção para monitoramento ? Marcos Ainda tem o OpenNMS. Temos dois WhatsUP monitorando pontos de clientes na rede, é massa pra por no telão. Boa ferramenta, mas essas já citadas pelo pessoal são ainda melhores, sem dúvida. - 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] [Meio-off] OpenBGPD + carp
Pessoal, Apesar de ser meio off, mas como sempre rola assunto relativo a BGP e afins aqui, vamos lá.. :) Andei migrando o quagga para o openbgpd, sem maiores complicações, porém o motivo desta migração é a integração com o carp. Para fazê-lo encontrei algumas opções: 1 - Subir o peer com a flag depend on carpX[1] e local-address, sendo a carpX a interface que é conectada ao ISP e local-address o IP de loopback(que antes ficava la lo0 mas agora é atrelado a uma interface carp); 2 - Subir 2 sessões com o ISP[2]; 3 - Fazer um ibgp[3].; Pelos testes, a opção 1 parece ser a mais simples e efetiva. Se alguém tem este cenário, poderia trocar as experiências de qual opção usa e qual trabalha melhor? Abraços [1]: http://www.mail-archive.com/m...@openbsd.org/msg88193.html [2]http://www.mail-archive.com/m...@openbsd.org/msg81336.html [3]: http://www.openbsd.org/papers/linuxtag06-network.pdf [4]: http://69.64.6.24/index.php/OpenBGPD_package - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [Meio-off] OpenBGPD + carp
Renato Frederick wrote: Pessoal, Apesar de ser meio off, mas como sempre rola assunto relativo a BGP e afins aqui, vamos lá.. :) Andei migrando o quagga para o openbgpd, sem maiores complicações, porém o motivo desta migração é a integração com o carp. Para fazê-lo encontrei algumas opções: 1 - Subir o peer com a flag depend on carpX[1] e local-address, sendo a carpX a interface que é conectada ao ISP e local-address o IP de loopback(que antes ficava la lo0 mas agora é atrelado a uma interface carp); 2 - Subir 2 sessões com o ISP[2]; 3 - Fazer um ibgp[3].; Pelos testes, a opção 1 parece ser a mais simples e efetiva. Se alguém tem este cenário, poderia trocar as experiências de qual opção usa e qual trabalha melhor? Abraços Todas as opcoes sao efetivas ;-) Mas a 3 por exemplo é um saco. O proprio autor do OpenBGP sugere cenarios com iBGP. Eu evito. Eu faco a Opcao 2. Mantenho 2 peering simultaneos com cada operadora, dou prepend-self +2 no de backup e localpref -10 no de backup tambem. Ai coloco carp na(s) interface(s) LAN do cliente. Dessa forma, nao tenho carp na WAN. Por outro lado todos os peerings no BGP master tem depend on carp0 pois se por algum motivo o carp virar pra outra maquina, e a master não travou por inteiro, preciso garantir que todos os peers passem a trafegar exclusivamente pelo outro BGP. Afinal la que esta a LAN. So que tem nuances. Em alguns setups com as operadoras o Cisco dos camarada piram o cabecão ao ter 2 sessões BGP com mesmo AS, mesmos anuncios, em IPs diferente e tendem a dar bixeira. Com Juniper ou outro OpenBGP isso nao gera problema. Pra corrigir indico pra operadora por nexthop 2 no Cisco delas. Se voce fizer a opcao #1 nao fica transparente. Na falha do MASTER o seu BGP BACKUP tem que anunciar e receber as rotas do peering. O que pode ser ate OK se voce so tem um peering, afinal enquanto as rotas não chegam voce vai de default route static e a demora se limita ao seu anuncio (seus CIDR) estabelecer com a outra ponta. Mas se voce tem varios peers, esperar todos eles fechar, anunciar pra todos, receber os full ou partial de todos, e depender de um default route static que provavelmente vai congestionar seu nexthop default por alguns minutos ate a putaria acabar e todas as rotas forem recebidas, vai gerar transtorno. A opcao #3 é a mais chata de manter, mas é a mais funcional. Só depende de você, não tem nuances que dependam de você ensinar o que tem que ser feito pro seu upstream, e tem efeito imediato (sem janela de default route). No tempo do Carp. Seus clientes podem nem sacar que o BGP Master falhou. Além disso é a opcão mais clean. Ja que BGP é um protocolo projetado pra ser hierárquico, e não paralelo. Eu vou de #1, mas #1 do meu jeito, com carp só na LAN e os peerings dependendo desse carp. Se voce for por carp nas interfaces WAN nao adianta nada. Da na mesma que a opcao #2 pois seu upstream vai fazer peering com apenas 1 IP, o virtual (carp), e ao falhar o CARP BACKUP tera que receber de novo as rotas e enviar os seus anuncios. Eu nunca implantei desse jeito pois quando pensei ja vi que nao seria uma boa. Sei que teriam outros problemas, alguns dos poucos eu ja previ, como a necessidade de dar um clear quando o backup assumir, pra ele informar o peer que é pra comecar de novo pois simplesmente mudar de IP o upstream vai se negar a reenviar as rotas, ele nao vai perceber que voce nao recebeu, vai ficar fora de sync vai dar uma lambanca só. Eu tenho apenas um cenario com o setup #3 e o resto é #1 do meu jeito, como descrito. E a proposito, faz bem em se livrar dessa caca. Digo, quagga hehehe. Sei que seu costume com cisco-like inclinava ao cavalo branco listrado, mas esse cavalo é manco. Quando voce usar pftables pela primeira vez e tuxar um route-to so na table que o OpenBGP popula dinamicamente pra voce, ou um probability com route-to e keep-state so praquele dado AS, voce vai estar feliz por estar no OpenBGP. Se bem que trocar uma penca de permit X e route map out por um único set X no neighbor ja é bacana hehe. Pode ser besteira em cenarios pequenos, mas quando voce passa a ter muitos neighbors e fazer transito com muitos outros peers, so Deus sabe como é bom poder fazer todas as coisas com 1 linha ou 1 match de filtro. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [Meio-off] OpenBGPD + carp
Eu não tenho experiencia com BGP somente em labs. Eu queria saber se o OpenBGPD é melhor que o Quagga ?? Esse deamon já acompanha o bsd faz tempo, eu uso muito o openospfd no lugar do quagga, e não tenho problemas.. Att. 2010/4/21 Patrick Tracanelli eks...@freebsdbrasil.com.br Renato Frederick wrote: Pessoal, Apesar de ser meio off, mas como sempre rola assunto relativo a BGP e afins aqui, vamos lá.. :) Andei migrando o quagga para o openbgpd, sem maiores complicações, porém o motivo desta migração é a integração com o carp. Para fazê-lo encontrei algumas opções: 1 - Subir o peer com a flag depend on carpX[1] e local-address, sendo a carpX a interface que é conectada ao ISP e local-address o IP de loopback(que antes ficava la lo0 mas agora é atrelado a uma interface carp); 2 - Subir 2 sessões com o ISP[2]; 3 - Fazer um ibgp[3].; Pelos testes, a opção 1 parece ser a mais simples e efetiva. Se alguém tem este cenário, poderia trocar as experiências de qual opção usa e qual trabalha melhor? Abraços Todas as opcoes sao efetivas ;-) Mas a 3 por exemplo é um saco. O proprio autor do OpenBGP sugere cenarios com iBGP. Eu evito. Eu faco a Opcao 2. Mantenho 2 peering simultaneos com cada operadora, dou prepend-self +2 no de backup e localpref -10 no de backup tambem. Ai coloco carp na(s) interface(s) LAN do cliente. Dessa forma, nao tenho carp na WAN. Por outro lado todos os peerings no BGP master tem depend on carp0 pois se por algum motivo o carp virar pra outra maquina, e a master não travou por inteiro, preciso garantir que todos os peers passem a trafegar exclusivamente pelo outro BGP. Afinal la que esta a LAN. So que tem nuances. Em alguns setups com as operadoras o Cisco dos camarada piram o cabecão ao ter 2 sessões BGP com mesmo AS, mesmos anuncios, em IPs diferente e tendem a dar bixeira. Com Juniper ou outro OpenBGP isso nao gera problema. Pra corrigir indico pra operadora por nexthop 2 no Cisco delas. Se voce fizer a opcao #1 nao fica transparente. Na falha do MASTER o seu BGP BACKUP tem que anunciar e receber as rotas do peering. O que pode ser ate OK se voce so tem um peering, afinal enquanto as rotas não chegam voce vai de default route static e a demora se limita ao seu anuncio (seus CIDR) estabelecer com a outra ponta. Mas se voce tem varios peers, esperar todos eles fechar, anunciar pra todos, receber os full ou partial de todos, e depender de um default route static que provavelmente vai congestionar seu nexthop default por alguns minutos ate a putaria acabar e todas as rotas forem recebidas, vai gerar transtorno. A opcao #3 é a mais chata de manter, mas é a mais funcional. Só depende de você, não tem nuances que dependam de você ensinar o que tem que ser feito pro seu upstream, e tem efeito imediato (sem janela de default route). No tempo do Carp. Seus clientes podem nem sacar que o BGP Master falhou. Além disso é a opcão mais clean. Ja que BGP é um protocolo projetado pra ser hierárquico, e não paralelo. Eu vou de #1, mas #1 do meu jeito, com carp só na LAN e os peerings dependendo desse carp. Se voce for por carp nas interfaces WAN nao adianta nada. Da na mesma que a opcao #2 pois seu upstream vai fazer peering com apenas 1 IP, o virtual (carp), e ao falhar o CARP BACKUP tera que receber de novo as rotas e enviar os seus anuncios. Eu nunca implantei desse jeito pois quando pensei ja vi que nao seria uma boa. Sei que teriam outros problemas, alguns dos poucos eu ja previ, como a necessidade de dar um clear quando o backup assumir, pra ele informar o peer que é pra comecar de novo pois simplesmente mudar de IP o upstream vai se negar a reenviar as rotas, ele nao vai perceber que voce nao recebeu, vai ficar fora de sync vai dar uma lambanca só. Eu tenho apenas um cenario com o setup #3 e o resto é #1 do meu jeito, como descrito. E a proposito, faz bem em se livrar dessa caca. Digo, quagga hehehe. Sei que seu costume com cisco-like inclinava ao cavalo branco listrado, mas esse cavalo é manco. Quando voce usar pftables pela primeira vez e tuxar um route-to so na table que o OpenBGP popula dinamicamente pra voce, ou um probability com route-to e keep-state so praquele dado AS, voce vai estar feliz por estar no OpenBGP. Se bem que trocar uma penca de permit X e route map out por um único set X no neighbor ja é bacana hehe. Pode ser besteira em cenarios pequenos, mas quando voce passa a ter muitos neighbors e fazer transito com muitos outros peers, so Deus sabe como é bom poder fazer todas as coisas com 1 linha ou 1 match de filtro. - 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] [Meio-off] OpenBGPD + carp
Olá Patrick Abraços Todas as opcoes sao efetivas ;-) Mas a 3 por exemplo é um saco. O proprio autor do OpenBGP sugere cenarios com iBGP. Eu evito. iBGP é coisa que a gente só faz na vida quando tem que tirar certificação cisco ou trabalha em uma operadora de Internet com cenários diversificados. Fora isto evito :) Eu faco a Opcao 2. Mantenho 2 peering simultaneos com cada operadora, dou prepend-self +2 no de backup e localpref -10 no de backup tambem. Ai coloco carp na(s) interface(s) LAN do cliente. Dessa forma, nao tenho carp na WAN. Por outro lado todos os peerings no BGP master tem depend on carp0 pois se por algum motivo o carp virar pra outra maquina, e a master não travou por inteiro, preciso garantir que todos os peers passem a trafegar exclusivamente pelo outro BGP. Afinal la que esta a LAN. Correto. No meu caso ainda tenho que ver como faria pois o servidor em questão tem clientes em várias interfaces carp, não tem só carp0(WAN) e carp1. Tem outras interfaces atendendo a diferentes perfis de cliente. Aliás coisa que o carp não funciona correto aqui: carp0(WAN)-bge0 carp1(LAN) - bge1 carp2(DMZ) - bge2 FIREWALL1 (MASTER) FIREWALL2(BACK) Suponha que somente o cabo que liga a bge2 do firewall1 quebre. Neste hora o carp vai entrar em ação na carp2 e vai eleger firewall2 como master. ficaremos então com: carp0 - firewall1 - master carp1 - firewall1 - master carp2 - firewall2 - master Então o pacote da DMZ vai chegar para o firewall2(master), mas porém é o firewall1 que está com a carp0 ativa na WAN. Aì neste ponto o pacote se perde :( Da mesma maneira, um pacote na Internet vai chegar pela WAN para o firewall1(MASTER), mas ele não enxerga mais a DMZ, porque o carp2 nele está slave. Só funciona neste caso se colocar carp0/1/2 como slave em firewall1, aí tudo funciona pelo 2. So que tem nuances. Em alguns setups com as operadoras o Cisco dos camarada piram o cabecão ao ter 2 sessões BGP com mesmo AS, mesmos anuncios, em IPs diferente e tendem a dar bixeira. Com Juniper ou outro OpenBGP isso nao gera problema. Pra corrigir indico pra operadora por nexthop 2 no Cisco delas. Então, o problema é fazer algumas operadoras, que já demoraram 8 meses para ativar 1 sessão BGP fazer a alteração :) Aliás, poucas são as operadoras que fecham o BGP usando mais de um IP do lado deles, grande maioria fecha no endereço WAN e pronto. Se voce fizer a opcao #1 nao fica transparente. Na falha do MASTER o seu BGP BACKUP tem que anunciar e receber as rotas do peering. O que pode ser ate OK se voce so tem um peering, afinal enquanto as rotas não chegam voce vai de default route static e a demora se limita ao seu anuncio (seus CIDR) estabelecer com a outra ponta. Mas se voce tem varios peers, esperar todos eles fechar, anunciar pra todos, receber os full ou partial de todos, e depender de um default route static que provavelmente vai congestionar seu nexthop default por alguns minutos ate a putaria acabar e todas as rotas forem recebidas, vai gerar transtorno. Vi uma discussão destas que a pessoa queria mudar os tempos padrão do openbgp para garantir que em caso de falha o openbgp subisse no backup mais rápido que o padrão. Talvez ajude A opcao #3 é a mais chata de manter, mas é a mais funcional. Só depende de você, não tem nuances que dependam de você ensinar o que tem que ser feito pro seu upstream, e tem efeito imediato (sem janela de default route). No tempo do Carp. Seus clientes podem nem sacar que o BGP Master falhou. Vou analisá-la com mais atenção, quem sabe... Além disso é a opcão mais clean. Ja que BGP é um protocolo projetado pra ser hierárquico, e não paralelo. Eu vou de #1, mas #1 do meu jeito, com carp só na LAN e os peerings dependendo desse carp. Se voce for por carp nas interfaces WAN nao adianta nada. Da na mesma que a opcao #2 pois seu upstream vai fazer peering com apenas 1 IP, o virtual (carp), e ao falhar o CARP BACKUP tera que receber de novo as rotas e enviar os seus anuncios. Eu nunca implantei desse jeito pois quando pensei ja vi que nao seria uma boa. Sei que teriam outros problemas, alguns dos poucos eu ja previ, como a necessidade de dar um clear quando o backup assumir, pra ele informar o peer que é pra comecar de novo pois simplesmente mudar de IP o upstream vai se negar a reenviar as rotas, ele nao vai perceber que voce nao recebeu, vai ficar fora de sync vai dar uma lambanca só. :-/ Pensei que ele era esperto o suficiente para no BACKUP fazer algo do tipo clear ip bgp * , que sobe a sessão toda. Tem outro porém também, ficar fazendo isto vai contar pontos e pode colocar o AS como dampened Eu tenho apenas um cenario com o setup #3 e o resto é #1 do meu jeito, como descrito. E a proposito, faz bem em se livrar dessa caca. Digo, quagga hehehe. Sei que seu costume com cisco-like inclinava ao cavalo branco listrado, mas esse cavalo é manco. Tadinho, o quagga é gente boa, hehehhee, só me deu dor de
Re: [FUG-BR] [Meio-off] OpenBGPD + carp
Olá Fabrício. Não é questão de ser melhor ou não, os 2 cumprem o trabalho a que se propõem muito bem :) Porém, como tudo em TI, algumas coisas se adequam melhor do que outras: Por exemplo, o quagga não tem integração com carp ou qualquer tipo de redundância compatível com o carp. O openbgpd já tem isto integrado, além de oferecer alguns recursos a mais para integração com o PF(afinal é tudo da mesma equipe, openbgpd, openospfd, carp, pf...) -- From: Fabricio Archanjo farcha...@gmail.com Sent: Wednesday, April 21, 2010 4:56 PM To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Subject: Re: [FUG-BR] [Meio-off] OpenBGPD + carp Eu não tenho experiencia com BGP somente em labs. Eu queria saber se o OpenBGPD é melhor que o Quagga ?? Esse deamon já acompanha o bsd faz tempo, eu uso muito o openospfd no lugar do quagga, e não tenho problemas.. Att. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [Meio-off] OpenBGPD + carp
Se voce fizer a opcao #1 nao fica transparente. Na falha do MASTER o seu BGP BACKUP tem que anunciar e receber as rotas do peering. O que pode ser ate OK se voce so tem um peering, afinal enquanto as rotas não chegam voce vai de default route static e a demora se limita ao seu anuncio (seus CIDR) estabelecer com a outra ponta. Mas se voce tem varios peers, esperar todos eles fechar, anunciar pra todos, receber os full ou partial de todos, e depender de um default route static que provavelmente vai congestionar seu nexthop default por alguns minutos ate a putaria acabar e todas as rotas forem recebidas, vai gerar transtorno. Pesquisando um pouco mais, achei esta interessante discussão[1], o trecho abaixo: with the carp integration, bgpd will keep all bgp sessions marked as depending on a particular carp interface in IDLE, and once the carp interface becomes master they immediately go to CONNECT (or ACTIVE for passive sessions), reduncing the failover time muchos. Acho que resolveria, não? NÃO declarar no bgpd.conf a sessão como passive. no firewall BACKUP vai ficar IDLE a sessão BGP. Quando ele virar MASTER, vai mandar comando CONNECT para a operadora. Se a operadora não tiver muita frescura, ela vai entender que a sessão caiu(Já que foi enviando um connect pra lá), vai ficar como active e depois established e vai enviar as rotas. Se ela recusar isto, vai mandar a conexão de novo pro state IDLE, talvez dê certo. [1]: http://monkey.org/openbsd/archive/misc/0411/msg03661.html - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
