<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Fernando,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Yendo a la pregunta: creo que hay algunos upstreams que aceptan enviar prefijos menores que /32 para hacer black hole. Sobre por qué se eligió un /32, es para evitar enviar prefijos menores que puedan enviar a null a IPs que no estén siendo atacadas. Sin embargo no creo que haya una RFC/BCP que obligue/recomiende un /32.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Creo que tiene la misma lógica de porqué el prefijo mayor que se acepta es un /24. Están basadas en las antiguas clases C y direcciones de host traducidas a CIDR sin ninguna otra lógica detrás.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Saludos,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Tomás Lynch</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 28, 2023 at 2:23 PM Fernando Frediani <<a href="mailto:fhfrediani@gmail.com">fhfrediani@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Exactamente Douglas, esta es la razón.<br>
Al permitir más anuncios agregados que /32, se reduce el número de
rutas en la FIB.<br>
<br>
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.<br>
<br>
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?<br>
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.</p>
<p>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</p>
<p>Fernando<br>
</p>
<div>On 28/06/2023 15:12, Douglas Fischer
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.<br>
<br>
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.<br>
Las empresas que valoran su reputación nunca aceptarán un número
tan grande.<br>
Entonces, para evitar esto, los downstream mais
criativos intentan sumarizar y enviarlo.<br>
Creo que esto no tiene sentido y estoy en contra de la idea.<br>
<br>
Sobre el argumento del número de rutas en la FIB...<br>
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.<br>
<br>
<br>
Personalmente, me gusta más la idea de una sesión BGP dedicada
para manejar este tipo de cosas(unwanted traffic).<br>
Esta sesión podría incluso abordar IPv4 AFI, IPv6 AFI.<br>
Y talvez hasta AFI de FlowSpec si la empresa cree que esto es
una ventaja competitiva para ella.<br>
<br>
Al tratarse esto de forma centralizada, es posible imponer un
rigor más intenso en el filtrado de las rutas recibidas.<br>
Y en este caso, la preocupación por desbordar el límite de
prefijos de la sesión principal deja de existir.<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Em seg., 19 de jun. de 2023 às
11:10, Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.com</a>>
escreveu:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello
folks<br>
<br>
I wanted to consult the community about a topic that has been
around<br>
for a while.<br>
Normally when announcing prefixes to an Upstream it is
commonly used<br>
/32 only which works for a short amount of IP unused addresses
but<br>
when you or your Downstream customers have a larger amount to
be<br>
announced it starts to get a lot of prefixes in that BGP
session.<br>
<br>
What downsides do you see in companies allowing announcements
marked<br>
with the blackhole community (or through a dedicated BH
server) to<br>
accept prefixes larger than /32 (up to /25) in order to
facilitate the<br>
consolidation of some unused larger prefixes ?<br>
<br>
Thanks<br>
Fernando Frediani<br>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">Douglas Fernando Fischer<br>
Engº de Controle e Automação<br>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
LACNOG mailing list
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div>