[LAC-TF] Preguntas: Anuncios BGP IPv6 regionales/internacionales?

Arturo Servin arturo.servin at gmail.com
Thu Jun 8 14:46:17 BRT 2017


>Podrías explicarme porque no se debería usar el mismo ASN?

En general se espera que un ASN tenga una politica de ruteo y esta sea
uniforme en todos los puntos donde se interconecta.

En este caso tu politica es diferente (cada punto anuncia cosas diferentes)
en cada punto y estos no estan conectados entre si, entonces es como que
cada punto sea independiente uno de otro y lo mejor sea usar un AS por
localidad.

Un solo ASN te va a funcionar pero quiza no es lo recomendable/prolijo a
hacer.

.as

On Thu, 8 Jun 2017 at 10:29 Nick Pais <nick at nickserver.net> wrote:

> Nicolas,
>
> Podrías explicarme porque no se debería usar el mismo ASN?
>
> Por lo que entendí, terminaría siendo algo así:
>
> SanFran:
> 2001:db8:100::/40 (sitio)
> 2001:db8::/32 (agg para network visibility)
>
> Buenos Aires:
> 2001:db8:200::/40
>
> PTT.br:
> 2001:db8:300::/40
>
> Todos bajo el mismo ASN de ARIN.
>
> Tal vez en PTT.br se podría anunciar el /32 ahí también y levantar iBGP?
>
> 2017-06-07 11:08 GMT-03:00 Nicolas Antoniello <nantoniello at gmail.com>:
>
>> El problema (tal vez no entendí del todo lo que planteas) es que si las
>> redes son disjuntas en Internet, no deberías utilizar el mismo ASN...
>> entonces con que ASN publicarías los bloques de las -demás- redes (las de
>> fuera de USA en tu ejemplo)??
>>
>> Saludos,
>> Nico
>>
>>
>>
>> El El mar, 6 de jun. de 2017 a las 14:40, Nick Pais <nick at nickserver.net>
>> escribió:
>>
>>> Sobre obtener recursos (tanto ASN y direcciones) de el RIR local sólo lo
>>> he visto en empresas/proveedores mucho más grande de lo que estoy
>>> presentando. Más en realidad sobre el ASN, ya que direcciones he visto
>>> asignada de LACNIC a un AS de ARIN.
>>>
>>> De momento anunciando prefijos más específicos suena más apetitoso...
>>> Aunque igual, no me opongo del todo a tener que obtener recursos de los RIR
>>> locales, pero si se debate un tema de costos para un despliegue inicial, es
>>> más lógico los anuncios más específicos, por lo menos para empezar.
>>>
>>> Gracias por las respuestas!
>>>
>>>
>>> 2017-06-06 14:26 GMT-03:00 JORDI PALET MARTINEZ <
>>> jordi.palet at consulintel.es>:
>>>
>>>> De hecho, diría que es lo más lógico y razonable, tener espacio en cada
>>>> región RIR donde trabajes …
>>>>
>>>> Saludos,
>>>> Jordi
>>>>
>>>>
>>>> -----Mensaje original-----
>>>> De: LACTF <lactf-bounces at lacnic.net> en nombre de Nicolas Antoniello <
>>>> nantoniello at gmail.com>
>>>> Responder a: <lactf at lac.ipv6tf.org>
>>>> Fecha: martes, 6 de junio de 2017, 19:15
>>>> Para: <lactf at lac.ipv6tf.org>
>>>> Asunto: Re: [LAC-TF] Preguntas: Anuncios BGP IPv6
>>>> regionales/internacionales?
>>>>
>>>>     También se pueden pedir direcciones y otro ASN al RIR local.
>>>>     :)
>>>>
>>>>     La solución de tuneles es cuando menos poco práctica, poco óptima y
>>>> puede ser una locura de administrar.
>>>>
>>>>     Saludos,
>>>>     Nicolas
>>>>
>>>>
>>>>     El El mar, 6 de jun. de 2017 a las 13:29, Carlos M. Martinez <
>>>> carlosm3011 at gmail.com> escribió:
>>>>
>>>>
>>>>     Hay diferentes formas de resolver ese problema. En realidad, no hay
>>>>     problema en anunciar un /40, hasta /48 podes bajar tranquilamente.
>>>> Lo
>>>>     mas fácil es anunciar pedazos diferentes desde cada “pop”,
>>>>     eventualmente anunciando el /32 entero desde uno de los lugares.
>>>>
>>>>     También podrías levantarte túneles entre los pops para poder usar tu
>>>>     iBGP de mejor manera.
>>>>
>>>>     Se de operadores que hacen cosas así, capaz que alguno puede
>>>> comentar
>>>>     detalles.
>>>>
>>>>     s2
>>>>
>>>>     Carlos
>>>>
>>>>     On 6 Jun 2017, at 13:17, Nick Pais wrote:
>>>>
>>>>     > Lista, buenos días/tardes.
>>>>     >
>>>>     > Les vengo con unas preguntas que me viene comiendo la cabeza ya
>>>> hace
>>>>     > un
>>>>     > tiempo, dado de que no puedo encontrar información "sólida" al
>>>>     > respecto.
>>>>     >
>>>>     > Todo lo siguiente es un caso hipotético:
>>>>     >
>>>>     > La empresa Pepe Inc. es una empresa establecida en USA con su
>>>> espacio
>>>>     > de IP
>>>>     > otorgado por ARIN, un /32. De momento, sólo venía anunciando su
>>>> /32
>>>>     > entero
>>>>     > en San Francisco. Tiene servicios de colocation y en su
>>>> planeamiento
>>>>     > de
>>>>     > IPv6 ha otorgado un /40 (internamente) para ese sitio. Tiene a
>>>>     > Hurricane
>>>>     > Electric como transit provider. Usa su propio ASN asignado por
>>>> ARIN.
>>>>     >
>>>>     > Pepe Inc. crece de tal manera que se expande internacionalmente y
>>>>     > decide
>>>>     > hacer colocation en Buenos Aires. Decide de que quiere asignar
>>>> otro
>>>>     > /40
>>>>     > (del /32 anteriormente) en Buenos Aires y tiene a Level3 como
>>>> transit
>>>>     > provider. Usa el mismo ASN mencionado arriba. Unos meses después,
>>>>     > expande a
>>>>     > Brasil y se conecta al IXP en São Paulo.
>>>>     >
>>>>     > En éste caso hipotético, por cuestiones de costo, no hay un enlace
>>>>     > directo
>>>>     > entre los dos sitios directamente, sino que dependería de Internet
>>>>     > mismo
>>>>     > para llegar al "otro lado" de si mismo.
>>>>     >
>>>>     > Mi pregunta es: Cómo hacen para anunciar ese /32 pero poder
>>>> usarlo en
>>>>     > diferentes puntos del mundo? Tengo presente que el anuncio mínimo
>>>>     > (máximo?)
>>>>     > para un ISP es un /32, pero qué pasa cuando tienen dos sitios
>>>>     > diferentes y
>>>>     > anuncian así?
>>>>     >
>>>>     > - Sería necesario desplegar iBGP en éste caso? Cómo sería?
>>>>     > - Se debería anunciar los /40 en los sitios regionales en vez de
>>>> el
>>>>     > /32? O
>>>>     > se debería anunciar ambos prefijos (tanto el /32 y el más
>>>>     > específico /40 en
>>>>     > su respectivo sitio regional)?
>>>>     > - Si se anunciara el /32 en ambos lados y usaría iBGP entre las
>>>> dos
>>>>     > PoP, no
>>>>     > agregaría demasiada latencia por tener que llegar de una punta a
>>>> la
>>>>     > otra?
>>>>     > - La pregunta más importante de todas: Es posible tener un
>>>> scenario
>>>>     > así?
>>>>     >
>>>>     > Agradezco sus comentarios, saludos!
>>>>     > _______________________________________________
>>>>     > LACTF mailing list
>>>>     > LACTF at lacnic.net
>>>>     > https://mail.lacnic.net/mailman/listinfo/lactf
>>>>     > Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>>>>     _______________________________________________
>>>>     LACTF mailing list
>>>>     LACTF at lacnic.net
>>>>     https://mail.lacnic.net/mailman/listinfo/lactf
>>>>     Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>>>>
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     LACTF mailing list
>>>>     LACTF at lacnic.net
>>>>     https://mail.lacnic.net/mailman/listinfo/lactf
>>>>     Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>>>>
>>>>
>>>>
>>>>
>>>> **********************************************
>>>> IPv4 is over
>>>> Are you ready for the new Internet ?
>>>> http://www.consulintel.es
>>>> The IPv6 Company
>>>>
>>>> This electronic message contains information which may be privileged or
>>>> confidential. The information is intended to be for the use of the
>>>> individual(s) named above. If you are not the intended recipient be aware
>>>> that any disclosure, copying, distribution or use of the contents of this
>>>> information, including attached files, is prohibited.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> LACTF mailing list
>>>> LACTF at lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>>> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>>>>
>>>
>>> _______________________________________________
>>> LACTF mailing list
>>> LACTF at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>>>
>>
>> _______________________________________________
>> LACTF mailing list
>> LACTF at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lactf
>> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>>
>>
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf
> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20170608/dd47d89d/attachment.html>


More information about the LACTF mailing list