[LAC-TF] Preguntas: Anuncios BGP IPv6 regionales/internacionales?
Nick Pais
nick at nickserver.net
Thu Jun 8 20:19:51 BRT 2017
Nico,
Muchas gracias por la información detallada! Entiendo si que no es "lo
mejor", por eso lo planteaba en un caso hipotético.
Tendré la información en cuenta si se llegase a concretar.
Muchas gracias a todos!
2017-06-08 16:01 GMT-03:00 Nicolas Antoniello <nantoniello at gmail.com>:
> Hola Nick,
>
> En general los ASN públicos, al igual que las direcciones IP públicas
> están diseñados para ser únicos. Porque todos los protocolos (en este caso
> BGP) se basan en esa premisa a la hora de decidir.
>
> Que lo podes hacer, podés, no voy a decir que no... pero no creo que el
> único potencial problema que tengas sea el de los loops.
> Por ejemplo, si llegas a tener conexión con un mismo carrier en ambos
> sitios podes llegar a tener un probelma de que te descarten algunas rutas
> (pues vos no controlas lo que otros carriers aplican para evitar justamente
> loops de tráfico o casos que consideren sub-óptimos). Después, si utilizas
> iBGP en los sitios seguramente vas a tener un problema con eso de ver tu
> ASN como "sandwich" entre otros ASNs; o si tenés clientes BGP a los que les
> das tránsito van a estar un poco confundidos digamos si les das
> full-routing cuando vean ese sandwich de ASNs públicos repetidos y
> disjuntos en un mismo AS path y por otro lado vean que están directamente
> conectados a vos... y otras coas que ni quiero imaginarme ahora...
>
> Lo que estás planteando creo que es un caso raro (que en mi caso solo lo
> "valido" para anycast pero es otro tema porque las IP también son
> exactamente las mismas) y -seguro- es un caso que se sale de los
> estándares... creo que te va a dar más dolores de cabeza que otra cosa. Un
> ASN no es muy costoso y por lo general se paga por única vez por lo que
> sigo manteniendo la recomendación de ser -prolijo- a la hora de utilizar o
> participar del ruteo en Internet.
>
> Es un tema básicamente técnico (https://tools.ietf.org/html/rfc1930) pero
> que se podría simplificar si la asignación de recursos en Internet fuese un
> poco diferente a lo que es... un tema para debatir en otra oportunidad...
>
> Saludos,
> Nico
>
>
>
> 2017-06-08 15:01 GMT-03:00 Nick Pais <nick at nickserver.net>:
>
>> Entiendo que no sea lo más prolijo, en todo caso con crecimiento (o falta
>> de) se hacen los cambios necesarios (ASN locales, /32 enteros/locales,
>> etc). Pero desde el punto de vista de explorar territorio, para empezar,
>> sería la opción más viable.
>>
>> En cuanto a lo del ruteo/loop, había visto que en los Junipers se puede
>> configurar los loops (http://www.juniper.net/docume
>> ntation/en_US/junos11.4/topics/reference/configuration-
>> statement/loops-edit-protocols-bgp-family.html).
>>
>> Muchas gracias a todos!
>>
>> 2017-06-08 14:47 GMT-03:00 Carlos M. Martinez <carlosm3011 at gmail.com>:
>>
>>> Si usas el mismo ASN vas a tener problemas para comunicar los tres
>>> sitios entre sí, porque el BGP va a creer que está viendo un loop y te va a
>>> descartar las rutas a los otros sitios.
>>>
>>> Lo podes emparchar con estáticas, pero bueno, vos sabes que el camino de
>>> emparchar cosas con estáticas es como el camino de las drogas, es difícil
>>> volver.
>>>
>>> S2
>>>
>>> C.
>>>
>>> On 8 Jun 2017, at 14:29, Nick Pais 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
>>>
>>> _______________________________________________
>>> 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/5483ca57/attachment.html>
More information about the LACTF
mailing list