Re: [FUG-BR] Freebsd + Quagga + BGP

2013-08-27 Por tôpico André Gustavo Neves Lopes
euvou montar um lab aqui com virtualbox e quagga e te envio
abraço.

On Tue, Aug 27, 2013 at 08:54:46AM -0300, Marco Aurelio wrote:
 Caro André,
 
 Obrigado pela atenção, tem como vc me mandar um pequeno exemplo ou site que
 explica como gerenciar pelo prefixo ?
 
 Mais uma vez agradeço a atenção recebida.
 
 Marco Aurélio Ventura da Silva
 marcoprod...@gmail.com
 Prodata Informática e Cadastro LTDA
 (33)3322-
 
 
 Em 26 de agosto de 2013 20:19, André Gustavo N. an...@mrx.com.br escreveu:
 
  Boa noite Renato,
 
  Eu conheço PBR, mas o que eu quis dizer, aproveitando o seu exemplo é que
  se vc pegar um /24 e anunciar com mais local-preference para o peer1
  escolher outro /24 e anunciar com mais local-preference para o peer2, e
  assim por diante, vai ter o mesmo resultado. Gerenciando o local-preference
  por prefixo, não por link.
 
  Se o link3 ficar saturado, você pode manobrar o tráfego tirando o
  local-preference dos prefixos que você tinha ajustado anteriormente.
  O balanceamento de tráfego para rotas com o mesmo custo (ECMP), depende de
  suporte no S.O. e isso é uma outra novela.
  No linux me disseram que funciona bem, no FreeBSD eu tive 1 milhão de
  problemas habilitando RADIX_MPATH e full routing com quagga.
  No OpenBSD eu já usei, e funciona bem.
 
  PBR é muito bacana, mas acho que não é pré requisito para funcionar o que
  o rapaz ali precisa =)
 
  Abraço!
 
  On Mon, Aug 26, 2013 at 06:39:18PM -0300, Renato Frederick wrote:
   On 8/26/2013 10:28 AM, André Gustavo N. Lopes wrote:
Bom dia Renato, eu não entendi muito bem a necessidade de PBR, não é
  só uma questão de ajustar os local-preference ?
   
On Sun, Aug 25, 2013 at 04:44:12PM -0300, Renato Frederick wrote:
  
   André,
  
   Boa Noite!
  
   Sobre o PBR, imagine isto
  
   link1 = 10mb
   link2 = 10mb
   link3 = 10mb
  
   Imagine, pra simplificar que você tem 3 blocos /24.
  
   redeA 10.0.0.0/24
   redeB 10.0.1.0/24
   redeC 10.0.2.0/24
  
   PBR seria o seguinte: Você falar que todo o tráfego da redeA sai pelo
   link1, todo trafego da redeB sai pelo link2 e todo tráfego da redeC pelo
   link3.
  
   Agora, imagine que o link3 está 100% usado, mas o link1 está 20% só.
  
   Se você for no BGP e falar que o link1 tem local-preference maior, TODAS
   as 3 redes, redeA, redeB, redeC, começaram a siar pelo link1. Então você
   não resolveu, apenas transferiu o problema do link3 pro link1.
  
   Com o PBR você faria o seguinte:
  
   Analisaria quais IP estão usando, por exemplo, 40% do link3.
  
   Daí, jogaria estes IP e SOMENTE eles para o link1.
  
   Então, o link1 que tinha 20%, vai ter agora 20 + 40 = 60% de uso.
   e o link3, que tinha 100%, vai ter só 60%.
  
   então ficou balanceado, 60% link1, 60% link3.
  
   Porém, imagina que o link1 caiu. sua regra está manual, você teria que
   entrar no firewall e mudar a regra.
  
   Com o PF + OPENBGPD você faz o seguinte que resolve.
  
   pega todas as redes(full rouring) aprendidas pelo BGP do link1 e poe na
   table do PF link1
  
   Faz o mesmo com o link2 e 3.
  
   E daí faz uma regra de fwd:
  
   pass out quick route-to ( em0 ip.remoto ) from { 10.0.0.0/24 } to
   link1 keep state
  
   assim, se o link1 cair, a table link1 estará vazia(já que o openbgpd
   não vai popular ela).
  
   isto é o que o cisco faz no bgp dele, você usa o bgp + estado da
   interface(fisica ou loopback). Se a interface cai, aquela origem é
   roteada para outra, usando pesos.
  
   então, em resumo, local-prefence redireciona TODAS as redes de origem,
   manipula só destino. Usando este esquema, você  manipula a origem
   também(com o route-to) e destino(com local-preference, weight, etc).
  
   No passado eu até perguntei isto aqui, acho que foi até o Patrick que
   falou algo sobre BATMAN, olha o link abaixo:
  
   http://www.fug.com.br/historico/html/freebsd/2008-11/msg00477.html
  
   Esta ideia dele de usar o pf + openbgpd foi muito legal, e me ajudou
   demais!!
  
   -
   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
 
 
 -
 Histórico: http://www.fug.com.br/historico/html/freebsd/
 Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


signature.asc
Description: Digital signature
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Re: [FUG-BR] squid e freebsd

2013-08-26 Por tôpico André Gustavo Neves Lopes
Boa noite Bruno,

Só pra eu ter certeza, quando você abre o site, sem passar pelo squid, 
funciona normal??

Att,

On Mon, Aug 26, 2013 at 09:43:27PM -0300, Bruno Teles wrote:
 Veja se alguém me ajuda, tenho diversos hosts funcionando como firewall
 em clientes, do 6... até o 9..., com squid do 3 ao 3.2. Alguns já estão
 em produção faz muito tempo e funcionam perfeitamente.
 
 Ocorre que de uns 4 meses pra cá, o site www.curitiba.pr.gov.br não abre
 mais em nenhum deles (funcionava antes, parou do nada, pra todos, no
 mesmo momento)
 
 Retorna erro de leitura, (60) operation timed out no squid, transparente
 ou não, tanto faz, o erro é o mesmo, pelo endereço ou por IP também
 tanto faz. No nat direto, funciona perfeitamente.
 
 São muitos clientes (uns 15), e todos tem conexões da GVT, mas algumas
 são fibra, outros (a maioria) adsl, mas não acho que tenha algo a ver
 com isso.
 
 Já verifiquei no ipfw e não tá parando nada, não é nada com ACL. As
 conexões são estabelecidas, mas morrem sem troca de dados.
 
 Obrigado a todos que puderem ajudar.
 
 Bruno
 
 
 -
 Histórico: http://www.fug.com.br/historico/html/freebsd/
 Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


signature.asc
Description: Digital signature
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd