[lacnog] Blackhole announcements larger than /32

[Fernando Frediani]

Exactamente Douglas, esta es la razón.
Al permitir más anuncios agregados que /32, se reduce el número de rutas 
en la FIB.

El tema de estar en una sesión separada o en la misma sesión BGP solo 
marcando community creo que no hace ninguna diferencia en este contexto 
si la intención es reducir el número de rutas en la FIB y resumir todos 
aquellos bloques que no están en uso por el Downstream.

Si un bloque, digamos /26, está actualmente en completo desuso por parte 
de un Downstream, ¿por qué generar 64 anuncios en lugar de solo uno 
cuando el objetivo es no recibir tráfico a esas IP?
Al final, como dije, quién sabe si todas las IP están en uso o no es 
quien origina los anuncios de BH, por lo que no debería haber ninguna 
preocupación al respecto de bloqueos indebidos.

Pero la pregunta principal es: ¿hay alguna preocupación o prejuicio por 
parte de Upstream que acepta estos tamaños de anuncios para no hacerlo? 
¿Por qué siempre se ha acordado /32

Fernando

On 28/06/2023 15:12, Douglas Fischer wrote:
> Por lo que tengo como referencia, el deseo que tienen los Downstreams 
> de que sus Upstreams acepten prefijos mayores a /32 en RTBH 
> básicamente se deriva de una sola razón... No exceder el Prefix-Limit 
> de la sesión.
>
> Downstream anuncia 200-210 rutas y quiere liberar un límite de 1000 
> prefijos para poder anunciar até uns 600-700 IPv4 em BH sem que caia a 
> sessão.
> Las empresas que valoran su reputación nunca aceptarán un número tan 
> grande.
> Entonces, para evitar esto, los downstream mais criativos intentan 
> sumarizar y enviarlo.
> Creo que esto no tiene sentido y estoy en contra de la idea.
>
> Sobre el argumento del número de rutas en la FIB...
> Este es un problema INTERNO del ASN. Si el operador va a sumarizar o 
> no las rutas para guardar FIB... Es una decisión que va a tomar cada 
> operador de red de acuerdo con lo que sabe de los recursos de sus equipos.
>
>
> Personalmente, me gusta más la idea de una sesión BGP dedicada para 
> manejar este tipo de cosas(unwanted traffic).
> Esta sesión podría incluso abordar IPv4 AFI, IPv6 AFI.
> Y talvez hasta AFI de FlowSpec si la empresa cree que esto es una 
> ventaja competitiva para ella.
>
> Al tratarse esto de forma centralizada, es posible imponer un rigor 
> más intenso en el filtrado de las rutas recibidas.
> Y en este caso, la preocupación por desbordar el límite de prefijos de 
> la sesión principal deja de existir.
>
> Em seg., 19 de jun. de 2023 às 11:10, Fernando Frediani 
> <fhfrediani en gmail.com> escreveu:
>
>     Hello folks
>
>     I wanted to consult the community about a topic that has been around
>     for a while.
>     Normally when announcing prefixes to an Upstream it is commonly used
>     /32 only which works for a short amount of IP unused addresses but
>     when you or your Downstream customers have a larger amount to be
>     announced it starts to get a lot of prefixes in that BGP session.
>
>     What downsides do you see in companies allowing announcements marked
>     with the blackhole community (or through a dedicated BH server) to
>     accept prefixes larger than /32 (up to /25) in order to facilitate the
>     consolidation of some unused larger prefixes ?
>
>     Thanks
>     Fernando Frediani
>     _______________________________________________
>     LACNOG mailing list
>     LACNOG en lacnic.net
>     https://mail.lacnic.net/mailman/listinfo/lacnog
>     Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
>
> -- 
> 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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20230628/c71c8aaf/attachment.htm>