El entorno de los ISP’s locales ha vivido en los últimos años un proceso de M&A frenético. El cierre de adquisiciones se produjo a lo largo del año 2019 y 2020. Existen dos tipologías de compradores claramente diferenciadas, unos basados en el modelo de red neutra y otros basados en la agregación de clientes. Ambos modelos, una vez superada la fase de compra, se enfrentan a un reto importante que es la consolidación de las adquisiciones. Del resultado de esta consolidación depende la fidelidad del cliente y una continuidad de negocio eficiente. Podemos incluir en este roadmap de consolidación varios subsistemas importantes. Analizaré algunos de estos sistemas en el artículo.

En primer lugar, los sistemas que habitualmente encontramos en estas redes son equipos de red muy heterogéneos y en muchos casos anticuados. En este sentido he detectado en muchas situaciones una falta de capacidad para entender que el sistema resultado de las adquisiciones no es la agregación de muchos pequeños sistemas incoherentes. Aquí se impone la protección de la inversión con sistemas que prioricen la agilidad de las operaciones y el soporte de negocio. Diferentes fabricantes hardware como #Huawei, #Nokia proporcionan soluciones de acceso, agregación y BNG que permiten la automatización de procesos críticos. Estos procesos automatizados se encuentran en muchos casos lejos de los perfiles técnicos de los ingenieros de las redes adquiridas.

Los perfiles de netdevop son los más adecuados para cubrir estos puestos.

Estos perfiles de netdevop cuentan con conocimientos de redes, python, yang y netconf. Se puede optar por dar formación a los ingenieros in-house o por hacer outsourcing de estos perfiles. En este tipo de perfil multidisciplinar entran en juego conocimientos de buenas prácticas, técnicas como HA, conocimientos de peering, IXP y protocolos como BGP y EVPN. Los fabricantes proveen de una amplia documentación en este sentido. Otra figura que hecho en falta es la existencia de arquitectura bien definida y probada. Aquí las buenas prácticas de diseño protegen la inversión y la continuidad del negocio.

Los perfiles anteriores son fundamentales en los procesos de migración y agregación. Hay que tener en cuenta que los procesos de migración y agregación penalizan el fallo. El porcentaje de fallo  en este tipo de actuaciones puede llegar al 25%. Esto afecta no solo a la pérdida de clientes sino también a gastos operativos por visitas masivas a los clientes. A la hora de realizar estas migraciones masivas, es tan importante los procesos automáticos de migración como los procesos automáticos de comprobación y marcha atrás.

Ciertos subsistemas son especialmente críticos, por ejemplo ACS para el correcto aprovisionamiento de los CPE de clientes. Este subsistema es en sí crítico pero es aún más crítico su correcta integración con otros sistemas de la empresa. En particular con los flujos de gestión de las órdenes y con los procesos de facturación. Otro punto habitual de maltrato a la inversión son los CRM o ERP, nos encontramos que o bien no existen CRM escalables o que los que se utilizan no están bien parametrizados. Sin un CRM eficiente la lealtad del cliente va a sufrir y por tanto la inversión se verá dañada. Aquí se impone el uso de un ERP que permite generar de forma prácticamente automática informes financieros. No solo los clásicos cuenta de pérdidas y ganancias, flujos de caja y balance, también los indicadores financieros comunes y las métricas propias del operador.

Por último y mirando un poco a futuro para mejorar el ROI y posibilitar sinergias con nuevos negocios que aparecerán en breve, son necesarias técnicas como el network slicing. Este término está en la boca de algún ejecutivo (no muchos), pero al ingeniero con experiencia le parece más bien un vocablo vende humo. Como es habitual en el término medio está el equilibrio, ¿para qué se puede utilizar el network slicing? pues para la creación de servicios de una forma dinámica. Sin una visión de negocio unida a un plan de marketing y ventas consensuado, no deja de ser una técnica más. Esta reflexión es el fruto de nuestra experiencia estos años con las dinámicas aquí mencionadas. Este tipo de modelos de negocio irán surgiendo a medida que el 5G se vaya imponiendo. Como conclusión una correcta planificación del proceso de consolidación de redes puede proteger la inversión actual y facilitar nuevos modelos de negocio en un futuro próximo.

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.

tr069-scheme

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.

bss-oss-jigsaw

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/

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.

BSS OSS Network

 

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.

 

 

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 Preferred-Value

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.

lo0-distancia-administrativa-cheatsheet

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.

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

BGP-Anunciar_una_ruta_externa

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.

R1

<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

R2

<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

[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

[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

[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

[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:

huawei-ebgp-display-bgp-peer

 

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

huawei-bgp-display-bgp-routing-table

 

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

huawei-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.

pcap-huawei-ebgp-lo0

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.

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.

 

wireguard-changelog

 

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

simple-network

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. Asignar direcciones IP

R1

[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

R2

[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

R1

[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.

R2

[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.

R1

[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

R1

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

R2

[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.

winbox-wireguard-bwtest

 

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 (MTCNAMTCRE), explicamos en profundidad los diferentes tipos de túneles y VPN, así como sus pros y contras.

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.

huawei-ospf-tres-areas-ejemplo

 

■ 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

 

huawei-ospf-2-areas-topo

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

R1

<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

R2

<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

R3

<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

R4

<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

[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

→ 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

R3

→ 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

[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:

huawei-r1-display-ip-routing-table

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

huawei-r1-display-ospf-lsdb

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

huawei-r2-display-ospf-lsdb

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

huawei-r3-display-ospf-lsdb

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

huawei-r4-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.

wireshark-huawei-ospf-dos-areas

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.

 

 

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?

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.

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

huawei-ospf-area0

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

R1

<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

R2

<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

[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

[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.

wireshark-huawei-ospf-area-unica

 

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.

 

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 IPFirewall donde se abrirá una pestaña y elegiremos la opción Raw y ahí podremos crear tablas Raw haciendo click en el mas.

mikrotik-ip-firewall-raw

 

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.

mikrotik-ip-firewall-raw-vs-filter

 

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.mikrotik-raw-chain

 

mikrotik-prerouting-output

  • 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.

mikrotik-nat-chain

 

mikrotik-prerouting-postrouting

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».

 

BGP – iBGP con Huawei

¿Por qué usar BGP?

A medida que nuestros alumnos asistentes al Máster en Arquitectura de Redes de Operadores de Telecomunicaciones aprenden protocolos de enrutamiento dinámicos, nos suelen hacer esta pregunta. ¿Por qué usar BGP?
Y la respuesta es: «because BGP means Big Guys Protocol»

BGP (Border Gateway Protocol) es el protocolo por el cual funciona internet. Este único motivo debería bastar para que desees profundizar acerca de su funcionamiento. Sin embargo, existen varios argumentos que sustentan el uso de BGP como protocolo de ruteo dinámico.

Destaca que es un protocolo simple de implementar y operar y que utiliza una métrica sencilla para las distancias. Además, por definición, oculta las políticas locales de las externas. También cabe destacar que es un protocolo maduro y que no necesita de gran coordinación entre organizaciones para compartir rutas.

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

Breve descripción de BGP

RFC 1654 definió el Border Gateway Protocol (BGP) como un protocolo de enrutamiento que proporciona escalabilidad, flexibilidad y estabilidad de la red. Cuando se creó BGP, la principal consideración de diseño fue la conectividad entre organizaciones en redes públicas, como Internet, o en redes privadas dedicadas. BGP es el único protocolo que se utiliza para intercambiar información de las redes en Internet. BGP no anuncia actualizaciones incrementales ni actualiza los anuncios de redes como sí hace OSPF o IS-IS. BGP prefiere la estabilidad dentro de la red, porque un link flap (cambio brusco del enlace) podría dar lugar a recalcular miles de rutas.

BGP considera un sistema autónomo (AS) como un conjunto de routers controlados por una sola organización. Este AS puede tener dispositivos comunicando rutas dentro de él mismo (lo que se denomina IGP) y con otros AS (denominado como EGP). Si además, este intercambio de rutas se produce mediante el protocolo BGP, este procedimiento se conoce como iBGP o eBGP (internal BGP o external BGP).

Si habéis leído el RFC al comienzo de este artículo, y como destacamos anteriormente, estamos hablando de un protocolo maduro, lo que ha permitido que sea ampliamente conocido, implantado, discutido, optimizado, etc. Para profundizar en el funcionamiento de este protocolo, tenemos los siguientes documentos:

■ RFC 4271, A Border Gateway Protocol 4 (BGP-4)
■ RFC 4456, BGP Route Reflection – An Alternative to Full Mesh Internal BGP (iBGP)
■ RFC 4278, Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification
■ RFC 4277, Experience with the BGP-4 Protocol
■ RFC 4276, BGP-4 Implementation Report
■ RFC 4275, BGP-4 MIB Implementation Survey
■ RFC 4274, BGP-4 Protocol Analysis
■ RFC 4273, Definitions of Managed Objects for BGP-4
■ RFC 4272, BGP Security Vulnerabilities Analysis
■ RFC 3392, Capabilities Advertisement with BGP-4
■ RFC 5065, Autonomous System Confederations for BGP
■ RFC 2918, Route Refresh Capability for BGP-4
■ RFC 1772, Application of the Border Gateway Protocol in the Internet Protocol (BGP-4) using SMIv2
■ RFC 4893, BGP Support for Four-octet AS Number Space

Sí. Es un protocolo «simple», ¿verdad?.

No es tan complicado de implementar como veremos a continuación.

Descripción del Laboratorio

Cuando un BGP se ejecuta entre dos peers (vecinos) con el mismo AS, se considera un iBGP (Internal BGP).

Para ello, en esta práctica, se han configurado un iBGP entre routers con el mismo AS con el fin de mostrar como es el funcionamiento y la configuración de un iBGP.

Objetivos de la práctica

  • Conocer el funcionamiento de iBGP.
  • Montar un iBGP 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 10.200.1.1 30 
[R1-GigabitEthernet0/0/0]quit
[R1]interface GigabitEthernet 0/0/1
[R1-GigabitEthernet0/0/1]ip address 192.168.100.1 24
[R1-GigabitEthernet0/0/1]quit
[R1]interface loopback 0
[R1-LoopBack0]ip address 10.0.1.1 32
[R1-LoopBack0]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
[R2]interface GigabitEthernet 0/0/1
[R2-GigabitEthernet0/0/1]ip address 172.16.100.2 24
[R2-GigabitEthernet0/0/1]quit
[R2]interface LoopBack 0
[R2-LoopBack0]ip address 10.0.2.2 32
[R2-LoopBack0]quit
#
<Huawei>system-view
[Huawei]sysname R3
[R3]interface GigabitEthernet 0/0/1
[R3-GigabitEthernet0/0/1]ip address 192.168.100.3 24
[R3-GigabitEthernet0/0/1]quit
[R3]interface LoopBack 0
[R3-LoopBack0]ip address 10.0.3.3 32
[R3-LoopBack0]quit
#
<Huawei>system-view
[Huawei]sysname R4
[R4]interface GigabitEthernet 0/0/1
[R4-GigabitEthernet0/0/1]ip address 172.16.100.4 24
[R4-GigabitEthernet0/0/1]quit
[R4]interface LoopBack 0
[R4-LoopBack0]ip address 10.0.4.4 32
[R4-LoopBack0]quit
#
[R1]bgp 64501
[R1-bgp]router-id 10.0.1.1
[R1-bgp]peer 192.168.100.3 as-number 64501
[R1-bgp]network 10.0.1.1 32
[R1-bgp]quit
#
[R3]bgp 64501
[R3-bgp]router-id 10.0.3.3
[R3-bgp]peer 192.168.100.1 as-number 64501
[R3-bgp]network 10.0.3.3 32
[R3-bgp]quit
#
[R2]bgp 64502
[R2-bgp]router-id 10.0.2.2
[R2-bgp]peer 172.16.100.4 as-number 64502
[R2-bgp]network 10.0.2.2 32
[R2-bgp]quit
#
[R4]bgp 64502
[R4-bgp]router-id 10.0.4.4
[R4-bgp]peer 172.16.100.2 as-number 64502
[R4-bgp]network 10.0.4.4 32
[R4-bgp]quit

Configuración paso a paso

1. Asignar direcciones IP

 

R1

<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
[R1]interface GigabitEthernet 0/0/1
[R1-GigabitEthernet0/0/1]ip address 192.168.100.1 24
[R1-GigabitEthernet0/0/1]quit
[R1]interface loopback 0
[R1-LoopBack0]ip address 10.0.1.1 32
[R1-LoopBack0]quit

R2

<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
[R2]interface GigabitEthernet 0/0/1
[R2-GigabitEthernet0/0/1]ip address 172.16.100.2 24
[R2-GigabitEthernet0/0/1]quit
[R2]interface LoopBack 0
[R2-LoopBack0]ip address 10.0.2.2 32
[R2-LoopBack0]quit

R3

<Huawei>system-view
[Huawei]sysname R3
[R3]interface GigabitEthernet 0/0/1
[R3-GigabitEthernet0/0/1]ip address 192.168.100.3 24
[R3-GigabitEthernet0/0/1]quit
[R3]interface LoopBack 0
[R3-LoopBack0]ip address 10.0.3.3 32
[R3-LoopBack0]quit

R4

<Huawei>system-view
[Huawei]sysname R4
[R4]interface GigabitEthernet 0/0/1
[R4-GigabitEthernet0/0/1]ip address 172.16.100.4 24
[R4-GigabitEthernet0/0/1]quit
[R4]interface LoopBack 0
[R4-LoopBack0]ip address 10.0.4.4 32
[R4-LoopBack0]quit

2. Montar un iBGP entre el R1 y R3

 

R1

[R1]bgp 64501 (1)
[R1-bgp]router-id 10.0.1.1 (2)
[R1-bgp]peer 192.168.100.3 as-number 64501 (3)
[R1-bgp]network 10.0.1.1 32 (4)
[R1-bgp]quit
1 Activación del BGP.
2 Asignamos como router-id el 10.0.1.1.
3 Definimos como peer al 192.168.100.3 cuyo AS es el 64501.
4 Anumciamos la red 10.0.1.1/32.

R3

[R3]bgp 64501 (1)
[R3-bgp]router-id 10.0.3.3 (2)
[R3-bgp]peer 192.168.100.1 as-number 64501 (3)
[R3-bgp]network 10.0.3.3 32 (4)
[R3-bgp]quit
1 Activación del BGP.
2 Asignamos como router-id el 10.0.3.3.
3 Definimos como peer al 192.168.100.1 cuyo AS es el 64501.
4 Anunciamos la red 10.0.3.3/32.

3. Montar un iBGP entre el R2 y R4

 

R2

[R2]bgp 64502 (1)
[R2-bgp]router-id 10.0.2.2 (2)
[R2-bgp]peer 172.16.100.4 as-number 64502 (3)
[R2-bgp]network 10.0.2.2 32 (4)
[R2-bgp]quit
1 Activación del BGP.
2 Asignamos como router-id el 10.0.2.2.
3 Definimos como peer al 172.16.100.4 cuyo AS es el 64502.
4 Anunciamos la red 10.0.2.2/32.

R4

[R4]bgp 64502 (1)
[R4-bgp]router-id 10.0.4.4 (2)
[R4-bgp]peer 172.16.100.2 as-number 64502 (3)
[R4-bgp]network 10.0.4.4 32 (4)
[R4-bgp]quit
1 Activación del BGP.
2 Asignamos como router-id el 10.0.4.4.
3 Definimos como peer al 172.16.100.2 cuyo AS es el 64502.
4 Anunciamos la red 10.0.4.4/32.

Comprobación

→ Para asegurarnos de que se ha configurado iBGP correctamente, ejecutamos el siguiente comando display ip routing-table:

Esta imagen muestra un display ip routing-table del R3
Figura 1. Esta imagen muestra un display ip routing-table del R3

 

Esta imagen muestra un display ip routing-table del R4

Figura 2. Esta imagen muestra un display ip routing-table del R4

Conclusión

Como has podido comprobar, con muy pocos comandos ya tenemos a nuestros routers Huawei compartiendo rutas dentro del mismo AS mediante el protocolo BGP. Esta sencilla configuración, con muy pocos cambios, nos permitirá también compartir rutas entre distintos AS.

Seguro que ahora eres capaz de implementar y distinguir entre que routers consideramos iBGP y cuales consideramos eBGP.

Huawei iBGP

 

En la captura resultante de esta configuración se puede comprobar el intercambio de mensajes entre los dos routers involucrados en la negociación de este iBGP.