[lacnog] Mess up - IRR de prefixos brasileiros - EMIX(ChinaTel) - Neustar - Internexa

Nicolas Antoniello nantoniello en gmail.com
Mie Mar 4 11:54:54 GMT+3 2020


Desde mi punto de vista, para que nos quede más claro a todos y en la misma
línea que menciona Carlos:

- Entiendo que el IRR desarrollado por Lacnic si soporta la creación de
AS-SETs.
- Lo de generar automáticamente AS-SETs para los clientes se me ocurre
muuuuuy difícil sin meterse y conocer la red del cliente... no recuerdo
IRRs que lo hagan automáticamente... ni IRRs (sin ser el de Lacnic) que
genere prácticamente nada automáticamente.

Saludos,
Nico



El El mié, mar. 4, 2020 a la(s) 11:40, Carlos M. Martinez <
carlosm3011 en gmail.com> escribió:

> Hi all,
>
> Just a clarification: LACNIC’s IRR does support AS-SETs, but
> operators/users need to create them.
>
> Our IRR is “mostly automatic” in the sense that route/route6 objects and
> maintainers are synthesized based on RPKI and WHOIS data.
>
> However, unlike route/route6 and maintainers, our IRR cannot synthesize
> AS-SETs for our users.
>
> Our IRR is still in its infancy (it has been in production for less than
> three months) but I hope when the word gets out we will see significant
> uptake of this tool.
>
> If there are any specific, architectural or service questions regarding
> LACNIC’s IRR please refer directly to us LACNIC staff.
>
> Cheers!
>
> /Carlos
>
> On 3 Mar 2020, at 9:00, Arturo Servin wrote:
>
> Douglas
>
> Thanks for getting this stats and bringing awareness that there is a lot
> to do in LATAM.
>
> I have these stats that I have presented in some fora in the past few
> months, these represent the percentage of valid prefixes (according to IRR
> data.) As you can see LATAM (69.11%) is way behind the rest of the regions
> and the global average of 86%.We are working to include LACNIC IRR so stats
> might improve soon but I am not sure how much as the IRR does not have
> AS-SETs and I would bet that a good chunk of invalid are coming from ASs
> that provide transit services to other ASNs (so AS-origin is not enough to
> validate.)
>
> [image: Initial Experiences Route Filtering at the Edge AS15169.png]
>
> Some places to check your prefixes:
>
>    - IRR Explorer NLNOG: http://irrexplorer.nlnog.net/
>    - RIPE RIS Routing Consistency:
>    https://stat.ripe.net/widget/as-routing-consistency
>
>
> Finally, Google is in the process to start filtering all invalid prefixes
> that do not match any IRR entry, so I recommend that if you peer with
> AS15169 you take a look if your prefixes are validated (Google ISP Portal
> https://isp.google.com/bgp/ and check your AS-SET in PeeringDB)
>
> Regards
> as
>
>
>
>
>
>
> On Mon, Mar 2, 2020 at 9:39 PM Douglas Fischer <fischerdouglas en gmail.com>
> wrote:
>
>> Acabei de criar mais uma visão sumarizada de quem está criando sujeira
>> nos IRRs, especificamente nos prefixos brasileiros.
>>  ->
>> https://docs.google.com/spreadsheets/d/1RXqzCP2uN-dZ1hRkridm4EBg4_6tYC09Y8ZAW68JSf8/
>> Esse arquivo nos mostra or Objetos IRR Route: e Route6: classificados com
>> INVALID e UNEEDED em 2020-03-01
>>
>> O 5 maintainers que mais tem criados registros INVALID de prefixos BR são:
>> Maint          | Name                   | INVALID | UNEEDED |
>> MAINT-AS8966   | Emirates IX - ChinaTel |    2511 |       2 |
>> MAINT-AS7786   | NeuStar                |     887 |         |
>> MAINT-AS18678  | Internexa              |     670 |     605 |
>> MAINT-SAMM     | SAMM CCR               |     140 |      80 |
>> MAINT-NRT-BB   | NOROESTECOM            |      60 |       3 |
>>
>> P.S.:
>> Procedimento de como se chegou a essas informações detalhado nessa troca
>> de e-mail
>> https://mail.lacnic.net/pipermail/lacnog/2020-February/007809.html
>>
>>
>> Eu preciso agradecer e parabenizar as equipes das empresas:
>>  - G8 Networks
>>  - Nexusguard
>> Desde a análise que eu havia feito no dia 13-Feb-2019 [1] tive a
>> oportunidade de conversar com pessoas dessas duas empresas, e eles fizeram
>> esforços e corrigiram/eliminaram grande parte dos registros incorretos que
>> eles haviam criados.
>> Esta, em minha opinião, deve ser a postura de operadores de rede. Estando
>> abertos a informações, validando, e corrigindo se cabível.
>>
>>
>>
>>
>> [1]
>> https://docs.google.com/spreadsheets/d/1XxUI2_JcKgkg5CniRi1E3ieEu9HgRJCfYfaH3hTIaHg/
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20200304/3a0cb47f/attachment-0001.html>


Más información sobre la lista de distribución LACNOG