[GTER] Problemas BGP Multihoming em cliente

[Bruno Cabral]

Se entendi direito esta anunciando um /24 específico só pro ptt, outro pra algar e outro pra vianet?

Penso que nao deveria ser assim. Devia anunciar um /23 pra cada operadora (mais o /22 pras duas) e 4 /24 pro ptt, inclusive porque ptt não é transito pra uma rede ser anunciada só nele

Se tem as rotas do ptt, o default vai independer se os anúncios estiverem corretos

!3runo
--
Cursos e Consultoria BGP e OSPF
________________________________
De: gter <gter-bounces at eng.registro.br> em nome de Clistenes Viana <cviana at vianet.com.br>
Enviado: quarta-feira, 5 de setembro de 2018 10:53:14
Para: gter at eng.registro.br
Assunto: [GTER] Problemas BGP Multihoming em cliente

Bom dia pessoal,

Não sei se alguém já passou por isso ou tem alguma dica a respeito, o
provedor onde trabalho passou a ser trânsito de outro provedor,
solicitamos a atualização dos filtros aos nossos upstreams com o AS do
nosso cliente, estabelecemos sessão via bgp sem problemas, mas estamos
passando pelos seguintes problemas:



[BGP/ALGAR]  [BGP/PTT-SP]     [BGP/VIANET]
    |             |                |
-----------------------------------------------------------
|                     BORDA CLIENTE                       |
|                                                         |
|      eth2      eth3          eth4      eth5             |
-----------------------------------------------------------
        |         |             |         |
     92.0/24     93.0/24     94.0/24    95.0/24


Anúncios: x.x.92.0/22 para Algar, x.x.94.0/24 para Vianet e x.x.95.0/24
para o PTT-SP, o cliente esta descartando o full routing nosso e da
Algar e recebendo apenas rota default com pesos diferentes, do PTT-SP
está descartando a rota default, prefixos dele mesmo, e dos upstreams
(Algar/Vianet), e recebendo o restante.

1. No cenário em que a rota default via bgp com peso maior para Algar,
funciona tudo que está embaixo dos blocos x.x.92.0/24, x.x.93.0/24 e
x.x.95.x/24, mas pacotes com origem do bloco x.x.94.0/24 não passam da
borda do cliente.

ip origem: x.x.94.150/24
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  _gateway (x.x.94.254)  0.300 ms  0.269 ms  0.253 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *

2. No cenário em que a rota default via bgp com pesor para Vianet,
funciona tudo que está embaixo do bloco x.x.94.0/24, mas tudo que está
embaixo dos blocos x.x.92.0/24, x.x.93.0/24, completam os traces para o
destino, icmp, etc, mas a navegação fica lenta, embaixo do bloco
x.x.95.0/24 também completa trace, icmp, etc, e a navegação fica um
pouco melhor, mas ainda com certa lentidão.

ip origem: x.x.92.150/24
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  _gateway (x.x.92.254)  0.177 ms  0.141 ms  0.156 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  ix0.exo.vianet.srv.br (187.95.54.254)  4.574 ms  4.510 ms  4.439 ms
 9  as53090.saopaulo.sp.ix.br (187.16.222.153)  4.228 ms  4.189
ms  4.118 ms
10  as15169.saopaulo.sp.ix.br (187.16.216.55)  6.608 ms  6.610
ms  6.571 ms
11  108.170.245.129 (108.170.245.129)  5.208 ms 108.170.245.161
(108.170.245.161)  5.203 ms 108.170.245.129 (108.170.245.129)  5.408 ms
12  108.170.232.41 (108.170.232.41)  5.363 ms 72.14.236.1
(72.14.236.1)  5.611 ms 66.249.95.129 (66.249.95.129)  5.118 ms
13  google-public-dns-a.google.com (8.8.8.8)  5.207 ms  5.178 ms  5.143
ms

Assemelhasse com problemas de RPF (Reverse path forwarding), mas nós
não temos nenhum roteador com o protocolo ativado e a Algar também
garantiu que não.

Desde já agradeço qualquer ajuda,

Att,
Clistenes S Viana
Engenharia de Redes
Vianet Telecomunicações

--
gter list    https://eng.registro.br/mailman/listinfo/gter