[GTER] Caso estranho BGP

[Eduardo Schoedler]

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