[GTER] Caso estranho BGP
Douglas Fischer
fischerdouglas at gmail.com
Thu Apr 2 10:55:51 -03 2015
Eu dou um Joinha na abordagem que o Bruno comentou...
Mande o teu prefixo menos específico para todos os teus trânsitos, e
inclusive para o PTT.
- Isso acaba funcionando como fall-back na hora que um de teus links(ou
o próprio upstream) cair...
- Além resolver o problema com a MERDA do Reverse Path Verification da
GVT(não resolve nada para eles e só atrapalha)
E "balanceie" mandando mais específicos para aonde desejares...
Sobre o problema descrito
-------------------------
Sou capaz de apostar que um de seus upstreams está preferindo manter a rota
que ele recebe vindo do outro upstream do que a rota que ele recebe de você
mesmo.
Exatamente como Rubens comentou sobre o Keep-Odlest...
(Se me lembro bem, isso tem o objetivo de evitar atualizações
desnecessárias na Tabela).
Aí essa rota (que não é a que você anunciou para ele) vai para a FIB do
router dele.
E aí prevalece o principio mais básico do BGP. Anunciar somente o que está
na FIB.
Eu estou tentando lembrar uma config que diz algo mais ou menos assim para
o processo do BGP:
"BGP, se eu tiver em Peer em algum dos meus iBGP-peers com <ESSE> ASN,
prefira as rotas que vem do Peering do ASN original".
Em 2 de abril de 2015 00:46, Fabio Colangelo <fcolang at live.com> escreveu:
> Acabei de receber contato do peer B. Informaram que fizeram uma
> ¨alteração¨ e o problema foi resolvido. Agora as rotas aparecem nos LG por
> ambos os peers e os critérios de seleção podem ser utilizados.
>
> Pedi que me informem a solução aplicada para compartilhar aqui na lista.
>
> Obrigado pelas ideias e opiniões, mas era mais do que um problema
> conceitual.
>
> From: fcolang at live.com
> To: gter at eng.registro.br
> Subject: RE: [GTER] Caso estranho BGP
> Date: Thu, 2 Apr 2015 00:06:14 -0300
>
>
>
>
> Mas só nao vai adiante quando anuncio pelos 2 peers e em determinada
> ordem. Se não, ambos enviam sem problema algum adiante.
>
> > Date: Wed, 1 Apr 2015 23:54:55 -0300
> > From: listas at esds.com.br
> > To: gter at eng.registro.br
> > Subject: Re: [GTER] Caso estranho BGP
> >
> > Algum trânsito deve mandar o prefixo como no-export... e acaba não indo
> > adiante.
> >
> > --
> > Eduardo Schoedler
> >
> >
> > Em quarta-feira, 1 de abril de 2015, Fábio Colangelo <fcolang at live.com>
> > escreveu:
> >
> > > Perfeito Rubens. Conheço os critérios.
> > >
> > > Não eh um problema de preferência por ordem do path recebido antes. O
> que
> > > ocorre eh que as rotas do provedor B desaparecem. Não são nem listadas
> como
> > > opções.
> > >
> > > Inclusive se voce remover os anúncios do provedor A chegam a levar 3
> > > minutos para as rotas do provedor B aparecerem, indicando que rotas do
> > > provedor B nem estavam na tabela de roteamento como alternativa.
> > >
> > > Já na ordem inversa ambas as rotas aparecem como opção e dai valem AA
> > > regras de best path ou localpref etc...
> > >
> > >
> > >
> > > Em 1 de abr de 2015 23:27, pelo 23:27, Rubens Kuhl <rubensk at gmail.com
> > > <javascript:;>> escrito:
> > > >>
> > > >> Entendam ordem do anuncio, o momento em que se faz anuncio para o
> > > >peer A
> > > >> ou B, ou seja, qual ocorre primeiro.
> > > >>
> > > >>
> > > >Isso é normal. Veja o critério 10 em
> > > >
> > >
> http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
> > > >
> > > >"When both paths are external, prefer the path that was received first
> > > >(the
> > > >oldest one)."
> > > >
> > > >Algumas implementações são diferentes, e mesmo os IOS mais novos
> > > >permitem
> > > >mudar isso, mas espere encontrar vários desses casos regularmente.
> > > >
> > > >Se chegou até esse ponto é porque os outros critérios deram empate...
> > > >isso
> > > >tipicamente acontece quando há LocalPreference de alguém por alguém, e
> > > >o
> > > >único jeito de lidar com isso remotamente é com prefixos mais
> > > >específicos.
> > > >Como você já está anunciado /22 e /24, uma opção seria fazer anúncios
> > > >/22,
> > > >/23 e /24.
> > > >
> > > >
> > > >
> > > >Rubens
> > > >--
> > > >gter list https://eng.registro.br/mailman/listinfo/gter
> > > --
> > > gter list https://eng.registro.br/mailman/listinfo/gter
> >
> >
> >
> > --
> > Eduardo Schoedler
> > --
> > gter list https://eng.registro.br/mailman/listinfo/gter
>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
--
Douglas Fernando Fischer
Engº de Controle e Automação
More information about the gter
mailing list