ErazoLuis 2020 AutomatizaciónPythonMPLS
ErazoLuis 2020 AutomatizaciónPythonMPLS
Autor
Luis Felipe Erazo Solarte
Universidad de Antioquia
Facultad de Ingeniería, Departamento de
Ingeniería Electrónica y Telecomunicaciones
Medellín, Colombia
2020
AUTOMATIZACIÓN DE LA CONFIGURACIÓN DE LOS SERVICIOS CARRIER
ETHERNET E IP NEXT GENERATION (CE/IPNG) EN LA TOPOLOGÍA DE RED MPLS
HUAWEI DE INTERNEXA COLOMBIA
Asesores
Universidad de Antioquia
Facultad de Ingeniería, Departamento de Ingeniería
Electrónica y Telecomunicaciones
Medellín, Colombia
2020
Resumen
3
Tabla de Contenido
Resumen ................................................................................................................ 3
Tabla de Contenido ............................................................................................. 4
Índice de Figuras y Tablas .................................................................................... 7
Lista de anexos ...................................................................................................... 9
1. INTRODUCCIÓN ............................................................................................ 10
2. OBJETIVOS ..................................................................................................... 12
3. MARCO TEÓRICO ......................................................................................... 13
3.1. TECNOLOGÍA MPLS ............................................................................... 13
3.2. RED MPLS HUAWEI DE INTERNEXA EN COLOMBIA .............................. 15
3.2.1. SWITCHES DE ENRUTAMIENTO S9300 HUAWEI ................................ 17
3.2.2. SERVICIO CARRIER ETHERNET .......................................................... 18
3.2.3. SERVICIO IPNG ................................................................................. 19
3.3. GESTIÓN DE REDES DE TELECOMUNICACIONES ................................. 20
3.4. HERRAMIENTAS PARA LA GESTIÓN AUTOMATIZADA DE REDES ......... 21
3.4.1. NetConf ............................................................................................ 21
3.4.2. Ansible .............................................................................................. 22
3.4.3. Python............................................................................................... 22
3.5. PROTOCOLO DE CONEXIÓN REMOTA SEGURA - SECURE SHELL (SSH)
22
3.6. DESCRIPCIÓN DE DESARROLLOS DE SOFTWARE ................................ 23
3.6.1. Norma ISO/IEC/IEEE 42010 .............................................................. 23
3.6.2. MODELO DE KRUCHTEN 4 + 1 ......................................................... 26
3.6.2.1. Vista Lógica ............................................................................... 27
3.6.2.2. Vista de Despliegue.................................................................. 27
3.6.2.3. Vista de Procesos ...................................................................... 27
3.6.2.4. Vista Física ................................................................................. 27
3.6.2.5. “+1” Vista de Escenarios .......................................................... 27
4. METODOLOGÍA ............................................................................................. 28
4.1. ESTUDIO DE CONCEPTOS BASES E IDENTIFICACIÓN DE DATOS ........ 28
4
4.1.1. CONFIGURACIÓN MANUAL ........................................................... 29
4.1.2. DATOS NECESARIOS EN CADA SERVICIO ...................................... 31
4.1.2.1. Datos generales ........................................................................ 32
4.1.2.2. Datos del equipo ...................................................................... 32
4.2. SELECCIÓN DE LA HERRAMIENTA DE TRABAJO .................................. 33
4.2.1. CRITERIOS DE SELECCIÓN ............................................................... 34
4.2.2. ANÁLISIS DE LAS HERRAMIENTAS .................................................... 34
4.2.3. RESULTADO DE LA SELECCIÓN ....................................................... 35
4.3. DESARROLLO DEL SOFTWARE............................................................... 36
4.3.1. REQUISITOS PARA LA GESTIÓN DE LOS SERVICIOS ........................ 36
4.3.2. DISEÑO DE LA INTERFAZ GRAFICA DE USUARIO (GUI) .................. 37
4.3.2.1. Librería Tkinter ............................................................................ 39
4.3.2.2. Librería WxPython...................................................................... 39
4.3.2.3. Librería PyQT .............................................................................. 39
4.3.3. CONEXIÓN REMOTA........................................................................ 44
4.3.3.1. Establecimiento de conexión SSH ........................................... 45
4.3.3.2. Mantenimiento de conexión SSH ............................................ 47
4.3.3.2.1. Generación de comandos.................................................. 47
4.3.3.2.2. Envío de comandos ............................................................. 51
4.3.3.2.3. Verificación de envío y recepción de comandos ............ 52
4.3.3.3. Finalización de conexión SSH .................................................. 53
4.3.4. MÓDULOS ADICIONALES ................................................................ 53
4.3.4.1. Librería Threading ..................................................................... 54
4.3.4.2. MySQL ........................................................................................ 55
4.3.5. RESUMEN DEL FUNCIONAMIENTO DEL PROGRAMA ..................... 58
4.4. DESCRIPCIÓN DE LA PLATAFORMA DESARROLLADA ........................ 60
4.4.1. DESCRIPCIÓN DE LA ARQUITECTURA ............................................. 61
4.4.1.1. Vista Lógica ............................................................................... 62
4.4.1.2. Vista de Procesos ...................................................................... 62
4.4.1.3. Vista de Desarrollo .................................................................... 66
4.4.1.4. Vista Física ................................................................................. 68
5
4.4.1.5. Vista de Escenarios ................................................................... 69
5. RESULTADOS Y ANÁLISIS ............................................................................... 70
5.1. PROTOCOLO DE PRUEBAS.................................................................... 70
5.2. TIEMPO DE CONFIGURACIÓN .............................................................. 72
5.2.1. TIEMPO DE ESTABLECIMIENTO SERVICIO CARRIER ETHERNET ....... 72
5.2.2. TIEMPO DE ESTABLECIMIENTO SERVICIO IP NEXT GENERATION ... 76
6. CONCLUSIONES ............................................................................................ 80
REFERENCIAS BIBLIOGRÁFICAS .......................................................................... 81
ANEXOS ................................................................................................................ 84
6
Índice de Figuras y Tablas
7
Figura 39: Vista Física. ......................................................................................... 68
Figura 40: Vista de Escenarios. ........................................................................... 69
Figura 41: Pestaña principal del software de automatización. ..................... 70
8
Lista de anexos
9
1. INTRODUCCIÓN
INTERNEXA es una empresa colombiana, filial del grupo ISA, la cual cuenta
con una experiencia de 20 años en el aprovisionamiento de soluciones
tecnológicas de negocio, confiables, seguras e innovadoras para
operadores de telecomunicaciones, instituciones del gobierno y empresas.
La compañía cuenta con un sistema de redes internacionales, nacionales
y metropolitanas, las cuales dan respaldo a sus servicios y están equipadas
con tecnología de punta que permite conectar a diferentes países de
América Latina (Centroamérica, Colombia, Ecuador, Brasil, Perú, Chile,
Argentina), y a éstos con los Estados Unidos. Esta red cuenta con más de
50.000 kilómetros de fibra óptica, lo que permite difundir la oferta de
servicios en más de 257 puntos de presencia en todo el continente
americano, beneficiando a más de 868 clientes. En Colombia, la red MPLS
(Multiprotocol Label Switching) de Huawei está en funcionamiento desde
el año 2011, cuenta con 7 anillos de transporte conformados por 37 nodos
ubicados en las principales ciudades y brinda una capacidad de
comunicación de 100GB. Carrier Ethernet (CE) e IP Next Generation (IPNG)
son algunos de los servicios ofertados sobre la red MPLS de InterNexa en
Colombia. De manera general se puede decir que un servicio CE es un
canal donde fluye un tráfico de datos entre empresas, servicios de
telefonía y cloud. Por otra parte, IPNG es un servicio que provee un canal
con tráfico de internet que cuenta con acceso a contenidos locales, CDN
(Content Distribution Network), que son contenidos almacenados
temporalmente dentro de la red de Internexa.
10
fabricante de los dispositivos de red. Este esquema de operación hace que
la configuración de un servicio pueda tardar aproximadamente 45 minutos
en promedio, sin tener en cuenta los errores que se pueden producir al
ingresar de manera errónea un parámetro dentro de un comando
ejecutado.
11
2. OBJETIVOS
OBJETIVO GENERAL
Implementar una plataforma de gestión que permita la automatización del
proceso de configuración de servicios CE/IPNG en la red MPLS Huawei
Colombia de InterNexa, haciendo uso del protocolo SSH (Secure Shell) y
herramientas de gestión automatizada de redes.
OBJETIVOS ESPECÍFICOS
12
3. MARCO TEÓRICO
13
• Valor de Etiqueta: Campo de 20 bits utilizado para la
identificación de la etiqueta.
• Experimental: Campo de 3 bits para uso experimental. Aparece
como calidad de servicio en otros textos, y afecta al encolado y
descarte de paquetes.
• Final de la pila: Campo de un bit que sirve para el apilado
jerárquico de las etiquetas. Cuando vale 0 indica que hay más
etiquetas añadidas al paquete. Cuando vale 1 estamos en el
fondo de la jerarquía.
• Tiempo de vida (TTL- Time To Live): Campo de 8 bits que se
decrementa en cada enrutador y al llegar a cero, el paquete es
descartado.
Las rutas, que se denominan rutas conmutadas por etiquetas (LSPs – Label
Switched Paths), permiten a los proveedores de servicios decidir con
anticipación la mejor manera para que ciertos tipos de tráfico fluyan
dentro de una red pública o privada [1].
En una red MPLS, cada paquete se etiqueta al entrar en la red del
proveedor de servicios por el enrutador de entrada, también conocido
como enrutador de borde de etiqueta (LER - Label Edge Router). Este
enrutador también decide el LSP que tomará el paquete para alcanzar su
dirección de destino [1].
Todos los enrutadores de conmutación de etiquetas (LSRs – Label Switching
Routers) posteriores realizan el reenvío de paquetes basado únicamente
en esas etiquetas MPLS, (Ver Figura 2).
14
Figura 2: Red MPLS básica.
Tomado de [1].
15
Internacional de Transporte Aéreo), de acuerdo a la ciudad donde el
nodo MPLS esté ubicado [4].
La disposición en anillo (Ver Figura 4) proporciona redundancia y
tolerancia a fallos, ya que, ante la caída de uno de los nodos principales,
el flujo de datos tendría continuidad a través del otro lado del anillo. Esta
característica también provee ventajas en la escalabilidad. Por ejemplo, si
se necesitara agregar un nuevo equipo al Core del anillo MPLS, no existiría
caída de servicio para los clientes actuales debido a que habría flujo de
datos a través de los otros equipos de la red que conforman la disposición
en anillo [3].
16
Los nodos que integran la red MPLS de Internexa hacen referencia a
switches de enrutamiento S9300 de Huawei [4].
17
3.2.2. SERVICIO CARRIER ETHERNET
Carrier Ethernet (CE) es el despliegue de tecnología y servicios que
aprovecha todas las ventajas de Ethernet mediante el desarrollo de un
marco flexible, con formato universal de tramas y diseño sencillo.
Además, CE provee capacidades de Operaciones, Administración y
Mantenimiento (OAM) mejoradas para las redes de alto rendimiento,
que son ideales para empresas, instituciones académicas, compañías
operadoras y las redes de área local del gobierno. Al igual que ocurrió
con Ethernet, la mayor adopción de Carrier Ethernet está cambiando la
forma de crear redes [6].
En este servicio se pueden establecer conexiones punto a punto y
conexiones punto a multipunto (entre un mismo cliente o entre clientes
diferentes), trabajando solamente hasta la capa 2 (Switching) del
modelo OSI (Open System Interconnection – Modelo de Interconexión
de Sistemas Abiertos). EL tráfico existente a través de estos canales
puede ser por ejemplo servicios de voz, telefonía, datos entre empresas
y cloud. A diferencia del servicio IPNG, el servicio CE no cuenta con
salida a internet (Ver Figura 6) [4].
18
3.2.3. SERVICIO IPNG
Una Red de Siguiente Generación es una red basada en la transmisión
de paquetes capaz de proveer servicios integrados, incluyendo los
tradicionales como acceso a Internet, llamadas de voz, mensajería, etc.
Es capaz de explotar al máximo el ancho de banda del canal haciendo
uso de las Tecnologías de Calidad del Servicio (QoS) de modo que el
transporte sea totalmente independiente de la infraestructura de red
utilizada. Además, ofrece acceso libre para usuarios de diferentes
compañías y apoya la movilidad que permite acceso multipunto a los
usuarios [7].
IPNG “next generation”, es un servicio que provee un canal con tráfico
de internet (Ver Figura 6) que cuenta con acceso a contenidos locales
y CDN (Content Distribution Network), que son contenidos almacenados
dentro de la red de Internexa. Se pueden establecer conexiones punto
a punto y conexiones punto a multipunto donde se trabaja entre las
capas dos y tres del modelo OSI. Se puede decir que el servicio CE está
implícito en los servicios IPNG [4].
19
3.3. GESTIÓN DE REDES DE TELECOMUNICACIONES
En la actualidad las redes de telecomunicación se caracterizan por un
constante incremento del número, complejidad y heterogeneidad de los
recursos que los componen.
Los principales problemas relacionados con la expansión de las redes son
la gestión de su correcto funcionamiento día a día y la planificación
estratégica de su crecimiento. De hecho, se estima que más del 70% del
coste de una red corporativa se atribuye a su gestión y operación [8].
De esta manera se define la gestión como un conjunto de capacidades
que permiten el intercambio y procesamiento de información. Su propósito
es ayudar a cualquier organización que opera o utiliza una red de
comunicaciones, a realizar sus actividades de planificación, instalación,
operación y administración con eficacia [8], [9].
Los tres recursos principales con los que cuenta un centro de gestión de
red son los siguientes [8]:
20
• Los agentes, por otra parte, son los componentes del sistema de
gestión invocados por el gestor o gestores de la red.
3.4.1. NetConf
NetConf (Network Configuration – Configuración de red) es un
protocolo de configuración de red que proporciona mecanismos para
instalar, manipular y eliminar la configuración de dispositivos de red. Este
protocolo utiliza archivos XML (eXtensible Markup Language) como
método de configuración y codificación de datos, y RPC (Remote
Procedure Call) como mecanismo para la operación y el control entre
21
un administrador y un dispositivo de la red. Se utilizan sesiones para
realizar el intercambio de datos de configuraciones de los dispositivos
de red. Una sesión Netconf, es la conexión lógica entre un administrador
de red o una aplicación de configuración de red y un dispositivo de red
[10].
3.4.2. Ansible
Ansible es una herramienta de software que sirve para configurar y
administrar sistemas. Permite desplegar configuraciones de servidores y
servicios por lotes y administrar configuraciones. Además de esto,
Ansible es categorizado como una herramienta de orquestación. Esta
herramienta gestiona nodos a través del protocolo SSH (Secure Shell) y
no requiere ningún software remoto adicional (excepto Python 2.4 o
posterior para instalarlo). Dispone de módulos que trabajan sobre JSON
(JavaScript Object Notation) y la salida estándar puede ser escrita en
cualquier lenguaje. Originalmente utiliza el formato YAML (Yet Another
Markup Language) para describir configuraciones reusables de los
sistemas [11].
3.4.3. Python
Por otro lado, Python es un lenguaje de programación que está
desarrollado bajo una licencia de código abierto, permitiendo trabajar
más rápidamente e integrar sus sistemas de manera más efectiva.
Python cuenta con una amplia gama de librerías que permite realizar
programas para automatizar procesos de configuración de dispositivos
de red. Entre estos se destaca paramiko (modulo para implementar
SSH) [12], [13].
22
SSH está diseñado para reemplazar los métodos más viejos y menos
seguros para registrarse remotamente en otro sistema a través de la shell
de comando, tales como telnet o rsh (remote shell), ya que estas
aplicaciones antiguas no cifran la información que viaja por la conexión.
El uso de métodos seguros para registrarse remotamente a otros sistemas
reduce los riesgos de seguridad tanto para el sistema cliente como para el
sistema remoto. [14]
23
desarrollo planteado por alguien más, tal como se explica a
continuación:
24
A continuación, en la Figura 10, se presenta un extracto de los
principales elementos que integra la norma ISO/IEC/IEEE 42010.
25
3.6.2. MODELO DE KRUCHTEN 4 + 1
El modelo de Kruchten 4+1, es un modelo de vistas diseñado por el
profesor Philippe Kruchten y que se acopla con el estándar “ISO/IEC/IEEE
42010” que se utiliza para describir la arquitectura de un sistema
software haciendo uso de múltiples puntos de vista [21].
Cada una de estas vistas describe toda arquitectura del software que
se esté documentando, pero cada una de ellas se documenta de
forma diferente y muestra aspectos diferentes del sistema. A
continuación, se explica que información debe contener la
documentación de cada una de estas vistas [21].
26
3.6.2.1. Vista Lógica
Esta vista representa la distribución del sistema y lo que éste debe
hacer. Aquí se presentan las funciones y/o clases implementadas en
el desarrollo de software.
Para completar la documentación de esta vista se pueden incluir los
diagramas de clases, de comunicación o de secuencia de UML
(Unified Modeling Language - Lenguaje Unificado de Modelado) [21].
27
4. METODOLOGÍA
28
Posteriormente se estudió la forma de configuración manual de los servicios
CE e IPNG, identificando el protocolo necesario para establecer una
comunicación entre el ingeniero y el equipo a configurar, los comandos de
configuración, así como los parámetros de cada servicio.
29
Figura 12: Comunicación con el equipo de la red MPLS desde la CLI de usuario.
Elaboración propia.
30
4.1.2. DATOS NECESARIOS EN CADA SERVICIO
A la hora de estructurar un servicio hay una serie de datos
fundamentales que el ingeniero requiere para iniciar la configuración
de los equipos. Cada uno de esos datos va a causar que el servicio
tenga variaciones en su proceso de configuración. Cuando un cliente
solicita un servicio, esta solicitud primero pasa a través de los ingenieros
comerciales, quienes se encargan de organizar los requerimientos y los
datos a procesar. Con esta información, el ingeniero de configuración
ya tiene los datos necesaria para proceder a estructurar el servicio en
cuestión.
31
Inicialmente se debe tener claro si se va a configurar un servicio CE o un
servicio IPNG. Ya que, si el servicio es CE, el ingeniero solamente va a
trabajar con los dispositivos de red de Huawei en la capa dos del
modelo OSI. Y si el servicio es IPNG, además de trabajar con los
dispositivos de red de Huawei en la capa dos del modelo OSI, también
tendrá que trabajar con los dispositivos de red de Nokia en la capa tres
del modelo OSI.
Si en la configuración solamente actúan dos equipos, se tiene un
servicio punto a punto VLL (Virtual Leased Lines), pero si se va a
configurar más de dos equipos se tiene un servicio punto a multipunto
VSI (Virtual Switch Instance).
32
hace referencia a un puerto por donde va a pasar únicamente una
sola VLAN. La configuración QinQ hace referencia a un puerto por
donde van a pasar demasiadas VLAN, muchas más que en la
configuración en Troncal. Y finalmente, la configuración Hibrido hace
referencia a la utilización de configuraciones en Acceso, Troncales y
QinQ de manera conjunta.
InterNexa tiene a la disposición de sus clientes 5 tipos de interfaces
de enlaces físicos, la utilización de cada una de estas viene definida
por el ancho de banda del servicio. Se utilizará la interfaz Ethernet
para aquellos servicios que cuenten con un ancho de banda en un
rango que va desde 2 Mbps hasta 10 Mbps. La interfaz GigaEthernet
se utilizará para aquellos servicios que cuenten con un ancho de
banda en un rango que va desde 10 Mbps hasta 900 Mbps. La
interfaz XGigaEthernet se utilizará para aquellos servicios que cuenten
con un ancho de banda en un rango que va desde 1 Gbps hasta 9
Gbps. La interfaz 100GigaEthernet se utilizará para aquellos servicios
que cuenten con un ancho de banda de 100 Gbps. Por otra parte, la
interfaz Eth-Trunk es un enlace lógico constituido a partir de los
enlaces físicos vistos anteriormente. El ancho de banda que pasa a
través de este enlace será la sumatoria del ancho de banda
existente en los enlaces físicos asociados al servicio.
Finalmente, a un puerto se le pueden asociar dos estados. Nuevo,
este estado implica que cuando se vaya a entregar un servicio en
dicho puerto se requiere la ejecución de comandos adicionales para
su creación y configuración. Existente, estado que no requiere la
ejecución de órdenes para la creación de un puerto.
33
Después de consultar y estudiar las diferentes opciones, en una primera
instancia se eligieron tres posibles herramientas: NetConf, Ansible y Python.
Y posteriormente para la selección final de la herramienta empleada en
este proyecto se tuvo en cuenta tres criterios.
34
en cada uno de los equipos de la red conlleva un gasto de tiempo y de
costos elevado. Además de esto, la IETF recomienda la utilización de
YANG (Yet Another Next Generation, Otra Nueva Generación) como
lenguaje de modelado de datos para el protocolo de configuración de
red NETCONF, lo cual implicaría comenzar desde cero el aprendizaje de
un nuevo leguaje, demandando tiempo adicional.
Por otro lado, Ansible es una herramienta de software que sirve para
configurar y administrar sistemas. Permite desplegar configuraciones de
servidores, servicios por lotes y administrar configuraciones, siendo
categorizado como una herramienta de orquestación. Es ampliamente
utilizada en el mundo de las redes de telecomunicaciones, pero a la
hora de trabajar con dispositivos de red de la marca Huawei requiere la
instalación de módulos adicionales, entre ellos el módulo CloudEngine.
Cabe resaltar que para trabajar con esta herramienta se debía
comenzar desde cero, debido a que en InterNexa ningún ingeniero
había trabajado con ella y de igual forma el estudiante en práctica
tampoco había tenido conocimiento de esta plataforma.
35
adicional en cada equipo de la red MPLS Huawei de InterNexa.
Además, el estudiante en práctica contaba con buenas bases en el
lenguaje de programación de Python lo cual fue de suma importancia
a la hora de la selección, debido a que se ahorró tiempo de
aprendizaje de un nuevo lenguaje en el desarrollo del proyecto.
Cabe resaltar que a pesar de no ser seleccionadas como herramientas
de trabajo NetConf y Ansible servirán como referencia en el desarrollo
de este proyecto.
36
• El desarrollo de software debía tener una interfaz gráfica de
usuario (GUI) donde el ingeniero pudiera ingresar y leer los datos
de forma cómoda.
37
controlará el proceso de automatización (CONTROLES). Tal como se
muestra en la Figura 14.
• Tkinter
• WxPython
38
• PyQT
39
Para desarrollar una GUI haciendo uso de esta librería se debe crear
inicialmente una ventana que va a ser la raíz del proyecto. Dentro de
esa ventana se podrán insertar más elementos (widgets), tales como:
• Botones
• Campos de entrada
• Campos de salida
• Botones de control
• Caja de listas
• Frames
• Menú de opciones
• Botones de menú
• Ventanas emergentes
• Botón de radio
• Barra de desplazamiento
• Spinbox
40
guardaran los siguientes datos: Fecha y hora, usuario, tiempo de
ejecución y una breve descripción de la configuración (Ver Figura
18).
Cabe resaltar que la ventana “Principal” (Figura 15) cuenta con una
serie de ventanas emergentes, que podrán ser informativas o de
decisión. Las informativas solamente muestran algunos datos y esperan
a que el usuario las cierre (Ver Figura 20 a). Por otro lado, las ventanas
de decisión se dividen en dos. Están las ventanas de decisión que
únicamente le permiten al usuario aceptar o denegar una acción (Ver
Figura 20 b). Y están las ventanas de decisión que solicitan que el
usuario ingrese algún valor para así continuar o abortar una acción (Ver
Figura 20 c).
41
Figura 16: Pestaña de Configuración de la GUI Final.
42
Figura 18: Pestaña de Historial de Ejeción de la GUI final.
43
Figura 20: Ventanas emergentes.
(a)Ventana informativa. (b) Ventana de decisión. (c) Ventana de decisión con
entradas.
44
hora de trabajar con redes de telecomunicaciones, debido a que
permite establecer conexiones SSH. Este módulo permite enviar y recibir
información desde un host remoto, proporcionando funcionalidad de
cliente y servidor, donde el cliente va a tener total control del servidor al
que acceda.
Si se hace buen uso de esta herramienta y se potencializa su
capacidad mediante Python, es posible el desarrollo de un software de
gestión que permita la automatización de tareas en una red de
telecomunicaciones. Cabe resaltar que para hacer uso de esta librería
se debe instalar dentro del entorno de Python, ya que ésta no viene
incluida por defecto [17].
45
describe la forma en que Paramiko pone en marcha la
comunicación entre un cliente y un servidor:
46
4.3.3.2. Mantenimiento de conexión SSH
En esta etapa se procederá a generar y enviar los comandos
generados desde el software hasta el host remoto. Cada comando
ejecutado será sometido a verificaciones, de tal manera que se
tenga certeza de que el comando fue enviado y recibido con éxito
en el equipo que está siendo configurado. También, se procederá a
verificar la salida o resultado obtenido después de la ejecución de
cada comando, de tal manera que se garantice que se recibirán
todos los datos correspondientes.
• Troncal:
- vlan num_vlan
- description cliente [id_servicio] origen_ destino_tipo_servicio
47
- interface vlan num_vlan
- description cliente – origen destino tipo_servicio [id_servicio]
- interface interfaz puerto
- port trunk allow-pass vlan num_vlan
• Acceso:
- display current interface interfaz puerto
- display interface interfaz puerto
- interface interfaz puerto
- clear configuration this
- undo portswitch
- description cliente – origen destino bw tipo_servicio
[id_servicio]
• QinQ:
- interface interfaz puerto
- description cliente – origen destino bw tipo_servicio
[id_servicio]
- set flow-stat interval 10
- port link-type dot1q-tunnel
- port default vlan num_vlan
- stp disable
• Hibrido:
- interface interfaz puerto
- description cliente – origen destino bw tipo_servicio
[id_servicio]
- port link-type hybrid
- set flow-stat interval 10
- port hybrid tagged vlan num_vlan
- stp disable
- broadcast-suppression 20"
Una vez que todos los equipos involucrados en un servicio han sido
configurados se procede a realizar una prueba de establecimiento
para la cual se hace uso de los siguientes comandos:
• Puerto nuevo:
- loopback internal
- undo shutdown
- dis this interface
48
- dis mpls l2vc id_servicio
- undo loopback
- shutdown
- quit
- save
• Puerto existente:
- dis mpls l2vc id_servicio
- quit
- save
• Equipo CTG:
- <S93CTGITX> system-view
- [S93CTGITX] display tunnel-policy
49
- [S93CTGITX] mpls l2vc 192.168.201.4 8888 mtu 9000 tunnel-
policy ctg-nva raw
- [S93CTGITX] vlan 3333
- [S93CTGITX] description Cliente [8888] ctg_ nva_CE
- [S93CTGITX] interface vlan 3333
- [S93CTGITX] description Cliente – ctg nva CE [8888]
- [S93CTGITX] interface ethernet 2/0/32
- [S93CTGITX] port trunk allow-pass vlan 3333
• Equipo NVA:
- <S93NVAITX> system-view
- [S93NVAITX] display tunnel-policy
- [S93NVAITX]mpls l2vc 192.168.201.6 8888 mtu 9000 tunnel-
policy nva-ctg
- [S93NVAITX] display current interface eth-trunk 456
- [S93NVAITX] display interface eth-trunk 456
- [S93NVAITX] interface eth-trunk 456
- [S93NVAITX] clear configuration this
- [S93NVAITX] undo portswitch
- [S93NVAITX] description Cliente – nva ctg BW CE [8888]
• Equipo NVA:
- [S93NVAITX] loopback internal
- [S93NVAITX] undo shutdown
- [S93NVAITX] dis this interface
- [S93NVAITX] dis mpls l2vc id_servicio
- [S93NVAITX] undo loopback
- [S93NVAITX] shutdown
- [S93NVAITX] quit
- <S93NVAITX> save
• Equipo CTG:
- [S93CTGITX] undo loopback
- [S93CTGITX] shutdown
50
- [S93CTGITX] quit
- <S93CTGITX> save
51
comando y su respectiva respuesta, los tiempos de ejecución
hubiesen aumentado.
52
comando. Cabe resaltar que esa información no se retorna
instantáneamente, por lo que es necesario aplicar el método
recv_ready(). Este método asociado al canal de comunicación
garantiza que el servidor remoto podrá entregarle al software toda su
información sin que haya perdidas.
53
4.3.4.1. Librería Threading
Con el uso de la librería threading, el software puede emular que se
están ejecutando varias tareas o procesos al mismo tiempo. Cada
hilo (se define hilo como un proceso o subproceso) tiene su propio
flujo de control. Mientras que un hilo podría estar leyendo datos de
un archivo, otro hilo puede mantener actualizada la pantalla. Para
evitar que dos hilos accedan a la misma estructura de datos interna
al mismo tiempo, Python usa un bloqueo global de intérprete. Solo un
hilo puede ejecutar código Python al mismo tiempo; Python cambia
automáticamente al siguiente subproceso después de un corto
período de tiempo, o cuando un subproceso hace algo que puede
llevar un tiempo (como esperar que llegue el siguiente byte a través
de un socket de red o leer datos de un archivo) [18].
En el software de automatización fue muy útil esta librería debido a
que mientras un hilo se encargaba de mantener actualizada la GUI,
otro hilo se encargaba de la ejecución de las tareas dentro del flujo
del programa.
54
En la Figura 28 se puede observar la distribución tanto del hilo
principal como del hilo secundario dentro del flujo del programa.
4.3.4.2. MySQL
El estándar MySQL constituye la base de datos (BD) de software libre
más popular del mercado. Es un sistema de gestión de base de
datos que ofrece los mecanismos para añadir, acceder y procesar
información almacenada en una base de datos.
MySQL es un software libre, lo cual significa que cualquiera puede
hacer uso del código fuente que lo constituye para usarlo libremente
o incluso modificarlo sin restricciones. Esta herramienta ofrece un
modelo de cliente/servidor consistente en un servidor SQL multihilo
que es capaz de soportar diferentes clientes, librerías, herramientas
administrativas y APIs (Application Programming Interface - Interfaz
de programación de aplicaciones) [19].
El software de automatización hizo uso de una base de datos en
MySQL, donde se registró la información asociada a cada equipo de
la red MPLS Huawei y Alcatel de InterNexa en Colombia.
55
La base de datos va a estar alojada en el sistema de
almacenamiento en la nube de InterNexa y dentro de la base de
datos van a existir cinco tablas inicialmente:
56
Figura 30: Tabla de equipos Alcatel en la BD.
57
Con el fin de proteger información sensible se censuraron los campos
correspondientes a la IP de gestión y la IP loopback de cada equipo.
Cabe resaltar que cada tabla es independiente, y realizar
modificaciones en una de ellas no tendrá repercusiones en la otra.
58
comandos necesarios para configurar el equipo, dependiendo
de los requerimientos solicitados por el cliente.
59
4.4. DESCRIPCIÓN DE LA PLATAFORMA DESARROLLADA
Realizar la descripción del desarrollo de un software suele ser complicado,
sobre todo si se trata de explicar las líneas del código elaborado. Para
esto, organizaciones como ISO (International Organization for
Standardization), IEC (International Electrotechnical Commission) y la IEEE
(Insitute of Electrical and Electronics Engineers) han establecido un
estándar para la descripción de la arquitectura de sistemas y productos
software.
Para realizar una descripción completa, detallada y legible del software
desarrollado se hizo uso de la norma ISO/IEC/IEEE 42010 (Ver Figura 34).
60
Para el caso de este proyecto:
• Este sistema cuenta con varios Interesados, como por ejemplo los
ingenieros del NOC, los directivos de la compañía y el estudiante en
práctica que desarrolló este software de automatización.
61
4.4.1.1. Vista Lógica
Esta vista fue representada por un diagrama global de
funcionamiento. En este diagrama (Ver Figura 35), se observa que el
software de automatización desarrollado está en la capacidad de
realizar conexiones SSH con equipos como Switches de enrutamiento
S9300 de Huawei y Enrutadores A7750 de Nokia. Además de esto,
brinda la posibilidad de enviar de manera automática comandos y
recibir sus respectivas respuestas, facilitando realizar configuraciones
en cada equipo.
62
conexión SSH. Es aquí donde se va a alojar la dinámica principal del
software, la generación y envío de comandos de manera
automática y la recepción de su respectiva respuesta por parte del
equipo que está siendo configurado.
63
- Nombre del equipo
- Tipo de puerto (Troncal, Acceso, QinQ o Hibrido)
- Interfaz de enlace (Ethernet, Gigabitethernet,
Xgigabitethernet, 100gigabitethernet o eth-truunk)
- Puerto de entrega
- Estado del puerto de entrega (Nuevo o existente)
64
Figura 36: Vista de Procesos.
Elaboración propia basado en [21].
65
4.4.1.3. Vista de Desarrollo
En esta vista se observa cómo está dividido el sistema software y es
posible detallar los diferentes componentes o módulos y las
dependencias que hay entre éstos (Ver Figura 37).
66
Figura 38: Diagrama de paquetes.
67
4.4.1.4. Vista Física
En esta vista se presentan todos los componentes físicos y las
conexiones del sistema. Este diagrama (Ver Figura 39) permite tener
una noción completa ya que proporciona una vista global, donde se
muestra la relación entre el software desarrollado y las demás partes
involucradas. Además, se detallan los protocolos de conexión de las
componentes físicas.
68
4.4.1.5. Vista de Escenarios
Finalmente, esta vista representa la funcionalidad que el sistema
proporcionará a los ingenieros del NOC. Haciendo uso de un
diagrama de casos (Ver Figura 40) fue posible mirar como esta vista
relaciona las 4 vistas anteriores.
69
5. RESULTADOS Y ANÁLISIS
Cabe resaltar que, para garantizar la validez del producto final, éste tuvo
que pasar por un protocolo de pruebas.
70
protocolo de tres pasos. Este procedimiento garantiza que después de la
ejecución del protocolo, el software estará listo para implementarse en un
ambiente de producción.
71
observar que además de configurar correctamente cada equipo, el
software no generaba daño al tráfico existente en esos equipos.
72
• Punto a punto (VLL): En la Tabla 1 se observan los tiempos requeridos
en cada una de las diez pruebas realizadas, tanto en la
configuración manual como en la configuración automática
(configuración del software de automatización). En la configuración
manual se tuvieron en cuenta los tiempos empleados por los dos
ingenieros de configuración del NOC.
Cabe resaltar que en cada prueba variaron los equipos
configurados, así como el tipo de puerto, la interfaz de conexión y el
estado de cada puerto.
CONFIGURACIÓN MANUAL
Config CONFIGURACIÓN
Tiempo Tiempo AUTOMÁTICA
Servicio Ingeniero A Ingeniero B (min)
(min) (min)
Servicio 1 23 23 2.849
Servicio 2 24 20 2.353
Servicio 3 22 22 2.389
Servicio 4 20 20 2.500
Servicio 5 21 23 2.878
Servicio 6 20 22 2.510
Servicio 7 24 20 2.186
Servicio 8 22 22 3.292
Servicio 9 22 22 2.705
Servicio 10 23 21 3.052
PROMEDIO 22.1 21.5 2.671
73
configuración del ingeniero A, “TpromB” corresponde al tiempo
promedio de configuración del ingeniero B y “TpromManual”
corresponde al tiempo promedio de configuración manual.
74
SERVICIO CE - DISTRIBUCIÓN VSI
CONFIGURACIÓN
MANUAL
Config CONFIGURACIÓN
Tiempo Tiempo AUTOMÁTICA
Servicio Ingeniero A Ingeniero B (min)
(min) (min)
Para este caso se va a tener dos valores porcentuales, los cuales van
a ser promediados para tener un valor porcentual final:
75
De esta manera se concluye que el software de automatización en
una configuración de un servicio CE con distribución punto a
multipunto (VSI) utiliza 12.307% del tiempo que necesitaría un
ingeniero para configurar dicho servicio.
CONFIGURACIÓN MANUAL
Config
CONFIGURACIÓN
Tiempo Tiempo AUTOMÁTICA
Servicio Ingeniero A Ingeniero B
(min) (min)
Servicio 1 30 29 4.012
Servicio 2 28 28 3.399
Servicio 3 25 26 3.847
Servicio 4 26 28 2.740
Servicio 5 31 27 3.797
Servicio 6 29 27 2.915
Servicio 7 31 25 4.196
Servicio 8 31 28 3.116
Servicio 9 29 30 3.504
Servicio 10 29 30 2.979
PROMEDIO 28.9 27.8 3.450
76
Dentro del servicio IPNG también es posible observar que el software
emplea menos tiempo en realizar la configuración de los equipos
correspondientes al servicio.
PORCENTAJES (%)
VLL 12.252
SERVICIO CE
VSI 12.307
PROMEDIO 12.243
77
configuraciones de manera manual. Por esta razón el software de
automatización fue considerado óptimo y ya está listo para utilizarse en un
ambiente de producción.
78
En la Tabla 7 se presentan los mismos resultados presentados en la
Tabla 3, a diferencia que al tiempo de configuración se le sumo el tiempo
de ingreso de datos al software de automatización.
PORCENTAJES (%)
VLL 26.013
SERVICIO CE
VSI 20.927
SERVICIO IPNG VLL 22.751
PROMEDIO 23.230
79
6. CONCLUSIONES
80
REFERENCIAS BIBLIOGRÁFICAS
• [3] J. López. (2019, Junio 09). Implementación de una red MPLS. [Online].
Disponible:
http://openaccess.uoc.edu/webapps/o2/bitstream/10609/95887/7/pce
ballosbTFG0619memoria.pdf
81
• [10] A. Amarillo. (2013). Prototipo del protocolo NETCONF para la Gestión
Integrada de elementos de red. [Online]. Disponible:
https://repository.javeriana.edu.co/bitstream/handle/10554/15397/Amar
illoRojasAdrianaFernanda2013.pdf?sequence=1&isAllowed=y
• [11] Red Hat. (2019, Junio 21). Ansible Tower User Guide. [Online].
Disponible: https://docs.ansible.com/ansible-
tower/3.4.2/pdf/AnsibleTowerUserGuide.pdf
• [13] E. Bahit. (2013). Conexiones SSH y SFTP desde Python con paramiko.
[Online]. Disponible:
http://46.101.4.154/Art%C3%ADculos%20t%C3%A9cnicos/Python/Parami
ko%20-%20Conexiones%20SSH%20y%20SFTP.pdf
• [14] Red Hat, Inc. (2005). Manual de referencia. Protocolo SSH. [Online].
Disponible: https://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-es-4/ch-
ssh.html
• [17] T. Birchard. (2020, Enero 03). SSH y SCP en Python con Paramiko.
[Online]. Disponible: https://hackersandslackers.com/automate-ssh-scp-
python-paramiko/
82
• [19] A. Barroso. (2005, Septiembre). Instalación de una plataforma para
prueba de Servicios Web XML sobre la J2ME. [Online]. Disponible:
http://bibing.us.es/proyectos/abreproy/11096/fichero/Memoria%252F04
+Cap%C3%ADtulo+4+Base+de+Datos+mySQL.pdf+
83
ANEXOS
84
85
86