<div>También se pueden pedir direcciones y otro ASN al RIR local.</div><div>:)</div><div><br></div><div>La solución de tuneles es cuando menos poco práctica, poco óptima y puede ser una locura de administrar.</div><div><br></div><div>Saludos,</div><div>Nicolas</div><div><br></div><div><br><div class="gmail_quote"><div>El El mar, 6 de jun. de 2017 a las 13:29, Carlos M. Martinez <<a href="mailto:carlosm3011@gmail.com">carlosm3011@gmail.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hay diferentes formas de resolver ese problema. En realidad, no hay<br>
problema en anunciar un /40, hasta /48 podes bajar tranquilamente. Lo<br>
mas fácil es anunciar pedazos diferentes desde cada “pop”,<br>
eventualmente anunciando el /32 entero desde uno de los lugares.<br>
<br>
También podrías levantarte túneles entre los pops para poder usar tu<br>
iBGP de mejor manera.<br>
<br>
Se de operadores que hacen cosas así, capaz que alguno puede comentar<br>
detalles.<br>
<br>
s2<br>
<br>
Carlos<br>
<br>
On 6 Jun 2017, at 13:17, Nick Pais wrote:<br>
<br>
> Lista, buenos días/tardes.<br>
><br>
> Les vengo con unas preguntas que me viene comiendo la cabeza ya hace<br>
> un<br>
> tiempo, dado de que no puedo encontrar información "sólida" al<br>
> respecto.<br>
><br>
> Todo lo siguiente es un caso hipotético:<br>
><br>
> La empresa Pepe Inc. es una empresa establecida en USA con su espacio<br>
> de IP<br>
> otorgado por ARIN, un /32. De momento, sólo venía anunciando su /32<br>
> entero<br>
> en San Francisco. Tiene servicios de colocation y en su planeamiento<br>
> de<br>
> IPv6 ha otorgado un /40 (internamente) para ese sitio. Tiene a<br>
> Hurricane<br>
> Electric como transit provider. Usa su propio ASN asignado por ARIN.<br>
><br>
> Pepe Inc. crece de tal manera que se expande internacionalmente y<br>
> decide<br>
> hacer colocation en Buenos Aires. Decide de que quiere asignar otro<br>
> /40<br>
> (del /32 anteriormente) en Buenos Aires y tiene a Level3 como transit<br>
> provider. Usa el mismo ASN mencionado arriba. Unos meses después,<br>
> expande a<br>
> Brasil y se conecta al IXP en São Paulo.<br>
><br>
> En éste caso hipotético, por cuestiones de costo, no hay un enlace<br>
> directo<br>
> entre los dos sitios directamente, sino que dependería de Internet<br>
> mismo<br>
> para llegar al "otro lado" de si mismo.<br>
><br>
> Mi pregunta es: Cómo hacen para anunciar ese /32 pero poder usarlo en<br>
> diferentes puntos del mundo? Tengo presente que el anuncio mínimo<br>
> (máximo?)<br>
> para un ISP es un /32, pero qué pasa cuando tienen dos sitios<br>
> diferentes y<br>
> anuncian así?<br>
><br>
> - Sería necesario desplegar iBGP en éste caso? Cómo sería?<br>
> - Se debería anunciar los /40 en los sitios regionales en vez de el<br>
> /32? O<br>
> se debería anunciar ambos prefijos (tanto el /32 y el más<br>
> específico /40 en<br>
> su respectivo sitio regional)?<br>
> - Si se anunciara el /32 en ambos lados y usaría iBGP entre las dos<br>
> PoP, no<br>
> agregaría demasiada latencia por tener que llegar de una punta a la<br>
> otra?<br>
> - La pregunta más importante de todas: Es posible tener un scenario<br>
> así?<br>
><br>
> Agradezco sus comentarios, saludos!<br>
> _______________________________________________<br>
> LACTF mailing list<br>
> <a href="mailto:LACTF@lacnic.net" target="_blank">LACTF@lacnic.net</a><br>
> <a href="https://mail.lacnic.net/mailman/listinfo/lactf" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lactf</a><br>
> Cancelar suscripcion: <a href="mailto:lactf-unsubscribe@lacnic.net" target="_blank">lactf-unsubscribe@lacnic.net</a><br>
_______________________________________________<br>
LACTF mailing list<br>
<a href="mailto:LACTF@lacnic.net" target="_blank">LACTF@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lactf" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lactf</a><br>
Cancelar suscripcion: <a href="mailto:lactf-unsubscribe@lacnic.net" target="_blank">lactf-unsubscribe@lacnic.net</a><br>
</blockquote></div></div>