Re: [FUG-BR] Freebsd + Quagga + BGP
Eu andei procurando um exemplo nas apresentações do GTER, já que faz um bom tempo que não mexo com BGP. Mas o anúncio de rota parcial é pra link multihoming, com diferente ISPs no uplink (no mínimo 2), criando uma regra de anúncio pra cada AS. Como no caso é o mesmo AS, talvez através do route-map, mas não sei se funcionaria da mesma forma. Entretanto, isso não vai importar, pois o ISP em que troca tráfego é sempre o mesmo. Vc pode tentar colocar peso até com route-path que deve funcionar. Não seria melhor rodar OSPF com o ISP? Abs, Helio Loureiro http://helio.loureiro.eng.br http://br.linkedin.com/in/helioloureiro http://twitter.com/helioloureiro http://gplus.to/helioloureiro Em 28 de agosto de 2013 15:16, Marco Aurelio marcoprod...@gmail.comescreveu: Caro Helio, Teria como vc postar um exemplo ? Marco Aurélio Ventura da Silva marcoprod...@gmail.com Prodata Informática e Cadastro LTDA (33)3322- Em 27 de agosto de 2013 14:31, Helio Loureiro he...@loureiro.eng.br escreveu: Oi, Anuncia os /24 em cada interface e o /22 em todas elas pra ter redundância e ter certeza que os pacotes enviados por uma interface vai voltar pela mesma. Abs, Helio Loureiro http://helio.loureiro.eng.br http://br.linkedin.com/in/helioloureiro http://twitter.com/helioloureiro http://gplus.to/helioloureiro Em 27 de agosto de 2013 10:20, Marco Aurelio marcoprod...@gmail.com escreveu: Caro André, Muito obrigado mais uma vez e no aguardo. Marco Aurélio Ventura da Silva marcoprod...@gmail.com Prodata Informática e Cadastro LTDA (33)3322- Em 27 de agosto de 2013 13:11, André Gustavo Neves Lopes an...@mrx.com.brescreveu: 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
Re: [FUG-BR] Freebsd + Quagga + BGP
Caro Helio,
Teria como vc postar um exemplo ?
Marco Aurélio Ventura da Silva
marcoprod...@gmail.com
Prodata Informática e Cadastro LTDA
(33)3322-
Em 27 de agosto de 2013 14:31, Helio Loureiro he...@loureiro.eng.brescreveu:
Oi,
Anuncia os /24 em cada interface e o /22 em todas elas pra ter redundância
e ter certeza que os pacotes enviados por uma interface vai voltar pela
mesma.
Abs,
Helio Loureiro
http://helio.loureiro.eng.br
http://br.linkedin.com/in/helioloureiro
http://twitter.com/helioloureiro
http://gplus.to/helioloureiro
Em 27 de agosto de 2013 10:20, Marco Aurelio marcoprod...@gmail.com
escreveu:
Caro André,
Muito obrigado mais uma vez e no aguardo.
Marco Aurélio Ventura da Silva
marcoprod...@gmail.com
Prodata Informática e Cadastro LTDA
(33)3322-
Em 27 de agosto de 2013 13:11, André Gustavo Neves Lopes
an...@mrx.com.brescreveu:
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
Re: [FUG-BR] Freebsd + Quagga + BGP
- Original Message -
From: Marco Aurelio marcoprod...@gmail.com
To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
freebsd@fug.com.br
Sent: Wednesday, August 28, 2013 3:16 PM
Subject: Re: [FUG-BR] Freebsd + Quagga + BGP
Em 27 de agosto de 2013 14:31, Helio Loureiro
he...@loureiro.eng.brescreveu:
Oi,
Anuncia os /24 em cada interface e o /22 em todas elas pra ter redundância
e ter certeza que os pacotes enviados por uma interface vai voltar pela
mesma.
Abs,
Helio Loureiro
http://helio.loureiro.eng.br
http://br.linkedin.com/in/helioloureiro
http://twitter.com/helioloureiro
http://gplus.to/helioloureiro
Em 27 de agosto de 2013 10:20, Marco Aurelio marcoprod...@gmail.com
escreveu:
Caro André,
Muito obrigado mais uma vez e no aguardo.
Marco Aurélio Ventura da Silva
marcoprod...@gmail.com
Prodata Informática e Cadastro LTDA
(33)3322-
Em 27 de agosto de 2013 13:11, André Gustavo Neves Lopes
an...@mrx.com.brescreveu:
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
Re: [FUG-BR] Freebsd + Quagga + BGP
Em 26/08/13 20:19, André Gustavo N. Lopes 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! Opa! Bacana André! De fato, sua abordagem por prefixo vai funcionar e bem mais simples que a minha :) Por isto que é bom trocar ideias, a gente entende de outra perspectiva! Não sei porque eu comecei com PBR, talvez eu tenha entendido errado o que o amigo precisava! Sobre o RADIX, você me fez recordar um histórico da lista[1], hehehe Netes casos, é openbsd mesmo, eu também tentei brincar com RADIX e só tive dor de cabeça!!! [1] http://www.fug.com.br/historico/html/freebsd/2012-02/msg00179.html - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Freebsd + Quagga + BGP
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
Re: [FUG-BR] Freebsd + Quagga + BGP
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] Freebsd + Quagga + BGP
Caro André,
Muito obrigado mais uma vez e no aguardo.
Marco Aurélio Ventura da Silva
marcoprod...@gmail.com
Prodata Informática e Cadastro LTDA
(33)3322-
Em 27 de agosto de 2013 13:11, André Gustavo Neves Lopes
an...@mrx.com.brescreveu:
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
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
-
Re: [FUG-BR] Freebsd + Quagga + BGP
Oi,
Anuncia os /24 em cada interface e o /22 em todas elas pra ter redundância
e ter certeza que os pacotes enviados por uma interface vai voltar pela
mesma.
Abs,
Helio Loureiro
http://helio.loureiro.eng.br
http://br.linkedin.com/in/helioloureiro
http://twitter.com/helioloureiro
http://gplus.to/helioloureiro
Em 27 de agosto de 2013 10:20, Marco Aurelio marcoprod...@gmail.comescreveu:
Caro André,
Muito obrigado mais uma vez e no aguardo.
Marco Aurélio Ventura da Silva
marcoprod...@gmail.com
Prodata Informática e Cadastro LTDA
(33)3322-
Em 27 de agosto de 2013 13:11, André Gustavo Neves Lopes
an...@mrx.com.brescreveu:
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:
Re: [FUG-BR] Freebsd + Quagga + BGP
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: Em 23/08/13 15:25, Marco Aurelio escreveu: Olá pessoal, precisando da ajuda de vocês, pois estou meio perdido nessa configurações. Sou iniciante no assunto, já peço desculpas se estiver no cominho errado. Meu cenário é este ... OPERADORAMEU PROVEDOR AS 1234 10.1/30 --- LINK1 18881 - RECEBENDO UM /30 -- 192.168.10.2/30 20.1/30 --- LINK2 18881 - RECEBENDO UM /30 -- 192.168.20.2/30 30.1/30 --- LINK3 18881 - RECEBENDO UM /30 -- 192.168.30.2/30 40.1/30 --- LINK4 18881 - RECEBENDO UM /30 -- 192.168.40.2/30 São 4 links da mesma operadora, porém não posso somar os links, preciso fechar 4 sessões bgp, são 4 placas de redes recebendo os ips em uma máquina apenas. Que loucura, que operadora é esta que entrega 4 links ethernet ao invés de um só? Gambiarra Pense no seguinte, você vai ter que fazer PBR para definir quais redes de origem vão usar cada um dos links, de modo que você possa tentar otimizar a vazão. Acho que fazer isto com o quagga é meio chato, no passado eu tentei mas larguei mão e fui para openbgpd + PFTABLES, de modo que eu, associando com o openbgpd, posso falar quais blocos /24 da minha rede sairão por cada sessão bgp fechada. Mas no seu caso, eu tenho certeza que vai ser trabalhoso, pode ser que um dia um link tenha menos uso porque aquele perfil de cliente não está usando, ai você vai ter que mudar os filtros.. Qual o motivo da operadora entregar 4 links ao invés de um só? Alguma limitação de equipamento? - 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] Freebsd + Quagga + BGP
Obrigado André pela atençao, fiz o que vc sugeriu , olha como ficou Está correto ? bgp multiple-instance ! router bgp 65531 bgp router-id 192.168.5.2 neighbor todos peer-group neighbor todos remote-as 65530 bgp log-neighbor-changes !no bgp default ipv4-unicast network 192.168.0.0/22 redistribute connected redistribute ospf - está habilitado pq montei um RB450 para simular a operadora. neighbor todos next-hop-self neighbor todos description GWs neighbor todos soft-reconfiguration inbound neighbor todos ebgp-multihop 4 neighbor todos update-source 192.168.5.2 neighbor todos route-map gw1out out neighbor todos activate neighbor 10.10.1.1 peer-group todos - Fechando os peers com a operadora neighbor 10.10.2.1 peer-group todos neighbor 10.10.3.1 peer-group todos neighbor 10.10.4.1 peer-group todos ip prefix-list gw1_p_out seq 5 permit 192.168.0.0/22 route-map gw1out permit 5 match ip address prefix-list gw1_p_out O problema é que dessa forma todo o tráfego está saindo apenas por um Link, o que preciso é balancear igualmente o meu download, são quatro link de 100 em cada sessão bgp, quando faço esse anuncio /22, ele ta escolhendo um link e saindo tudo apenas em 100mb Marco Aurélio Ventura da Silva marcoprod...@gmail.com Prodata Informática e Cadastro LTDA (33)3322- Em 26 de agosto de 2013 10:28, André Gustavo N. an...@mrx.com.br escreveu: 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: Em 23/08/13 15:25, Marco Aurelio escreveu: Olá pessoal, precisando da ajuda de vocês, pois estou meio perdido nessa configurações. Sou iniciante no assunto, já peço desculpas se estiver no cominho errado. Meu cenário é este ... OPERADORAMEU PROVEDOR AS 1234 10.1/30 --- LINK1 18881 - RECEBENDO UM /30 -- 192.168.10.2/30 20.1/30 --- LINK2 18881 - RECEBENDO UM /30 -- 192.168.20.2/30 30.1/30 --- LINK3 18881 - RECEBENDO UM /30 -- 192.168.30.2/30 40.1/30 --- LINK4 18881 - RECEBENDO UM /30 -- 192.168.40.2/30 São 4 links da mesma operadora, porém não posso somar os links, preciso fechar 4 sessões bgp, são 4 placas de redes recebendo os ips em uma máquina apenas. Que loucura, que operadora é esta que entrega 4 links ethernet ao invés de um só? Gambiarra Pense no seguinte, você vai ter que fazer PBR para definir quais redes de origem vão usar cada um dos links, de modo que você possa tentar otimizar a vazão. Acho que fazer isto com o quagga é meio chato, no passado eu tentei mas larguei mão e fui para openbgpd + PFTABLES, de modo que eu, associando com o openbgpd, posso falar quais blocos /24 da minha rede sairão por cada sessão bgp fechada. Mas no seu caso, eu tenho certeza que vai ser trabalhoso, pode ser que um dia um link tenha menos uso porque aquele perfil de cliente não está usando, ai você vai ter que mudar os filtros.. Qual o motivo da operadora entregar 4 links ao invés de um só? Alguma limitação de equipamento? - 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
Re: [FUG-BR] Freebsd + Quagga + BGP
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
Re: [FUG-BR] Freebsd + Quagga + BGP
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
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] Freebsd + Quagga + BGP
Em 23/08/13 15:25, Marco Aurelio escreveu: Olá pessoal, precisando da ajuda de vocês, pois estou meio perdido nessa configurações. Sou iniciante no assunto, já peço desculpas se estiver no cominho errado. Meu cenário é este ... OPERADORAMEU PROVEDOR AS 1234 10.1/30 --- LINK1 18881 - RECEBENDO UM /30 -- 192.168.10.2/30 20.1/30 --- LINK2 18881 - RECEBENDO UM /30 -- 192.168.20.2/30 30.1/30 --- LINK3 18881 - RECEBENDO UM /30 -- 192.168.30.2/30 40.1/30 --- LINK4 18881 - RECEBENDO UM /30 -- 192.168.40.2/30 São 4 links da mesma operadora, porém não posso somar os links, preciso fechar 4 sessões bgp, são 4 placas de redes recebendo os ips em uma máquina apenas. Que loucura, que operadora é esta que entrega 4 links ethernet ao invés de um só? Gambiarra Pense no seguinte, você vai ter que fazer PBR para definir quais redes de origem vão usar cada um dos links, de modo que você possa tentar otimizar a vazão. Acho que fazer isto com o quagga é meio chato, no passado eu tentei mas larguei mão e fui para openbgpd + PFTABLES, de modo que eu, associando com o openbgpd, posso falar quais blocos /24 da minha rede sairão por cada sessão bgp fechada. Mas no seu caso, eu tenho certeza que vai ser trabalhoso, pode ser que um dia um link tenha menos uso porque aquele perfil de cliente não está usando, ai você vai ter que mudar os filtros.. Qual o motivo da operadora entregar 4 links ao invés de um só? Alguma limitação de equipamento? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Freebsd + Quagga + BGP
Olá pessoal, precisando da ajuda de vocês, pois estou meio perdido nessa configurações. Sou iniciante no assunto, já peço desculpas se estiver no cominho errado. Meu cenário é este ... OPERADORAMEU PROVEDOR AS 1234 10.1/30 --- LINK1 18881 - RECEBENDO UM /30 -- 192.168.10.2/30 20.1/30 --- LINK2 18881 - RECEBENDO UM /30 -- 192.168.20.2/30 30.1/30 --- LINK3 18881 - RECEBENDO UM /30 -- 192.168.30.2/30 40.1/30 --- LINK4 18881 - RECEBENDO UM /30 -- 192.168.40.2/30 São 4 links da mesma operadora, porém não posso somar os links, preciso fechar 4 sessões bgp, são 4 placas de redes recebendo os ips em uma máquina apenas. Utilizo quagga, minha configuração está da seguinte forma. Ja possuo meu próprio as /22, no exemplo ele é o 192.168.0.0/22 --- bgp multiple-instance ! router bgp 1234 bgp router-id 10.0.0.1 bgp log-neighbor-changes !no bgp default ipv4-unicast network 192.168.0.0/22 --- DUVIDA, posso divulgar o /22 nas quatro sessões bgp, ou vou ter que quebrar esse /22 em quatro /254 ?? redistribute connected ! redistribute static redistribute ospf neighbor 192.168.10.1 remote-as 18881 neighbor 192.168.10.1 next-hop-self neighbor 192.168.10.1 description GW1 neighbor 192.168.10.1 soft-reconfiguration inbound neighbor 192.168.10.1 ebgp-multihop 4 neighbor 192.168.10.1 update-source 192.168.10.2 neighbor 192.168.10.1 prefix-list gw1_p_out out neighbor 192.168.10.1 route-map gw1in in neighbor 192.168.10.1 route-map gw1out out neighbor 192.168.10.1 default-originate neighbor 192.168.10.1 activate neighbor 192.168.20.1 remote-as 18881 neighbor 192.168.20.1 next-hop-self neighbor 192.168.20.1 description GW2 neighbor 192.168.20.1 soft-reconfiguration inbound neighbor 192.168.20.1 ebgp-multihop 4 neighbor 192.168.20.1 update-source 192.168.20.2 neighbor 192.168.20.1 prefix-list gw2_p_out out neighbor 192.168.20.1 route-map gw2in in neighbor 192.168.20.1 route-map gw2out out neighbor 192.168.20.1 default-originate neighbor 192.168.20.1 activate neighbor 192.168.30.1 remote-as 18881 neighbor 192.168.30.1 next-hop-self neighbor 192.168.30.1 description GW3 neighbor 192.168.30.1 soft-reconfiguration inbound neighbor 192.168.30.1 ebgp-multihop 4 neighbor 192.168.30.1 update-source 192.168.30.2 neighbor 192.168.30.1 prefix-list gw3_p_out out neighbor 192.168.30.1 route-map gw3in in neighbor 192.168.30.1 route-map gw3out out neighbor 192.168.30.1 default-originate neighbor 192.168.30.1 activate neighbor 192.168.40.1 remote-as 18881 neighbor 192.168.40.1 next-hop-self neighbor 192.168.40.1 description GW4 neighbor 192.168.40.1 soft-reconfiguration inbound neighbor 192.168.40.1 ebgp-multihop 4 neighbor 192.168.40.1 update-source 192.168.40.2 neighbor 192.168.40.1 prefix-list gw4_p_out out neighbor 192.168.40.1 route-map gw4in in neighbor 192.168.40.1 route-map gw4out out neighbor 192.168.40.1 default-originate neighbor 192.168.40.1 activate Acho que me confundi com esses configuração daki pra baixo, estou tentando priorizar as classes /24 sair pelos determinados gw`s, não sei se isso vai funcionar, pois coloquei o local-preference igual, minha intenção foi igualar os 4 links !GW1 ip prefix-list gw1_p_out seq 5 permit 192.168.0.0/24 route-map gw1out permit 5 match ip address prefix-list gw1_p_out set as-path prepend 1234 route-map gw1in permit 5 set local-preference 100 !GW2 ip prefix-list gw2_p_out seq 10 permit 192.168.1.0/24 route-map gw2out permit 10 match ip address prefix-list gw2_p_out set as-path prepend 1234 route-map gw2in permit 10 set local-preference 100 !GW3 ip prefix-list gw3_p_out seq 10 permit 192.168.2.0/24 route-map gw3out permit 10 match ip address prefix-list gw3_p_out set as-path prepend 1234 route-map gw3in permit 10 set local-preference 100 !GW4 ip prefix-list gw4_p_out seq 10 permit 192.168.2.0/24 route-map gw4out permit 10 match ip address prefix-list gw4_p_out set as-path prepend 1234 route-map gw4in permit 10 set local-preference 100 Preciso receber esses 4 links, serão 4 sessões de bgp full, em uma máquina apenas e divulgar meu asn 192.168.0.0/22 nos quatro bgp, balanceando esses links igualmente. Obs: são quatro links de 50m cada. Se alguém puder ajudar, agradeço muito. Marco Aurélio Ventura da Silva marcoprod...@gmail.com Prodata Informática e Cadastro LTDA (33)3322- - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Freebsd + Quagga + BGP
Boa tarde marcos Primeira coisa, se todos os seus peers, usam configs semelhantes, melhor você criar um peer-group, configurar tudo nele, e adicionar os peers a esse peer-group. Sim, você pode anunciar como você disse, mas uma das maneiras de influenciar o tráfego de entrada é anunciar prefixos mais específicos em alguns links. Se você vai anunciar as mesmas coisas para os 4 peers, é desnecessário criar uma prefix-list para cada também. Prepend é outra maneira de influenciar o tráfego de entrada, mas se você setar todos iguais, não vai fazer diferença. localpref é um jeito de escolher a saída, mas novamente, se estiverem todos iguais, não faz sentido também... Para anunciar pro seu peer, você escolhe, tem gente que faz com distribute-list, outros com route-map... On Fri, Aug 23, 2013 at 03:25:43PM -0300, Marco Aurelio wrote: Olá pessoal, precisando da ajuda de vocês, pois estou meio perdido nessa configurações. Sou iniciante no assunto, já peço desculpas se estiver no cominho errado. Meu cenário é este ... OPERADORAMEU PROVEDOR AS 1234 10.1/30 --- LINK1 18881 - RECEBENDO UM /30 -- 192.168.10.2/30 20.1/30 --- LINK2 18881 - RECEBENDO UM /30 -- 192.168.20.2/30 30.1/30 --- LINK3 18881 - RECEBENDO UM /30 -- 192.168.30.2/30 40.1/30 --- LINK4 18881 - RECEBENDO UM /30 -- 192.168.40.2/30 São 4 links da mesma operadora, porém não posso somar os links, preciso fechar 4 sessões bgp, são 4 placas de redes recebendo os ips em uma máquina apenas. Utilizo quagga, minha configuração está da seguinte forma. Ja possuo meu próprio as /22, no exemplo ele é o 192.168.0.0/22 --- bgp multiple-instance ! router bgp 1234 bgp router-id 10.0.0.1 bgp log-neighbor-changes !no bgp default ipv4-unicast network 192.168.0.0/22 --- DUVIDA, posso divulgar o /22 nas quatro sessões bgp, ou vou ter que quebrar esse /22 em quatro /254 ?? redistribute connected ! redistribute static redistribute ospf neighbor 192.168.10.1 remote-as 18881 neighbor 192.168.10.1 next-hop-self neighbor 192.168.10.1 description GW1 neighbor 192.168.10.1 soft-reconfiguration inbound neighbor 192.168.10.1 ebgp-multihop 4 neighbor 192.168.10.1 update-source 192.168.10.2 neighbor 192.168.10.1 prefix-list gw1_p_out out neighbor 192.168.10.1 route-map gw1in in neighbor 192.168.10.1 route-map gw1out out neighbor 192.168.10.1 default-originate neighbor 192.168.10.1 activate neighbor 192.168.20.1 remote-as 18881 neighbor 192.168.20.1 next-hop-self neighbor 192.168.20.1 description GW2 neighbor 192.168.20.1 soft-reconfiguration inbound neighbor 192.168.20.1 ebgp-multihop 4 neighbor 192.168.20.1 update-source 192.168.20.2 neighbor 192.168.20.1 prefix-list gw2_p_out out neighbor 192.168.20.1 route-map gw2in in neighbor 192.168.20.1 route-map gw2out out neighbor 192.168.20.1 default-originate neighbor 192.168.20.1 activate neighbor 192.168.30.1 remote-as 18881 neighbor 192.168.30.1 next-hop-self neighbor 192.168.30.1 description GW3 neighbor 192.168.30.1 soft-reconfiguration inbound neighbor 192.168.30.1 ebgp-multihop 4 neighbor 192.168.30.1 update-source 192.168.30.2 neighbor 192.168.30.1 prefix-list gw3_p_out out neighbor 192.168.30.1 route-map gw3in in neighbor 192.168.30.1 route-map gw3out out neighbor 192.168.30.1 default-originate neighbor 192.168.30.1 activate neighbor 192.168.40.1 remote-as 18881 neighbor 192.168.40.1 next-hop-self neighbor 192.168.40.1 description GW4 neighbor 192.168.40.1 soft-reconfiguration inbound neighbor 192.168.40.1 ebgp-multihop 4 neighbor 192.168.40.1 update-source 192.168.40.2 neighbor 192.168.40.1 prefix-list gw4_p_out out neighbor 192.168.40.1 route-map gw4in in neighbor 192.168.40.1 route-map gw4out out neighbor 192.168.40.1 default-originate neighbor 192.168.40.1 activate Acho que me confundi com esses configuração daki pra baixo, estou tentando priorizar as classes /24 sair pelos determinados gw`s, não sei se isso vai funcionar, pois coloquei o local-preference igual, minha intenção foi igualar os 4 links !GW1 ip prefix-list gw1_p_out seq 5 permit 192.168.0.0/24 route-map gw1out permit 5 match ip address prefix-list gw1_p_out set as-path prepend 1234 route-map gw1in permit 5 set local-preference 100 !GW2 ip prefix-list gw2_p_out seq 10 permit 192.168.1.0/24 route-map gw2out permit 10 match ip address prefix-list gw2_p_out set as-path prepend 1234 route-map gw2in permit 10 set local-preference 100 !GW3 ip prefix-list gw3_p_out seq 10 permit 192.168.2.0/24 route-map gw3out permit 10 match ip address prefix-list gw3_p_out set as-path prepend 1234 route-map gw3in permit 10 set local-preference 100 !GW4 ip prefix-list gw4_p_out seq 10 permit 192.168.2.0/24 route-map gw4out permit 10 match ip address prefix-list gw4_p_out set as-path prepend 1234 route-map gw4in permit
Re: [FUG-BR] Freebsd + Quagga + BGP
Caro André, Seria possível vc me mandar um exemplo de peer-group ? Desde já agradeço a atenção recebida. Marco Aurélio Ventura da Silva marcoprod...@gmail.com Prodata Informática e Cadastro LTDA (33)3322- Em 23 de agosto de 2013 17:06, André Gustavo N. an...@mrx.com.br escreveu: Boa tarde marcos Primeira coisa, se todos os seus peers, usam configs semelhantes, melhor você criar um peer-group, configurar tudo nele, e adicionar os peers a esse peer-group. Sim, você pode anunciar como você disse, mas uma das maneiras de influenciar o tráfego de entrada é anunciar prefixos mais específicos em alguns links. Se você vai anunciar as mesmas coisas para os 4 peers, é desnecessário criar uma prefix-list para cada também. Prepend é outra maneira de influenciar o tráfego de entrada, mas se você setar todos iguais, não vai fazer diferença. localpref é um jeito de escolher a saída, mas novamente, se estiverem todos iguais, não faz sentido também... Para anunciar pro seu peer, você escolhe, tem gente que faz com distribute-list, outros com route-map... On Fri, Aug 23, 2013 at 03:25:43PM -0300, Marco Aurelio wrote: Olá pessoal, precisando da ajuda de vocês, pois estou meio perdido nessa configurações. Sou iniciante no assunto, já peço desculpas se estiver no cominho errado. Meu cenário é este ... OPERADORAMEU PROVEDOR AS 1234 10.1/30 --- LINK1 18881 - RECEBENDO UM /30 -- 192.168.10.2/30 20.1/30 --- LINK2 18881 - RECEBENDO UM /30 -- 192.168.20.2/30 30.1/30 --- LINK3 18881 - RECEBENDO UM /30 -- 192.168.30.2/30 40.1/30 --- LINK4 18881 - RECEBENDO UM /30 -- 192.168.40.2/30 São 4 links da mesma operadora, porém não posso somar os links, preciso fechar 4 sessões bgp, são 4 placas de redes recebendo os ips em uma máquina apenas. Utilizo quagga, minha configuração está da seguinte forma. Ja possuo meu próprio as /22, no exemplo ele é o 192.168.0.0/22 --- bgp multiple-instance ! router bgp 1234 bgp router-id 10.0.0.1 bgp log-neighbor-changes !no bgp default ipv4-unicast network 192.168.0.0/22 --- DUVIDA, posso divulgar o /22 nas quatro sessões bgp, ou vou ter que quebrar esse /22 em quatro /254 ?? redistribute connected ! redistribute static redistribute ospf neighbor 192.168.10.1 remote-as 18881 neighbor 192.168.10.1 next-hop-self neighbor 192.168.10.1 description GW1 neighbor 192.168.10.1 soft-reconfiguration inbound neighbor 192.168.10.1 ebgp-multihop 4 neighbor 192.168.10.1 update-source 192.168.10.2 neighbor 192.168.10.1 prefix-list gw1_p_out out neighbor 192.168.10.1 route-map gw1in in neighbor 192.168.10.1 route-map gw1out out neighbor 192.168.10.1 default-originate neighbor 192.168.10.1 activate neighbor 192.168.20.1 remote-as 18881 neighbor 192.168.20.1 next-hop-self neighbor 192.168.20.1 description GW2 neighbor 192.168.20.1 soft-reconfiguration inbound neighbor 192.168.20.1 ebgp-multihop 4 neighbor 192.168.20.1 update-source 192.168.20.2 neighbor 192.168.20.1 prefix-list gw2_p_out out neighbor 192.168.20.1 route-map gw2in in neighbor 192.168.20.1 route-map gw2out out neighbor 192.168.20.1 default-originate neighbor 192.168.20.1 activate neighbor 192.168.30.1 remote-as 18881 neighbor 192.168.30.1 next-hop-self neighbor 192.168.30.1 description GW3 neighbor 192.168.30.1 soft-reconfiguration inbound neighbor 192.168.30.1 ebgp-multihop 4 neighbor 192.168.30.1 update-source 192.168.30.2 neighbor 192.168.30.1 prefix-list gw3_p_out out neighbor 192.168.30.1 route-map gw3in in neighbor 192.168.30.1 route-map gw3out out neighbor 192.168.30.1 default-originate neighbor 192.168.30.1 activate neighbor 192.168.40.1 remote-as 18881 neighbor 192.168.40.1 next-hop-self neighbor 192.168.40.1 description GW4 neighbor 192.168.40.1 soft-reconfiguration inbound neighbor 192.168.40.1 ebgp-multihop 4 neighbor 192.168.40.1 update-source 192.168.40.2 neighbor 192.168.40.1 prefix-list gw4_p_out out neighbor 192.168.40.1 route-map gw4in in neighbor 192.168.40.1 route-map gw4out out neighbor 192.168.40.1 default-originate neighbor 192.168.40.1 activate Acho que me confundi com esses configuração daki pra baixo, estou tentando priorizar as classes /24 sair pelos determinados gw`s, não sei se isso vai funcionar, pois coloquei o local-preference igual, minha intenção foi igualar os 4 links !GW1 ip prefix-list gw1_p_out seq 5 permit 192.168.0.0/24 route-map gw1out permit 5 match ip address prefix-list gw1_p_out set as-path prepend 1234 route-map gw1in permit 5 set local-preference 100 !GW2 ip prefix-list gw2_p_out seq 10 permit 192.168.1.0/24 route-map gw2out permit 10 match ip address prefix-list gw2_p_out set as-path prepend 1234 route-map gw2in permit 10 set local-preference
Re: [FUG-BR] Freebsd + Quagga + BGP
Ex.: router bgp 1234 bgp router-id seu router_id neighbor xyz peer-group neighbor xyz remote-as 65535 neighbor xyz ebgp-multihop neighbor xyz etc neighbor ip_do_peer_1 peer-group xyz neighbor ip_do_peer_2 peer-group xyz ! On Fri, Aug 23, 2013 at 05:18:29PM -0300, Marco Aurelio wrote: Caro André, Seria possível vc me mandar um exemplo de peer-group ? Desde já agradeço a atenção recebida. Marco Aurélio Ventura da Silva marcoprod...@gmail.com Prodata Informática e Cadastro LTDA (33)3322- Em 23 de agosto de 2013 17:06, André Gustavo N. an...@mrx.com.br escreveu: Boa tarde marcos Primeira coisa, se todos os seus peers, usam configs semelhantes, melhor você criar um peer-group, configurar tudo nele, e adicionar os peers a esse peer-group. Sim, você pode anunciar como você disse, mas uma das maneiras de influenciar o tráfego de entrada é anunciar prefixos mais específicos em alguns links. Se você vai anunciar as mesmas coisas para os 4 peers, é desnecessário criar uma prefix-list para cada também. Prepend é outra maneira de influenciar o tráfego de entrada, mas se você setar todos iguais, não vai fazer diferença. localpref é um jeito de escolher a saída, mas novamente, se estiverem todos iguais, não faz sentido também... Para anunciar pro seu peer, você escolhe, tem gente que faz com distribute-list, outros com route-map... On Fri, Aug 23, 2013 at 03:25:43PM -0300, Marco Aurelio wrote: Olá pessoal, precisando da ajuda de vocês, pois estou meio perdido nessa configurações. Sou iniciante no assunto, já peço desculpas se estiver no cominho errado. Meu cenário é este ... OPERADORAMEU PROVEDOR AS 1234 10.1/30 --- LINK1 18881 - RECEBENDO UM /30 -- 192.168.10.2/30 20.1/30 --- LINK2 18881 - RECEBENDO UM /30 -- 192.168.20.2/30 30.1/30 --- LINK3 18881 - RECEBENDO UM /30 -- 192.168.30.2/30 40.1/30 --- LINK4 18881 - RECEBENDO UM /30 -- 192.168.40.2/30 São 4 links da mesma operadora, porém não posso somar os links, preciso fechar 4 sessões bgp, são 4 placas de redes recebendo os ips em uma máquina apenas. Utilizo quagga, minha configuração está da seguinte forma. Ja possuo meu próprio as /22, no exemplo ele é o 192.168.0.0/22 --- bgp multiple-instance ! router bgp 1234 bgp router-id 10.0.0.1 bgp log-neighbor-changes !no bgp default ipv4-unicast network 192.168.0.0/22 --- DUVIDA, posso divulgar o /22 nas quatro sessões bgp, ou vou ter que quebrar esse /22 em quatro /254 ?? redistribute connected ! redistribute static redistribute ospf neighbor 192.168.10.1 remote-as 18881 neighbor 192.168.10.1 next-hop-self neighbor 192.168.10.1 description GW1 neighbor 192.168.10.1 soft-reconfiguration inbound neighbor 192.168.10.1 ebgp-multihop 4 neighbor 192.168.10.1 update-source 192.168.10.2 neighbor 192.168.10.1 prefix-list gw1_p_out out neighbor 192.168.10.1 route-map gw1in in neighbor 192.168.10.1 route-map gw1out out neighbor 192.168.10.1 default-originate neighbor 192.168.10.1 activate neighbor 192.168.20.1 remote-as 18881 neighbor 192.168.20.1 next-hop-self neighbor 192.168.20.1 description GW2 neighbor 192.168.20.1 soft-reconfiguration inbound neighbor 192.168.20.1 ebgp-multihop 4 neighbor 192.168.20.1 update-source 192.168.20.2 neighbor 192.168.20.1 prefix-list gw2_p_out out neighbor 192.168.20.1 route-map gw2in in neighbor 192.168.20.1 route-map gw2out out neighbor 192.168.20.1 default-originate neighbor 192.168.20.1 activate neighbor 192.168.30.1 remote-as 18881 neighbor 192.168.30.1 next-hop-self neighbor 192.168.30.1 description GW3 neighbor 192.168.30.1 soft-reconfiguration inbound neighbor 192.168.30.1 ebgp-multihop 4 neighbor 192.168.30.1 update-source 192.168.30.2 neighbor 192.168.30.1 prefix-list gw3_p_out out neighbor 192.168.30.1 route-map gw3in in neighbor 192.168.30.1 route-map gw3out out neighbor 192.168.30.1 default-originate neighbor 192.168.30.1 activate neighbor 192.168.40.1 remote-as 18881 neighbor 192.168.40.1 next-hop-self neighbor 192.168.40.1 description GW4 neighbor 192.168.40.1 soft-reconfiguration inbound neighbor 192.168.40.1 ebgp-multihop 4 neighbor 192.168.40.1 update-source 192.168.40.2 neighbor 192.168.40.1 prefix-list gw4_p_out out neighbor 192.168.40.1 route-map gw4in in neighbor 192.168.40.1 route-map gw4out out neighbor 192.168.40.1 default-originate neighbor 192.168.40.1 activate Acho que me confundi com esses configuração daki pra baixo, estou tentando priorizar as classes /24 sair pelos determinados gw`s, não sei se isso vai funcionar, pois coloquei o local-preference igual, minha intenção foi igualar os 4 links
Re: [FUG-BR] Freebsd + Quagga + BGP
Caro André, Muitíssimo obrigado, foi de grande ajuda. Marco Aurélio Ventura da Silva marcoprod...@gmail.com Prodata Informática e Cadastro LTDA (33)3322- Em 23 de agosto de 2013 17:26, André Gustavo N. an...@mrx.com.br escreveu: Ex.: router bgp 1234 bgp router-id seu router_id neighbor xyz peer-group neighbor xyz remote-as 65535 neighbor xyz ebgp-multihop neighbor xyz etc neighbor ip_do_peer_1 peer-group xyz neighbor ip_do_peer_2 peer-group xyz ! On Fri, Aug 23, 2013 at 05:18:29PM -0300, Marco Aurelio wrote: Caro André, Seria possível vc me mandar um exemplo de peer-group ? Desde já agradeço a atenção recebida. Marco Aurélio Ventura da Silva marcoprod...@gmail.com Prodata Informática e Cadastro LTDA (33)3322- Em 23 de agosto de 2013 17:06, André Gustavo N. an...@mrx.com.br escreveu: Boa tarde marcos Primeira coisa, se todos os seus peers, usam configs semelhantes, melhor você criar um peer-group, configurar tudo nele, e adicionar os peers a esse peer-group. Sim, você pode anunciar como você disse, mas uma das maneiras de influenciar o tráfego de entrada é anunciar prefixos mais específicos em alguns links. Se você vai anunciar as mesmas coisas para os 4 peers, é desnecessário criar uma prefix-list para cada também. Prepend é outra maneira de influenciar o tráfego de entrada, mas se você setar todos iguais, não vai fazer diferença. localpref é um jeito de escolher a saída, mas novamente, se estiverem todos iguais, não faz sentido também... Para anunciar pro seu peer, você escolhe, tem gente que faz com distribute-list, outros com route-map... On Fri, Aug 23, 2013 at 03:25:43PM -0300, Marco Aurelio wrote: Olá pessoal, precisando da ajuda de vocês, pois estou meio perdido nessa configurações. Sou iniciante no assunto, já peço desculpas se estiver no cominho errado. Meu cenário é este ... OPERADORAMEU PROVEDOR AS 1234 10.1/30 --- LINK1 18881 - RECEBENDO UM /30 -- 192.168.10.2/30 20.1/30 --- LINK2 18881 - RECEBENDO UM /30 -- 192.168.20.2/30 30.1/30 --- LINK3 18881 - RECEBENDO UM /30 -- 192.168.30.2/30 40.1/30 --- LINK4 18881 - RECEBENDO UM /30 -- 192.168.40.2/30 São 4 links da mesma operadora, porém não posso somar os links, preciso fechar 4 sessões bgp, são 4 placas de redes recebendo os ips em uma máquina apenas. Utilizo quagga, minha configuração está da seguinte forma. Ja possuo meu próprio as /22, no exemplo ele é o 192.168.0.0/22 --- bgp multiple-instance ! router bgp 1234 bgp router-id 10.0.0.1 bgp log-neighbor-changes !no bgp default ipv4-unicast network 192.168.0.0/22 --- DUVIDA, posso divulgar o /22 nas quatro sessões bgp, ou vou ter que quebrar esse /22 em quatro /254 ?? redistribute connected ! redistribute static redistribute ospf neighbor 192.168.10.1 remote-as 18881 neighbor 192.168.10.1 next-hop-self neighbor 192.168.10.1 description GW1 neighbor 192.168.10.1 soft-reconfiguration inbound neighbor 192.168.10.1 ebgp-multihop 4 neighbor 192.168.10.1 update-source 192.168.10.2 neighbor 192.168.10.1 prefix-list gw1_p_out out neighbor 192.168.10.1 route-map gw1in in neighbor 192.168.10.1 route-map gw1out out neighbor 192.168.10.1 default-originate neighbor 192.168.10.1 activate neighbor 192.168.20.1 remote-as 18881 neighbor 192.168.20.1 next-hop-self neighbor 192.168.20.1 description GW2 neighbor 192.168.20.1 soft-reconfiguration inbound neighbor 192.168.20.1 ebgp-multihop 4 neighbor 192.168.20.1 update-source 192.168.20.2 neighbor 192.168.20.1 prefix-list gw2_p_out out neighbor 192.168.20.1 route-map gw2in in neighbor 192.168.20.1 route-map gw2out out neighbor 192.168.20.1 default-originate neighbor 192.168.20.1 activate neighbor 192.168.30.1 remote-as 18881 neighbor 192.168.30.1 next-hop-self neighbor 192.168.30.1 description GW3 neighbor 192.168.30.1 soft-reconfiguration inbound neighbor 192.168.30.1 ebgp-multihop 4 neighbor 192.168.30.1 update-source 192.168.30.2 neighbor 192.168.30.1 prefix-list gw3_p_out out neighbor 192.168.30.1 route-map gw3in in neighbor 192.168.30.1 route-map gw3out out neighbor 192.168.30.1 default-originate neighbor 192.168.30.1 activate neighbor 192.168.40.1 remote-as 18881 neighbor 192.168.40.1 next-hop-self neighbor 192.168.40.1 description GW4 neighbor 192.168.40.1 soft-reconfiguration inbound neighbor 192.168.40.1 ebgp-multihop 4 neighbor 192.168.40.1 update-source 192.168.40.2 neighbor 192.168.40.1 prefix-list gw4_p_out out neighbor 192.168.40.1 route-map gw4in in
Re: [FUG-BR] FreeBSD + Quagga
Interessante voce ter comentado sobre reboot. Aqui, nao sei se eu que faço alguma coisa errada, mas sempre que preciso atualizar o Perl eu preciso rebootar pois parece que ele nao encontra algumas bibliotecas (fica dando erro em alguns .pm da vida). Tem algum comando que se rode, logo apos a instalacao/upgrade do perl, para nao precisar rebootar ? (sem ser o perl-after-upgrade, que sempre rodo) Obrigado Edinilson -- ATINET Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Original Message - From: Erick Lazaro erick@gmail.com To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Thursday, December 15, 2011 4:55 PM Subject: Re: [FUG-BR] FreeBSD + Quagga instalei o portupgrade, mandei atualizar, foi numa boa =/ Achei estranho, dai resolvi reinstalar o free, atualizei os binarios (freebsd-update fetch upgrade freebsd-update install), mandei atualizar o ports (portsnap fetch portsnap extract), dei um reboot. Entrei no /usr/ports/net/quagga make install, selecionei o que precisava de opções e foi numa boa... não entendi... Enfim... agora vou por pra rodar IPv4 e IPv6 =] FreeBSD 10 x 0 Erick Muito obrigado a todos e desculpe-me por alguma coisa! 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] FreeBSD + Quagga
Bom dia Srs. Estou montando um Servidor com Quagga. Instalei o Free 8.2-RELEASE, atualizei ele, atualizei o ports, instalei o portupgrade, vim e quando vou instalar o quagga, dá erro: undefined reference to 'vtysh_init_cmd' Dai é abortado. A versão do quagga no ports é a 0.99.20 Alguém pegou isso? Abraço. -- Linux user: 478061 Google Talk : erick@gmail.com MSN : eric...@msn.com Skype: erick.lzr Erick Rodrigo Lazaro - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD + Quagga
Numa versao muito antiga, tanto do Quagga quanto do Freebsd, tinha este problema: http://comments.gmane.org/gmane.network.quagga.user/7477 E a correção era atualizar o Perl. Nao sei se seria o seu caso. Edinilson -- ATINET Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Original Message - From: Erick Lazaro erick@gmail.com To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Thursday, December 15, 2011 11:28 AM Subject: [FUG-BR] FreeBSD + Quagga Bom dia Srs. Estou montando um Servidor com Quagga. Instalei o Free 8.2-RELEASE, atualizei ele, atualizei o ports, instalei o portupgrade, vim e quando vou instalar o quagga, dá erro: undefined reference to 'vtysh_init_cmd' Dai é abortado. A versão do quagga no ports é a 0.99.20 Alguém pegou isso? Abraço. -- Linux user: 478061 Google Talk : erick@gmail.com MSN : eric...@msn.com Skype: erick.lzr Erick Rodrigo Lazaro - 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] FreeBSD + Quagga
Instalei o Free numa VM, sem atualizar o ports, instala de boa! Só que a versão do quagga é antiga: 0.99.17_5 E usa o perl 5.10 Achei isso na net: http://osdir.com/ml/network.quagga.user/2004-08/msg00112.html E vi que esse erro é antigo mesmo... Obrigado pela resposta. Em 15 de dezembro de 2011 13:58, Edinilson - ATINET edinil...@atinet.com.br escreveu: Numa versao muito antiga, tanto do Quagga quanto do Freebsd, tinha este problema: http://comments.gmane.org/gmane.network.quagga.user/7477 E a correção era atualizar o Perl. Nao sei se seria o seu caso. Edinilson -- ATINET Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Original Message - From: Erick Lazaro erick@gmail.com To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Thursday, December 15, 2011 11:28 AM Subject: [FUG-BR] FreeBSD + Quagga Bom dia Srs. Estou montando um Servidor com Quagga. Instalei o Free 8.2-RELEASE, atualizei ele, atualizei o ports, instalei o portupgrade, vim e quando vou instalar o quagga, dá erro: undefined reference to 'vtysh_init_cmd' Dai é abortado. A versão do quagga no ports é a 0.99.20 Alguém pegou isso? Abraço. -- Linux user: 478061 Google Talk : erick@gmail.com MSN : eric...@msn.com Skype: erick.lzr Erick Rodrigo Lazaro - 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 -- Linux user: 478061 Google Talk : erick@gmail.com MSN : eric...@msn.com Skype: erick.lzr Erick Rodrigo Lazaro - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD + Quagga
Sei que pode não ter nada haver... mas já experimentaram usar OpenBGPd ?!?! eu PESSOALMENTE acho muito mais facil de gerenciar sessão bgp com ele e é nativo no sistema ;) integra com PF e CARP. Fica a dica Em Qui, 2011-12-15 às 14:09 -0200, Erick Lazaro escreveu: Instalei o Free numa VM, sem atualizar o ports, instala de boa! Só que a versão do quagga é antiga: 0.99.17_5 E usa o perl 5.10 Achei isso na net: http://osdir.com/ml/network.quagga.user/2004-08/msg00112.html E vi que esse erro é antigo mesmo... Obrigado pela resposta. Em 15 de dezembro de 2011 13:58, Edinilson - ATINET edinil...@atinet.com.br escreveu: Numa versao muito antiga, tanto do Quagga quanto do Freebsd, tinha este problema: http://comments.gmane.org/gmane.network.quagga.user/7477 E a correção era atualizar o Perl. Nao sei se seria o seu caso. Edinilson -- ATINET Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Original Message - From: Erick Lazaro erick@gmail.com To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Thursday, December 15, 2011 11:28 AM Subject: [FUG-BR] FreeBSD + Quagga Bom dia Srs. Estou montando um Servidor com Quagga. Instalei o Free 8.2-RELEASE, atualizei ele, atualizei o ports, instalei o portupgrade, vim e quando vou instalar o quagga, dá erro: undefined reference to 'vtysh_init_cmd' Dai é abortado. A versão do quagga no ports é a 0.99.20 Alguém pegou isso? Abraço. -- Linux user: 478061 Google Talk : erick@gmail.com MSN : eric...@msn.com Skype: erick.lzr Erick Rodrigo Lazaro - 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 -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 Blog: http://www.luizgustavo.pro.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] FreeBSD + Quagga
Também acho o OpenBGPd sensacional! Prefiro ele também... mas o cliente quer quagga, por que ele manja de cisco e fica mais fácil... =/ Vai entender... Em 15 de dezembro de 2011 14:23, Luiz Gustavo luizgust...@luizgustavo.pro.br escreveu: Sei que pode não ter nada haver... mas já experimentaram usar OpenBGPd ?!?! eu PESSOALMENTE acho muito mais facil de gerenciar sessão bgp com ele e é nativo no sistema ;) integra com PF e CARP. Fica a dica Em Qui, 2011-12-15 às 14:09 -0200, Erick Lazaro escreveu: Instalei o Free numa VM, sem atualizar o ports, instala de boa! Só que a versão do quagga é antiga: 0.99.17_5 E usa o perl 5.10 Achei isso na net: http://osdir.com/ml/network.quagga.user/2004-08/msg00112.html E vi que esse erro é antigo mesmo... Obrigado pela resposta. Em 15 de dezembro de 2011 13:58, Edinilson - ATINET edinil...@atinet.com.br escreveu: Numa versao muito antiga, tanto do Quagga quanto do Freebsd, tinha este problema: http://comments.gmane.org/gmane.network.quagga.user/7477 E a correção era atualizar o Perl. Nao sei se seria o seu caso. Edinilson -- ATINET Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Original Message - From: Erick Lazaro erick@gmail.com To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Thursday, December 15, 2011 11:28 AM Subject: [FUG-BR] FreeBSD + Quagga Bom dia Srs. Estou montando um Servidor com Quagga. Instalei o Free 8.2-RELEASE, atualizei ele, atualizei o ports, instalei o portupgrade, vim e quando vou instalar o quagga, dá erro: undefined reference to 'vtysh_init_cmd' Dai é abortado. A versão do quagga no ports é a 0.99.20 Alguém pegou isso? Abraço. -- Linux user: 478061 Google Talk : erick@gmail.com MSN : eric...@msn.com Skype: erick.lzr Erick Rodrigo Lazaro - 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 -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 Blog: http://www.luizgustavo.pro.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Linux user: 478061 Google Talk : erick@gmail.com MSN : eric...@msn.com Skype: erick.lzr Erick Rodrigo Lazaro - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD + Quagga
É, tem disto... curva de conforto da CLI cisco, fiquei alguns anos assim também, mas era tanta gambiarra para fazer recursos simples como um PBR que aprendi a sintaxe do openbgpd, que cá entre nós, nem é tão complexa assim. O bom dito é em breve você vai ter mais uma consultoria, de migrar para o openbgpd quando o cliente precisar de mais recursos ;-) []s Em 15/12/11 14:31, Erick Lazaro escreveu: Também acho o OpenBGPd sensacional! Prefiro ele também... mas o cliente quer quagga, por que ele manja de cisco e fica mais fácil... =/ Vai entender... - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD + Quagga
instalei o portupgrade, mandei atualizar, foi numa boa =/ Achei estranho, dai resolvi reinstalar o free, atualizei os binarios (freebsd-update fetch upgrade freebsd-update install), mandei atualizar o ports (portsnap fetch portsnap extract), dei um reboot. Entrei no /usr/ports/net/quagga make install, selecionei o que precisava de opções e foi numa boa... não entendi... Enfim... agora vou por pra rodar IPv4 e IPv6 =] FreeBSD 10 x 0 Erick Muito obrigado a todos e desculpe-me por alguma coisa! Abraço. Em 15 de dezembro de 2011 14:09, Erick Lazaro erick@gmail.comescreveu: Instalei o Free numa VM, sem atualizar o ports, instala de boa! Só que a versão do quagga é antiga: 0.99.17_5 E usa o perl 5.10 Achei isso na net: http://osdir.com/ml/network.quagga.user/2004-08/msg00112.html E vi que esse erro é antigo mesmo... Obrigado pela resposta. Em 15 de dezembro de 2011 13:58, Edinilson - ATINET edinil...@atinet.com.br escreveu: Numa versao muito antiga, tanto do Quagga quanto do Freebsd, tinha este problema: http://comments.gmane.org/gmane.network.quagga.user/7477 E a correção era atualizar o Perl. Nao sei se seria o seu caso. Edinilson -- ATINET Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Original Message - From: Erick Lazaro erick@gmail.com To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Thursday, December 15, 2011 11:28 AM Subject: [FUG-BR] FreeBSD + Quagga Bom dia Srs. Estou montando um Servidor com Quagga. Instalei o Free 8.2-RELEASE, atualizei ele, atualizei o ports, instalei o portupgrade, vim e quando vou instalar o quagga, dá erro: undefined reference to 'vtysh_init_cmd' Dai é abortado. A versão do quagga no ports é a 0.99.20 Alguém pegou isso? Abraço. -- Linux user: 478061 Google Talk : erick@gmail.com MSN : eric...@msn.com Skype: erick.lzr Erick Rodrigo Lazaro - 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 -- Linux user: 478061 Google Talk : erick@gmail.com MSN : eric...@msn.com Skype: erick.lzr Erick Rodrigo Lazaro -- Linux user: 478061 Google Talk : erick@gmail.com MSN : eric...@msn.com Skype: erick.lzr Erick Rodrigo Lazaro - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Freebsd + Quagga + CYMRU
Faz um tempo que não uso o quagga, mas baseado no que está no site para ipv6, a versão para ipv4 seria algo assim +-: neighbor A.B.C.D route-map BOGONS in ip community-list 100 permit 65332:888 route-map BOGONS permit 10 match community 100 set ip next-hop 192.0.2.1 no cisco você colocaria o 192.0.2.1 pro null: ip route 192.0.2.1 255.255.255.255 Null0 Só que no BSD(pelo menos no 7 na época), eu tive que fazer assim, pois o quagga dava match no route-map, mas o freebsd não jogava a rota pro null, então fiz assim: no rc.conf: cloned_interfaces=disc0 ifconfig_disc0=192.0.2.1 netmask 255.255.255.255 route_blackhole=10.255.255.254/32 192.0.2.1 e daí alterei no quagga de: set ip next-hop 192.0.2.1 para set ip next-hop 10.255.255.254 Daí o quagga entregava pra um IP que estava atrás da disc0, mandando tudo pro limbo..:-) Se quiser aproveitar e migrar pro openbgpd, é mega simples, basta esta simples linha: #TEAM-CYMRU Bogons allow from any community 65333:888 set pftable bogons e no pf.conf, ative a table bogons: table bogons persist block log quick from bogons to any block log quick from any to bogons abraços Em 25/10/2011 09:03, Edinilson - ATINET escreveu: Caros amigos, alguem que esteja utilizando a combinação Freebsd + Quagga e os bogons filters do Team Cymru, poderia por favor me enviar um exemplo de configuracao para os filtros BGP? No site deles só possui uma versao para Quagga + IPv6: http://www.team-cymru.org/Services/Bogons/bgp-examples.html#quagga-full Obrigado Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - 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] Freebsd + Quagga + CYMRU
aqui tive que criar a rota para null0 no zebra e não no freeBSD. Zebra# conf t Zebrar# ip route 192.0.2.1/32 null0 Se criar a rota direto no FreeBSD ele não descarta os pacotes corretamente. Então a lógica é: No Quagga (bgpd) ele joga para o gateway (nexthop) 192.0.2.1 No Zebra (e não no FreeBSD) ele joga para null0, pela rota criada. Apesar de ter a rota no kernel do FreeBSD (lembre-se criada pelo zebra). bgp# netstat -nr | grep 192.0.2.1 192.0.2.1 127.0.0.1 UH1B00lo0 Wenderson Souza e-mail: wendersonso...@gmail.com msn: wendersonso...@msn.com skype: wendersonsouza Em 27 de outubro de 2011 17:26, Renato Frederick ren...@frederick.eti.br escreveu: Faz um tempo que não uso o quagga, mas baseado no que está no site para ipv6, a versão para ipv4 seria algo assim +-: neighbor A.B.C.D route-map BOGONS in ip community-list 100 permit 65332:888 route-map BOGONS permit 10 match community 100 set ip next-hop 192.0.2.1 no cisco você colocaria o 192.0.2.1 pro null: ip route 192.0.2.1 255.255.255.255 Null0 Só que no BSD(pelo menos no 7 na época), eu tive que fazer assim, pois o quagga dava match no route-map, mas o freebsd não jogava a rota pro null, então fiz assim: no rc.conf: cloned_interfaces=disc0 ifconfig_disc0=192.0.2.1 netmask 255.255.255.255 route_blackhole=10.255.255.254/32 192.0.2.1 e daí alterei no quagga de: set ip next-hop 192.0.2.1 para set ip next-hop 10.255.255.254 Daí o quagga entregava pra um IP que estava atrás da disc0, mandando tudo pro limbo..:-) Se quiser aproveitar e migrar pro openbgpd, é mega simples, basta esta simples linha: #TEAM-CYMRU Bogons allow from any community 65333:888 set pftable bogons e no pf.conf, ative a table bogons: table bogons persist block log quick from bogons to any block log quick from any to bogons abraços Em 25/10/2011 09:03, Edinilson - ATINET escreveu: Caros amigos, alguem que esteja utilizando a combinação Freebsd + Quagga e os bogons filters do Team Cymru, poderia por favor me enviar um exemplo de configuracao para os filtros BGP? No site deles só possui uma versao para Quagga + IPv6: http://www.team-cymru.org/Services/Bogons/bgp-examples.html#quagga-full Obrigado Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - 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
[FUG-BR] Freebsd + Quagga + CYMRU
Caros amigos, alguem que esteja utilizando a combinação Freebsd + Quagga e os bogons filters do Team Cymru, poderia por favor me enviar um exemplo de configuracao para os filtros BGP? No site deles só possui uma versao para Quagga + IPv6: http://www.team-cymru.org/Services/Bogons/bgp-examples.html#quagga-full Obrigado Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.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] Freebsd + Quagga + CYMRU
É a mesma coisa. -- Eduardo Schoedler ESDS Consultoria de TI Enviado via iPhone Em 25/10/2011, às 09:03, Edinilson - ATINET edinil...@atinet.com.br escreveu: Caros amigos, alguem que esteja utilizando a combinação Freebsd + Quagga e os bogons filters do Team Cymru, poderia por favor me enviar um exemplo de configuracao para os filtros BGP? No site deles só possui uma versao para Quagga + IPv6: http://www.team-cymru.org/Services/Bogons/bgp-examples.html#quagga-full Obrigado Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - 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] Freebsd + Quagga + CYMRU
Caro Eduardo, realmente... depois que li logo abaixo que tinha esta observacao. Obrigado e desculpe pelo transtorno. Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Original Message - From: Eduardo Schoedler lis...@esds.com.br To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Tuesday, October 25, 2011 1:36 PM Subject: Re: [FUG-BR] Freebsd + Quagga + CYMRU É a mesma coisa. -- Eduardo Schoedler ESDS Consultoria de TI Enviado via iPhone Em 25/10/2011, às 09:03, Edinilson - ATINET edinil...@atinet.com.br escreveu: Caros amigos, alguem que esteja utilizando a combinação Freebsd + Quagga e os bogons filters do Team Cymru, poderia por favor me enviar um exemplo de configuracao para os filtros BGP? No site deles só possui uma versao para Quagga + IPv6: http://www.team-cymru.org/Services/Bogons/bgp-examples.html#quagga-full Obrigado Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - 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
Re: [FUG-BR] Freebsd + Quagga
Qual patch vocÊ usou para a sessão BGP funcionar com MD5 no Free? Nunca consegui funcionar, no máximo só de um lado[1] Outra coisa, IPSEC? Até onde entendo, MD5 na sessão BGP seria algo do tipo: [...] router bgp 1234 no synchronization bgp log-neighbor-changes network x.x.x.x/y neighbor A.B.C.D remote-as 4567 neighbor A.B.C.D password 0 SENHA_SESSAO tirando a última linha a sessão com o parceiro A.B.C.D, para a rede x.x.x.x/y não tem MD5. Será que você não estaria era fazendo um tunel ipsec para criptografar todo o tráfego de um roteador até outro e encapsulando a sessão BGP sobre ele? :) Abraços [1] http://lists.freebsd.org/pipermail/freebsd-net/2009-April/021732.html -Original Message- From: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] On Behalf Of Eduardo Schoedler Sent: quinta-feira, 1 de outubro de 2009 02:16 To: 'Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)' Subject: [FUG-BR] Freebsd + Quagga Pessoal. Compilei um Freebsd com todas opções necessárias para utilizar Quagga com senhas MD5. Para teste, levantei uma sessão bgp do Quagga com um Mikrotik. Configurei uma senha no Mikrotik e, ao ativar o IPSec no Freebsd a sessão levantou. Seria normal, se eu houvesse setado a senha no Quagga, mas não setei... e mesmo assim a sessão subiu! Ao parar o IPSec, a sessão cai no Mikrotik. Alguém já passou por isso? Está certo assim mesmo? O IPsec envia sempre a senha para o neighbor, mesmo sem precisar configurar no quagga? Abraços, -- Eduardo - 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] Freebsd + Quagga
Caro Renato, aproveitando: Voce abandonou o Quagga e partiu para o openbgpd ou continua ainda com o Quagga? []´s Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.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] Freebsd + Quagga
Pelo que andei lendo o openbgpd e openospfd são mais robustos que o Quagga. Como nunca usei, não posso afirmar. 2009/10/1 Edinilson - ATINET edinil...@atinet.com.br Caro Renato, aproveitando: Voce abandonou o Quagga e partiu para o openbgpd ou continua ainda com o Quagga? []´s Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - 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] Freebsd + Quagga
Continuo com quagga, o custo de migrar a solução e aprendizado não tem como no momento, é muito serviço e curta janela de parada. Na verdade, coloquei um freebsd com quagga na frente do openbsd, de forma que o gateway padrao do openbsd agora é o freebsd e eu nao tenho que mexer nas regras PF atuais. -Original Message- From: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] On Behalf Of Edinilson - ATINET Sent: quinta-feira, 1 de outubro de 2009 11:23 To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Subject: Re: [FUG-BR] Freebsd + Quagga Caro Renato, aproveitando: Voce abandonou o Quagga e partiu para o openbgpd ou continua ainda com o Quagga? []´s Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - 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] Freebsd + Quagga
Acho que isto é mais questão de familiaridade/necessidade de recursos do que robustez, afinal fechar sessao BGP ambos fecham e são estáveis, tirando aí no passado o bug do quagga com as de 32bits que foi um transtorno até liberarem o relase novo. O que varia de um para o outro é depois da sessao fechada, o que eles fazem de integração com o freebsd/openbsd! -Original Message- From: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] On Behalf Of Fabricio Archanjo Sent: quinta-feira, 1 de outubro de 2009 11:34 To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Subject: Re: [FUG-BR] Freebsd + Quagga Pelo que andei lendo o openbgpd e openospfd são mais robustos que o Quagga. Como nunca usei, não posso afirmar. 2009/10/1 Edinilson - ATINET edinil...@atinet.com.br Caro Renato, aproveitando: Voce abandonou o Quagga e partiu para o openbgpd ou continua ainda com o Quagga? []´s Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - 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
[FUG-BR] Freebsd + Quagga
Pessoal. Compilei um Freebsd com todas opções necessárias para utilizar Quagga com senhas MD5. Para teste, levantei uma sessão bgp do Quagga com um Mikrotik. Configurei uma senha no Mikrotik e, ao ativar o IPSec no Freebsd a sessão levantou. Seria normal, se eu houvesse setado a senha no Quagga, mas não setei... e mesmo assim a sessão subiu! Ao parar o IPSec, a sessão cai no Mikrotik. Alguém já passou por isso? Está certo assim mesmo? O IPsec envia sempre a senha para o neighbor, mesmo sem precisar configurar no quagga? Abraços, -- Eduardo - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
