[GTER] Problemas com BGP Multihomed

Jean Carlos Oliveira Guandalini jean.guandalini at corp.visaonet.com.br
Thu May 20 09:54:51 -03 2010


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
>
>



More information about the gter mailing list