[GTER] Problemas com BGP Multihomed
Jean Carlos Oliveira Guandalini
jean.guandalini at corp.visaonet.com.br
Thu May 20 16:42:04 -03 2010
Obrigado pelas respostas, depois também encontrei um site falando do
assunto: http://www.znep.com/~marcs/mtu/index.html
Mas as explicações bateram em cima do que aconteceu aqui.
Resultado final dessa odisséia (rsrs) é que finalmente funcionou.
On 20-05-2010 11:51, Rubens Kuhl wrote:
> 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
>>
>>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list