[lacnog] [Ext] Agregación /22 (Era Re: Validación de prefijo)

Mauricio Vergara mauricio.vergara en icann.org
Lun Nov 30 14:01:59 -03 2020 

Hola Tomas!

 

Sólo como anécdota, en IMRS ocupamos la práctica de publicar nuestro mismo bloque Anycast  con un /23 y /24 al mismo tiempo.

Esto nos da flexibilidad de poder alejar o hacer menos específico nuestro bloque en caso de DDoS y es una alternativa extra a usar prepend dependiendo de con quién estemos haciendo peering.

 

Saludos!

 

-- 

Mauricio Vergara Ereche

Lead DNS Engineer

ICANN

 

 

From: LACNOG <lacnog-bounces en lacnic.net> on behalf of Tomas Lynch <tomas.lynch en gmail.com>
Reply-To: Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>
Date: Friday, November 27, 2020 at 15:23
To: Latin America and Caribbean Region Network Operators Group <lacnog en lacnic.net>
Subject: [Ext] [lacnog] Agregación /22 (Era Re: Validación de prefijo)

 

Jorge,

 

Vos podrías propagar 2x/23, 4x/24 o, lo más recomendable, un /22. Quagga no tendría problemas en hacerlo.

 

La pregunta es ¿por qué querés hacerlo? Aunque parezca muy poco, enviando un /22 en lugar de 4 /24s ayuda mucho a que la tabla global no crezca exponencialmente

 

Tomas Lynch

 

pd: Cambié el tema (subject) del correo para poder seguir este tema.

 

On Thu, Nov 26, 2020 at 11:02 AM Jorge Franco vía LACNOG <lacnog en lacnic.net> wrote:

Estimados, buenas tardes.

 

Mi nombre es Jorge y trabajo en Fibras Opticas del Oeste en Mendoza, Argentina.

 

Quiero efectuar una consulta, que actualmente tengo dudas de implementar.

 

Sobre nuestra infraestructura, tenemos virtualizado un router Quagga que es donde corre BGP. Nosotros tenemos asignados un /22 por LACNIC. Mi duda puntual, es si se pueden anunciar unicamente prefijos /24 en el Quagga. Actualmente tenemos publicados 2 /24 y después el /22 completo.

 

Saludos coordiales.

 

De: "Hernan Moguilevsky" <noc.hernan en gmail.com>
Para: "Latin America and Caribbean Region Network Operators Group" <lacnog en lacnic.net>
Enviados: Miércoles, 25 de Noviembre 2020 17:32:49
Asunto: Re: [lacnog] Validación de prefijo

 

Estimados,

 

Tomando en cuenta este hilo, he presentado una propuesta en el proceso de políticas de LACNIC para resolver el problema.

 

https://mail.lacnic.net/pipermail/politicas/2020-November/005967.html

 

 

Saludos.

 

 

El El vie, 30 oct. 2020 a la(s) 19:17, Ramon Flores <rfmairena en gmail.com> escribió:

Roque, es buena su consulta, me gustaría tener control del ROA de los IP que me asignó el proveedor. Así no hubiese tenido el inconvenientes, que por cierto ya se resolvió.

Saludos.

 

El vie., 30 oct. 2020 a las 10:00, Roque Gagliano (<rgaglian en gmail.com>) escribió:

Hola Alejandro,

 

En realidad el problema de Ramón se puede solucionar desde los sistemas de LACNIC. 

 

El caso es de un SP (el proveedor) que ha delegado un bloque de direcciones para otro cliente. En el modelo teórico de RPKI, el proveedor debería adoptar el modelo "delegado" de RPKI, administrar un CA y darle a Ramón la opción de administrar sus certificados y ROAs (sea de forma hosted o delegada).

 

Lo que no sé (pues hace tiempo que no uso el sistema) es si el sistema "hosted" de LACNIC le permitiría a Ramón de administrar sus certificados/ROAs siempre que el proveedor delegue los prefijos (agregando una CA en el sistema).

 

Saludos,

Roque




 

On Thu, Oct 29, 2020 at 5:52 PM Alejandro Acosta <alejandroacostaalamo en gmail.com> wrote:

teoría vs vida real :-)

On 10/29/20 12:01 PM, Nicolas Antoniello wrote:

Estimad en s,

 

De acuerdo con el comentario de Tomas.

Yo pienso que es algo muy normal el tener que dividir prefijos por varias razones operativas. Desde balancear tráfico (combinado con comunidades de BGP como no tránsito, etc...), temas puntuales de seguridad de ruteo (como cuando se produce un secuestro de rutas), etc.

 

Es decir, creo que son cosas diferentes y por ello existen ambas posibilidades de configuración en el sistema de RPKI (configurar cada prefijo y al mismo tiempo preever el grado máximo de des agregación que vamos a permitir).

 

Tal vez alguien me va tirar con algo por la cabeza por esta recomendación, pero creo que para alguien que recién comienza con RPKI o que no sabe a priori cuanto o cuando va a desagregar, puede ser recomendable setear el máximo en /24 para un prefijo IPv4 (y lo análogo para IPv6) 😊

 

Fraterno saludo,

Nico

 

 

 

El El jue, oct. 29, 2020 a la(s) 12:45, Tomas Lynch <tomas.lynch en gmail.com> escribió:

Como toda BCP se va a chocar con el día a día de la operación donde muchas empresas agregan y desagregan prefijos por distintos motivos en distintos tiempos (e.g. empresas que balancean tráfico por /24, que no digo que esté bien, pero es la realidad)

 

On Thu, Oct 29, 2020 at 10:06 AM Marcos Manoni <marcosmanoni en gmail.com> wrote:

Hola,

El mié., 28 oct. 2020 a las 13:39, Tomas Lynch
(<tomas.lynch en gmail.com>) escribió:
> El mayor error cuando crean los ROAs es no poner bien el max len. Esto lo estuvimos analizando en el último LACNOG.
>
> Simplificando, hay tres campos para llenar: sistema autónomo, el prefijo y la máxima longitud permitida. Mucha gente confunde la máxima longitud con el tamaño del prefijo y terminan poniendo lo mismo.

Ese comportamiento, más que error, está camino a ser una "best
practice". Lo que tiene que coincidir es el ROA con los anuncios BGP.
O sea, conviene hacer varios ROAs (1 por prefijo anunciado) en lugar
de pocos con máscara grande.

The Use of Maxlength in the RPKI
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpkimaxlen/
[...]whenever possible, operators SHOULD use "minimal ROAs" that
include only those IP prefixes that are actually originated in BGP,
and no other prefixes.

Saludos,
Marcos
_______________________________________________
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
_______________________________________________
LACNOG mailing list
LACNOG en lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog



-- 



At least I did something
Don Draper - Mad Men

_______________________________________________
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

-- 

HM


_______________________________________________
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/20201130/1ade3fba/attachment-0001.htm>
------------ próxima parte ------------
Se ha borrado un mensaje adjunto que no está en formato texto plano...
Nombre     : smime.p7s
Tipo       : application/pkcs7-signature
Tamaño     : 4624 bytes
Descripción: no disponible
Url        : <https://mail.lacnic.net/pipermail/lacnog/attachments/20201130/1ade3fba/attachment-0001.bin>

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