RPKI en MikroTik – Routinator en RouterOS v7 Container

RPKI en MikroTik usando Container RouterOS v7

¿Qué es RPKI?

En este artículo vamos a explicar como utilizar Routinator en un Container en MikroTik RouterOS v7. Pero antes de ello se hace imprescindible explicar que es RPKI.

Imagina que el mundo de internet es como una gran ciudad llena de edificios (routers) donde cada uno tiene su propia identidad. A veces, las “carreteras” (anuncios de rutas BGP) que conectan estos edificios pueden ser falsas, lo que lleva a problemas y confusión. Aquí es donde entra en juego RPKI, un sistema de seguridad inteligente diseñado para verificar esas conexiones y hacer que todo sea más confiable.

RPKI, que significa Resource Public Key Infrastructure, utiliza un conjunto de reglas y directrices establecidas en el RFC 6480, que es básicamente como su manual de operaciones. Este documento te dice cómo funciona RPKI y cómo se comunican sus componentes entre sí.

En este sistema de seguridad, los sistemas autónomos (AS) son como los barrios de la ciudad que agrupan a los edificios. Cada sistema autónomo tiene un número único y es responsable de ciertas partes de internet. Para asegurarse de que estos sistemas autónomos se comuniquen de manera auténtica, RPKI emite lo que se llaman Certificados de Recurso, que son los identificaciones digitales para estos sistemas. Cada sistema autónomo obtiene su propio certificado.

Pero aquí viene lo interesante: para verificar que un sistema autónomo está autorizado para anunciar ciertas rutas (caminos de tráfico) en internet, se utilizan ROAs (Anotaciones de Origen de Ruta). Estas ROAs son como contratos digitales que establecen qué sistema autónomo tiene permiso para manejar que rutas. Es como si cada edificio tuviera un permiso específico para construir una carretera en la ciudad.

Cuando se anuncian rutas mediante eBGP, RPKI entra en acción. Verifica si estas rutas coinciden con las ROAs, lo que garantiza que solo las rutas autorizadas sean utilizadas y que no haya “rutas falsas” que puedan llevar a problemas de seguridad o rendimiento.

En resumen, RPKI, el RFC6480 y en su desarrollo el RFC8210 son como los árbitros de confianza en el mundo de interconexión de redes mediante eBGP. Establecen reglas para que los sistemas autónomos se identifiquen de manera segura y usen rutas autorizadas mediante certificados, ROAs y verificaciones BGP. Esto reduce el riesgo de anuncios de rutas falsas y ayuda a mantener una experiencia en línea más segura y confiable para todos nosotros.

Descripción

MikroTik desde la version 7.0beta7 implementa la funcionalidad RPKI y desde la versión 7.4beta4 se introdujo la característica para poder utilizar containers alojados en la propia RouterBoard. Los contenedores ofrecen eficiencia, velocidad, portabilidad y administración simplificada en comparación con las máquinas virtuales tradicionales. Son ideales para aplicaciones que necesitan una implementación ágil, escalabilidad rápida y un uso eficiente de recursos.

Routinator es un paquete de software RPKI Relying Party, diseñado por los amigos de NLnetLabs, que se ejecuta como un servicio que descarga y verifica periódicamente los datos RPKI. Los routers pueden conectarse a una máquina ejecutando Routinator para obtener datos verificados mediante el protocolo RPKI-to-Router (RTR) RFC 8210 El servidor HTTP integrado ofrece una interfaz de usuario y puntos finales API para los distintos formatos de archivo, así como registro, estado y métricas Prometheus.

Descripción del Laboratorio

En este laboratorio, prepararemos un escenario donde instalaremos Routinator en un container alojado en el propio MikroTik.

Objetivos de la práctica

Conocer el funcionamiento de RPKI
Establecer una conexión entre un router y un sistema RTR
Verificar la configuración realizada.

Configuración paso a paso

Antes de comenzar con la configuración, un detalle muy importante a resaltar: vamos a hacer una configuración que es altamente exigente con los recursos del equipo anfitrión, vigila la cantidad disponible de memoria RAM y de espacio de almacenamiento o podrás tener errores asociados a la carencia de los mismos.

Cuestiones importantes referida a los containers:

Se necesita acceso físico al router para activar la función de contenedor, que está desactivada por defecto;
Una vez habilitada la función de contenedor, los contenedores pueden ser añadidos/configurados/iniciados/parados/eliminados remotamente.
Si el router se ve comprometido, los contenedores pueden utilizarse para instalar fácilmente software malicioso en su router y a través de la red;
Tu router es tan seguro como cualquier cosa que ejecutes en contenedor;
Si ejecutas contenedores, no hay garantía de seguridad de ningún tipo;
Ejecutar una imagen de contenedor de terceros en tu router podría abrir un agujero de seguridad/vector de ataque/superficie de ataque;
Un experto con conocimientos de cómo construir exploits será capaz de jailbreak o elevar a root;

Para poder utilizar esta práctica necesitamos equipos con arquitectura ARM, ARM64 o x86

Este laboratorio da por supuesto que tu RouterBoard tiene comunicación con internet, DNS, etc con una configuración básica y que el firewall está configurado de manera que permita conexiones entrantes por la interfaz WAN.

1. Configurar el MikroTik para poder utilizar containers.

Necesitamos la versión de RouterOS v7.4beta o superior. Instalamos el paquete extra container con cualquier método conocido, por ejemplo picar y arrastrar el archivo hasta la carpeta Files de nuestro MikroTik.

[admin@RouterOS] > /system/device-mode/update container=yes

Nos aparecerá un mensaje y un contador con una cuenta atrás para activar la funcionalidad. Para esto necesitamos manipular físicamente el dispositivo, quitándole directamente la alimentación de corriente eléctrica o pulsando el botón de reset una vez. Cuándo el router se reinicie, tendremos la característica de Containers activada.

2. Conexión con los containers

Ahora configuraremos una interfaz ethernet virtual, con su dirección IP en un bridge, donde se produzca la conectividad de los containers y creamos las reglas de NAT para que nuestro container se pueda comunicar con internet en los puertos necesarios.

[admin@RouterOS] > /interface/veth add address=172.16.72.5/24 gateway=172.16.72.1 name=veth5
[admin@RouterOS] > /interface/bridge add name=bridge_containers
[admin@RouterOS] > /interface/bridge/port add bridge=bridge_containers interface=veth5
[admin@RouterOS] > /ip/address add address=172.16.72.1/24 interface=bridge_containers
[admin@RouterOS] > /ip/firewall/nat add action=dst-nat chain=dstnat dst-port=3323 in-interface=wan protocol=tcp to-addresses=172.16.72.5 to-ports=3323
[admin@RouterOS] > /ip/firewall/nat add action=dst-nat chain=dstnat dst-port=8323 in-interface=wan protocol=tcp to-addresses=172.16.72.5 to-ports=8323
[admin@RouterOS] > /ip/firewall/nat add action=dst-nat chain=dstnat dst-port=9556 in-interface=wan protocol=tcp to-addresses=172.16.72.5 to-ports=9556

3. Instalar Routinator

A continuación procederemos a utilizar las repos de DockerHub donde se encuentra Routinator, descargamos la imagen y creamos el container.

[admin@RouterOS] > /container/config set registry-url=https://registry-1.docker.io tmpdir=pull
[admin@RouterOS] > /container/add remote-image=nlnetlabs/routinator:latest interface=veth5 root-dir=disk1 logging=yes start-on-boot=yes

4. Iniciar el container y conexión por consola

[admin@RouterOS] > /container/start 0
[admin@RouterOS] > /container/shell 0

5. Configuración Routinator

Utilizaremos la configuración básica de Routinator por defecto para simplificar este laboratorio. Es recomendable iniciar un test una vez funcionando, para eso utilizaremos el siguiente comando:

/ # routinator -vv vrps

Podemos comprobar ahora como Routinator se conecta a los Trust Anchor RPKI, se descarga el contenido de los repositorios, lo verifica y produce una lista de VRP (validated ROA payload).

[INFO] Using the following TALs:
[INFO]   * afrinic
[INFO]   * apnic
[INFO]   * arin
[INFO]   * lacnic
[INFO]   * ripe
[DEBUG] Found valid trust anchor https://rpki.ripe.net/ta/ripe-ncc-ta.cer. Processing.
[DEBUG] Found valid trust anchor https://rrdp.lacnic.net/ta/rta-lacnic-rpki.cer. Processing.
[DEBUG] Found valid trust anchor https://rpki.afrinic.net/repository/AfriNIC.cer. Processing.
[DEBUG] Found valid trust anchor https://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer. Processing.
[DEBUG] Found valid trust anchor https://rrdp.arin.net/arin-rpki-ta.cer. Processing.
[DEBUG] RRDP https://rrdp.ripe.net/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rrdp.lacnic.net/rrdp/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rrdp.apnic.net/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rrdp.afrinic.net/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rrdp.arin.net/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rrdp.apnic.net/notification.xml: snapshot update completed.
[DEBUG] RRDP https://rpki-rrdp.us-east-2.amazonaws.com/rrdp/08c2f264-23f9-49fb-9d43-f8b50bec9261/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rpki-rrdp.us-east-2.amazonaws.com/rrdp/08c2f264-23f9-49fb-9d43-f8b50bec9261/notification.xml: snapshot update completed.
[DEBUG] RRDP https://rpki.akrn.net/rrdp/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rpki.akrn.net/rrdp/notification.xml: snapshot update completed.
[DEBUG] RRDP https://rpki.admin.freerangecloud.com/rrdp/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rpki.admin.freerangecloud.com/rrdp/notification.xml: snapshot update completed.
[DEBUG] RRDP https://rpki.cnnic.cn/rrdp/notify.xml: updating from snapshot.
[DEBUG] RRDP https://rrdp.ripe.net/notification.xml: snapshot update completed.
[DEBUG] RRDP https://0.sb/rrdp/notification.xml: updating from snapshot.
[DEBUG] RRDP https://0.sb/rrdp/notification.xml: snapshot update completed.
[DEBUG] RRDP https://rrdp.sub.apnic.net/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rrdp.sub.apnic.net/notification.xml: snapshot update completed.
[DEBUG] RRDP https://rpki.roa.net/rrdp/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rpki.roa.net/rrdp/notification.xml: snapshot update completed.
[DEBUG] RRDP https://rrdp.rp.ki/notification.xml: updating from snapshot.
[DEBUG] RRDP https://rpki.cnnic.cn/rrdp/notify.xml: snapshot update completed.
...
ASN,IP Prefix,Max Length,Trust Anchor
AS137884,103.116.116.0/23,23,apnic
AS9003,91.151.112.0/20,20,ripe
AS38553,120.72.19.0/24,24,apnic
AS58045,37.209.242.0/24,24,ripe
AS9583,202.177.175.0/24,24,apnic
AS50629,2a0f:ba80::/29,29,ripe
AS398085,2602:801:a008::/48,48,arin
AS21050,83.96.22.0/24,24,ripe
AS55577,183.82.223.0/24,24,apnic
AS44444,157.167.73.0/24,24,ripe
AS197695,194.67.97.0/24,24,ripe
...

6. Configuración en RouterOS para utilizar RPKI

Una vez configurado Routinator, necesitamos crear las reglas para que BGP utilice los filtros adecuados y se produzca la validación correctamente, en caso contrario, rechazamos ese prefijo. En este Lab de ejemplo utilizaremos IPs de Loopback genéricas y AS de documentación.

[admin@RouterOS] > /routing/rpki add address=172.16.72.5 group=RPKI-Group port=3323
[admin@RouterOS] > /routing/filter/rule add chain=BGP-In rule="rpki-verify RPKI-Group"
[admin@RouterOS] > /routing/filter/rule add chain=BGP-In disabled=no rule="if (rpki invalid) { reject } else { accept }"
[admin@RouterOS] > /routing/bgp/connection add name=bgp-ISP1 as=65001 connect=yes listen=yes disabled=no input.filter=BGP-In local.address=10.0.0.1
local.role=ebgp remote.address=10.0.0.2/32 remote.as=65002 router-id=10.0.0.1

7. Comprobación

Ahora comprobaremos mensajes válidos, inválidos y desconocidos usando diferentes AS y diferentes prefijos.

[admin@RouterOS] > /routing/rpki/rpki-check origin-as=15169 prefix=8.8.8.0/24 group=RPKI-Group

Este laboratorio es una prueba de concepto acerca de estas tecnologías y estándares. En caso de querer realizar estas configuraciones en producción, la recomendación es liberar de recursos a nuestra RouterBoard para su principal cometido (en este caso eBGP y RPKI) y que sea un servidor dedicado el que gestione propiamente los containers o máquinas virtuales.

En el Máster en Arquitectura de Redes de Operadores de Telecomunicaciones, y en las certificaciones oficiales de MikroTik impartidas en loopback0 (MTCINE), explicamos en profundidad los diferentes tipos de configuraciones BGP, explicando en profundidad filtros, así como los métodos de configuración, características, pros y contras.

/by Victor Bolaños Guerra

MLAG en MikroTik

Uncategorized

Multi-chassis Link Aggregation en MikroTik

¿Por qué usar MLAG?

La implementación de MLAG (Multi-chassis Link Aggregation Group) permite configurar enlaces LACP (802.3ad) en dos dispositivos independientes, funcionando de tal manera que el dispositivo cliente cree estar conectado al mismo equipo. Esto proporciona grandes ventajas, entre ellas, redundancia física en caso de fallo del switch. A partir de la version de RouterOS 7.1beta6, todos los dispositivos de la serie CRS3xx pueden configurarse con MLAG (solo mediante CLI).

“LAG is good, but it’s not as good as a fatter pipe”
LAG está bien, pero no es tan bueno como un “canuto gordo”

Dicho popular

Descripción

Una de las cuestiones fundamentales es que cada fabricante tiene su modo particular de establecimiento de pares. En el caso de MikroTik, ambos equipos establecen la interfaz MLAG y actualizan la tabla de hosts del bridge a través de los puertos pareados utilizando ICCP (Inter Chassis Control Protocol). Los principios de funcionamiento se describen en el RFC7275. RouterOS ICCP no requiere una configuración IP, pero debe ser aislado del resto de la red utilizando una VLAN dedicada sin taggear. Esta VLAN no etiquetada será configurada con vlan-filtering y pvid. Los puertos pares también pueden configurarse como interfaces de enlace LACP. El MLAG requiere la activación del protocolo STP o RSTP.

Descripción del Laboratorio

En este laboratorio, prepararemos un escenario donde podamos unir dos switches mediante MLAG y servir a un cliente de manera unificada.

Objetivos de la práctica

Conocer el funcionamiento de MLAG
Establecer una conexión entre switches de agregación a un switch de acceso, otorgando disponibilidad y redundancia.
Verificar la configuración realizada.

Topología

Configuración paso a paso

Antes de comenzar con la configuración, un detalle muy importante a resaltar: estamos trabajando con un sistema operativo que todavía está en fase beta. Esto quiere decir que aún estamos ante una versión en desarrollo que no ha sido lo suficientemente testada, por lo que la recomendación es no utilizarla en entornos críticos.

1. Configurar el switch Cliente

Configuramos un LACP bonding normalmente. En nuestro caso utilizaremos las interfaces sfp-sfpplus1 conectadas entre sí.

Cliente

[admin@Cliente] > interface bonding/ add mode=802.3ad name=enlace1 slaves=sfp-sfpplus1,sfp-plus2

2. Configurar los switch MLAG

Configuramos el mismo mlag-id en ambos dispositivos. Es el parámetro que nos pareara los switches.

[admin@S1] > interface bonding/ add mlag-id=1 mode=802.3ad name=enlace1 slaves=sfp-sfpplus2

[admin@S2] > interface bonding/ add mlag-id=1 mode=802.3ad name=enlace1 slaves=sfp-sfpplus2

Ahora configuramos en el bridge el filtrado de vlan mediante vlan-filtering y añadimos las interfaces necesarias. Para poder establecer la comunicación entre sí, necesitamos una vlan no taggeada que será dedicada específicamente a esta comunicación (pvid=11)

[admin@S1] > interface bridge/ add name bridge1 vlan-filterign=yes
[admin@S1] > interface bridge port/ add bridge1 interface=sfp-sfpplus1 pvid=11
[admin@S1] > interface bridge port/ add bridge1 interface=enlace1

[admin@S2] > interface bridge/ add name bridge1 vlan-filterign=yes
[admin@S2] > interface bridge port/ add bridge1 interface=sfp-sfpplus1 pvid=11
[admin@S2] > interface bridge port/ add bridge1 interface=enlace1

Todas las VLANs usadas para los bridge slaves deben ser también configuradas como VLANs etiquetadas para el puerto peer, por lo que este puerto se añade ahora como miembro de la VLAN 1 etiquetada (el pvid por defecto para enlace1). Se pueden añadir otras VLANs si es necesario.

[admin@S1] > interface bridge vlan/ add bridge=bridge1 tagged=sfp-sfpplus1 vlan-ids=1

[admin@S2] > interface bridge vlan/ add bridge=bridge1 tagged=sfp-sfpplus1 vlan-ids=1

Por último, necesitamos configurar el bridge y el peer-port a través los dispositivos se parean, para activar MLAG.

[admin@S1] > interface bridge mlag/ set bridge=bridge1 peer-port=sfp-sfpplus1

[admin@S2] > interface bridge mlag/ set bridge=bridge1 peer-port=sfp-sfpplus1

Comprobación

→ Nos aseguramos de la correcta configuración comprobando los status de las interfaces con los siguientes comandos:

[admin@S1] > interface/bridge/mlag/monitor
     status: connected
  system-id: 74:4D:28:37:A6:1B
active-role: primary

[admin@S2] > interface/bridge/mlag/monitor
     status: connected
  system-id: 74:4D:28:37:A6:1B
active-role: secondary

Cliente

[admin@Cliente] > interface/bonding/monitor/enlace1
                  mode: 802.3ad
          active-ports: sfp-sfpplus1,sfp-sfpplus2
        inactive-ports:
        lacp-system-id: 74:4D:28:71:0A:71
  lacp-system-priority: 65535
lacp-partner-system-id: 74:4D:28:37:A6:1C

En el Máster en Arquitectura de Redes de Operadores de Telecomunicaciones, y en las certificaciones oficiales de MikroTik impartidas en loopback0 (MTCNA y MTCSWE), explicamos en profundidad los diferentes tipos de bonding, explicando en profundidad LACP, así como los métodos de configuración, características, pros y contras.

/by Victor Bolaños Guerra

BSS/OSS para redes neutras (II)

Uncategorized

En este segundo artículo de la serie BSS/OSS vamos a hablar de los sistemas OSS. Aquí voy a intentar explicar nuestra forma de afrontar este tipo de desarrollos con el último estado del arte de la tecnología. El modelo de negocio de red neutra que se está llevando a cabo en España se apoya en la compra masiva de pequeños y medianos operadores. Este tipo de operaciones se conocen como M&A, de merges (fusiones) y adquisitions (adquisiciones). Este proceso de fusiones y adquisiciones junto al dinamismo del sector de las telecomunicaciones presenta una serie de desafíos. Por citar algunos de ellos: migración de los clientes del sistema del comprador al vendedor, redimensionamiento de la red del comprador para adaptarse a los nuevos requisitos u homogeneización de los sistemas.

Una vez planteado nuestros problemas vamos a ver qué soluciones podemos encontrar implantando un sistema OSS.

OSS se define como los “Sistemas de soporte a las operaciones” (Operational Support Systems) y hacen referencia a sistemas de información empleados por las empresas operadoras de telecomunicaciones. El término OSS por lo general describe a los “sistemas de red” que están directamente vinculados a la red de telecomunicaciones misma, por ejemplo: procesos de soporte para el mantenimiento del inventario de red, servicios de aprovisionamiento, configuración de los elementos de red y software para la gestión de fallas.

Cómo podemos leer en la definición anterior extraída de la wikipedia, se hace mención a una serie de subsistemas. En este artículo me centraré en alguno de ellos por la criticidad que tienen en el modelo de negocio que se está llevando a cabo en España.

Provisioning

El primer sistema que vamos a analizar es el sistema de aprovisionamiento. Para no complicar excesivamente el escenario vamos a hablar de redes FTTH. Aunque se puede dar el caso que la red adquirida estuviera implementada con otra tecnología como wifi. Cuando afrontamos un proceso de M&A esta será una de las primeras decisiones que deberemos abordar. Los problemas habituales que podemos encontrar en esta parte del proyecto son ausencia de documentación, sistemas propietarios, gran variedad de modelos de ONT, etc…

A estos problemas de tipo técnico se unen problemas de tipo logístico, ya que la migración de los clientes se debe producir sin pérdida del servicio. El último componente de complejidad puede ser el sistema de negocio que esté fuertemente acoplado al sistema de red. A continuación voy a describir algunas soluciones técnicas.

En el caso del aprovisionamiento es interesante contemplar el sistema de aprovisionamiento como software en vez de hardware. Para ello utilizamos técnicas de Netdevops. La dinámica de los fabricantes tiende a ofrecer “Zero touch provisioning”. Los protocolos a considerar en esta parte serían OMCI, TR069, etc.. En nuestro caso en entornos heterogéneos con mucha variedad de ONT, preferimos el uso de TR069. Esta decisión nos permite hacer menos dependiente las configuraciones del hardware.

Los servidores ACS exponen el sistema a través de webservices y se puede incluir entonces la configuración dentro de los procesos de CD/CI. Este proceso de automatización es importante cuando nos enfrentamos a migraciones de miles de clientes. Otro aspecto a tratar cuando estamos en un escenario de red neutra con tamaños considerables, entre 100 000 y varios millones de unidades instaladas (uuii’s), es cómo gestionamos el almacenamiento de las configuraciones.

En el caso de redes del tamaño mencionado anteriormente nos podemos encontrar con cientos de OLT’s. En algunos casos con diversas marcas y modelos conviviendo en la red. Para el caso de las configuraciones es interesante acercarse a la configuración como elementos dentro de un control de versiones. Utilizar git y python nos facilita la automatización de este control de versiones. Si estamos hablando de equipos de red el uso de yang y netconf permite incluir los dispositivos de red dentro del flujo CD/CI.

Otro aspecto importante a tratar en el modelo neutro es cómo se van a ofrecer esta provisión de los equipos a los operadores que van a explotar la red neutra. Cuando diseñamos los servicios rest o gRPC, que van a servir como interfaz con nuestro sistema a los operadores, hay que definir un modelo de estados. Este modelo de estados tiene que contemplar eventos como la ausencia de recursos y otro tipo de eventos. Además estos servicios devolverán valores de monitorización de las ONT’s.

Acceso L2

Otra configuración a tener en cuenta a la hora de diseñar la red neutra es el servicio de acceso L2 que se va a proporcionar a los operadores que exploten la red. En este punto hablamos de C-VLAN y S-VLAN. En estos diseños se tienen varias alternativas. Por un lado el modelo de VLAN dedicada (1:1 VLAN) y por otro lado el modelo de VLAN compartida (N:1). La utilización de tipo de tráfico según VLAN influye directamente en el modelo de negocio que se ofrece, siendo habitual tener varios tipos de tráfico con tarifas diferentes y dando la posibilidad de ofrecer tráfico garantizado. Es una práctica habitual asociar el precio de un servicio a un tipo de tráfico y a un ancho de banda. El ancho de banda se puede ofrecer con diferentes capacidades y es el operador el que adapta esas capacidades a sus servicios. Hay que tener en cuenta que estas redes serán utilizadas por operadores mayoristas que ya ofrecen servicios en otras partes del territorio.

Como podéis apreciar en el artículo el diseño de una red neutra plantea desafíos importantes. En próximos artículos intentaré explicar otras partes importantes en el diseño de una red de estas características.

Referencias:

https://tools.ietf.org/id/draft-ietf-netconf-zerotouch-19.html

https://automate.network/

/by José Manuel Román Fernández Checa

BSS/OSS para redes neutras (I)

Uncategorized

En esta serie de artículos vamos a analizar los sistemas OSS/BSS que son necesarios para proporcionar servicios en redes de telecomunicaciones neutras. El desarrollo del mercado de los ISP en España ha llegado a un momento de madurez. Este momento de madurez ha propiciado la aparición de redes neutras con comercializaciones del servicio bitstream, con proyectos maduros como Adamo y nuevos proyectos como Onivia. Estos proyectos participados por fondos de inversión realizan importantes inversiones en CAPEX. Los ISP que utilizan los servicios de las redes neutras se liberan de esa fuerte inversión inicial y les permite concentrarse en su core de negocio. A la vez estos proyectos racionalizan el uso de los recursos, desplegando una sola red en un área determinada.

Una red neutra necesita una aproximación diferente en su diseño y en su O&M. Hasta ahora los operadores neutros en España no tenían solo el servicio bitstream sino también el servicio retail, por ejemplo Telefónica. El bitstream necesita unos servicios diferentes que den apoyo al plan de negocio de la red neutra. Intentaré en este artículo describir los diferentes componentes de los sistemas que dan servicio a un negocio de red neutra.

Una visión completa de los activos requiere visibilidad en los tres dominios de datos: BSS, OSS y Red

Para abordar la descripción de los servicios de una red neutra vamos a dividir los distintos procesos en dos grandes sistemas: por un lado el sistema BSS y por otro lado el sistema OSS.

BSS

El sistema BSS (Business support systems) resuelve la problemática del procesamiento de pedidos, cobros y gestión financiera. En este sistema encontraremos a su vez subsistemas como:

Gestión de creación de servicios. Los servicios de las redes neutras son los servicios que se ofrecerán en el modelo bitstream. Las variables con las que se suele trabajar a la hora de definir estos servicios es la capacidad y la calidad del servicio. Por ejemplo un servicio con capacidad de 1Gbps y Best effort. Ya en este servicio vemos la importancia de una buena integración con otros subsistemas que veremos en el próximo post. Por ejemplo la gestión de red y la configuración de los sistemas. Los sistemas de BSS se adaptan bien a una modelización utilizando ERP. Para este tipo de proyectos, en Fibercli solemos elegir Odoo como ERP, por su modularidad y su capacidad de integración. Odoo utiliza Python que es el lenguaje que utilizamos en el sistema OSS.
Gestión de Usuarios. Aquí es importante resaltar que el usuario de nuestra red es un ISP no el cliente final. En nuestra solución el tratamiento se hace a través del CRM de Odoo. No solo es importante el tratamiento de pedidos por parte de los ISP, desde el punto de vista comercial el tratamiento de los leads y la firma de contratos es fundamental. De esta forma podemos reducir el tiempo de contratación del servicio bitstream de 7 u 8 meses a unas 3 semanas. La gestión documental tiene un papel importante en la gestión de ampliaciones de servicios y en el seguimiento de los cumplimientos de los contratos.
Gestión de la facturación y la contabilidad. En un negocio de este tipo con una facturación de tantos ítems y una oferta de servicios tan dinámica (en el caso por ejemplo del tránsito o el transporte), un sistema de facturación automático y que valide contra nuestros sistemas de red y acceso es fundamental. Debido a la dinámica del negocio una contabilidad analítica, con un centro de costes bien dimensionado ayudará a validar la inversión por parte del board y su reporte posterior a los fondos de inversión.
Gestión de órdenes de altas por parte de los clientes. Este es uno de los procesos donde la automatización y la integración con nuestro OSS va a marcar la rentabilidad del negocio. Las órdenes de pedido se tratan en nuestro sistema como una orquestación CD/CI que ataca sistemas como la gestión de la configuración, el inventario, gestión de red, QoS, sistemas de autenticación, sistemas de aprovisionamiento y acceso. Por supuesto todos estos sistemas están orquestados con Python.

Como podéis ver en esta primera parte del post hemos analizado el sistema BSS, que es el sistema más próximo a negocio y que a su vez está estrechamente ligado a nuestros sistemas. Teniendo en cuenta las implicaciones financieras que tiene este sistema, es importante que refleje con el mayor grado de precisión posible los flujos de negocio. Quiero destacar en esta parte la capacidad de emitir informes precisos apoyados en una contabilidad analítica bien parametrizada. Estos informes son de gran ayuda para validar el modelo de negocio y por consiguiente las grandes inversiones que se llevan a cabo en este tipo de proyectos.

La correcta modelización de algunos flujos, como pueda ser el de contratación por parte del ISP del servicio, pueden significar una mejora importante en los indicadores, en particular el ROI y el porcentaje de ocupación de la red. En cuanto a la parte de conexión con los sistemas, que hablaremos en el próximo post, la integración de la automatización utilizando CD/CI con equipos de ingenieros multidisciplinares es la clave para el éxito de estos proyectos.

/by José Manuel Román Fernández Checa

Distancia Administrativa vs Métrica

Cheatsheet, Uncategorized

Distancia Administrativa vs Métrica

¿Qué hace un router?

El objetivo del router es distribuir paquetes por la ruta más adecuada en cada momento. Para ello consulta su tabla FIB, y elige en cada momento que interfaz de salida va a seleccionar para un paquete determinado. En esta consulta interviene la tabla RIB, donde tendrá almacenada la ruta para cada una de las direcciones. Es aquí donde actúan los diferentes parámetros como la longitud del prefijo, la métrica o la distancia administrativa, creando un algoritmo a interpretar. El router puede tener instalada en su tabla de rutas, diferentes direcciones aprendidas por medio de diferentes protocolos de enrutamiento y en base a esto, modificará su algoritmo de selección de ruta.

Tabla FIB: Es la información actual que un router usará para elegir la interfaz correcta por la que enviar un paquete. Esta información se elige de la tabla RIB y de las tablas de adyadcencia para poder encapsular correctamente el paquete.

Tabla RIB: Se deriva del plano de control. No se utiliza para hacer Forwarding. Cada protocolo de enrutamiento tiene su propia tabla RIB y seleccionan sus mejores candidatas para instalar sus rutas en una tabla RIB global. Una vez instaladas en la tabla RIB global, ya pueden ser usadas para el Forwarding.

¿Qué es la convergencia?

Es el objetivo principal de todos los protocolos de enrutamiento. Cuando un conjunto de enrutadores converge significa que todos sus elementos se han puesto de acuerdo y reflejan la situación real del entorno de red donde se encuentran. La velocidad con la que los protocolos convergen después de un cambio es una buena medida de la eficacia del protocolo de enrutamiento.

¿Qué es la métrica?

La métrica es el análisis, y en lo que se basa el algoritmo del protocolo de enrutamiento dinámico para elegir y preferir una ruta por sobre otra, basándose en eso el protocolo creará la tabla de enrutamiento en el router, publicando sólo las mejores rutas. Un protocolo de enrutamiento utiliza métrica para determinar qué vía utilizar para transmitir un paquete a través de un Intercambio. La métrica utilizada por protocolos de enrutamiento incluyen:

■Numero de saltos: Número de routers por los que pasará un paquete.
■Pulsos: Retraso en un enlace de datos usando pulsos de reloj de PC.
■Coste: Valor arbitrario, basado generalmente en el ancho de banda, el coste económico u otra medida.
■Ancho de banda: Capacidad de datos de un enlace.
■Retraso: Cantidad de actividad existente en un recurso de red, como un router o un enlace.
■Carga: Cantidad de actividad existente en un recurso de red, como un router o un enlace.
■Fiabilidad: Se refiere al valor de errores de bits de cada enlace de red.
■MTU: Unidad máxima de transmisión. Longitud máxima de trama en octetos que puede ser aceptada por todos los enlaces de la ruta. Los protocolos de enrutamiento almacenar los resultados de estas cifras en una tabla de enrutamiento.

¿Qué es la Distancia Administrativa?

La Distancia Administrativa es otro criterio que se comprueba cuando se usa más de una protocolo de enrutamiento para llegar a una misma red. Sirve para que un router elija la ruta a utilizar para alcanzar esa misma red La ruta del protocolo de enrutamiento que tenga la distancia administrativa más baja sera la mejor ruta. La distancia administrativa solo tiene un efecto “local” dentro del router y no se propaga ni se anuncia de ninguna manera. Es un criterio de fiabilidad que mide el origen del aprendizaje de esa ruta.

Fabricantes

Como hemos destacado antes, la distancia administrativa es una implementación interna del router y no se propaga, por lo que tenemos que estar muy atentos a cómo lo hace cada fabricante. Huawei, este parámetro lo conoce como Preference

En esta tabla, hemos recopilado un resumen de las distancias administrativas para varios fabricantes líderes en el mercado. Esta tabla nos será muy útil cuando configuremos escenarios multifabricante.

En el Máster en Arquitectura de Redes de Operadores de Telecomunicaciones, en el curso HCIA Routing&Switching y en las certificaciones oficiales de MikroTik impartidas en loopback0 (MTCRE), explicamos en profundidad las características de los protocolos de enrutamiento así como sus correctas implementaciones y configuraciones en entornos multifabricante.

/by Victor Bolaños Guerra

Configuración BGP – eBGP y anunciar rutas con Huawei

Uncategorized

Configuración BGP – eBGP y anunciar rutas con Huawei

Descripción

Continuando con nuestra serie de artículos referidos al protocolo BGP, en esta entrada comentamos teóricamente las principales diferencias entre iBGP y eBGP y prácticamente como se anuncian rutas con los routers Huawei.

Diferencias clave entre EBGP and IBGP :

	EBGP	IBGP
1	EBGP significa External Border Gateway Protocol.	IBGP significa Internal Border Gateway Protocol.
2	Funciona entre routers BGP en un sistema autónomo diferente.	Funciona entre routers BGP en el mismo sistema autónomo.
3	Las rutas de EBGP recibidas de un par de EBGP pueden ser anunciadas a los pares de EBGP e IBGP.	Las rutas del IBGP recibidas de un par del IBGP no pueden ser anunciadas a otro par del IBGP sino que pueden ser anunciadas a un par del EBGP.
4	No requiere una topología de malla completa.	Requiere topología de malla completa.
5	Usado entre routers de una organización o entre la organización y el ISP.	Se utiliza dentro de la misma organización.
6	Utiliza el atributo as-path para prevenir los bucles.	Usa BGP Split Horizon como prevención de bucles.
7	Sus peers por defecto se establecen con TTL = 1	Sus peers por defecto se establecen con TTL = 255
8	En los peers de EBGP, los atributos como la preferencia local no se envían.	En los peers del IBGP, se envían atributos como la preferencia local.
9.	Cuando la ruta se anuncia a un peer de EBGP, el next-hop se cambia al router local.	Cuando se anuncia la ruta a un peer del IBGP, el siguiente salto permanece sin cambios.
10.	Una ruta aprendida de un peer de eBGP será anunciada de vuelta a otro vecino de iBGP o eBGP por defecto.	Una ruta aprendida de un peer iBGP no se anunciará a otro vecino del iBGP por defecto.

La distancia administrativa depende de cada fabricante. En los routers Huawei, la distancia administrativa es 255 tanto para eBGP como para iBGP.

Comenzaremos el proceso BGP y estableceremos la relación de peering entre dispositivos. En base a las características descritas en la comparación en el punto 9 y 10, el siguiente paso es el anunciar y/o aprender rutas. En este artículo enseñaremos de forma sencilla como anunciar una ruta que ya tenemos instalada en nuestra tabla de rutas. En entradas posteriores configuraremos políticas de filtrado, obligatorias para el buen funcionamiento del eBGP.

Objetivos de la práctica

Establecer una relación eBGP.
Anunciar rutas en un external BGP.

Topología

Configuración paso a paso

<Huawei>system-view
[Huawei]sysname R1
[R1]interface GigabitEthernet 0/0/0
[R1-GigabitEthernet0/0/0]ip address 10.200.1.1 30
[R1-GigabitEthernet0/0/0]quit
#
<Huawei>system-view
[Huawei]sysname R2
[R2]interface GigabitEthernet 0/0/0
[R2-GigabitEthernet0/0/0]ip address 10.200.1.2 30
[R2-GigabitEthernet0/0/0]quit
#
[R1]bgp 64501
[R1-bgp]router-id 10.0.1.1
[R1-bgp]peer 10.200.1.2 as-number 64502
[R1-bgp]quit
#
[R2]bgp 64502
[R2-bgp]router-id 10.0.2.2
[R2-bgp]peer 10.200.1.1 as-number 64501
[R2-bgp]quit
#
[R1]interface LoopBack 0
[R1-LoopBack0]ip address 10.0.1.1 32
[R1-LoopBack0]quit
[R1]bgp 64501
[R1-bgp]network 10.0.1.1 32
[R1-bgp]quit
#
[R2]interface LoopBack 0
[R2-LoopBack0]ip address 10.0.2.2 32
[R2-LoopBack0]quit
[R2]bgp 64502
[R2-bgp]network 10.0.2.2 32
[R2-bgp]quit

Paso 1. Asignar direcciones IP´s.

<Huawei>system-view
[Huawei]sysname R1
[R1]interface GigabitEthernet 0/0/0
[R1-GigabitEthernet0/0/0]ip address 10.200.1.1 30
[R1-GigabitEthernet0/0/0]quit

<Huawei>system-view
[Huawei]sysname R2
[R2]interface GigabitEthernet 0/0/0
[R2-GigabitEthernet0/0/0]ip address 10.200.1.2 30
[R2-GigabitEthernet0/0/0]quit

Paso 2. Montar un eBGP entre 2 routers.

[R1]bgp 64501 (1)
[R1-bgp]router-id 10.0.1.1 (2)
[R1-bgp]peer 10.200.1.2 as-number 64502 (3)
[R1-bgp]quit

1	Activamos y accedemos del BGP..
2	Asignamos como router-id el 10.0.1.1.
3	Definimos como peer al 10.200.1.2 cuyo AS es 64502.

[R2]bgp 64502 (1)
[R2-bgp]router-id 10.0.2.2 (2)
[R2-bgp]peer 10.200.1.1 as-number 64501 (3)
[R2-bgp]quit

1	Activamos y accedemos del BGP.
2	Asignamos como router-id el 10.0.2.2.
3	Definimos como peer al 10.200.1.1 cuyo AS es 64501.

Paso 3. Anunciar una ruta.

[R1]interface LoopBack 0 (1)
[R1-LoopBack0]ip address 10.0.1.1 32 (2)
[R1-LoopBack0]quit
[R1]bgp 64501 (3)
[R1-bgp]network 10.0.1.1 32 (4)
[R1-bgp]quit

1	Nos metemos en el interfaz LoopBack 0.
2	Asignamos la IP 10.0.1.1 con máscara /32.
3	Accedemos al BGP.
4	Anunciamos la red 10.0.1.1/32.

[R2]interface LoopBack 0 (1)
[R2-LoopBack0]ip address 10.0.2.2 32 (2)
[R2-LoopBack0]quit
[R2]bgp 64502 (3)
[R2-bgp]network 10.0.2.2 32 (4)
[R2-bgp]quit

1	Nos metemos en el interfaz LoopBack 0.
2	Asignamos la IP 10.0.2.2 con máscara /32.
3	Accedemos al BGP.
4	Anunciamos la red 10.0.2.2/32.

En este ejemplo nuestros routers han anunciado y aprendido su dirección de loopback al router vecino recíprocamente.

Comprobación

Para asegurarnos de que se ha realizado correctamente la configuración, comprobamos los peers ejecutando desde R2 el siguiente comando display bgp peer:

Posteriormente, ejecutamos desde R2 el siguiente comando display bgp routing-table:

A continuación, ejecutamos desde R2 el siguiente comando display ip routing-table:

Conclusión

Como final de la explicación, adjuntamos las capturas de nuestro escenario. Con esto se demuestra el uso del puerto 179 TCP para el intercambio de mensajes. Una vez establecida la relación entre peers, en los KEEPALIVE Message es donde se produce el anuncio de las rutas. En este caso, la red anunciada es la de loopback, que se ha aprendido mediante un protocolo de ruteo interno IGP.

Con esta explicación, hemos visto que anunciar y aprender rutas por BGP es muy sencillo. Cuando queremos anunciar diferentes redes, se hace fundamental cuales rutas tenemos que importar y cuales rutas tenemos que exportar. Para eso entran en juego diferentes atributos del protocolo BGP así como la correcta configuración de los filtros de entrada y salida.

En el Máster en Arquitectura de Redes de Operadores de Telecomunicaciones, en el curso HCIP Routing&Switching y en las certificaciones oficiales de MikroTik impartidas en loopback0 (MTCINE), explicamos en profundidad los diferentes tipos de ruteos dinámicos, así como sus pros y contras, escenarios de uso y configuraciones.

/by Victor Bolaños Guerra

Configuración de Wireguard en MikroTik

Uncategorized

Configuración de Wireguard en MikroTik

¿Por qué usar Wireguard?

Wireguard fue diseñado por Jason A. Donenfeld como una alternativa a los túneles VPN ya existentes. Mr Donenfeld tuvo muy claras las premisas para su desarrollo. Debe ser simple y sencillo de usar, con un alto rendimiento, necesita ser criptográficamente seguro, proporcionar una mínima superficie de ataque, y cada detalle y decisión del desarrollo, debe ser considerado y valorado intensamente antes de su aprobación o descarte.

En los sistemas Linux, la solución estándar para los asegurar las comunicaciones de la capa 3 es IPSec. Esto permite el poder proteger protocolos de la capa 4 como TCP y UDP, siendo muy versátil con respecto a los protocolos de capa de aplicación, como SSL y TLS. Puede utilizarse para crear VPN en sus dos modos: transporte y túnel. Es la solución por defecto para la interconexión entre sedes, puesto que está compuesto por un conjunto de RFCs ampliamente testados y sobre los que se sigue trabajando. Combinado con L2TP, nos da la posibilidad de que el concentrador de VPN no tenga que conocer previamente la IP de la conexión remota, por lo que es muy útil para trabajadores itinerantes. Es considerado de uso corporativo.

OpenVPN es otra de las herramientas utilizada para VPN. Creada pensando en todo tipo de usuarios, es una herramienta basada en código libre y usa tanto SSL como TLS para la encriptación. Puede funcionar sobre UDP o sobre TCP multiplexando los túneles SSL creados sobre un solo puerto TCP/UDP. Tiene su propio protocolo de seguridad y no necesita basarse en otras tecnologías como IKE o IPSec. Sin embargo, es bien conocido su problema cuando funciona sobre TCP para establecer el túnel: el rendimiento es aceptable solo mientras haya suficiente exceso de ancho de banda en la red no tunelizada, para así poder garantizar que los timers TCP no expiren. Este fenómeno se conoce como TCP Meltdown.

¿Puedo declarar una vez más mi amor por [WireGuard] y esperar que se fusione pronto? Tal vez el código no sea perfecto, pero lo he ojeado, y comparado con los horrores que son OpenVPN e IPSec, es una obra de arte.

Linus Torvalds, Linux Kernel Mailing List

En definitiva, Wireguard resuelve cantidad de problemas inherentes a las VPN: es fácil de configurar, es estable, es seguro, la conexión se produce rápidamente, el rendimiento es alto…

Descripción

RouterOS soporta una multitud de túneles sin necesidad de licenciamiento adicional: GRE, IPoIP, EoIP y PPP: PPPoE, PPP, PPTP, SSTP, L2TP, OVPN. En el verano de 2020 han añadido soporte para Wireguard en su versión de desarrollo 7.1beta2.

Descripción del Laboratorio

En este laboratorio, prepararemos un escenario donde podamos unir dos sedes remotas mediante la tecnología Wireguard.

Objetivos de la práctica

Conocer el funcionamiento de Wireguard
Montar un túnel entre 2 routers
Verificar la configuración realizada.

Topología

Configuración paso a paso

1. Asignar direcciones IP

[admin@R1] > ip address/ add interface=ether1 address=192.168.1.10/24 disabled=no
[admin@R1] > ip route/add dst-address=0.0.0.0/0 gateway=192.168.1.1

[admin@R2] > ip address/ add interface=ether1 address=192.168.1.11/24 disabled=no
[admin@R2] > ip route/add dst-address=0.0.0.0/0 gateway=192.168.1.1

Es un escenario se ha montado sobre en una red local, por lo que ambos routers compartirán gateway y estableceremos el túnel a través de ella. Será nuestro “internet”. Aunque la topología sea sencilla, ahora es el momento de ejecutar un ping y comprobar que los routers responden entre sí.

2. Configurar Wireguard

[admin@R1] > interface/wireguard/add name=wg1 listen-port=56710
[admin@R1] > :put [/interface/wireguard/get 0 public-key]

Con el último comando obtenemos la clave pública generada por R1. La llamaremos CLAVE-PUBLICA-R1. Esta clave la introduciremos a continuación en el peer del R2 entrecomillada ” ” puesto que al tratarse de una cadena con caracteres especiales, nos puede inducir al error.

[admin@R2] > interface/wireguard/add name=wg1 listen-port=56711
[admin@R2] > interface/wireguard/peers/add interface=wg1 endpoint=192.168.1.10:56710 allowed-address=0.0.0.0/0 public-key="CLAVE-PUBLICA-R1"
[admin@R2] > :put [/interface/wireguard/get 0 public-key]

Hemos creado el peer permitiendo 0.0.0.0/0 (todas las redes) por lo que, dependiendo de la configuración requerida, lo prudente es permitir solo las redes deseadas. Con el último comando obtenemos la clave pública generada por R2. La llamaremos CLAVE-PUBLICA-R2. Esta clave la introduciremos a continuación en el peer del R1 entrecomillada ” ” puesto que al tratarse de una cadena con caracteres especiales, nos puede inducir al error.

[admin@R1] > interface/wireguard/peers/add interface=wg1 endpoint=192.168.1.11:56711 allowed-address=0.0.0.0/0 public-key="CLAVE-PUBLICA-R2"

Ya tenemos nuestro túnel funcionando. Ahora para probar la conectividad, le asignaremos IP a cada una de las interfaces creadas.

3. Asignar direcciones IP al túnel Wireguard

[admin@R1] > ip address/ add interface=wg1 address=10.0.0.10/24 disabled=no

[admin@R2] > ip address/ add interface=wg1 address=10.0.0.11/24 disabled=no

Con esta sencilla configuración, ya tenemos conectividad en capa 3 sobre el túnel. A partir de aquí, ya podríamos enrutar sobre esta nueva red, proporcionando así conectividad en sedes remotas. Con la configuración planteada, no es muy complicado cambiar los parámetros correspondientes a un escenario en el que los propios MikroTik gestionen las IP públicas.

Recordando nuevamente que estamos ante una versión beta, resaltamos que el escenario ha sido configurado mediante terminal exclusivamente. Mediante Winbox hay ciertos parámetros que aún no son accesibles por lo que es probable que la configuración se genere con errores.

Comprobación

→ Nos aseguramos de la correcta configuración en utilizando la herramienta incorporada al routerOS Bandwidth Test.

Conclusión

Proporcionar conectividad VPN es una de las múltiples funcionalidades para lo que MikroTik nos ofrece una plataforma sólida. Aunque tradicionalmente ha sido un fabricante muy orientado al sector ISP/WISP, la incorporación de Wireguard es una clara apuesta de la marca para continuar posicionándose en el sector corporativo. Con Wireguard, una compañía puede tanto establecer un servicio multisede como proporcionar acceso a trabajadores remotos o roadwarriors sin tener que depender exclusivamente de IPSec, OpenVPN, etc. En su web podemos encontrar cada uno de los clientes para las diferentes plataformas más usuales.

En el Máster en Arquitectura de Redes de Operadores de Telecomunicaciones, y en las certificaciones oficiales de MikroTik impartidas en loopback0 (MTCNA y MTCRE), explicamos en profundidad los diferentes tipos de túneles y VPN, así como sus pros y contras.

/by Victor Bolaños Guerra

Configuración de OSPF con Huawei: Dos Áreas

Uncategorized

OSPF con Huawei – Dos Áreas

¿Por qué usar dos áreas?

En el primer artículo de esta serie ya explicamos las ventajas fundamentales de usar OSPF en redes considerablemente grandes. Continuando con la serie de artículos referidos al protocolo OSPF, en este artículo profundizaremos en las bondades de poder separar en áreas diferentes los routers involucrados en OSPF así como su configuración en routers Huawei. Es el momento de echarle un vistazo al artículo anterior puesto que haremos referencia constantemente a los tipos de LSA descritos.

Descripción de las áreas standard OSPF

Recuperando la descripción de área OSPF del artículo anterior:

OSPF nos permite agrupar conjuntos de redes y cada grupo de estas redes se denominan áreas. La topología de un área se esconde del resto del Sistema Autónomo, lo que habilita una gran reducción del tráfico de ruteo así como protege al área de una inyección incorrecta de información de ruteo.

El tipo básico de áreas de OSPF es:

■ Backbone area (area 0)

El área backbone es esencialmente un área standard que ha sido designada como el punto central al que todas las otras áreas conectan. Su existencia es obligatoria y todo el tráfico entre áreas debe atravesarla. Todo el enrutamiento entre áreas se distribuye a través del área backbone.

■ Standard area

En el interior de un área standard se producen LSA (anuncios de actualización del estado de enlaces) de tipo 1 y de tipo 2. Recordemos que el tipo 1 describe el estado y el coste de los link conectados al área de un router y que el tipo 2 es generada por DR (router designado) y representa al conjunto de routers unidos a una red. Para continuar explicando como podemos unir dos áreas, se hace necesario la describir el papel que toman los routers involucrados. Lo vemos en la imagen a continuación.

■ Internal Routers

Los routers internos son aquellos que tienen todas sus interfaces dentro del mismo área. Todos los routers del mismo área tienen la misma LSDB (Link-State Data Base).

■ Backbone Routers

Son los routers que tienen al menos una interfaz conectada al área backbone.

■ Area Border Routers (ABR)

Los routers de borde de área son aquellos que tienen interfaces pertenecientes a diferentes áreas. Mantienen diferentes LSDB para cada área. Estos routers son los encargados de transmitir los LSA entre áreas. Son los únicos routers donde se puede configurar la sumarización de rutas. Su misión es separar las zonas de propagación de LSA. Al introducir un ABR es cuando aparecen los LSA de tipo 3.

Los LSA de tipo 3 son los summary-LSAs. Describen las rutas entre áreas y permiten condensar la información de rutas en los límites del área. Se originan en los routers de borde.

Descripción del Laboratorio

El área backbone es esencialmente un área standard que ha sido designada como el punto central al que todas las otras áreas conectan. En esta práctica se realizará una configuración de OSPF con el fin de entender cómo se comunican los equipos bajo un entorno OSPF en dos áreas distintas, comprobando la propagación de los LSA de tipo 3. Para ello se dispondrá de un solo router ABR.

Objetivos de la práctica

Conocer el funcionamiento de OSPF
Montar un OSPF entre 4 routers.
Verificar la configuración realizada.

Topología

Script de Configuración

<Huawei>system-view
[Huawei]sysname R1
[R1]interface GigabitEthernet 0/0/0
[R1-GigabitEthernet0/0/0]ip address 192.168.0.1 24
[R1-GigabitEthernet0/0/0]quit
#
<Huawei>system-view
[Huawei]sysname R2
[R2]interface GigabitEthernet 0/0/0
[R2-GigabitEthernet0/0/0]ip address 192.168.0.2 24
[R2-GigabitEthernet0/0/0]quit
[R2]interface GigabitEthernet 0/0/1
[R2-GigabitEthernet0/0/0]ip address 10.0.0.2 24
[R2-GigabitEthernet0/0/0]quit
#
<Huawei>system-view 
[Huawei]sysname R3 
[R3]interface GigabitEthernet 0/0/1 
[R3-GigabitEthernet0/0/1]ip address 10.0.0.3 24 
[R3-GigabitEthernet0/0/1]quit
[R3]interface GigabitEthernet 0/0/0
[R3-GigabitEthernet0/0/0]ip address 172.16.0.1 24 
[R3-GigabitEthernet0/0/0]quit
#
<Huawei>system-view 
[Huawei]sysname R4 
[R4]interface GigabitEthernet 0/0/0 
[R4-GigabitEthernet0/0/0]ip address 172.16.0.2 24 
[R4-GigabitEthernet0/0/0]quit
#
[R1]ospf 1 router-id 192.168.0.1
[R1-ospf-1]area 0
[R1-ospf-1-area-0.0.0.0]network 192.168.0.0 0.0.0.255
[R1-ospf-1-area-0.0.0.0]quit
[R1-ospf-1]quit
# 
[R2]ospf 1 router-id 192.168.0.2
[R2-ospf-1]area 0 
[R2-ospf-1-area-0.0.0.0]network 192.168.0.0 0.0.0.255
[R2-ospf-1-area-0.0.0.0]quit
[R2-ospf-1]quit
[R2]ospf 1
[R2-ospf-1]area 1 
[R2-ospf-1-area-0.0.0.1]network 10.10.0.0 0.0.0.255 
[R2-ospf-1-area-0.0.0.1]quit 
[R2-ospf-1]quit
# 
[R3]ospf 1 router-id 10.10.0.3 
[R3-ospf-1]area 1 
[R3-ospf-1-area-0.0.0.1]network 10.10.0.0 0.0.0.255 
[R3-ospf-1-area-0.0.0.1]network 172.16.0.0 0.0.0.255 
[R3-ospf-1-area-0.0.0.1]quit 
[R3-ospf-1]quit
#
[R4]ospf 1 router-id 172.16.0.2
[R4-ospf-1]area 1
[R4-ospf-1-area-0.0.0.1]network 172.16.0.0 0.0.0.255 
[R4-ospf-1-area-0.0.0.1]quit 
[R4-ospf-1]quit

Configuración paso a paso

1. Asignar direcciones IP a las interfaces

<Huawei>system-view 
[Huawei]sysname R1 
[R1]interface GigabitEthernet 0/0/0 
[R1-GigabitEthernet0/0/0]ip address 192.168.0.1 24 
[R1-GigabitEthernet0/0/0]quit

<Huawei>system-view 
[Huawei]sysname R2 
[R2]interface GigabitEthernet 0/0/0 
[R2-GigabitEthernet0/0/0]ip address 192.168.0.2 24 
[R2-GigabitEthernet0/0/0]quit
[R2]interface GigabitEthernet 0/0/1 
[R2-GigabitEthernet0/0/1]ip address 10.0.0.2 24 
[R2-GigabitEthernet0/0/1]quit

<Huawei>system-view 
[Huawei]sysname R3 
[R3]interface GigabitEthernet 0/0/1 
[R3-GigabitEthernet0/0/1]ip address 10.0.0.3 24 
[R3-GigabitEthernet0/0/1]quit
[R3]interface GigabitEthernet 0/0/0
[R3-GigabitEthernet0/0/0]ip address 172.16.0.1 24 
[R3-GigabitEthernet0/0/0]quit

<Huawei>system-view 
[Huawei]sysname R4
[R4]interface GigabitEthernet 0/0/0 
[R4-GigabitEthernet0/0/0]ip address 172.16.0.2 24 
[R4-GigabitEthernet0/0/0]quit

Ahora es el momento de ejecutar un ping y comprobar que los routers responden entre sí.

2. Configurar OSPF en los diferentes áreas

[R1]ospf 1 router-id 192.168.0.1 
[R1-ospf-1]area 0
[R1-ospf-1-area-0.0.0.0]network 192.168.0.0 0.0.0.255 
[R1-ospf-1-area-0.0.0.0]quit 
[R1-ospf-1]quit

→ En esta configuración R2 actúa como ABR por lo que configuramos un solo proceso (también llamado instancia), al que pertenecen dos redes, puesto que cada interfaz está en una area distinta.

[R2]ospf 1 router-id 192.168.0.2 
[R2-ospf-1]area 0 
[R2-ospf-1-area-0.0.0.0]network 192.168.0.0 0.0.0.255 
[R2-ospf-1-area-0.0.0.0]quit 
[R2-ospf-1]quit 
[R2]ospf 1 
[R2-ospf-1]area 1 
[R2-ospf-1-area-0.0.0.1]network 10.10.0.0 0.0.0.255 
[R2-ospf-1-area-0.0.0.1]quit 
[R2-ospf-1]quit

→ En esta configuración R3 actúa como router interno aunque configuremos un solo proceso (también llamado instancia), al que pertenecen dos redes, al estar todas las interfaces en el mismo área:

[R3]ospf 1 router-id 10.10.0.3 
[R3-ospf-1]area 1 
[R3-ospf-1-area-0.0.0.1]network 10.10.0.0 0.0.0.255 
[R3-ospf-1-area-0.0.0.1]network 172.16.0.0 0.0.0.255 
[R3-ospf-1-area-0.0.0.1]quit 
[R3-ospf-1]quit

[R4]ospf 1 router-id 172.16.0.2 
[R4-ospf-1]area 1 
[R4-ospf-1-area-0.0.0.1]network 172.16.0.0 0.0.0.255 
[R4-ospf-1-area-0.0.0.1]quit
[R4-ospf-1]quit

Comprobación

→ Nos aseguramos de la correcta configuración en R2 con el siguiente comando display ospf brief:

huawei-ospf-area-brief

→ Comprobamos la tabla de rutas en R1, con el comando display ip routing-table:

→ Comprobamos la base de datos en R1, con el comando display ospf lsdb:

→ Comprobamos la base de datos en R2, con el comando display ospf lsdb:

→ Comprobamos la base de datos en R3, con el comando display ospf lsdb:

→ Comprobamos la base de datos en R4, con el comando display ospf lsdb:

Conclusión

En este ejemplo hemos podido comprobar que levantar una red OSPF en un dos áreas distintas, unidas por un ABR, se trata de una configuración muy sencilla. Con esta configuración, ya tenemos a los routers compartiendo información acerca de la topología de la red y de sus cambios, mediante los tipos de LSA correspondientes. Con esta información proceden a actualizar sus LSDB. A medida que avancemos con esta serie de configuraciones explicando el protocolo OSPF, iremos creando una red cada vez más grande y podremos comprobar la verdadera potencia de este ruteo dinámico.

En la captura de R2 resultante de esta configuración se puede comprobar el intercambio de paquetes entre los dos routers involucrados en un área standard de este escenario OSPF. En la captura de R1 comprobamos como se producen los LS Update con los Summary LSA.

En el Máster en Arquitectura de Redes de Operadores de Telecomunicaciones, en el curso HCIA Routing&Switching y en las certificaciones oficiales de MikroTik impartidas en loopback0 (MTCRE), explicamos en profundidad las características del ruteo OSPF así como sus diferentes técnicas de implementación.

/by Victor Bolaños Guerra

Configuración de OSPF con Huawei: Área Única

Uncategorized

OSPF con Huawei – Área Única

¿Por qué usar OSPF?

OSPF es uno de los protocolos de ruteo interno más usados cuando hablamos de redes de un tamaño considerable. Al ser un protocolo de enrutamiento dinámico basado en el enlace-estado, suple las carencias de los cuatro protocolos denominados vector-distancia (RIPv1, RIPv2, IGRP, EIGRP). La gran ventaja de los protocolos enlace-estado, como OSPF, es que permiten a los routers conocer el estado de la red al completo. Esta tecnología toma las decisiones basadas en el estado de la red, por lo tanto, se hace un enrutamiento mucho más eficiente, eligiendo el camino más corto primero (Open Shortest Path First).

Con esta entrada del blog, comenzamos con una serie de configuraciones utilizando el protocolo OSPF. Empezaremos gradualmente con configuraciones básicas e iremos integrando diferentes fabricantes.

Breve descripción de OSPF

RFC2328 definió OSPF como un protocolo de ruteo dinámico que detecta rápidamente cambios en la topología dentro del Sistema Autónomo (como fallos de la interfaz del router) y calcula rutas nuevas carentes de bucles después de un periodo de convergencia. Este periodo de convergencia es corto e involucra un mínimo de tráfico. Para ello, cada router mantiene una base de datos idéntica que contiene la descripción de la topología de la red y para actualizar esta base de datos, se producen una serie de intercambios de paquetes. Estos paquetes permiten a cada router conformar un árbol de los caminos más cortos con respecto a cada uno de los vecinos.

Existen seis tipos de paquetes involucrados en conocer las adyacencias entre vecinos.

■ Hello Packets
■ Database Description Packets
■ Link-State Request Packets
■ Link-State Update Packets
■ Link-State Acknowledgment Packets
■ Link-State Advertisement Packets

Los anuncios de OSPF se denominan Link State Advertisements (LSA) y comunican la información del estado del enlace entre vecinos. A continuación describimos un breve resumen de los tipos de LSA:

■ Tipo 1: Routers LSA. Describe el estado y el coste de los link conectados al área de un router.
■ Tipo 2: Networks LSA. Representa al DR (router designado) para el enlace multiacceso. Representa al conjunto de routers unidos a una red.
■ Tipo 3: Summary LSA. Ruta interna generada en el ABR.
■ Tipo 4: Summary LSA. Ruta generada en el ASBR (router limítrofe del Sistema Autónomo, router que tiene al menos una interfaz conectada a una red externa).
■ Tipo 5: Una ruta externa al dominio OSPF
■ Tipo 7: Usado en las áreas stub en lugar del LSA Tipo 5

Los tipos 1 y 2 nos los encontraremos en todas las áreas y nunca será inyectados fuera de un área. Los otros tipos de LSA son anunciados dependiendo del tipo de área. Pero, ¿qué es un área?

Los tipos de áreas de OSPF son:

■ Backbone area (area 0)
■ Standard area
■ Stub area
■ Totally stubby area
■ Not-so-stubby-area (NSSA)

Descripción del Laboratorio

El área backbone es esencialmente un área standard que ha sido designada como el punto central al que todas las otras áreas conectan. En esta práctica se realizará una configuración de OSPF con el fin de entender como se comunican los equipos bajo un entorno OSPF en una única área.

Objetivos de la práctica

Conocer el funcionamiento de OSPF
Montar un OSPF entre 2 routers.
Verificar la configuración realizada.

Topología

Script de Configuración

<Huawei>system-view
[Huawei]sysname R1
[R1]interface GigabitEthernet 0/0/0
[R1-GigabitEthernet0/0/0]ip address 192.168.0.1 24
[R1-GigabitEthernet0/0/0]quit
#
<Huawei>system-view
[Huawei]sysname R2
[R2]interface GigabitEthernet 0/0/0
[R2-GigabitEthernet0/0/0]ip address 192.168.0.2 24
[R2-GigabitEthernet0/0/0]quit
#
[R1]ospf 1 router-id 192.168.0.1
[R1-ospf-1]area 0
[R1-ospf-1-area-0.0.0.0]network 192.168.0.0 0.0.0.255
#
[R2]ospf 1 router-id 192.168.0.2
[R2-ospf-1]area 0
[R2-ospf-1-area-0.0.0.0]network 192.168.0.0 0.0.0.255

Configuración paso a paso

1. Asignar direcciones IP

<Huawei>system-view 
[Huawei]sysname R1 
[R1]interface GigabitEthernet 0/0/0 
[R1-GigabitEthernet0/0/0]ip address 192.168.0.1 24 
[R1-GigabitEthernet0/0/0]quit

<Huawei>system-view 
[Huawei]sysname R2 
[R2]interface GigabitEthernet 0/0/0 
[R2-GigabitEthernet0/0/0]ip address 192.168.0.2 24 
[R2-GigabitEthernet0/0/0]quit

Aunque la topología sea sencilla, ahora es el momento de ejecutar un ping y comprobar que los routers responden entre sí.

2. Configurar OSPF en un área

[R1]ospf 1 router-id 192.168.0.1 
[R1-ospf-1]area 0 
[R1-ospf-1-area-0.0.0.0]network 192.168.0.0 0.0.0.255

[R2]ospf 1 router-id 192.168.0.2 
[R2-ospf-1]area 0 
[R2-ospf-1-area-0.0.0.0]network 192.168.0.0 0.0.0.255

Comprobación

→ Para asegurarnos de que se ha configurado OSPF correctamente, ejecutamos en R2 el siguiente comando display ospf brief:

huawei-area0-display-ospf-brief

Conclusión

Cómo has podido comprobar, levantar una red OSPF en un área única se trata de una configuración muy sencilla. Con esta configuración, ya tenemos a los dos routers compartiendo información acerca de la topologia de la red y de sus cambios. Este protocolo demuestra todo su potencial en redes de gran tamaño, en la que múltiples routers e infinidad de rutas, nos permiten crear redes con una alta capacidad de redundancia. Este tipo de enrutamiento es muy común en el escenario de los proveedores de servicio de internet (ISP y WISP), puesto que si algún nodo falla, la red converge rápidamente y no se pierde la conectividad.

En el Máster en Arquitectura de Redes de Operadores de Telecomunicaciones, en el curso HCIA Routing&Switching y en las certificaciones oficiales de MikroTik impartidas en loopback0 (MTCRE), explicamos en profundidad las características del ruteo OSPF así como sus diferentes técnicas de implementación.

En la captura resultante de esta configuración se puede comprobar el intercambio de paquetes entre los dos routers involucrados en el área backbone de este escenario OSPF.

/by Victor Bolaños Guerra

La tabla RAW en MikroTik

Uncategorized

La tabla RAW en MikroTik

¿Por qué usar la tabla RAW? O como mitigar un ataque DoS de manera eficiente

La entrada del blog que tiene la Oficina de Seguridad del Internauta española, explica perfectamente la descripción de los ataques DoS. De esta descripción, cabe destacar lo siguiente:

“En los ataques DoS se generan una cantidad masiva de peticiones al servicio desde una misma máquina o dirección IP, consumiendo así los recursos que ofrece el servicio hasta que llega un momento en que no tiene capacidad de respuesta y comienza a rechazar peticiones, esto es cuando se materializa la denegación del servicio.

En el caso de los ataques DDoS, se realizan peticiones o conexiones empleando un gran número de ordenadores o direcciones IP. Estas peticiones se realizan todas al mismo tiempo y hacia el mismo servicio objeto del ataque. Un ataque DDoS es más difícil de detectar, ya que el número de peticiones proviene desde diferentes IP´s y el administrador no puede bloquear la IP que está realizando las peticiones, como sí ocurre en el ataque DoS.”

La plataforma RouterOS de MikroTik, posee un cortafuegos de estado completo (stateful firewall) que, entendiendo su funcionamiento en profundidad, nos permite mitigar este tipo de ataques.

Descripción

MikroTik describe en su wiki el funcionamiento de la tabla RAW como la que permite omitir o eliminar paquetes de forma selectiva antes de que se produzca el seguimiento de la conexión (connection tracking), de manera que reduce la carga de la CPU significativamente. Es por esto que es una herramienta muy útil para mitigar los ataques de denegación de servicio.

Cómo podemos acceder a la tabla Raw

Para acceder a la tabla Raw a través de WinBox, se accede entrando en el menú lateral a IP → Firewall donde se abrirá una pestaña y elegiremos la opción Raw y ahí podremos crear tablas Raw haciendo click en el .

Diferencias entre la tabla Raw y Filter Rules

Si observamos bien la imagen siguiente, en la que se muestra la comparación entre tabla Filter Rules y tabla Raw, veremos que los campos se parecen, hasta In Interface List y Out Interface List.
La tabla Filter Rules es diferente, ya que consta de una parte de Marcado y otra de Conexión.
La tabla Filter Rules, permite definir reglas mucho más precisas con respecto al “matching” y a la acción a realizar.

Pero, ¿esto por qué? Comparando con la tabla NAT

Si observamos la tabla Raw, veremos que en la opción Chain (cadena), hay solo dos opciones, prerouting y output (Figura 2), donde el realizar el marcado de paquetes y la conexión se nos antoja innecesario ya que, según la arquitectura del Packet Flow, el funcionamiento del prerouting y el output se produce previo al marcado de paquetes y la conexión y no después.

En cambio, en la opción Chain (cadena) de la tabla NAT veremos que aparecen dos opciones, que son dstnat y srcnat, y podemos apreciar que la acción se realiza después de que se haga el marcado de conexiones y Mangle.

Conclusión

La funcionalidad del cortafuegos de RouterOS es una de las características en las que merece la pena detenerse a comprender.

Configurando correctamente la tabla RAW, mejoramos la eficiencia del procesado de las reglas ya que la toma de decisiones, hará un recorrido más sencillo por el packet flow.

Con este recorrido más sencillo, optimizamos la carga de trabajo que le estamos forzando a la CPU. Como final de este artículo y un detalle en el que siempre hacemos hincapié (aunque sea obvio). RouterOS posee un cortafuegos que, configurado eficientemente nos va a ayudar en varios escenarios, pero ¡RouterOS es un router! Su funcionalidad principal es la de enrutar, no la de cortafuegos. Los diferentes fabricantes de firewalls existentes, diseñan los cortafuegos con electrónica específica destinada únicamente a la inspección profunda de los paquetes y a la toma de decisiones con respecto a ellos. Cada dispositivo tiene su función concreta por lo que es necesario planear la situación y configuración en la red de cada uno de ellos de manera que se dediquen óptimamente a su trabajo específico.

En el Máster en Arquitectura de Redes de Operadores de Telecomunicaciones y en las certificaciones oficiales de MikroTik impartidas en loopback0 (tanto MTCTCE como MTCSE), explicamos en profundidad las características de cortafuegos y sus “mejores prácticas”.

/by Victor Bolaños Guerra