[GTER] Redundância automática em BGP multihomed

Tue Mar 9 22:35:02 -03 2021

Meus 50 cents:

Seu roteador de borda recebendo é Mikrotik ?
Se sim dá pra fazer uma gambi legal...

Com filtros, alterar a rota default que você recebe da operadora A para um
next-hop recursivo (exemplo, pode ser um IP anycast, tipo um root server
[1] ) ,aumentar o target-scope e marcar CHECK GATEWAY PING.
Aí você cria uma rota estática desse IP Anycast usado, apontando gateway
para seu next-hop real (sua operadora A).

Prática:
Você terá uma rota default RECURSIVA apontando para um IP AnyCast com check
gateway.
O check-gateway será obrigado a testar aquele IP Anycast via operadora A
devido a rota estática.
O gateway continuará sendo a operadora A devido a ser recursivo à rota
estática criada.

Cenário funcionado de failover:
Se o IP anycast não pingar, como ele é um gateway recursivo, a rota será
desabilitada, entrando assim a operadora B.

Implicações:
O IP Anycast sempre usará a rota estática, ou seja, sempre a operadora A.
Não use um IP de grande relevância, tipo, 8.8.8.8 do google-dns, senão se
cair a operadora A você vai perder conectividade com esse IP, o que será
tragédia.

Obs. Se caso sua operadora A ainda assim te mantenha, por exemplo,
anunciando pra outras operadoras, mesmo sem ter tráfego, então você também
pode usar o IP de Anycast em netwatch e fazer um script que mexa nos
filtros de OUT dessa operadora A, baseado no PING desse IP Anycast.

Att,

Andre Almeida

Em ter., 9 de mar. de 2021 às 22:21, Lucas Willian Bocchi <
lucas.bocchi at gmail.com> escreveu:

> Então seria exatamente o caso que citei. Não há nada no protocolo BGP que
> resolva isso, pois afinal o BGP é uma conversa entre você e o roteador com
> o qual você faz sessão. Se por algum motivo ele continua te enviando as
> rotas, você precisa resolver este problema com o teu provedor de trânsito.
> Existem casos de problemas de rotas fantasmas / presas em alguns vendors.
> Pode ser o caso. Se não, você vai ter que estudar a solução que eu citei no
> e-mail anterior. Não adianta configurar keepalive, holdtime, etc.
>
> Em ter., 9 de mar. de 2021 às 21:45, Danilo Augusto <
> danilo at iotecnologia.com.br> escreveu:
>
> > Bruno e Lucas, obrigado.
> >
> > Bruno
> >
> > O problema é que o provedor A deixa de sair para a Internet toda (por
> algum
> > motivo), mas continuo recebendo as rotas BGP.
> >
> > Para lidar com intermitências, o melhor é trabalhar no hold time e keep
> > alive?
> >
> > Seria esse o caso.
> >
> > Em ter., 9 de mar. de 2021 às 21:01, Lucas Willian Bocchi <
> > lucas.bocchi at gmail.com> escreveu:
> >
> > > Bom Danilo
> > > Não ficou muito explicado o que aconteceu, mas vamos lá. O Bruno já
> citou
> > > alguma coisa aí encima, porém temos outra questão. A sessão fica
> > > estabelecida, você está recebendo normalmente as rotas do seu provedor,
> > > porém um problema lá no terceiro ou quarto HOP de roteamento não está
> > > deixando você chegar no destino que você quer (um firewall mal
> > configurado,
> > > etc). Este problema o BGP não vai resolver pra você, pois para ele, a
> > > sessão com o teu fornecedor está OK e o problema não é no protocolo de
> > > roteamento. Isso você só vai conseguir detectar através de scripts que
> > > fiquem pingando em algum determinado destino e aí você use um expect ou
> > > algo da vida para manipular seu BGP através de uma automação qualquer.
> > >
> > > Você também deve levar em conta que existe um tempo de convergência das
> > > rotas no momento da queda. Não pode ser isso seu problema? Você tem que
> > dar
> > > um tempinho até o bgp dos outros voltarem a enxergar o seu bloco, e
> isso
> > > não é imediato. Você pode ativar o BFD nas duas pontas para dar uma
> > > acelerada nessa detecção da queda. Eu gosto muito daquele recurso
> > > "check-gateway" do mikrotik e gostaria de saber se o iproute consegue
> > > simular aquilo, pois ajuda a detectar a conectividade até no gateway de
> > > maneira fácil sem BFD.
> > >
> > > Dá maiores detalhes aí Danilo que vai ficar mais fácil de entender.
> > >
> > > Em ter., 9 de mar. de 2021 às 20:42, Bruno Cabral <
> bruno at openline.com.br
> > >
> > > escreveu:
> > >
> > > > Ola
> > > >
> > > > O provedor A continua te mandando default mesmo com o link dele fora?
> > > Veja
> > > > se ele pode te mandar a rota default apenas se estiver recebendo do
> > > > upstream dele (no Mikrotik seria "if installed")
> > > >
> > > > Voce ja observou o AS-PATH da rota default com o provedor A
> funcionando
> > > ou
> > > > sem funcionar? Se ela mudar, da para fazer uma gambi via filtro.
> > > >
> > > > Outra opção é pedir a esse provedor A que te mande rota full sem
> > default.
> > > > Ai se o upstream dele cair, some todas as rotas e a default com o
> > > provedor
> > > > B assume
> > > >
> > > > []s
> > > > !3runo
> > > >
> > > > --
> > > > Cursos e Consultoria BGP e OSPF
> > > > ________________________________
> > > > De: gter <gter-bounces at eng.registro.br> em nome de Danilo Augusto <
> > > > danilo at iotecnologia.com.br>
> > > > Enviado: terça-feira, 9 de março de 2021 20:32
> > > > Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
> > > > gter at eng.registro.br>
> > > > Assunto: [GTER] Redundância automática em BGP multihomed
> > > >
> > > > Pessoal, boa noite
> > > >
> > > > Minha organização é multihomed com 2 provedores (A e B). Tenho um
> bloco
> > > /24
> > > > e uso rota padrão.
> > > >
> > > > Quando o provedor A tem problemas no acesso à Internet, eu continuo
> > > saindo
> > > > por ele pois o peering permanece estabelecido e ele continua
> propagando
> > > as
> > > > rotas BGP pra mim. Isso é um problema, pois o meu BGP não consegue
> > > perceber
> > > > a queda e por isso continua tentando sair pelo provedor A. Afinal, a
> > > queda
> > > > não repercute no protocolo de roteamento.
> > > >
> > > > Vocês conhecem algo que possa me ajudar a fazer o chaveamento
> > automático
> > > > entre o provedor A e o provedor B quando ocorrer alguma
> > indisponibilidade
> > > > ou intermitência como a do cenário acima?
> > > >
> > > > Desde já agradeço a todos que puderem me ajudar.
> > > >
> > > >
> > > > --
> > > > Danilo Augusto
> > > > *Este e-mail deixará de funcionar.*
> > > > *Envie para daniloaugusto.ax at gmail.com <daniloaugusto.ax at gmail.com>*
> > > > Natal/RN (84) 98109-6177
> > > > --
> > > > 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
> > >
> >
> >
> > --
> > Danilo Augusto
> > *Este e-mail deixará de funcionar.*
> > *Envie para daniloaugusto.ax at gmail.com <daniloaugusto.ax at gmail.com>*
> > Natal/RN (84) 98109-6177
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>