Se describe en este documento la arquitectura anycast adoptada por LACNIC para sus servicios.

 

Existen en LACNIC un conjunto de bases de datos que actualmente están concentradas en servidores localizados en San Pablo o Montevideo. Esta información necesita ser accedida desde distintos sitios de la región, por lo que se vería beneficiada de una estructura distribuida. Con este fin, se ha desarrollado una arquitectura de servidores anycast a fin de que pueda ser desplegada en sitios estratégicos de la región, logrando de esa forma contribuir a la estabilidad y resiliencia de la Red.

 

 

Cada servidor físico contendrá distintos servidores virtuales (contenedores) que almacenarán bases de datos independientes. Para esto se utilizan los contenedores de Linux. Entre los servicios que se proveerán están: repositorios RPKI, servidores reversos de los miembros de LACNIC, servidores secundarios de los DNS de LACNIC, root-reversos d.in-addr.arpa y d.ip6.arpa.

 

Se describe a continuación la arquitectura para los servidores anycast que desplegará LACNIC.

 

Servidores

 

Los servidores son DELL con interfaz de administración remota iDRAC. Esto permite un acceso remoto a la consola configurando una IP pública.

Cada servidor tiene dos placas ethernets físicas de servicio: una se utilizará para gestión de los servers y otra para los servicios que correrán en cada servidor.

A su vez, cada uno de los contenedores virtuales tendrá una interfaz virtual de red de gestión y una interfaz virtual de red anycast.

 

 


 

 

 

 

 

Arquitectura de gestión

 

Cada contenedor virtual debe poder ser accedido en forma remota a través de su interfaz de gestión. Se analizaron varias posibilidades: lo ideal sería contar con una IP pública por cada contenedor virtual, pero este modelo obliga a que LACNIC reserve un /24 para cada servidor, a fin de que ese bloque pueda ser ruteado a Internet por la institución que lo aloja. Otra posibilidad sería solicitar esas direcciones IP a la institución, pero resulta poco adecuado y en caso de querer agregar servicios obligaría a pedir direcciones extras a la institución. Se analizó la posibilidad de hacer NAT y utilizar direccionamiento privado en las interfaces de gestión, pero resulta una configuración compleja y rígida. Por último, la solución elegida fue configurar túneles entre cada servidor de gestión y un concentrador de túneles de LACNIC. De esta forma, se destina un rango /28 para cada servidor, asignando de allí una IP a cada contenedor virtual y ruteando todo el bloque /28 a través del túnel hacia LACNIC.

El túnel se levanta con IPs privadas.

 

 

Arquitectura de anycast

 

Para las interfaces anycast, se asignarán direcciones de un bloque reservado /24, que será el mismo que se utilizará en todos los servidores. Estas interfaces serán las que se utilizarán para servicio. Por bgp se publicará este bloque al router de la institución para que ésta a su vez lo publique a Internet. Para la sesión bgp en el linux se utilizará quagga.

 

Direccionamiento

 

Interfaces iDRAC y físicas del servidor: serán suministradas por la institución que aloja el servidor.

 

Interfaces virtuales de gestión: se utilizan bloques /28 asignadas del bloque 179.0.159.0/24. En IPv6 se usa el bloque 2001:13c7:7001:200::/64. Esto se documentará en el IPPLAN a medida que se vayan agregando instituciones.

 

Interfaces virtuales anycast: se utiliza el bloque 200.0.88.0/24 en todos los servidores. El .1 se reserva para el brigde con el host. En IPv6 2801::/48.

 

Tunel: se usan direcciones privadas para el direccionamiento del túnel (virtuales). Se tomarán bloques /30 del bloque 192.168.179.0/24. En IPv6 se tomarán bloques /127 del bloque 2001:13c7:7001:179::/64.

Como IP remota se usa la del concentrador de túneles de LACNIC 200.7.84.42, como IP local la de la interfaz de gestión.