[GTER] Problemas com BGP Multihomed
Guilherme Domingues
guilhdom1 at yahoo.com.br
Sun Jul 4 15:01:17 -03 2010
Ola Jean, acompanhei com muito interesse a Thread.
Eu tenho uma experiencia que considero ainda mediana com BGP, frente as
consideracoes que foram feitas na Thread. Pelo que eu entendi, foi estabelecido um tunel entre os roteadores de borda que falam eBGP.
Ate o momento, eu so trabalhei com topologias sem tuneis entre os roteadores que falam eBGP, com OSPF como protocolo de roteamento intra-AS.
Voce poderia estar enunciando os beneficios, segundo sua experiencia, de se trabalhar com tuneis entre os roteadores que falam eBGP em uma topologia com OSPF como protocolo de roteamento intra-AS ?
Uma duvida que fiquei e se a utilizacao de tuneis na sua topologia de conexao se deve a um cenario em que a ausencia de tuneis impossibilitaria a comunicacao entre os roteadores que falam eBGP no AS ?
Eu fiquei bem interessado na questao e gostaria de ouvir suas ponderacoes de
engenharia nessa solucao para aumentar minha compreensao no caso de topologias
futuras com as quais ainda nao me deparei, mas onde seja necessario ou
muito benefico a utilizacao de tuneis entre os roteadores de borda do AS que
falam eBGP com outros ASes.
Atenciosamente,
Guilherme Domenico.
--- Em qui, 20/5/10, Jean Carlos Oliveira Guandalini <jean.guandalini at corp.visaonet.com.br> escreveu:
De: Jean Carlos Oliveira Guandalini <jean.guandalini at corp.visaonet.com.br>
Assunto: Re: [GTER] Problemas com BGP Multihomed
Para: gter at eng.registro.br
Data: Quinta-feira, 20 de Maio de 2010, 9:54
Pessoal, agradeço mais uma vez as dicas, conseguimos um avanço.
Seguindo essa dica do André, sobre alterar o MSS Clamping.
No roteador de "saída", utilizamos o shorewall, na configuração dele
podemos colocar um valor para o MSS. Então nele resolvi colocar esse
valor para 1480 que é o tamanho do MTU do túnel IPIP.
Mas não funcionou. Então resolvi diminuir o MSS em 20 baseado no tamanho
do header IP. Ainda não funcionou
Quando mudei o MSS para 1440, finalmente funcionou.
Mas essa mudança para 1440 foi mais uma tentativa sem nexo, pois não
havia motivo, pelo menos para mim precisar abaixar tanto o MSS.
Alguém tem alguma idéia porque eu precisei diminuir o MSS para 1440 na
"saída", se na volta meu túnel tem MTU em 1480?
Obrigado
Jean
On 15-05-2010 15:33, Andre Gustavo de C. Albuquerque wrote:
> Jean, tenta TCP MSS Clamping.
> Esse ajuste de MTU vc faz nos roteadores, os end-hosts não sabem disso.
>
> Abs, Gustavo
>
> 2010/5/15 Jean Carlos Oliveira Guandalini
> <jean.guandalini at corp.visaonet.com.br
> <mailto:jean.guandalini at corp.visaonet.com.br>>
>
> Então, aqui tenho um outro caso que não temos túneis, e funciona
> certinho. Sai por um link e volta por outro.
> O meu problema mesmo é quando passamos por dentro do túnel, e só
> quando
> passamos o "download" por ele, o que me convence cada vez mais que
> deva
> ser MTU. Mas como disse, já tentamos inúmeros valores e dois tipos de
> túneis diferentes.
>
> On 15-05-2010 11:00, Arlindo F. Neto wrote:
> > Eu não me convenci de que há a necessidade de um túnel ligando
> as bordas!
> >
> > O BGP, deveria normalmente sair e entrar pelas bordas. Não há
> túnel na
> > rede, não há alteração de MTU, Firewall, etc. Não me convenço dessa
> > necessidade até porque já vi ambientes sem isso!
> >
> > []'s
> >
> > Em 15 de maio de 2010 10:47, Andre Gustavo de C. Albuquerque
> > <gustavo.albuquerque at gmail.com
> <mailto:gustavo.albuquerque at gmail.com>
> <mailto:gustavo.albuquerque at gmail.com
> <mailto:gustavo.albuquerque at gmail.com>>>
> > escreveu:
> >
> > Não acompanhei esta thread desde o início, mas vi que vocês já
> > estão cientes de problemas que podem ser causados por
> divergências
> > de MTU e quebra de PMTU-D na rede.
> >
> > Algo que pode ajudar em alguns casos com tunelamento é utilizar
> > TCP MSS clamping. Veja se a solução que vc está usando suporta
> > esta funcionalidade (acredito que seja bem comum hoje).
> >
> > Apesar de podermos ajustar muitos parâmetros nos roteadores
> > iniciadores e terminadores de túneis, isso pode ser impraticável
> > em end-hosts. O TCP MSS Clamping é uma solução de contorno
> > razoável para o tráfego TCP. Se você tiver tráfego UDP com
> pacotes
> > grandes e em quantidade razoável, deve pesquisar a aplicação
> > envolvida para soluções de contorno apropriadas.
> >
> > Abs, Gustavo Albuquerque
> >
> > 2010/5/15 Arlindo F. Neto <lopan.eti at gmail.com
> <mailto:lopan.eti at gmail.com>
> > <mailto:lopan.eti at gmail.com <mailto:lopan.eti at gmail.com>>>
> >
> > Jean,
> >
> > Eu passei por este mesmo problema, estou acompanhando sua
> > thread para ver se
> > algo de novo surge.
> >
> > Eu não consegui fazer com que o sistema fosse totalmente
> > autônomo, ou seja,
> > sair por um lado e voltar pelo outro normalmente. Toda a
> rede
> > utiliza
> > Mikrotik e eu fui em busca de qualquer coisa no Mikrotik
> que possa
> > atrapalhar esse funcionamento (Firewall, Configurações,
> > Protocolos, etc) e
> > não encontrei nada.
> >
> > Fiz os testes com túneis também, não funcionou! Por
> último, eu
> > parti o ASN
> > em um bloco /22, onde este é anunciado em cada Mikrotik na
> > borda com um Link
> > (Mikrotik A e Mikrotik B receberam o anúncio do bloco /22).
> > Feito isso, o
> > bloco /22 foi novamente segmentado em dois /23. Com isso, os
> > clientes da
> > rede que estavam mais próximos do Mikrotik A (e
> > consequentemente o utilizam
> > como gateway), receberam os IPs de um dos blocos /23 e este
> > foi anunciado no
> > Mikrotik A, o mesmo foi feito para o Mikrotik B com a outra
> > parte do bloco
> > /23. Dessa forma a rede foi "dividida", enquanto as duas
> > bordas estão
> > funcionando (A e B) os clientes saem e voltam pela mesma
> > borda. Quando uma
> > delas para, um Mikrotik sozinho assume todo o tráfego.
> No BGP,
> > a prioridade
> > de anúncio é dado pelo bloco menor, ou seja, se eu tenho um
> > /22 e /23
> > anunciado, o /23 tem prioridade. Caso o /23 de um lado
> pare de
> > anunciar, o
> > /22 do outro assume.
> >
> > Mas, mesmo assim, eu ainda espero resolver o problema e
> tornar
> > a rede
> > totalmente autônoma. Tenho planos de mudar toda a rede
> interna
> > de OSPF para
> > BGP, depois realizar novos testes.
> >
> > Abraços,
> >
> > Em 12 de maio de 2010 14:49, Jean Carlos Oliveira
> Guandalini <
> > jean.guandalini at corp.visaonet.com.br
> <mailto:jean.guandalini at corp.visaonet.com.br>
> > <mailto:jean.guandalini at corp.visaonet.com.br
> <mailto:jean.guandalini at corp.visaonet.com.br>>> escreveu:
> >
> > > Pessoal, demoramos pra poder configurar um túnel L2TP, mas
> > infelizmente
> > > mesmo com o túnel L2TP ainda não funcionou. Sites como
> > globo.com <http://globo.com> <http://globo.com> e
> > > mercadolivre não acessam, ficam carregando.
> > > Revisamos as configurações do firewall, rp_filter
> desativado.
> > > Jorge, você que sugeriu a solução, tem alguma modificação
> > que você
> > > precisou fazer?
> > > Nesse caso estamos usando Linux de um lado e mikrotik
> de outro.
> > >
> > > Obrigado
> > > Jean
> > >
> > > On 05-05-2010 17:58, Jorge Thiele wrote:
> > > > Rapaz, o meu tunel também era IPIP e com dois Mikrotiks,
> > no final das
> > > > contas o problema foi resolvido com
> > > > outro tunelamento, se não me engano fizemos um L2TP
> > temporariamente de
> > > > depois acabamos por remover
> > > > o tunelamento de vez porque a Copel passou a aceitar
> > roteamento com
> > > > IPs válidos.
> > > > Lembro que tentei tudo com o IPIP, diminuir MTU, forçar
> > PMTU e nada
> > > > resolveu, o jeito foi mesmo apelar para o L2TP.
> > > >
> > > >
> > > >
> > > > Em 05/05/2010 16:56, Jean Carlos Oliveira Guandalini
> escreveu:
> > > >> Jorge, eu tenho um túnel sim, usando IPIP. Você poderia
> > me passar que
> > > >> tipo de configuração precisou mudar? MTU?
> > > >>
> > > >> obrigado
> > > >>
> > > >> On 05-05-2010 15:21, Jorge Thiele wrote:
> > > >>
> > > >>> como que fica se o caso for:
> > > >>> Out: QUAGGA1 In: QUAGGA2 = ?
> > > >>>
> > > >> --
> > > >> gter list
> https://eng.registro.br/mailman/listinfo/gter
> > > >>
> > > >
> > > --
> > > gter list https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list https://eng.registro.br/mailman/listinfo/gter
> >
> >
> >
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
>
--
gter list https://eng.registro.br/mailman/listinfo/gter
More information about the gter
mailing list