Salas dedicadas en NIXVAL

Salas dedicadas en NIXVAL

Acabamos de lanzar al mercado nuestro nuevo producto de salas dedicadas “datacenter suites” para clientes con requerimientos específicos de seguridad, que requieren un espacio dedicado en exclusiva para su proyecto. Las salas se diseñan conforme a los requerimientos técnicos específicos del cliente con el grado de independencia de instalaciones que el cliente escoja.

Las salas se equipan con instalaciones de climatización y extinción dedicadas, ofreciéndose un tamaño estándar de las suites de 35m2 con espacio hasta 16 racks de 600mm, e instalación de falso suelo de 50 cm de altura.

El cliente puede escoger entre distintas opciones de extinción, UPS dedicadas o compartidas con el centro, diseño específico de bandejas e instalaciones de cableado, e incluso disponer de sus propios sistemas de control de accesos y videovigilancia. Las salas cuentan con un avanzado sistema de monitorización y un panel de control on-line con información en tiempo real de parámetros medioambientales y consumo energético.

DSC_8832v2

DSC_8841v2

DSC_8833v2

 

Configuración en RIPE para el alta en DE-CIX Madrid – versión para novatos

Configuración en RIPE para el alta en DE-CIX Madrid – versión para novatos

Recientemente hemos estado dando soporte a varios clientes de DE-CIX Madrid en su configuración de BGP y de RIPE en la conexión a los servidores de rutas. Esta entrada es un resumen de algunas de las consideraciones a tener en cuenta a la hora de dar de alta este servicio, y será de interés para el pequeño ISP que se esté iniciando en el peering, y que no tenga muy claro el funcionamiento de los servidores de rutas de los puntos de intercambio de internet con filtrado automatizado. Vamos, que si no es así esta entrada no es para tí y si tienes RIPE perfectamente configurado y mantenido – como debería ser – pues la mayor parte de esta información será perfectamente conocida.

Para el alta en DE-CIX Madrid es necesario proporcionar la siguiente información:

  • El AS del cliente
  • El AS-SET para IPv4 – Este objeto de RIPE (u otro RIR) es el que utilizan los route-servers de DE-CIX para el filtrado de los prefijos que anuncian los participantes en el punto de intercambio.
  • El AS-SET para IPv6 -Lo mismo que el anterior para IPv6.
  • Los FQDNs para IPv4 e IPv6 – Los Fully Qualified Domain Names para la resolución de las IPsv4 e IPv6 que nos asignará DE-CIX.
  • El RIR: RIPE, APNIC, etc…
  • MAC – DE-CIX filtra por dirección MAC y es necesario informarles de la MAC utilizada en el puerto de conexión. Cualquier cambio en la MAC hay que notificarlo, ya que el servicio dejará de funcionar.

Si – a pesar de ser LIR – no tenemos muy claro el funcionamiento de la base de datos orientada a objetos de RIPE, el mejor sitio para empezar es su formación on-line: https://academy.ripe.net/. Lo mejor en estos casos es siempre leerse bien las instrucciones y tener un poco de lo que parece que hemos perdido últimamente: la paciencia, que nos va a hacer falta.

Para el objeto AS-SET hay que seguir, evidentemente, las directrices de RIPE o del RIR que corresponda. El objeto AS-SET contiene un listado de ASs que en nuestro caso se van a utilizar para autorizar o no los prefijos recibidos por los route servers.

Este sería un ejemplo de un AS-SET para el AS1234 que tiene 3 clientes en tránsito, el ASXXXXX, el ASYYYYYY y el ASZZZZZ. Tan sencillo como incluir como members a todos los ASs que van a anunciar prefijos a través de nuestro AS. Incluimos nuestro propio AS, ya que lo normal es que anunciemos prefijos nosotros también. Un ejemplo de este objeto:

 

as-set:          AS-MIRED1234-TRANSIT

descr:           Este es mi AS-SET para servicios de tránsito

members:         AS1234

remarks:         —– Este es nuestro AS ——-

members:         ASXXXXXX

remarks:         —– Este es el AS de nuestro cliente de tránsito IP X ——-

members:         ASYYYYYY

remarks:         —– Este es el AS de nuestro cliente de tránsito IP Y ——-

members:         ASZZZZZZ

(………)

tech-c:          [Objeto RIPE obligatorio]

admin-c:         [Objeto RIPE obligatorio]

mnt-by:         [Objeto maintainer de RIPE]

created:         2016-03-11T09:35:59Z

last-modified:   2017-09-05T07:18:14Z

source:          RIPE

 

En cuanto a la configuración del objeto AS en sí – nuestro objeto aut-num – los route-servers de DE-CIX no verifican realmente las entradas import y export de dicho objeto. Pero eso no quiere decir que no tengamos que tenerlas correctamente configuradas.

Por último, todos los prefijos que se van a anunciar tienen que tener sus correspondientes objetos inetnum y objetos route creados siguiendo las directrices de RIPE. Nada de esto último es específico de DE-CIX, simplemente se trata de cumplir con lo que nos exige RIPE.

Una vez estamos conectados y tenemos la configuración BGP correcta – en lo que no vamos a entrar aquí –  es necesario tener en cuenta también que:

  • Los filtros de DE-CIX Madrid se actualizan cada 4 horas
  • Los prefijos deben estar registrados en RIPE como mínimo 24 horas antes de su anuncio inicial en el punto de intercambio.

Los filtros que utilizan los route servers de DE-CIX para permitir el intercambio de prefijos son los siguientes:

  • El prefijo IP se verifica para que no esté incluido en los prefijos MARTIAN, prefijos reservados y de direccionamiento privado que nunca deben estar presentes en internet. (RFC 1918, RFC 5735, and RFC 6598).
  • Se verifica que el prefijo IP esté registrado en un RIR (RIPE) por un AS que sea parte del AS-SET proporcionado por el cliente. Es decir, tiene que existir un inetnum en RIPE con ese prefijo que pertenezca a uno de los ASs indicados como member del AS-SET.
  • Se comprueba el AS de origen resolviendo el AS-SET proporcionado. Es decir, el prefijo recibido por la sesión BGP tiene que tener su origen en uno de los ASs indicados como member en el AS-SET proporcionado.
  • El AS-path del prefijo se comprueba también con los ASNs reservados y privados definidos en las RFC7607, RFC6793, RFC5398, RFC6996, RFC7300, RFC5398, RFC6996, RFC7300).

 

Una herramienta muy interesante – probablemente imprescindible – para verificar si nuestra configuración en el RIR (RIPE, etc…) es correcta y consistente con lo que estamos anunciando en nuestras sesiones BGP es IRR Explorer (la verificación que utiliza el equipo técnico de DE-CIX):  http://irrexplorer.nlnog.net/ , introduciendo en la casilla nuestro número de AS.

Esta herramienta comprueba si la configuración en RIPE coincide o no con lo que estamos anunciando en nuestra sesión BGP. Si no nos muestra ningún error, nuestra configuración es correcta. Los errores que nos aparezcan en rojo indicarán que los route-servers no aceptarán dichos prefijos por ser su configuración errónea.

Los errores típicos pueden ser:

  • No existe el objeto route Prefix in DFZ, but no route-object with correct origin anywhere
  • Origen incorrecto en RIPE: Prefix is in DFZ, but registered with wrong origin in RIPE!
  • Objetos route innecesarios : Not seen in BGP, but (legacy?) route-objects exist, consider clean-up

 

Si la comprobación da un resultado de Perfect entonces la configuración es correcta y podemos dar el proceso por finalizado.

Por último, en el looking glass de DE-CIX Madrid: https://lg.mad.de-cix.net/ podemos verificar si los route-servers están recibiendo correctamente nuestros prefijos. En la pestaña “neighbor info” si introducimos la IP que nos ha asignado DE-CIX podremos ver la relación de prefijos que está recibiendo cada uno de los route-servers.

 

Esperamos que estas indicaciones sean de utilidad.

Chuleta de expresiones regulares para BGP

Chuleta de expresiones regulares para BGP

Para el que le pueda interesar el filtrado de rutas BGP se puede realizar utilizando expresiones regulares sobre la cadena as-path que forma parte de todas las rutas propagadas con este protocolo. Este post es un recordatorio de algunas expresiones que suelen ser útiles y algunos ejemplos más rebuscados para quien le pueda interesar.

La mayor parte de los sistemas operativos de los equipos de comunicaciones soportan expresiones POSIX, pero cada versión puede tener un alcance diferente, como ocurre con CISCO. Por el momen

Los caracteres con los que se implementan las funciones básicas son:

  • ^    inicio de cadena
  • $    final de cadena
  • .     cualquier carácter
  • _   cualquiera de los siguientes caracteres: espacio, inicio de cadena, final de cadena, corchete inicial o final, paréntesis inicial o final.
  • []   identifica un carácter dentro de un conjunto de valores ([134] = carácter 1,3 o 4) o un rango (delimitado por “-“)
  • –     delimitador del rango: por ejemplo cualquier número entre el 0 y el 3 [0-3]
  • ()   Agrupación lógica
  • +    Hay una repetición o más de una del último carácter o agrupación de la cadena
  • *     Ninguna repetición, una o más del último carácter o agrupación de la cadena
  • ?    Una instancia o ninguna del último carácter o agrupación de la cadena
  • |     Operador lógico OR

Algunos ejemplos básicos de una lista de prefijos o acceso en nomenclatrura CISCO pero trasladables fácilmente a otras plataformas (el xxx es el número de la access-list):

  • Permitir las rutas que nos anuncia el AS 65000 (en este caso es nuestro peer):
    ip as-path access-list  xxx  permit ^65000_
  • Permitir todas las rutas que se originen en el AS 65000:
    ip as-path access-list xxx  permit _65000$
  • Todas las rutas en las que aparezca el as 65000 en el as-path:
    ip as-path access-list xxx permit _65000_
  • Permitir todas las rutas:
    ip as-path access-list xxx permit .*
  • Permitir únicamente los prefijos locales (as-path vacío):
    ip as-path access-list xxx permit ^$
  • Permitir únicamente rutas de mis peers:
    ip as-path access-list xxx permit ^[0-9]+$
  • Permitir las rutas originadas por un cliente en tránsito – AS 65001 – con cualquier número de prepends:
    ip as-path access-list xxx permit ^(65001_)+$
  • Permitir las rutas originadas por un cliente en tránsito – AS 65001 – y un cliente en tránsito del AS65001 – AS65002 – con cualquier número de prepends:
    ip as-path access-list xxx permit ^(65001_)+(65002_)+$
  • Permitir las rutas que nos anuncia un determinado AS y cualquier número de prepends de ese mismo AS ( * incluye también ningún prepend):
    ip as-path access-list xxx permit ^65000(_65000)*$
  • Permitir las rutas que tienen su origen en el AS 65000 o el 65001:
    ip as-path access-list  xxx  permit _(65000|65001)$
  • Permitir las rutas que tienen su origen en el AS6501 y nos anuncia el 6500, con cualquier número de ASs entre ellos:
  • ip as-path access-list  xxx  permit  ^6500_(.+)_6501$
  • Permitir las rutas que tienen su origen en el AS6501 y nos anuncia el 6500 que transitan por un único AS (sea el que sea):
  • ip as-path access-list  xxx  permit ^6500_[0-9]+)_6501$

 

Esperamos completar este post con más ejemplos en breve.

Prefijos de Google en DE-CIX desagregados por los proveedores de tránsito IP

Prefijos de Google en DE-CIX desagregados por los proveedores de tránsito IP

Tras algunas conversaciones con nuestros clientes de DE-CIX, publicamos esta entrada del blog acerca de los prefijos del AS 15169, es decir, Google.  Estos prefijos engloban servicios no solo muy populares, sino imprescindibles hoy en día, con lo que la opción de utilizar el peering de DE-CIX parece sin duda la más acertada. Sin embargo, un número importante de los prefijos anunciados por los route-servers de DE-CIX se anuncian desagregados por todos los proveedores de tránsito IP que tienen peering directo con Google. No es que sea muy complicado tener peering directo con Google, tan sólo hay que solicitarlo en: https://isp.google.com/iwantpeering, pero puede darse el caso de que nos lo denieguen. Con un breve análisis de nuestras tablas de enrutamiento podemos ver que al menos los siguientes prefijos son anunciados por los principales operadores de tránsito con la longitud indicada, y al mismo tiempo total o parcialmente desagregados en prefijos /24:

  • 66.102.0.0/20
  • 74.125.0.0/16
  • 108.177.0.0/17
  • 173.194.0.0/16
  • 209.85.128.0/17
  • 216.58.192.0/19
  • 216.239.32.0/19
  • 66.102.0.0/20
  • 172.102.8.0/21
  • 172.217.0.0/16
  • 216.252.220.0/22

En este escenario, nuestro proceso BGP seleccionará el prefijo más específico y utilizará las rutas que anuncian los prefijos desagregados en /24, y nunca los prefijos que nos anuncia DE-CIX. El tráfico que estábamos esperando utilizara DE-CIX preferentemente se enrutará, por tanto, por las conexiones de tránsito de nuestros proveedores.

Para evitar esta situación se pueden implementar diversas soluciones, una de las cuales es filtrar los prefijos /24 que estamos recibiendo de manera que no se incluyan en nuestra tabla de enrutamiento BGP. El proceso BGP en este caso, seleccionará preferentemente las rutas anunciadas por DE-CIX por tener el AS-PATH más corto; al fin y al cabo para esto estamos haciendo peering en DE-CIX, no?

Una posible implementación del filtrado de prefijos en equipos CISCO es la siguiente:

Creamos una prefix-list que identifique dentro de cada prefijo los prefijos con máscara /24, /23…. Por ejemplo:

ip prefix-list 24GOOGLE seq 10 permit 66.102.0.0/20 ge 24
ip prefix-list 24GOOGLE seq 20 permit 74.125.0.0/16 ge 24
ip prefix-list 24GOOGLE seq 30 permit 108.177.0.0/17 ge 24
ip prefix-list 24GOOGLE seq 40 permit 173.194.0.0/16 ge 24
ip prefix-list 24GOOGLE seq 50 permit 209.85.128.0/17 ge 24
ip prefix-list 24GOOGLE seq 60 permit 216.58.192.0/19 ge 24
ip prefix-list 24GOOGLE seq 70 permit 216.239.32.0/19 ge 24
ip prefix-list 24GOOGLE seq 80 permit 66.102.0.0/20 ge 24
ip prefix-list 24GOOGLE seq 90 permit 172.102.8.0/21 ge 23
ip prefix-list 24GOOGLE seq 100 permit 172.217.0.0/16 ge 24
ip prefix-list 24GOOGLE seq 110 permit 216.252.220.0/22 ge 24

 

…………
neighbor X.X.X.X route-map TRANSIT1_IN in
neighbor X.X.X.X route-map TRANSIT1_OUT out
…………….

 

Añadimos un filtro previo a nuestra configuración actual en la que se deniegan en entrada los prefijos que concuerdan con los criterios de la lista de prefijos anterior:

route-map TRANSIT1_IN deny 10
match ip address prefix-list 24GOOGLE

route-map TRANSIT1_IN permit 20

…….

El resultado será que veremos desaparecer las rutas BGP con prefijos /24 – los que hayamos indicado en el listado de prefijos – y volveremos a ver el tráfico enrutado por el peering de DE-CIX sin perder redundancia por los operadores de trásito que, recordemos, también anuncian los prefijos comentados sin desagregar.

DE-CIX peering workshop

DE-CIX peering workshop

El pasado martes, 21 de Febrero, tuvimos la oportunidad de disfrutar del peering workshop de DE-CIX en nuestras instalaciones. DE-CIX tiene un gran equipo comercial y nos propuso después de nuestro arranque como revendedores en junio de 2016, hacer un evento en NIXVAL dirigido a ISPs locales en el que presentar las ventajas de los servicios de peering que ofrecen en DE-CIX Madrid.

Para ejemplificar este concepto más allá de las presentaciones correspondientes montamos un panel de clientes en el que participaron tres clientes nuestros y de DE-CIX : NUNSYS, Carrier-Enabler y Nostravant, aportando su experiencia como proveedores de servicios y operadores de telecomunicaciones también en el ámbito residencial. El panel fue extremadamente interesante para todos, porque como es lógico, nada como un ejemplo real para entender que muchas de las bondades del peering son simplemente realidades demostrables. En él los participantes relataron la mejora de la calidad de su tráfico mediante el uso de las conexiones de peering,  como habían reducido sus costes de tránsito IP utilizando estos servicios, o las nuevas oportunidades que los puntos de intercambio les han abierto.

Por último, tuvimos la enorme suerte de contar con Bernd Spiess, el Peering Manager de DE-CIX, un auténtico experto en este ámbito, que hizo una interesantísima presentación sobre aspectos estratégicos, técnicos y financieros relacionados con el peering. De ella, destacaría sin duda las posibilidades de mejora de latencias a través del peering y la dependencia del ancho de banda real de las latencias de red.  La explicación de Bernd nos dejó reflexionando sobre la necesidad de diseñar y planificar basándonos también en las latencias y no únicamente en las capacidades de ancho de banda necesarias para cada conexión.