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.

Implementación de políticas de peering mediante communities en DE-CIX Madrid

Implementación de políticas de peering mediante communities en DE-CIX Madrid

A continuación presentamos ejemplos de implementación de políticas mediante BGP communities en la conexión a los route-servers de DE-CIX Madrid. La utilidad de la aplicación de estas políticas sirve, por ejemplo, para no hacer peering en DE-CIX Madrid con un AS con el que ya estamos intercambiando prefijos en NIXVAL-ix, que en determinados escenarios puede no ser necesario.

Las políticas soportadas son las siguientes:

Política Community
Bloquear el anuncio de una ruta a un peer específico : 0:[peer-as]
Anunciar una ruta a un peer : 48793:[peer-as]
Bloquear el anuncio de una ruta a todos los peers: 0:48793
Anunciar una ruta a todos los peers: 48793:48793

Cualquier community que no empiece por 0: o 48739: se ignora, y los anuncios que no llevan communities se propagan siempre a todos los peers.

A continuación un ejemplo simplificado para la configuración de routers CISCO para conectarse a los route-servers de DECIX Madrid e implementar un filtro de salida que anuncia las communities requeridas para que el contenido de un filtro NO se anuncie al AS 1234:


router bgp 57542
no bgp enforce-first-as #(IMPRESCINDIBLE!!)
neighbor decixrs peer-group
neighbor decixrs remote-as 48793
neighbor decixrs route-map decixrs_out out
neighbor decixrs maximum-prefix 200
neighbor 185.1.68.252 peer-group decixrs
neighbor 185.1.68.253 peer-group decixrs
....

route-map decixrs_out
match as-path 10 #(filtro de salida que se utilice, prefix-list, etc...)
set community 0:1234 48793:48793

Esta última línea es la que especifica a los route servers que los prefijos que se identifican mediante el as-path 10 no se anuncien al AS 1234, y sí a todos los demás peers presentes en los route-servers.

Implementación de políticas de peering mediante communities en DE-CIX Madrid

Ver el tráfico de DE-CIX en IXP Manager

Como los puertos de acceso remoto a DE-CIX están en la infraestructura de NIXVAL-ix, es posible ver la totalidad del tráfico de la VLAN de DE-CIX en la aplicación de gestión IXP Manager. A diferencia de los clientes con los que hacemos peering en NIXVAL-ix, en el caso de DE-CIX únicamente podemos ver la totalidad del tráfico, y necesitaremos acceder al área de cliente de DE-CIX para obtener información más detallada.

Los puertos de DE-CIX aparecen en IXP Manager como una VLAN privada entre el cliente de NIXVAL-ix y el puerto DE-CIX. Para acceder a las gráficas de tráfico hay que entrar en la aplicación y seleccionar «Peer to Peer Traffic» en el menú. Entramos en la pantalla del tráfico Peer-to-Peer y en el desplegable «Network» veremos que además de «Peering LAN 1» hay una opción «NombreCliente-DECIX», que seleccionaremos y pulsaremos el botón»Submit»:

ix_decix01

 

Seleccionando la red de peering con DE-CIX tendremos acceso a las gráficas de estadísticas de tráfico IPv4, IPv6, bits/paquetes o periodos de tráfico.

ix_decix02