<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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 class="moz-cite-prefix">On 28/06/2023 15:12, Douglas Fischer
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKEr4RQJ8_h=EeCwLUPTk6bwa4dbAxXOpNhkF0ovHAVgf63fRQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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 class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
</body>
</html>