[GTER] Problemas com BGP Multihomed

Rubens Kuhl rubensk at gmail.com
Thu May 20 11:51:23 -03 2010


Porque o MSS é o MTU menos 40 bytes. Do MTU, descontam-se 20 bytes do
cabeçalho IPv4 e 20 bytes do cabeçalho TCP, ficando o MSS em 40 a
menos que o MTU.


Rubens

> 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