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
