[GTER] [caiu] AS19611 anunciando toda a tabela para a Level 3

[Douglas Fischer]

Obrigado pelo relato Marcelo!

Parabéns à você pela pró-atividade e ao pessoal
da Unisinos por estar prontos a atender o INOC.


Pois é, depois desse relato podemos chegar à conclusão que o RPKI não
resolveria.
Mas ainda assim não desacredito do uso dessa ferramenta.

Sequestros de prefixos e lambanças por problemas com IGP seriam evitados.



Em 25 de julho de 2014 12:38, Marcelo Balbinot <marcelo at gegnet.com.br>
escreveu:

> Douglas,
>
> Na verdade, a Unisinos não estava originando os anúncios, estava sim
> exportando todos os prefixos da sua tabela para a level 3, prefixos esses,
> que aprendeu de suas conexões com o PTT-RS (ao qual também estou
> conectado), UFRS (que aprendia da rnp, que por sua vez aprendia do PTT-SP
> ao qual também estou conectado).
>
> No meu primeiro teste, vi no route-server.he.net que nossos prefixos
> chegavam "3549 19611 53062",
> verifiquei e vi que o AS19611 estava no PTT-RS, então parei minha conexão
> com o PTT-RS.
>
> Verifiquei novamente no lg da he e nossos prefixos continuavam chegando
> como trânsito pela Unisinos "3549 19611 2716 1916 53062".
>
> Parei nossa conexão com PTT-SP (pois tenho anúncios menores por lá) e
> entrei em contato com a Unsinos (via INOC, muito útil).
>
> Eles estavam ativando um circuito com a L3, então solicitei a eles que
> derrubassem a sessão BGP e verificassem suas politicas de export.
>
> Sobre o problema, eu particularmente, uso filtros baseados em
> prefix-lists, as-path, communities e prefix-limit.
>
> Se listas são inviáveis para provedores de grande porte, acho que pelo
> menos um simples prefix-limit deveria sempre ser implementado.
>
> []'s
>
> ---
>
> Marcelo Balbinot
> GegNET Telecomunicações
> Operação de Redes e Serviços IP
> AS 53062
> INOC-DBA 53062*200
>
> Em 2014-07-25 10:40, Douglas Fischer escreveu:
>
>  Desculpe...
>> Pelo que entendi, não foi trânsito pura e simplesmente.
>>
>> P.S.: Tá Aí! Seria legal haver um relato oficial do ocorrido. Das
>> múltiplas
>> partes.
>>       Sem caça às bruxas, apenas para promover o aprendizado com o
>> equívoco
>> alheio.
>>
>> Pelo que andei vendo, o que aconteceu foi que ele redistribui todos os
>> blocos que recebeu como se fossem dele.
>> E sendo assim, como eram todos prefixos miúdos(por causa do PTT) e o
>> AS-Path ficou bem curtinho (Orgin-AS sendo ele mesmo) todo mundo começou a
>> preferir as rotas dele.
>>
>>    O que já me aconteceu(mas não deixei vazar para a internet)
>>    foi que o BGP estava sendo redistribuído para um IGP em um
>>    dos Border-Routers(EIGRP no meu caso) e o IGP redistribuiu
>>    todos aqueles blocos para o outro Border-Router, e aquilo
>>    tudo caiu para o BGP.
>>    Por sua vez, o BGP repassou tudo aquilo para o outro
>>    trânsito como se ele fosse o Origin-AS daqueles blocos.
>>       Na verdade não repassou eu havia
>>       aplicado um filtro para meus blocos.
>>
>> \SE/ o que aconteceu com eles foi o mesmo que aconteceu comigo, e
>> \SE/ a operadora tivesse filtrado com base em RPKI, o filtro diria:
>>   "Ei, mas você não é o dono do prefixo 8.8.8.0/24.
>>    Não vou aceitar essa rota!
>>    Seu roteador bobo, feio, e chato!"
>>
>>
>>
>> Em 25 de julho de 2014 10:13, Frederico A C Neves <fneves at registro.br>
>> escreveu:
>>
>>  Douglas,
>>>
>>> On Fri, Jul 25, 2014 at 08:56:17AM -0300, Douglas Fischer wrote:
>>> ...
>>> >
>>> > No caso específico da Unisinos, salvo engano, o source das rotas
>>> > redistribuídas era "?" confere?
>>> > O RPKI não teria protegido a Internet nesse caso?
>>>
>>> Este evento, como o outro que você cita, novamente foi alguém dando
>>> trânsito que não devia. Não, RPKI, somente com validação de origem,
>>> não ajuda em nada.
>>>
>>> Fred
>>> --
>>> 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