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

Lun Nov 30 20:58:48 -03 2020

Mauricio,

Definitivamente hay muchas razones técnicas para no enviar el superbloque.
Por eso pregunté cuál era el motivo para hacerlo. Si no hay un motivo
técnico siempre es mejor enviar el agregado.

Tomás

On Mon, Nov 30, 2020 at 12:02 PM Mauricio Vergara <
mauricio.vergara en icann.org> wrote:

> 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
>
> _______________________________________________
> 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/1f9ec437/attachment-0001.htm>