Análisis de la virtualización de conmutadores virtuales en ...

Departamento de Telecomunicaciones y Electrónica

Análisis de la virtualización de conmutadores virtuales

en redes empresariales.

Autor: Lázaro Enrique Tabasco Vasallo

Tutor: Dr. C. Ing. Félix Florentino Álvarez Paliza

Este documento es Propiedad Patrimonial de la Universidad Central “Marta Abreu”

de Las Villas, y se encuentra depositado en los fondos de la Biblioteca Universitaria

“Chiqui Gómez Lubian” subordinada a la Dirección de Información Científico

Técnica de la mencionada casa de altos estudios.

Se autoriza su utilización bajo la licencia siguiente:

Atribución- No Comercial- Compartir Igual

Para cualquier información contacte con:

Dirección de Información Científico Técnica. Universidad Central “Marta Abreu” de

Las Villas. Carretera a Camajuaní. Km 5½. Santa Clara. Villa Clara. Cuba. CP. 54

830

Teléfonos.: +53 01 42281503-1419

Hago constar que el presente trabajo de diploma fue realizado en la Universidad

Central “Marta Abreu” de Las Villas como parte de la culminación de estudios de la

especialidad de Ingeniería en Telecomunicaciones y Electrónica, autorizando a que

el mismo sea utilizado por la Institución, para los fines que estime conveniente, tanto

de forma parcial como total y que además no podrá ser presentado en eventos, ni

publicados sin autorización de la Universidad.

Firma del Autor

Los abajo firmantes certificamos que el presente trabajo ha sido realizado según

acuerdo de la dirección de nuestro centro y el mismo cumple con los requisitos que

debe tener un trabajo de esta envergadura referido a la temática señalada.

Firma del Tutor

Firma del Jefe de

Departamento donde se

defiende el trabajo

Firma del Responsable de

Información Científico-Técnica

i

PENSAMIENTO

Sin cambio no hay innovación, creatividad, o incentivo para la mejora.

Aquellos que inicien el cambio tendrán una mejor oportunidad de manejar el

cambio que es inevitable.

William Pollard.

ii

DEDICATORIA

A mis padres, por todo su amor y cariño.

A mis abuelos, por educarme desde niño.

A mis hermanos, por estar en mi vida.

iii

AGRADECIMIENTOS

A mis padres Niurka y Joel, por educarme y siempre insistir en mis estudios.

A mi abuela Concha, por criarme desde niño y enseñarme todo lo que ella sabía.

A mi abuelo Vasallo, por enseñarme a ser un hombre, siempre estar orgulloso de

mí y aunque ya no esté conmigo para verme graduado hoy, sé que siempre estará

cuidándome toda mi vida. Gracias por todo mi viejito.

A mis hermanos Osvaldito y Joanne, por llenar de felicidad mi vida.

A mi familia materna, por siempre apoyarme y enseñarme que la familia es lo más

importante en esta vida.

A mi familia paterna, que siempre está ahí cuando la necesito.

A mis amigos, en especial a Eddier, por su amistad en las buenas y las malas.

A mi tutor, por todos los consejos y experiencia aportados para la realización de

este trabajo.

A todos los profesores de la UCLV, que contribuyeron a mi formación como

ingeniero y como persona.

A todas las personas que han contribuido de una forma u otra en la elaboración de

esta tesis y a que pronto me gradúe como ingeniero, a todos aquellos que me

quieren y se preocupan por mí……

MUCHAS GRACIAS.

iv

TAREAS TÉCNICAS

• Análisis de los estándares internacionales para la virtualización de

conmutadores.

• Valoración de la situación actual de la virtualización de conmutadores virtuales.

• Determinación de las principales herramientas de software y hardware para la

virtualización de conmutadores, así como sus modelos de referencia.

• Propuesta de diferentes escenarios de aplicación de la virtualización de

conmutadores en las redes de telecomunicaciones.

Firma del Autor Firma del Tutor

v

RESUMEN

La Virtualización de las Funciones de Red (NFV, Network Function Virtualization)

es un novedoso paradigma cuyo objetivo fundamental consiste en desacoplar las

funciones de red del hardware específico y realizarlas a través de software, que se

conocen como Funciones de Red Virtual (VNF, Virtual Network Functions). Tal

desacoplamiento introduce muchos beneficios que incluyen la reducción de Gastos

de Capital (CAPEX, Capital Expenses) y de Gastos de Operación (OPEX, Operation

Expenses), además de una mejora de la flexibilidad en la prestación de servicios.

La virtualización de las funciones de red permite a los operadores y proveedores de

servicio correr sobre software las funciones de red localizadas en Servidores de

Propósito Universal (COTS, Commercial of the Self) o en sistemas de Computación

en la Nube (Cloud Computing).

En este trabajo se analiza la virtualización de conmutadores en una red empresarial,

más conocidos por sus siglas en idioma inglés (conmutador virtual).

Determinándose el estado de avance de la virtualización de conmutadores y se

fundamenta teóricamente la arquitectura la virtualización de conmutadores acorde

a arquitectura de virtualización de funciones de red, acorde a los estándares

internacionales.

Como aspecto importante se analizan las siguientes herramientas: VMWare

Workstation, Microsoft Hyper-V y Virtual Box, así como los escenarios para la

virtualización de conmutadores (VMWare vSphere, Microsoft Hyper-V y Mininet en

Linux.

vi

SIGLARIO

ACL Access Control List (Lista de Control de Acceso).

API Application Programming Interface (Interfaz de Programación de Aplicaciones).

ARP Address Resolution Protocol (Protocolo de Resolución de Direcciones).

BFD Bidirectional Forwarding Detection (Soporte para Detección de Reenvío

Bidireccional).

CAPEX Capital Expenses (Gastos de Capital).

CDP Cisco Discovery Protocol (Protocolo de Descubrimiento de CISCO).

COTS Commercial of the Self (Servidores de Propósito Universal).

CRM Customer Relationship Management (Administración de las Relaciones con

los Clientes).

DC Data Center (Centros de Datos).

DHCP Dynamic Hosts Configuration Protocol (Protocolo de Configuración Dinámica

de Anfitriones).

EG Expert Group (Grupos de Expertos).

ERP Enterprise Resource Planning (Planificación de Recursos de la Empresa).

ETSI European Telecommunications Standards Institute (Instituto Europeo de

Normas de Telecomunicaciones).

GRE Generic Routing Encapsulation (Encapsulación de Enrutamiento Genérico).

IETF Internet Engineering Task Force (Grupo de Trabajo de Ingeniería de Internet).

LACP Link Aggregation Control Protocol (Protocolo de Control de Agregación de

Enlaces).

LLDP Link Layer Discovery Protocol (Protocolo de Descubrimiento de Capa de

Enlace).

MAC Media Access Control (Control de Acceso al Medio).

MANO Management and Orchestration (Gestión y Orquestación).

vii

NAT Network Address Translation (Traducción de Direcciones de Red).

ND Neighbors Discovery (Descubrimiento de Vecinos).

NFV Network Function Virtualization (Virtualización de las Funciones de Red).

NFV ISG Industry Specification Group (Grupo de Especificación de la Industria para

NFV).

NGMN Net Generation Mobile Networks Alliance (Alianza de Redes Móviles de

Nueva Generación).

NIC Network Interface Network (Tarjeta de Interfaz de Red).

NOC Network Operators Council (Consejo de operadores de Red).

OPEX Operation Expenses (Gastos de Operación).

OVS Open Virtual Switch (Conmutador Virtual Abierto).

OVSDB Open Virtual Switch Database (Base de Datos de Conmutador Virtual

Abierto).

QoS Quality of Service (Calidad de Servicio).

RSPAN Remote SPAN (Conmutador Remoto Analizador de Puertos).

SDN Software Defined Networks (Redes Definidas por Software).

SPAN Switch Port Analyzer (Conmutador Analizador de Puertos).

SPB Shortest Path Bridging (Camino más corto al puente).

STP Spanning Tree Protocol (Protocolo de Expansión de Árbol).

TI Information Technologies (Tecnologías de la Información).

TRILL Transparent Interconnection of Lots of Links (Interconexión Transparente de

Lotes de Enlaces).

TSC Technical Steering Committee (Comité de Dirección Técnica).

UIT-T International Telecommunication Union (Comisión de Estudio del Sector de

Normalización de las Telecomunicaciones).

viii

VM Virtual Machines (Máquinas Virtuales).

VMM Virtual Machine Monitor (Monitor de Máquina Virtual).

VNF Virtual Network Functions (Funciones de Red Virtual).

VNFC Virtual Network Function Component (Componentes Virtuales de Función de

la Red).

WAN Wide Area Network (Red de Área Amplia).

WFP Windows Filtering Platform (Plataforma de Filtrado de Windows).

WG Working Groups (Grupos de Trabajo).

ix

TABLA DE CONTENIDOS

PENSAMIENTO ........................................................................................................ i

DEDICATORIA ......................................................................................................... ii

AGRADECIMIENTOS ............................................................................................. iii

TAREAS TÉCNICAS ............................................................................................... iv

RESUMEN ............................................................................................................... v

SIGLARIO ............................................................................................................... vi

TABLA DE CONTENIDOS ...................................................................................... ix

INTRODUCCIÓN .................................................................................................. 12

CAPÍTULO 1. LA VIRTUALIZACIÓN DE CONMUTADORES. .......................... 16

1.1 Breve reseña histórica de las NFV. .......................................................... 16

1.2 Estandarización de NFV. ......................................................................... 17

1.3 Arquitectura de NFV................................................................................. 19

1.4 Tipos de virtualización. ............................................................................. 20

1.4.1 Virtualización de hardware o servidor. ............................................... 20

1.4.2 Virtualización de redes. ..................................................................... 21

1.4.3 Virtualización de almacenamiento. .................................................... 21

1.4.4 Virtualización de escritorio. ................................................................ 22

1.4.5 Virtualización de aplicaciones. .......................................................... 23

1.5 Hipervisor. ................................................................................................ 23

1.5.1 Clasificación de los Hipervisores. ...................................................... 25

1.6 Contenedores. ......................................................................................... 27

1.6.1 Funcionamiento e importancia de los contenedores. ........................ 27

1.7 Hipervisores vs Contenedores. ................................................................ 29

x

1.8 Hardware COTS. ..................................................................................... 29

1.9 Desafíos y destino. .................................................................................. 31

1.10 Ventajas de la virtualización de conmutadores. .................................... 31

1.11 Conclusiones parciales del capítulo. ..................................................... 32

CAPÍTULO 2. ARQUITECTURA DE LA VIRTUALIZACIÓN DE

CONMUTADORES. .............................................................................................. 33

2.1 Arquitectura estándar de un Conmutador Virtual. .................................... 33

2.2 Estándares definidos por la ETSI. ............................................................ 36

2.2.1 Open Virtual Switch (OVS). ............................................................... 36

2.2.2 Protocolo OpenFlow y su funcionamiento. ........................................ 41

2.2.3 Protocolo OVS Database (OVSDB). .................................................. 45

2.3 Tipos de Conmutador Virtuales que se pueden implementar. ................. 46

2.3.1 Conmutadores Virtuales en VMWare. ............................................... 46

2.3.2 Conmutadores Virtuales en Microsoft Hyper-V. ................................ 50

2.3.3 Conmutadores virtuales en Linux. ..................................................... 53

2.4 Conclusiones parciales del capítulo. ........................................................ 53

CAPÍTULO 3. HERRAMIENTAS Y ESCENARIOS PARA EVALUAR EL

FUNCIONAMIENTO DE CONMUTADORES VIRTUALES. .................................. 54

3.1 Creación de un conmutador virtual en VMWare. ..................................... 54

3.2 Creación de un conmutador virtual en Hyper-V. ...................................... 57

3.3 Creación de un conmutador virtual en Linux. ........................................... 61

3.4 Conclusiones parciales del capítulo. ........................................................ 65

CONCLUSIONES Y RECOMENDACIONES ........................................................ 66

Conclusiones ..................................................................................................... 66

Recomendaciones ............................................................................................. 67

xi

REFERENCIAS BIBLIOGRÁFICAS ...................................................................... 68

ANEXOS ............................................................................................................... 74

Anexo 1 SYMKLOUD. .................................................................................. 74

Anexo 2 TCS-025-01924-001. ..................................................................... 75

Anexo 3 TCS-025-01941-001. ..................................................................... 78

Anexo 4 TCS-025-01955-001. ..................................................................... 81

Anexo 5 Comandos para la instalación del OVS. ......................................... 83

INTRODUCCIÓN 12

INTRODUCCIÓN

En la recomendación Y.3011 de la UIT-T se define el concepto de virtualización de

red como una tecnología que posibilita la creación de particiones de red aisladas

lógicamente sobre redes físicas compartidas, tal que colecciones heterogéneas de

redes virtuales múltiples pueden coexistir simultáneamente sobre redes

compartidas. Ello incluye la agregación de múltiples recursos en un proveedor y

aparecen como un simple recurso. [1]

La virtualización de las funciones de red permite reducir o eliminar el hardware

propietario específico de una aplicación de la infraestructura de red. En lugar de

requerir que un operador de red despliegue nuevos componentes de hardware para

cada nuevo servicio o aplicación, el modelo de NFV proporciona la misma

funcionalidad utilizando dispositivos virtuales que se ejecutan en servidores x86

convencionales. Conceptualmente, un operador puede desplegar un dispositivo

virtual bajo demanda y actualizar la funcionalidad a través de actualizaciones de

software a lo largo del tiempo.

Entre los avances de la virtualización de las funciones de red están que libera el

acople de las funciones de los equipos de hardware dedicados y corren sobre

servidores estándar, almacenadores y conmutadores.

NFV permite una utilización más eficiente de los recursos de hardware y licencias

de software, mejorando la eficiencia, robustez y escalabilidad de la red y reduciendo

drásticamente el tiempo y recursos dedicados a la planificación y su

dimensionamiento. [2]

Diferentes organismos y organizaciones internacionales se han destacado en la

estandarización de la virtualización de las funciones de red.

Entre ellos se destaca la Comisión de Estudio del Sector de Normalización de las

Telecomunicaciones (UIT-T, International Telecommunication Union) con las

recomendaciones de la serie Y.3000: 3001, 3011 y 3012. En la Y.3011 se describe

la armazón y se presentan motivaciones y definiciones. La misma discute también

INTRODUCCIÓN 13

el problema del espacio de la virtualización de red e investiga en sus objetivos.

También discute la aplicabilidad de la virtualización y resume sus ventajas y

desventajas.[1] En la Y.3012 se especifican las necesidades o exigencias para la

virtualización de red. [3]

En el modelo de NFV, los dispositivos virtuales que residen en servidores físicos o

virtuales reemplazan los dispositivos de red basados en hardwares dedicados. Las

funciones de operación y administración se manejan a través de un sistema de

orquestación que coordina los dispositivos virtuales en funcionamiento en una red.

Al igual que las máquinas virtuales, los dispositivos virtuales se seleccionan en

función de las necesidades del cliente final y se despliegan según sea necesario

cuando y donde se requieran. La escalabilidad para adaptarse a los cambios de las

necesidades del cliente se basa en la carga del software en los servidores

apropiados. Además, cuando el dispositivo virtual ya no es necesario, el espacio en

el servidor se puede liberar para usar por otra aplicación. Este uso compartido de

recursos ayuda a los proveedores de servicios a disminuir los costos generales.

El ecosistema de VNF incluye una amplia variedad de componentes de múltiples

proveedores. Algunos ejemplos de VNF incluyen la funcionalidad de enrutadores, la

seguridad y el cifrado, el equilibrio de carga, la optimización de la Red de Área

Amplia (WAN, Wide Area Network) y el monitoreo de desempeño. Una vez

seleccionadas, las VNF se controlan y operan a través de lo que el Instituto Europeo

de Normas de Telecomunicaciones (ETSI, European Telecommunications

Standards Institute) definió como la función Gestión y Orquestación (MANO,

Management and Orchestration). [4]

Cuando se piensa en conmutadores ethernet se tiende a pensar en una caja física

en un armario de alambraje o en el tope de un armario de servidores. Pero todo

hipervisor en un centro de datos virtualizado contiene un conmutador de software,

tal como el OVS para conectar Máquinas Virtuales (VM, Virtual Machines). En los

Centros de Datos (DC, Data Center) hay más hipervisores que conmutadores de

hardware y los mismos tienen más conmutadores virtuales que conmutadores

físicos. Así mismo debido a que cada hipervisor hospeda varias máquinas virtuales,

INTRODUCCIÓN 14

el centro de datos tiene más puertos ethernet virtuales que físicos. Por lo que el

diseño de conmutadores por software es un tema importante. [5]

En este trabajo de diploma la atención será centrada en la virtualización de

conmutadores, la cual en un ámbito empresarial reside en el lado del cliente y la

misma tiene varias opciones de implementación.

La virtualización de los conmutadores se ha convertido en una aplicación líder para

cumplir la promesa de las NFV de mover la funcionalidad de la aplicación de

hardware al software en plataformas comerciales, tal como lo tienen los centros de

datos. Sin embargo, los conmutadores virtuales también pueden ser desarrollados

dentro de Servidores Universales empleando la técnica de contenedores.

Si bien la virtualización de los conmutadores virtuales tiene el potencial de ofrecer

los beneficios de la NFV que los proveedores de servicios y empresas necesitan

con urgencia, no está exento de retos como, comprender las implicaciones reales

del mismo, lo cual constituye un paso esencial para los proveedores de servicios

que buscan cumplir la promesa de NFV; y aunque los desafíos parecen

desalentadores, hay maneras de superarlos. Esta virtualización se encuentra en

una etapa de pleno desarrollo y es preciso conocer los diferentes estándares,

proyectos, aplicaciones e implementaciones más exitosas de la misma. [6]

Por lo que es necesario evaluar las diferentes alternativas realizando una búsqueda

de información, documentando lo encontrado, para poder evaluar opciones y

realizar en un futuro una implementación de la misma en la red de la Universidad

Central Marta Abreu de las Villas (UCLV).

La situación descrita anteriormente trae consigo la interrogante siguiente: ¿Cuáles

son las principales opciones relacionadas con la virtualización de conmutadores y

sus implementaciones más exitosas en las redes empresariales?

Para darle respuesta al mismo, es necesario tener en cuenta:

• ¿Cuáles son los estándares aprobados de las NFV para la virtualización de

conmutadores?

INTRODUCCIÓN 15

• ¿Cuáles son los fundamentos teóricos de la virtualización de conmutadores,

tanto a nivel de centros de datos como de servidores universales?

• ¿Cuáles son las herramientas y escenarios más comunes para implementar

conmutadores virtuales?

El objetivo principal de este trabajo es analizar las opciones de implementación

de conmutadores virtuales en redes empresariales. Del anterior se derivan los

siguientes objetivos específicos:

• Generalizar la situación actual de la virtualización de conmutadores.

• Fundamentar teóricamente la arquitectura de virtualización de conmutadores.

• Evaluar las herramientas y escenarios para la virtualización de conmutadores.

Organización del informe:

El informe va a estar estructurado de la siguiente forma: introducción, tres capítulos

dedicados a la investigación, conclusiones, recomendaciones, referencias

bibliográficas, glosario de términos y anexos. Los temas abordados en cada capítulo

están estructurados de la siguiente forma:

Capítulo 1: La virtualización de conmutadores, donde se van a plantear algunos

principios básicos sobre la virtualización y sus aplicaciones y fundamentar

teóricamente la situación actual de la virtualización de conmutadores.

Capítulo 2: Arquitectura de la virtualización de conmutadores. En este capítulo se

va a analizar la arquitectura básica definida para un conmutador virtual y se van a

enumerar los distintos estándares existentes, así como los tipos de conmutadores

que se pueden implementar según la plataforma de virtualización que se escoja.

Capítulo 3: Herramientas y escenarios para evaluar el funcionamiento de

conmutadores virtuales. En este capítulo se van a ilustrar los distintos tipos de

escenarios donde podemos llevar a cabo la virtualización de un conmutador.

CAPÍTULO 1: LA VIRTUALIZACIÓN DE CONMUTADORES 16

CAPÍTULO 1. LA VIRTUALIZACIÓN DE CONMUTADORES.

En el presente capítulo se van a plantear los principios básicos a tener en cuenta a

la hora de realizar virtualización, así como sus ventajas, enfocándose en la

virtualización de conmutadores y sus aplicaciones en las redes actuales.

1.1 Breve reseña histórica de las NFV.

El concepto se originó en los proveedores de servicios que buscaban acelerar el

despliegue de nuevos servicios de red para respaldar sus ingresos y objetivos de

crecimiento. Las limitaciones de los dispositivos basados en hardware los llevaron

a aplicar tecnologías de virtualización de Tecnologías de la Información (TI,

Information Technologies) estándar a sus redes. Para acelerar el progreso hacia

este objetivo común, varios proveedores se unieron y crearon el ETSI.[7]

Puede considerarse 2012 como el inicio oficial de NFV, a partir del Libro Blanco

(White Paper: “Network Functions Virtualization”) presentado en octubre de dicho

año por miembros del ETSI en Alemania, relacionado con SDN y OpenFlow.

En dicha presentación, se plantearon los siguientes puntos clave:

• Necesidades de diseño para nuevos equipamientos.

• Costes y restricciones físicas de fabricación.

• Alto nivel de conocimiento necesario para operar las soluciones propietarias de

hardware/software.

• Complejidad hardware en las soluciones de fabricante.

• Ciclo de vida muy corto, lo que hace mínima la vida útil de dicho hardware.

• El ciclo de producto comienza antes de haber podido comenzar el retorno de

inversión.[8]


Este nuevo conjunto de necesidades desemboca en la creación de nuevas

soluciones, más ágiles y efectivas, nacidas en este nuevo entorno y orientadas a la

agilidad, escalabilidad y facilidad de implementación.

El enfoque NFV se aleja de la concepción dependiente de varias plataformas

hardware para dotar soluciones, pasando a un modelo de uso de plataformas

estandarizadas que soporten soluciones virtuales que provean las soluciones de

función de red requeridas.[4]

1.2 Estandarización de NFV.

La estandarización de NFV está siendo liderada por la ETSI. Tras varias

conversaciones informales y reuniones dese abril de 2012, el Grupo de

Especificación de la Industria para NFV (ETSI NFV ISG, Industry Specification

Group) fue creada formalmente en noviembre de 2012, por siete operadoras de

telecomunicaciones (AT&T, BT, Deutsche Telekom, Orange, Telecom Italia,

Telefónica, Verizon). La NFV ISG está abierta tanto a organizaciones miembros o

no de la ETSI y, hoy en día, está formada por más de 150 compañías, entre ellas

las principales operadoras de telecomunicaciones, proveedores de infraestructura

de telecomunicaciones y proveedores de tecnología de la información.

Aunque ETSI es una organización para el desarrollo de estándares, el objetivo de

la NFV ISG no es la producción de estándares, sino conseguir el consenso de la

industria en los requerimientos técnicos y de negocio de NFV, y en acordar enfoques

comunes para alcanzar estos requerimientos bajo una arquitectura común. Los

resultados son publicados de forma abierta y compartidos con los principales grupos

de estandarización, foros industriales y consorcios, como el Grupo de Trabajo de

Ingeniería de Internet (IETF, Internet Engineering Task Force) y la Alianza de Redes

Móviles de Nueva Generación (NGMN, Net Generation Mobile Networks Alliance);

con el fin de conseguir un esfuerzo de colaboración más amplio. La NFV ISG

colaborará con otros organismos de estandarización en caso de que sea necesaria

cualquier tipo de estandarización para cumplir los requisitos.


Además de la dirección del ISG, el Consejo de operadores de Red (NOC, Network

Operators Council) y el Comité de Dirección Técnica (TSC, Technical Steering

Committee), el NFV ISG se compone de varios Grupos de Trabajo (WG, Working

Groups). En concreto, existen cuatro grupos de trabajo centrados en áreas

específicas de NFV:

• INF (Infraestructura).

• SWA (Arquitectura, software).

• MANO (Gestión y Orquestación).

• REL (Fiabilidad y disponibilidad).

También hay dos Grupos de Expertos (EG, Expert Group) de carácter transversal:

• PER (Rendimiento y portabilidad).

• SEC (Seguridad).

Las primeras especificaciones de la ETSI ISG fueron publicadas en octubre de

2013:

• GS NFV 001 Casos de Uso.[9]

• GS NFV 002 Marco Arquitectónico.[10]

• GS NFV 003 Terminología de los Conceptos Principales en NFV.[11]

• GS NFV 004 Requisitos de Virtualización.[12]

• GS NFV-PER 002 Marco de Pruebas de Concepto.[13]

Estos cinco documentos establecen un marco de trabajo fundamental para el

desarrollo de NFV, cubriendo: casos de uso, requerimientos, arquitectura marco y

terminología. Además, se establece un marco de trabajo para coordinar y promover

demostraciones públicas de los aspectos claves de NFV. Esto hará más sencillo

para los operadores red y proveedores de soluciones NFV trabajar juntos,

mejorando la interoperabilidad y el desarrollo de un ecosistema abierto, que

facilitará las economías de escala globales. Estas primeras especificaciones han

sido desarrolladas en tan sólo 10 meses con el fin de poder satisfacer la alta


demanda de la industria, pues se espera que los despliegues de NFV se aceleren

en los próximos años.[14]

1.3 Arquitectura de NFV.

En la Figura 1.1 se observa la estructura definida por la ETSI en el Libro Blanco

publicado en 2012:

• Infraestructura de Virtualización de Funciones de Red (NFVI, Network

Function Virtualization Infrastructure): Constituye la base general de la

arquitectura, es la infraestructura física donde se ejecutan las máquinas virtuales

que componen las NFV. Engloba el hardware de las máquinas y la tecnología

de virtualización que abstrae a los niveles superiores del hardware real,

permitiendo simular unos recursos virtuales que serán utilizados por las

máquinas virtuales.

• Función de Red Virtual: Utiliza las máquinas virtuales que ofrece el bloque

NFVI, construyendo sobre ellas las funciones virtualizadas de red, añadiendo el

software necesario. Es la función de red virtual (un enrutador, cortafuegos, etc.).

Un VNF está compuesta de uno o más componentes llamados Componentes

Virtuales de Función de la Red (VNFC, Virtual Network Function Component),

ya que una función de red puede ser compleja y cada componente realizar una

función dentro de la misma función de red. Finalmente, un componente se

traduce en una o más máquinas virtuales que serán las que realice el trabajo de

la función de red.

• Gestión y Orquestación: Se define como un bloque separado dentro de la

arquitectura, que interactúa tanto con NFVI como con VNF. Se delega en esta

capa toda la gestión de los recursos de la infraestructura (incluyendo la creación,

borrado y reserva de espacio necesario para la gestión de las diferentes

máquinas virtuales).[8] [15]


Figura 1.1: Arquitectura de la NFV.[16]

1.4 Tipos de virtualización.

Los diferentes tipos de virtualización conforman un tipo de tecnología que está

transformando rápidamente el panorama de las Tecnologías de la Información y que

ha cambiado la manera en que las empresas utilizan los ordenadores.

La virtualización es fundamental en la Computación en la Nube, ya que reduce el

consumo de energía y ahorra costes, y hace posible ejecutar múltiples aplicaciones

y varios sistemas operativos en el mismo servidor. A su vez, aumenta la utilización,

la eficiencia y la flexibilidad del existente en el Centro de Datos.[17]

1.4.1 Virtualización de hardware o servidor.

El uso de un entorno de máquina virtual ha proporcionado un gran nivel de

satisfacción a los informáticos de todo tipo de empresas, en las que además también

se ha ahorrado en recursos. A través de este método de virtualización de servidores

se proporciona la oportunidad de sacar el máximo partido a la instalación. Un

servidor físico permite que se instalen distintas máquinas virtuales independientes

que se benefician de la tecnología instalada, pero que actúan con eficiencia e

independencia. Una buena configuración de estas máquinas virtuales puede ser lo

que de verdad llegue a mostrar un antes y un después en el rendimiento informático

de la empresa.[18]


De entre todos los tipos de virtualización, la virtualización de hardware o de servidor

es el más común, ya que ofrece ventajas de utilización de hardware y tiempo de

actividad de la aplicación. La idea básica de la tecnología es combinar muchos

servidores físicos pequeños en un servidor físico grande para que el procesador

pueda ser utilizado de una manera más eficiente. El sistema operativo que se

ejecuta en un servidor físico se convierte en un sistema operativo bien definido que

se ejecuta en la máquina virtual.

El hipervisor controla el procesador, la memoria y otros componentes al permitir que

diferentes sistemas operativos se ejecuten en la misma máquina sin necesidad de

un código fuente.[19]

1.4.2 Virtualización de redes.

Se refiere a la metodología de “virtualizar” redes para simplificar. Por ejemplo, la

gestión individual de los conmutadores, la incorporación de nuevas características

y el aseguramiento de la continuidad de los servicios y el rápido despliegue que hoy

requieren los negocios. Es un concepto asociado a la tendencia hacia lo que se

conoce como Redes Definidas por Software. Las redes virtuales ofrecen las mismas

funciones y garantías que una red física; no obstante, proporcionan las ventajas

operacionales y la independencia del hardware propias de la virtualización, lo que

incluye aprovisionamiento rápido, implementación no disruptiva, y mantenimiento y

soporte automatizados para aplicaciones heredadas y nuevas. El resultado

esperado de la virtualización de red es una mayor productividad y eficiencia de la

red.[17]

1.4.3 Virtualización de almacenamiento.

Se unen múltiples dispositivos de almacenamiento en red, dando la apariencia de

ser una única unidad de almacenamiento. La virtualización de almacenamiento es

utilizada con frecuencia en redes de área de almacenamiento de alta velocidad, que

comparten dispositivos y realizan tareas de respaldo y recuperación de datos de

manera más fácil y rápida. Forma parte de la capa de almacenamiento definida por

el software que debe proporcionar mejoras en el rendimiento y eficiencia del

espacio, sin la necesidad de adquirir hardware de almacenamiento adicional. La


tecnología de virtualización del almacenamiento proporciona una manera mucho

mejor de administrar recursos de almacenamiento para la infraestructura virtual y

en general mejora la flexibilidad y la utilización de recursos de manera significativa,

incrementa el tiempo de servicio de las aplicaciones y simplifica las operaciones

diarias.[20]

Este tipo de virtualización reduce los problemas generados por las grandes

cantidades de datos que se gestionan, pasando a separarse las unidades de

memoria y los discos de la unidad de los servidores. Se busca con este tipo de

virtualización un rendimiento de efectividad superior, dado que tanto unidades como

flash pasan a combinarse en depósitos de mayor eficiencia. De esta forma no se

producen situaciones adversas gracias a las ventajas que proporciona el confiar la

administración del almacenamiento al uso de software.[18]

Este tipo de virtualización proporciona varias ventajas considerables:

• Actualizaciones fáciles y mejor disponibilidad.

• Tiempo de inactividad reducido.

• Mejor utilización del almacenamiento.

• Gestión automatizada.[19]

Realmente, los usuarios finales no pueden distinguir entre la máquina virtual y el

ordenador físico. Se opta así por la virtualización de hardware cuando se trata de

proporcionar a diferentes usuarios un sinnúmero de servidores virtuales basados en

una plataforma informática potente, lo que constituye la base, por ejemplo, del

conocido modelo de anfitriones compartido.[21]

1.4.4 Virtualización de escritorio.

Es el proceso de separación entre el escritorio con datos y programas de los

usuarios, de la máquina física. El escritorio “virtualizado” es almacenado

remotamente en un servidor central, en lugar de hacerlo en el disco de cada PC. La

implementación de escritorios como un servicio administrado permite responder con

mayor rapidez a las necesidades y las oportunidades cambiantes, reduce costos y

aumenta los servicios mediante el suministro rápido y sencillo de escritorios y


aplicaciones virtualizados a diferentes oficinas o sucursales distantes, incluso

proporcionando acceso remoto seguro sin sacrificar rendimiento.[17]

No cabe duda de que cada vez más empresas están optando por la virtualización

de escritorios para formar a su alrededor un entorno estable que pueda llegar a

todos los rincones del mundo. El informático se puede beneficiar de la virtualización

de escritorios para tener controlado en un mismo lugar sin ningún tipo de

complicación la presencia de escritorios a distancia que podrán utilizar otros

miembros de la empresa sin importar cuál sea su situación. Todo estará optimizado,

funcionará a un buen nivel y será como si quienes están en el extranjero estuvieran

aprovechando la tecnología de la empresa desde las oficinas centrales. Es una

buena filosofía para aquellas empresas que se lanzan a la conquista de territorio

internacional a través de sucursales.[18]

1.4.5 Virtualización de aplicaciones.

Las organizaciones “virtualizan” cada vez más sus aplicaciones empresariales y sus

plataformas, así como también las Bases de Datos, la Planificación de Recursos de

la Empresa (ERP, Enterprise Resource Planning), la Administración de las

Relaciones con los Clientes (CRM, Customer Relationship Management), el correo

electrónico, la colaboración y muchas más. Este tipo de virtualización apunta a que

las aplicaciones se ejecuten mejor y proporcionen alta disponibilidad, posibilidad de

recuperación ante desastres, mayor velocidad y agilidad, así como también una

adecuada preparación para ir al modelo en la nube. En general, mejoran la calidad

de los servicios de TI que se proporcionan y, al mismo tiempo, simplifican la

infraestructura, maximizan la eficiencia y eliminan el costoso aprovisionamiento

excesivo. La virtualización favorece el acceso a los datos distribuidos y agrega

capacidad de análisis para extraer información valiosa, que permite correlacionar

datos históricos en reposo con una transmisión de análisis en tiempo real.[20]

1.5 Hipervisor.

Un hipervisor o también llamado Monitor de Máquina Virtual (VMM, Virtual Machine

Monitor) puede definirse como una tecnología que se compone por una capa de


software que permite utilizar, al mismo tiempo, diferentes sistemas operativos o

máquinas virtuales en una misma computadora central.

Su principal objetivo es satisfacer las necesidades de los sistemas operativos

invitados (máquinas virtuales) que se ejecutan en una máquina anfitrión y garantizar

que los sistemas operativos invitados no se interrumpan entre sí. En general, un

hipervisor se encarga de distribuir la memoria, el ancho de banda y el espacio de

almacenamiento en disco para VMs. Dado que hay un hipervisor entre el hardware

y los sistemas operativos, varios sistemas operativos pueden ejecutarse en la

misma plataforma de hardware.[22]

Los hipervisores gestionan los recursos de hardware proporcionados por el sistema

anfitrión como CPU, RAM, disco duro y periféricos y los comparte con los sistemas

alojados que correspondan. Desde el punto de vista técnico este proceso se

produce mediante virtualización completa o mediante paravirtualización:

• Virtualización completa: En este tipo de virtualización el hipervisor simula un

entorno completo de hardware para cada máquina virtual. Cada máquina virtual

dispone entonces de su propio conjunto de recursos de hardware virtuales

asignados por el hipervisor y ejecuta aplicaciones sobre esta base, de modo que

el sistema alojado no tiene acceso al hardware físico del sistema anfitrión. Las

soluciones de software más conocidas de este tipo de virtualización son:

Parallels Workstation, VMware Workstation, y Microsoft Virtual Server.

• Paravirtualización: Mientras que en la virtualización completa se dispone de un

entorno de hardware completo para cada máquina virtual, en la

paravirtualización el hipervisor ofrece solo una Interfaz de Programación de

Aplicaciones (API, Application Programming Interface) a través de la que los

sistemas alojados acceden al hardware físico del anfitrión, con lo que el

rendimiento mejora. Como requisito se exige que la API integre el kernel del

sistema operativo del huésped, es decir, solo se puede “paravirtualizar” sistemas

huésped modificados. Los proveedores de sistemas propietarios, como

Microsoft Windows, no permiten por norma general este tipo de modificación.

Entre los hipervisores que permiten la paravitualización se encuentran Xen y


Oracle VM Server for SPARC. El concepto también tiene su aplicación en el

sistema operativo para computadoras z/VM de IBM.

1.5.1 Clasificación de los Hipervisores.

En la Figura 1.2 se observan los tres tipos principales de Hipervisores existentes

en el mercado:

1. Hipervisor nativo (bare-metal o tipo 1): Este tipo de hipervisor se ejecuta

directamente sobre el hardware físico; el hipervisor se carga antes que ninguno

de los sistemas operativos invitados, y todos los accesos directos a hardware

son controlados por él. En términos más simple se puede decir que un hipervisor

de este tipo es un Sistema Operativo dedicado a la virtualización

En el mercado actual las principales y más potentes soluciones tienen en el enfoque

de hipervisor tipo 1, ejemplos de estos son:

• VMware ESXi.

• Citrix XenServer.

• Red Hat.

• Oracle VM.

• Proxmox VE.

• IBM PowerVM.

La tecnología nativa se adapta mejor a centros de datos empresariales. Esto es

porque dispone de características avanzadas como la administración de recursos,

alta disponibilidad, seguridad y administración centralizada de la infraestructura de

virtualización.

2. Hipervisor alojado (hosted o tipo 2): Es software que se ejecuta sobre un

sistema operativo para ofrecer la funcionalidad descrita. Un hipervisor tipo 2,

presenta claras desventajas. Al no tener acceso directo sobre el hardware, y

funcionar bajo un sistema operativo, se incrementa la utilización de recursos lo

cual puede degradar el rendimiento de la máquina virtual. Pensemos en que el

sistema operativo tendrá sus propias aplicaciones y servicios funcionando, lo


cual está quitando recursos disponibles a las máquinas virtuales que se

ejecuten.

Este tipo de tecnología es típica de utilizar en estaciones de trabajo, principalmente

para propósitos de prueba, desarrollo o para aquellos que necesiten ejecutar más

de un sistema operativo. Los hipervisores alojados más populares son:

• VMware Workstation.

• Microsoft Hyper-V.

• QEMU.

• Virtuozzo.

• Parallels Desktop.

• Bhyve.

• GNOME Boxes.

3. Hipervisores híbridos (hibrid o tipo 3): En este modelo tanto el sistema

operativo anfitrión como el hipervisor interactúan directamente con el hardware

físico.

Las máquinas virtuales se ejecutan en un tercer nivel con respecto al hardware, por

encima del hipervisor, pero también interactúan directamente con el sistema

operativo anfitrión.

Es la aproximación usada en:

• Microsoft Virtual PC.

• Microsoft Virtual Server.

• Parallels.

• VirtualBox.

• VMWare Server.[23]


Figura 1.2: Tipos de Hipervisores.[23]

1.6 Contenedores.

Los contenedores son máquinas virtuales mucho más portables y menos exigentes

a nivel recursos de cómputo que las máquinas virtuales convencionales (de ahí que

se conozcan como “máquinas virtuales ligeras”). Una de las más extendidas es la

que ofrece Docker; de hecho, Amazon lanzó después su propio servicio de gestión

de contenedores Docker.[24]

1.6.1 Funcionamiento e importancia de los contenedores.

Los contenedores funcionan de forma muy diferente que las máquinas virtuales

tradicionales. Como los paquetes solo alojan la aplicación, las librerías, etc. de los

que dependen, puede haber muchos contenedores que funcionan en un solo

sistema operativo. Esto hace que los contenedores ocupen muy poco espacio y que

la sobrecarga sea muy baja, por lo que los tiempos de ejecución son óptimos.

Los contenedores comenzaron siendo una característica central de Linux hace

tiempo, pero eran muy difíciles de utilizar. Docker se puso entonces manos a la obra

para intentar hacer más fácil el uso de esta tecnología para los desarrolladores. Los

usuarios saben que con los contenedores su software se ejecutará, no les importa

dónde. Además, permiten también los llamados “micro servicios”. En vez de tener

una gran aplicación en una sola pieza, esta se puede descomponer en pequeñas


partes que se relacionan entre ellas. Esto significa que los diferentes grupos pueden

trabajar fácilmente en distintas partes de una aplicación, siempre que no realicen

cambios en la forma de actuar de la aplicación global. Así se consigue desarrollar

el software y encontrar y solucionar los errores mucho más rápidamente.

Para gestionar todos los contenedores, se necesita el software especializado

Kubernetes (desarrollado por Google originariamente) que ayuda a introducir los

contenedores en diferentes máquinas, se asegura de que se ejecutan y permite

hacer funcionar varios contenedores más con una aplicación específica cuando la

demanda aumenta.

Los contenedores pueden ejecutar todo tipo de aplicaciones, pero muchas

empresas no lo soportan porque siguen trabajando con máquinas virtuales. Las

máquinas virtuales pueden seguir ejecutando esas aplicaciones antiguas en

servicios en la nube; por eso, a pesar de las ventajas que ofrece trabajar con

contenedores, las viejas máquinas virtuales coexistirán con estos durante bastante

tiempo.[25]

Con la virtualización basada en contenedores, no existe la sobrecarga asociada con

tener a cada huésped ejecutando un sistema operativo completamente instalado.

Este enfoque también puede mejorar el rendimiento porque hay un solo sistema

operativo encargándose de los avisos de hardware. Una desventaja de la

virtualización basada en contenedores, sin embargo, es que cada invitado debe

utilizar el mismo sistema operativo que utiliza el anfitrión.

Por lo general, los entornos corporativos evitan la virtualización basada en

contenedores, prefiriendo los hipervisores y la opción de tener muchos sistemas

operativos. Un entorno virtual basado en contenedor, sin embargo, es una opción

ideal para los proveedores de alojamiento que necesitan una manera eficiente y

segura para ofrecer sistemas operativos para que los clientes ejecuten sus servicios

en ellos.[26]


1.7 Hipervisores vs Contenedores.

En los últimos años, la tecnología de contenedores ha crecido en popularidad como

un posible reemplazo para los hipervisores, ya que pueden colocar más

aplicaciones en un solo servidor físico que una máquina virtual.

Sin embargo, las preocupaciones de seguridad y los usos prácticos de las máquinas

virtuales implican que los contenedores no necesariamente reemplazarán a los

hipervisores / máquinas virtuales, sino que las empresas utilizarán una combinación

de ambos. En cuanto al tema de seguridad, algunos consideran que los

contenedores son menos seguros que los hipervisores, debido a que los

contenedores solo tienen un sistema operativo que las aplicaciones comparten,

mientras que las máquinas virtuales aíslan no solo la aplicación, sino también el

sistema operativo. Si una aplicación se ve comprometida, podría atacar el sistema

operativo único en un contenedor, afectando a otras aplicaciones. Si una aplicación

en una máquina virtual se ve comprometida, solo un sistema operativo en ese

servidor se vería afectado, no otras aplicaciones o sistemas operativos en la

máquina virtual.[27]

1.8 Hardware COTS.

Los productos COTS están diseñados para ser instalados fácilmente y para

interoperar con los componentes del sistema existentes. Casi todo el software

comprado por el usuario promedio de computadoras se ajusta a la categoría COTS:

los sistemas operativos, los paquetes de productos de oficina, el procesamiento de

textos y los programas de correo electrónico se encuentran entre los innumerables

ejemplos. Una de las principales ventajas del software COTS, que se produce en

serie, es su costo relativamente bajo. Son soluciones empaquetadas que luego se

adaptan para satisfacer las necesidades de la organización de compras, en lugar

de la puesta en servicio de soluciones a medida o a medida.

En varios países del mundo se ha definido "COTS" como un término formal para los

artículos comerciales, incluidos los servicios, disponibles en el mercado comercial

que se pueden comprar y usar bajo un contrato gubernamental. Por ejemplo,


Microsoft es un proveedor de software COTS. Los bienes y materiales de

construcción pueden calificar como COTS, pero la carga a granel no lo hace. Los

servicios asociados con los artículos comerciales también pueden calificar como

COTS, incluidos los servicios de instalación, servicios de capacitación y servicios

en la nube. En el Anexo 1, 2, 3 y 4 se pueden observar varios de estos servidores

COTS, así como su descripción. Las compras de COTS son alternativas al software personalizado o desarrollos

únicos, desarrollos financiados por el gobierno u otros.[28]

Si bien los productos COTS se pueden usar de inmediato, en la práctica, el producto

COTS debe configurarse para satisfacer las necesidades de la empresa e integrarse

a los sistemas organizativos existentes. La extensión de la funcionalidad de los

productos COTS a través del desarrollo personalizado también es una opción, sin

embargo, esta decisión debe considerarse cuidadosamente debido a las

implicaciones de soporte y mantenimiento a largo plazo. Dicha funcionalidad

personalizada no es compatible con el proveedor COTS, por lo que presenta sus

propios conjuntos de problemas al actualizar el producto COTS.

El uso de COTS ha sido obligatorio en muchos programas gubernamentales y

empresariales, ya que dichos productos pueden ofrecer ahorros significativos en

adquisiciones, desarrollo y mantenimiento. Las motivaciones para usar los

componentes de COTS incluyen esperanzas de que el sistema de reducción cubra

toda la vida útil.

En la década de 1990, muchos consideraron que el COTS era extremadamente

efectivo para reducir el tiempo y el costo del desarrollo de software. El software

COTS se produjo con muchos compromisos no tan obvios: una reducción en el

costo inicial y el tiempo de desarrollo en comparación con un aumento en el trabajo

de integración de componentes de software, la dependencia del proveedor, los

problemas de seguridad y las incompatibilidades de futuros cambios.[29]


1.9 Desafíos y destino.

Uno de los desafíos clave con la virtualización de servidores ha sido encontrar una

manera de permitir a los administradores de red mover máquinas virtuales a través

de anfitriones físicos sin tener que detenerse y reconfigurarlas individualmente.

Debido a que mover máquinas virtuales a través de anfitriones físicos de manera

escalable requiere mucho tiempo y puede exponer a la red a violaciones de

seguridad si no se realiza correctamente, estas preocupaciones pueden evitar que

una empresa lleve su iniciativa de virtualización más allá de la simple consolidación

de servidores a una asignación de recursos más dinámica. Ahí es donde los

avances en los conmutadores virtuales pueden ayudar. Debido a que un

conmutador virtual es inteligente, se puede usar para garantizar la integridad del

perfil de una máquina virtual, incluida su configuración de red y seguridad, ya que

la Máquina Virtual se migra a través de anfitriones físicos en la red. [6]

Un conmutador virtual está destinado a proporcionar un mecanismo para reducir la

complejidad de la configuración de la red. Esto se logra reduciendo el número de

conmutadores que deben administrarse después de tomar en cuenta el tamaño de

la red, los paquetes de datos y la arquitectura. También puede garantizar la

integridad del perfil de la máquina virtual, que incluye la configuración de red y

seguridad. Esto demuestra una gran ayuda para los administradores de red, ya que

mover máquinas virtuales a través de anfitriones físicos puede llevar mucho tiempo

y presentar riesgos de seguridad. [5]

1.10 Ventajas de la virtualización de conmutadores.

Un conmutador virtual tiene algunas ventajas clave:

• Ayuda en la fácil implementación y migración de servidores virtuales.

• Permite a los administradores de red administrar el conmutador virtual

implementado a través de un hipervisor

• En comparación con un interruptor físico, es fácil implementar una nueva

funcionalidad, que puede estar relacionada con el hardware o el firmware.[5]


• Separación de redes con VLAN y enrutadores, lo que le permite restringir el

acceso de una red a otra.

• Seguridad mejorada.

• Gestión flexible de la red.

• Se necesitan menos adaptadores de red de hardware para la conexión de red

redundante (en comparación con las máquinas físicas).

• Migración y despliegue más sencillo de máquinas virtuales.[30]

1.11 Conclusiones parciales del capítulo.

Luego de realizarse una investigación en este primer capítulo sobre el estado actual

de la virtualización de conmutadores, se puede concluir que la virtualización de los

conmutadores es un recurso con capacidades de aplicación muy grandes, que

puede revolucionar por completo la forma de ver y comprender las redes como las

conocemos hoy en día; ya que esta tecnología puede ser implementada en

cualquier red con un costo menor que el de las redes tradicionales y ofreciendo

además una mayor estabilidad, confiabilidad y rapidez comprobada.

La virtualización de los conmutadores es una solución que llegó para quedarse y

seguir evolucionando con el tiempo, ya que permite la implementación de nuevas

tecnologías y algoritmos que pueden incrementar aún más el rendimiento de

cualquier red que la use, proporcionando facilidades para los administradores de

red de las empresas, los cuales reducirían su trabajo a la hora de expandir la red,

que con esta tecnología resulta más fácil y efectivo que antes.

CAPÍTULO 2. ARQUITECTURA DE LA VIRTUALIZACIÓN DE CONMUTADORES 33

CAPÍTULO 2. ARQUITECTURA DE LA VIRTUALIZACIÓN DE

CONMUTADORES.

En el presente capítulo se describirá la arquitectura definida para un conmutador

virtual estándar, así como los principales estándares aprobados mundialmente y los

posibles tipos de conmutadores virtuales que se pueden implementar dependiendo

de la plataforma de virtualización a emplear, que van a contribuir a nuestro

aprendizaje sobre conmutadores virtuales.

2.1 Arquitectura estándar de un Conmutador Virtual.

Un conmutador estándar, o conmutador virtual estándar, funciona como un

conmutador físico de capa 2 como se aprecia en la Figura 2.1. Mantiene una tabla

de reenvío de puertos de Control de Acceso al Medio (MAC, Media Access Control)

y realiza tres funciones importantes:

• Busca el MAC de destino de cada cuadro cuando llega.

• Reenvía un marco a uno o más puertos para la transmisión.

• Evita entregas innecesarias.

Figura 2.1: Arquitectura de un conmutador virtual estándar.[31]


En un lado del conmutador virtual hay grupos de puertos que se conectan a

máquinas virtuales. En el otro lado están las conexiones de enlace ascendente a

los adaptadores ethernet físicos en el servidor donde reside el conmutador virtual.

Las máquinas virtuales se conectan al mundo exterior a través de los adaptadores

ethernet físicos que están conectados a los enlaces ascendentes del conmutador

virtual.

Un conmutador estándar puede conectar sus enlaces ascendentes a más de un

adaptador ethernet físico para habilitar la formación de equipos con Tarjeta de

Interfaz de Red (NIC, Network Interface Network). Con la formación de equipos NIC,

se pueden usar dos o más adaptadores físicos para equilibrar la carga o para

proporcionar una conmutación por error pasiva en caso de una falla de hardware

del adaptador físico o una interrupción de la red.

Los puertos virtuales en un conmutador virtual proporcionan puntos de conexión

lógica entre dispositivos virtuales y entre dispositivos virtuales y físicos. Puedes

pensar en los puertos como conectores virtuales RJ-45. Cada conmutador virtual

puede tener hasta 1.016 puertos virtuales, con un límite de 4.096 puertos en todos

los conmutadores virtuales en un anfitrión. Sin embargo, este límite de todo el

sistema incluye ocho puertos reservados por el conmutador virtual estándar, por lo

que puede usar solo 4088 puertos.

Un adaptador ethernet virtual actualiza el puerto del conmutador virtual con

información de filtrado del Control de Acceso a Medios (MAC, Media Access

Control) cuando se inicializa y siempre que cambia. Un puerto virtual puede ignorar

cualquier solicitud del adaptador ethernet virtual que violaría la política de seguridad

de Capa 2 vigente para el puerto. Por ejemplo, si la simulación de MAC está

bloqueada, el puerto descarta cualquier paquete que infrinja esta regla.[31]

En la Figura 2.2 se puede observar que el grupo de puertos es un concepto único

en el entorno virtual. Un grupo de puertos es un mecanismo para establecer políticas

que gobiernan la red conectada a él. En lugar de conectarse a un puerto en

particular en el conmutador virtual estándar, una máquina virtual conecta su NIC

virtual (vNIC) a un grupo de puertos. Todas las máquinas virtuales que se conectan


al mismo grupo de puertos pertenecen a la misma red dentro del entorno virtual,

incluso si se encuentran en servidores físicos diferentes. Los grupos de puertos se

pueden configurar para aplicar una serie de políticas que proporcionan seguridad

de red mejorada, segmentación de red, mejor rendimiento, mayor disponibilidad y

administración de tráfico.[32]

Figura 2.2: Concepto grupo de puertos.[32]


2.2 Estándares definidos por la ETSI.

La ETSI ha definido varios estándares y protocolos a usar a la hora de llevar a cabo

la creación de un conmutador virtual, de los cuales se van a analizar los más

utilizados a nivel mundial.

2.2.1 Open Virtual Switch (OVS).

El Conmutador Virtual Abierto (OVS, Open Virtual Switch) es un software de código

abierto creado para funcionar como un conmutador virtual en entornos de servidores

virtualizados (actualmente el conmutador virtual más adoptado). Igualmente se

encargan de reenviar el tráfico entre diferentes máquinas virtuales en el mismo

anfitrión físico y reenvían el tráfico entre las máquinas virtuales y la red física, en la

Figura 2.3 se pueden observar algunas de sus principales funciones.[33]

Figura 2.3: Open Virtual Switch.[33]


OVS además de exponer interfaces estándar de control y visibilidad con la capa de

red virtual, puede soportar una distribución a través de múltiples servidores físicos.

También tolera diversas tecnologías de virtualización basadas en Linux como:

• Xen/XenServer: Es un monitor de máquinas virtuales de código abierto.

• Máquina Virtual basada en Kernel (KVM, Kernel-Based Virtual Machine): Es

una solución para implementar virtualización completa Linux.

• VirtualBox: Es un software para realizar la virtualización de equipos.

• Proxmox VE: Es una solución completa de virtualización de servidores basada

en sistemas de código abierto. Permite la virtualización tanto sobre KVM como

contenedores y gestiona máquinas virtuales, almacenamiento, redes

virtualizadas y clústeres.

Este software de código abierto para la virtualización de conmutadores puede ser

fácilmente portado a diferentes plataformas de hadrware y sistemas operativos.

OVS se ejecuta en servidores físicos y permite la administración remota, lo cual

simplifica muchos aspectos de gestión de la red.[34]

El conmutador virtual libre OVS puede utilizarse con las aplicaciones de Flujo de

Red (NetFLow), Flujo de Muestra (sFlow, Sampled Flow), espejo de puertos, VLANs

y más. Desde una perspectiva de control y gestión, el conmutador virtual abierto

ejecuta lo que se ha denominado el protocolo OpenFlow y el protocolo de getión

Base de Datos de Conmutador Virtual Abierto (OVSDB, Open Virtual Switch

Database). Esto significa que un conmutador virtual puede operar de las dos formas,

como un conmutador de software ejecutándose dentro del hipervisor y como pila de

control de redes sobre un circuito integrado de conmutador.[35]

Características con las que es compatible.

La versión actual de Open Virtual Switch es compatible con las siguientes

características:

• Modelo estándar de VLAN 802.1Q con puertos troncales y de acceso.[36, p. 4]

• NetFLow y sFlow: Posibilidad de sacar NetFlow (paquetes del protocolo

NetFlow que sirven para capturar información sobre el tráfico IP) y sFlow


(paquetes del protocolo sFlow diseñado para monitorización de interfaces,

dispositivos inalámbricos y del equipo anfitrión) entre máquinas virtuales, que

pueden ser capturados y analizados.

• OpenFlow 1.0 o extensiones posteriores.

• Conmutador Analizador de Puertos (SPAN, Switch Port Analyzer) y Conmutador

Remoto Analizador de Puertos (RSPAN, Remote SPAN): Nos permite hacer

reflejo de un puerto o incluso de un puente entero, es decir, enviar una copia de

los paquetes vistos en un puerto del conmutador (o VLAN entera) a una conexión

para el monitoreo de red en un puerto del conmutador y de esta forma poder

llevar a cabo el diagnóstico de errores en la red.

• Protocolo de Control de Agregación de Enlaces (LACP, Link Aggregation Control

Protocol), Vinculación (IEE 802.1 AX-2008): Permite balancear el tráfico entre

varios enlaces, LACP es a nivel de conmutador exterior (truncado) y la

vinculación a nivel de máquina virtual.[37]

• Protocolo de Expansión de Árbol (STP, Spanning Tree Protocol) (IEEE 802.1D-

1998): Es un protocolo de red de nivel 2 del modelo OSI. Su función es la gestión

de bucles en topologías de red.[38]

• Políticas de tráfico por puerto.

• Calidad de Servicio (QoS, Quality of Service): Para definir niveles de calidad de

servicio como disponibilidad, ancho de banda, ratio de error, latencia, priorizar

tráfico, etc.

• Protocolos de Túnel Múltiples: Encapsulación de Enrutamiento Genérico (GRE,

Generic Routing Encapsulation) es un protocolo de túnel desarrollado por Cisco

Systems que puede encapsular una variedad de protocolos de capa de red

dentro de enlaces virtuales punto a punto a través del protocolo IP.

• Soporte para Detección de Reenvío Bidireccional (BFD, Bidirectional Forwarding

Detection).

• Selección de herramientas para el monitoreo de enlaces 802.1ag CFM, estándar

para redes de puentes virtuales y metropolitanas, que define una serie de

protocolos y prácticas para operaciones, administración y mantenimiento para

puentes y redes locales (LAN).[39]


Usos más comunes de OVS.

A continuación, describiremos usos comunes de OVS en entornos virtuales:

• Gestión centralizada: Los interfaces para la configuración centralizada y las

notificaciones asíncronas pueden ser utilizadas para crear un único conmutador

lógico sobre varios conmutadores virtuales ejecutándose en servidores físicos

diferentes. Básicamente, un proceso de gestión global abstrae una vista lógica

de los conmutadores y su configuración y permite a los administradores operar

con esa vista lógica en lugar de con conmutadores individuales. Es

responsabilidad de este proceso de gestión el asegurar que cualquier estado de

configuración de los conmutadores individuales acoplados a las entidades

lógicas se mantenga estable, como la unión, salida, y migración de VMs.

• Redes privadas virtuales: Un creciente segmento de la virtualización es el

"alojamiento en la nube" en el cual, un anfitrión ajeno (third part host) alberga

máquina virtual de múltiples clientes (inquilinos). Idealmente, para utilizar mejor

el hardware, estos ambientes deben co-localizar los inquilinos en la misma

infraestructura física y proporcionar fuertes garantías de aislamiento al mismo

tiempo. De la misma manera que un grupo de máquinas físicas pueden estar

conectados entre sí a través de una red dedicada, en un entorno virtualizado una

colección de máquinas virtuales puede estar conectados entre sí a través de una

red privada virtual implementada en la parte superior de una infraestructura de

red física compartida. Si todas las máquinas virtuales de un solo arrendatario

están en el mismo anfitrión físico, o si están en anfitriones separados donde cada

uno dedica una NIC para conectarse a un conmutador físico aislado, el apoyo a

estas redes privadas virtuales es simple. Sin embargo, cuando las máquinas

virtuales que comparten una red privada se distribuyen en varios anfitriones y /

o múltiples conmutadores físicos, la capa de red de virtualización debe soportar

la creación dinámica de superposición. OVS soporta túneles de tipo GRE y

VLAN.

• Movilidad entre subredes IP: Una limitación bien sabida por las plataformas de

virtualización comerciales de hoy en día es que la migración debe ocurrir dentro


de una misma subred IP. Esto se debe a la imposibilidad de mantener sesiones

de transporte TCP si se cambia la dirección del anfitrión destino. La migración

entre subredes es deseable por varias razones. Por ejemplo, si una red tiene

problemas de escalamiento en cuanto al número de anfitriones, hay diversas

formas de conseguir esto con OVS. La más directa es unir un modelo similar a

Mobile IP en el que un OVS base recibe todos los paquetes dirigidos a una

máquina virtual y luego reenvía los paquetes a la verdadera dirección del

anfitrión usando tunelado. El proceso de gestión global debe manejar reglas de

tunelado consistentes en la localización de las máquinas virtuales dentro de la

red.[39]

Ventajas del OVS.

Sabemos que OVS es un sustituto de los “puentes” a la hora de dar conectividad a

las máquinas virtuales. Además, su funcionamiento, que puede ser a través de un

“controlador” tiene ciertas ventajas. Las ventajas de este sustituto de los puentes a

la hora de dar conectividad a las máquinas virtuales son varias.

• Incorporan funcionalidades de red similares a los conmutadores físicos: El

OVS, a parte de las funcionalidades L2 y L3, VLAN etiquetadas (por puerto) y

agregar enlaces, también administra funcionalidades propias de un conmutador

configurable, que son las que características compatibles que definíamos

anteriormente como pueden ser SPAN/RSPAN, Netflow/sFlow, QoS, Túneles

GRE, etc. Las configuraciones de VLANs y agregados se realizan directamente

sobre el OVS, no sobre terceros elementos como puede ser un puente por

VLAN, etc. Por lo que se asemejan de este modo a los conmutadores.

• OVSDB y OpenFlow (OVS en modo flujos configurables): Al utilizar OVS y el

Controller SDN, se facilita el responder dinámicamente a la gran tasa de cambios

que se producen en la infraestructura de red, modificando la configuración de

red. Anteriormente, se ha dicho que el OVS mantiene la base de datos llamada

OVSDB, la cual contiene toda la información distribuida de la configuración y el

estado de los OVS de una infraestructura. Utilizando esta información que

contiene la base de datos podemos hacer uso de numerosos aspectos de red


más allá de los tradicionales, como por ejemplo el movimiento de máquinas

virtuales, de modo que las herramientas de dirección puedan conocer el estado

de la Nube y utilizar esa información para modificar, mediante el Controlador

SDN, el comportamiento de reenvío de paquetes dentro de los flujos con

OpenFlow. También, gracias a la base de datos OVSDB, el estado del puerto de

red de una máquina virtual puede ser fácilmente migrado junto con la máquina.

• Compatibilidad con software basado en puentes: Cuando OVS necesitase

ser compatible con softwares que están basados en puentes, se tendría que

configurar el OVS de manera que imitara el comportamiento de un “puente”

frente a las VLANs. Así que, tendríamos un puente por cada VLAN, en lugar de

tener un OVS, en el que cada puerto tiene una configuración propia como si

fuese un conmutador tradicional.

• Descarga de procesamiento de paquetes a hardware: Una ventaja añadida

de OVS es que está diseñado para poder realizar el procesamiento en hardware,

es decir, que puede realizar una descarga del procesamiento de paquetes a las

NICs de los Anfitriones KVMs en los que residen, en lugar de hacerlo por

software, con lo que así se mejora del rendimiento.[40]

2.2.2 Protocolo OpenFlow y su funcionamiento.

Es una tecnología de conmutación que surgió a raíz del proyecto de Investigación:

OpenFlow: “Habilitando la Innovación en las Redes del Campus” (OpenFlow:

Enabling Innovation in Campus Networks”) de 2008 en la Universidad de Stanford.

Se define como un protocolo emergente y abierto de comunicaciones que permite

a un servidor de software determinar el camino de reenvío de paquetes que debería

seguir en una red de conmutadores. Con el protocolo OpenFlow, una red puede ser

gestionada como un todo, no como un número de dispositivos que gestionar

individualmente, es el propio servidor el que dice a los conmutadores dónde deben

enviar los paquetes. Con esta tecnología, las decisiones que impliquen el

movimiento de paquetes están centralizadas, por lo que la red puede ser

programada independientemente de los conmutadores.[41]


En un conmutador convencional, el reenvío de paquetes Ruta de Datos (Datapath)

y el encaminamiento de alto nivel se realizan en el mismo dispositivo, sin embargo,

en los conmutadores OpenFlow ambos se separan. Con OpenFlow, una parte de la

ruta de datos reside en el mismo conmutador, pero es un controlador el que realiza

las decisiones de encaminamiento de alto nivel. Ambos elementos se comunican

por medio del protocolo OpenFlow. Esta metodología, conocida como SDN permite

una mayor efectividad en el uso de los recursos de la red que en una red

convencional. OpenFlow está pensada para afrontar la movilidad de máquinas

virtuales, redes con misiones críticas o redes NGN móviles.[35]

Los conmutadores tradicionales usan STP, camino más corto al puente (SPB,

Shortest Path Bridging), Interconexión Transparente de Lotes de Enlaces (TRILL,

Transparent Interconnection of Lots of Links) para determinar cómo se reenvían los

paquetes. OpenFlow traslada esta decisión de reenvío de los conmutadores a los

controladores, típicamente un servidor o una estación de trabajo. Una aplicación de

gestión se ejecutará en las interfaces del controlador que une todos los

conmutadores en la red, facilitando la configuración de caminos de reenvío que

utilizarán todo el ancho de banda disponible. La especificación define el protocolo

entre el controlador y los conmutadores y un conjunto de operaciones que se

pueden realizar entre ellos. Las instrucciones de reenvío se basan en el flujo, que

consiste en que todos los paquetes comparten una serie de características

comunes. Existen infinidad de parámetros que pueden especificarse para definir un

flujo. Entre los posibles criterios podemos incluir los puertos por donde se reciben

los paquetes cuando llegan, el puerto ethernet de origen, la etiqueta VLAN, el

destino ethernet o el puerto IP y otro número de características de los paquetes. Un

nuevo flujo se debe crear cuando un paquete que llega no encuentra ninguna

coincidencia con ninguna entrada de la tabla. El conmutador debería tener

configurado un descartado de paquetes para el flujo que no haya sido definido, pero

en la mayoría de los casos, el paquete será enviado al controlador. El controlador

entonces define un nuevo flujo para ese paquete y crea una o más entradas para la

tabla. Éste envía la entrada o entradas al conmutador para que sean añadidas a las


tablas de flujo. Finalmente, el paquete se envía de vuelta al conmutador para ser

procesado con las nuevas entradas creadas.[39]

El Conmutador OpenFlow.

La idea básica es simple: explotar el hecho de que la mayoría de los conmutadores

ethernet contienen Tablas de Flujos (Flow-Tables), que trabajan a la velocidad de

la línea para implementar cortafuegos, NAT, QoS y recolectar estadísticas. Aunque

las Tablas de Flujos que maneja cada fabricante son propias, se han aprovechado

características observadas y comunes a todas ellas. Precisamente eso es lo que

ofrece OpenFlow, un protocolo abierto para poder programar las tablas de flujo en

diferentes conmutadores y enrutadores, como se puede apreciar en la Figura 2.4.

Figura 2.4: Conmutador OpenFlow.[42]

Los administradores de la red solo necesitarían dividir el tráfico entre producción y

el dedicado a la investigación. De esta manera, se conseguiría experimentar con

nuevos protocolos, nuevos modelos de seguridad, esquemas de direccionamiento,

incluso alternativas para IP y en definitiva una innovación mayor. Visto de esta

manera, OpenFlow podría ser una generalización de las VLAN´s. El tráfico de

producción no se vería afectado ya que está aislado y se procesaría de la misma


manera que se ha estado realizando hasta hoy día. Las acciones que pueden

soportar los conmutadores OpenFlow son extensibles, si bien es necesario tener

unas características mínimas y comunes a todos ellos.[43]

Tipos de Conmutadores OpenFlow.

Existen dos tipos de conmutadores:

• Conmutadores OpenFlow-únicamente: Un conmutador que soporta

OpenFlow, contiene múltiples tablas de flujos, y cada flujo contiene múltiples

entradas de flujo. El procesado define cómo los paquetes interactuarán con

estas tablas de flujos. Requiere que tenga al menos una tabla de flujo y

opcionalmente más. Cuantas menos entradas más simplificado será el

procesado.

• Conmutadores OpenFlow-híbridos: Conmutadores que soportan tanto la

operación OpenFlow como la conmutación ethernet convencional. Operaciones

habituales pueden ser: conmutación ethernet de Capa 2, aislamiento de tráfico

con VLAN, nivel 3 o de enrutamiento (IPV4, IPV6), listas de acceso o QoS. Estos

conmutadores deberán proveer un mecanismo de clasificación fuera de

OpenFlow que enrute el tráfico o bien ser procesado por OpenFlow. Por ejemplo,

un conmutador deberá usar una etiqueta VLAN o puerto de entrada para decidir

si se procesa el paquete de una manera u otra o debe redirigirlos hacia el

procesador OpenFlow. Este mecanismo de clasificación sale fuera del ámbito de

la especificación. El protocolo OpenFlow permite que el conmutador sea

controlado por dos o más controladores para incrementar el rendimiento y la

robustez del sistema.[43]

Beneficios del protocolo OpenFlow.

A continuación, se describen los beneficios de usar este protocolo:

• En primer lugar, habilita la programabilidad permitiendo hacer innovaciones y

acelerando la implementación de nuevas características.


• En segundo lugar, crea una inteligencia centralizada que optimiza el desempeño

y proporciona gestión granular.

• Finalmente desacopla el plano de envío de datos del plano de control.[44]

2.2.3 Protocolo OVS Database (OVSDB).

El OVSDB es un protocolo de configuración OpenFlow que está diseñado para

administrar las implementaciones de OVS.

En una implementación de OVS, se utilizan un servidor de base de datos y un

demonio de conmutación. El protocolo OVSDB se usa en un grupo de control, junto

con otros administradores y controladores, para proporcionar información de

configuración al servidor de base de datos del conmutador. Los controladores

utilizan OpenFlow para identificar los detalles de los flujos de paquetes a través del

conmutador. Cada conmutador puede recibir instrucciones de múltiples

administradores y controladores, y cada administrador y controlador puede dirigir

múltiples conmutadores.

Al usar el protocolo OVSDB, los profesionales de TI pueden determinar la cantidad

de puentes virtuales individuales dentro de una implementación de OVS, lo que

permite a un ingeniero de redes crear, configurar y eliminar puertos y túneles de un

puente. Los ingenieros también pueden crear, configurar y eliminar colas.[45]

Aunque a veces se asume que OpenFlow puede hacerlo todo, este no es el caso.

Para las implementaciones de un controlador SDN con OVS, OpenFlow todavía se

usa para programar entradas de flujo, pero OVSDB se usa para configurar el propio

OVS. Configurar OVS significa hacer cosas como crear / eliminar / modificar

puentes, puertos e interfaces. Si OVS se implementa en un entorno independiente,

no hay ninguna razón por la que OVSDB no pueda ser utilizado por sí mismo para

configurar OVS (entorno no OpenFlow). Si bien esto es posible, existen muy pocas

plataformas de administración de red independientes que admitan OVS o

específicamente, OVSDB nativo.


Mientras que OVSDB se introdujo en el mundo, junto con OVS, la base de datos

OVS ahora es compatible con más plataformas de conmutadores, a excepción de

OVS. Ahora está siendo soportado por proveedores de red, como Cumulus, Arista

y Dell, solo por nombrar algunos. Al ser compatible con la base de datos OVS, estos

proveedores están integrando sus plataformas de hardware con SDN y soluciones

de virtualización de red.[46]

Principales tareas que realiza OVS Database (OVSDB).

El protocolo OVSDB, como se ha visto, permite consultar y modificar la

configuración del OVS, permitiendo un medio de reprogramar las variables de la

base de datos interna, realizando de esta manera tareas como, por ejemplo:

• Creación y modificación de puertos en OpenFlow.

• Creación de Rutas de Datos OpenFlow.

• Configuración de los controladores que gestionan la plataforma.

• Recolección de estadísticas.

• Configuración, modificación y eliminación de túneles.

• Configuración de Calidad de Servicio (QoS).

• Creación, modificación y eliminación de las colas.[45]

2.3 Tipos de Conmutador Virtuales que se pueden implementar.

A la hora de implementar un conmutador virtual es necesario conocer los principales

tipos que más se usan, por ello, se va a llevar a cabo una descripción de los mismos

en cada una de las correspondientes plataformas de virtualización.

2.3.1 Conmutadores Virtuales en VMWare.

Los conmutadores virtuales en VMWare se puede dividir en dos tipos:

conmutadores virtuales estándar y conmutadores virtuales distribuidos.


Conmutador Virtual Estándar.

Un conmutador estándar de red virtual (Figura 2.5) es un conmutador virtual que se

puede configurar en un solo anfitrión ESXi. Por defecto, este conmutador virtual

tiene 120 puertos. El número máximo de puertos por anfitrión ESXi es 4096.

El descubrimiento de enlaces es una función que utiliza el Protocolo de

Descubrimiento de CISCO (CDP, CISCO Discovery Protocol) para recopilar y enviar

información sobre los puertos de conmutador conectados que se pueden usar para

solucionar problemas de red.

La configuración de seguridad le permite establecer políticas de seguridad:

• Al activar la opción Modo promiscuo, el adaptador virtual invitado puede

escuchar todo el tráfico, en lugar de solo el tráfico en la propia dirección MAC

del adaptador.

• Con la opción Cambios en la dirección MAC, puede permitir o no cambiar la

dirección MAC del adaptador de red virtual de una máquina virtual.

• Con la opción Transmisiones Forjadas, puede permitir o bloquear el envío de

tramas de salida con direcciones MAC diferentes a la configurada para el

adaptador VM.

Se pueden unir dos o más adaptadores de red en un equipo y enviarlos a un

conmutador virtual. Esto aumenta el ancho de banda (agregación de enlaces) y

proporciona una conmutación por error pasiva en caso de que uno de los

adaptadores en equipo se caiga. La configuración de equilibrio de carga le permite

especificar un algoritmo para la distribución del tráfico entre las NIC del equipo.

Puede establecer un orden de conmutación por error moviendo los adaptadores de

red (que pueden estar en modo "activo" o "en espera") arriba y abajo en la lista. Un

adaptador de reserva se activa en caso de falla del adaptador activo.


Figura 2.5: Conmutador virtual estándar.[47]

La configuración del tráfico limita el ancho de banda del tráfico saliente para cada

adaptador de red virtual conectado al conmutador virtual. Puede establecer límites

para el ancho de banda promedio (Kb / s), el ancho de banda máximo (Kb / s) y el

tamaño de ráfaga (KB). Las políticas de grupo de puertos, como la seguridad, la

agrupación de NIC y la configuración del tráfico, se heredan de las políticas de

conmutador virtual de forma predeterminada. Puede anular estas políticas

configurándolas manualmente para grupos de puertos.[48]

Conmutador Virtual Distribuido.

Un Conmutador Virtual Distribuido (Distributed Virtual Switch) (Figura 2.6) es un

conmutador virtual que incluye funciones estándar de conmutador virtual al tiempo

que ofrece una interfaz de administración centralizada. Un conmutador virtual

distribuido solo se puede configurar en vCenter Server. Una vez configurado en

vCenter, un conmutador virtual distribuido tiene la misma configuración en todos los

anfitriones ESXi definidos dentro del centro de datos, lo que facilita la administración

de grandes infraestructuras virtuales, no es necesario configurar un conmutador

virtual estándar manualmente en cada anfitrión ESXi. Cuando se utiliza un

conmutador virtual distribuido, las máquinas virtuales mantienen sus estados de red


y puertos de conmutador virtual después de la migración entre los anfitriones ESXi.

La cantidad máxima de puertos por conmutador virtual distribuido es 60,000. Un

conmutador distribuido virtual utiliza los adaptadores de red físicos del anfitrión ESXi

en los que residen las máquinas virtuales para vincularlos con la red externa.

VMware conmutador virtual distribuido crea conmutadores proxy en cada anfitrión

ESXi para representar las mismas configuraciones.

Nota: Se requiere una licencia Enterprise Plus para usar la función conmutador

virtual distribuido.

En comparación con un conmutador virtual, el conmutador virtual distribuido

proporciona un conjunto más amplio de características:

• Gestión centralizada de la red: Puede administrar el conmutador virtual

distribuido para todos los anfitriones ESXi definidos simultáneamente con

vCenter.

• Conformación del tráfico: A diferencia del conmutador virtual estándar, un

conmutador virtual distribuido admite la configuración del tráfico entrante y

saliente.

• Bloqueo de grupo de puertos: Puede deshabilitar el envío y / o recepción de

datos para grupos de puertos.

• Espejado de puertos: Esta función duplica cada paquete de un puerto a un

puerto especial con un sistema SPAN. Esto puede permitirle monitorear el tráfico

y realizar diagnósticos de red.

• Por política portuaria: Puede establecer políticas específicas para cada puerto,

no solo para grupos de puertos.

• Compatibilidad con el Protocolo de Descubrimiento de Capa de Enlace (LLDP,

Link Layer Discovery Protocol): LLDP es un protocolo no propietario de segunda

capa que es útil para monitorear redes de múltiples proveedores.

• Soporte de Netflow: Esto le permite monitorear la información de tráfico IP en un

conmutador distribuido, lo que puede ser útil para solucionar problemas.[32]


Figura 2.6: Conmutador Virtual Distribuido.[49]

2.3.2 Conmutadores Virtuales en Microsoft Hyper-V.

El conmutador virtual Hyper-V funciona con Windows Server y Windows Server

2016. También permite que los usuarios se conecten a redes virtuales en el servidor

que ejecuta Hyper-V al implementar Redes Definidas por Software, según un

documento técnico de octubre de 2017, publicado en el Microsoft Windows IT Pro

Center.[50]

El conmutador virtual Hyper-V es un conmutador de red de capa 2 ethernet basado

en software que se puede encontrar en el Administrador de conmutador virtual de

Hyper-V. (Figura 2.7). Incluye "capacidades ampliables y gestionadas de manera

programática para conectar máquinas virtuales a redes virtuales y a la red física", al

mismo tiempo que proporciona cumplimiento de políticas para seguridad,


aislamiento y niveles de servicio. El conmutador solo es compatible con ethernet y

no se puede utilizar con otras tecnologías de red de área local (LAN) cableadas.

Figura 2.7: Conmutador virtual Hyper-V.[51]

Los usuarios pueden elegir entre una amplia gama de funciones para usar dentro

del conmutador virtual Hyper-V, incluidas las capacidades de aislamiento de

inquilinos, la configuración del tráfico, la protección contra máquinas virtuales

maliciosas y la solución de problemas simplificada. El conmutador cuenta con

soporte incorporado para controladores de filtro de Especificación de Interfaz de

Dispositivo de Red (NDIS, Network Device Interface Specification) y controladores

de llamada de la Plataforma de Filtrado de Windows (WFP, Windows Filtering

Platform). Esto permite a los Proveedores de Software Independientes (ISP,

Independent Software Providers) crear complementos extensibles denominados

extensiones de conmutador virtual, que pueden proporcionar capacidades

mejoradas de red y seguridad.

Otras características útiles disponibles en el conmutador de red virtual Hyper-V son:

• Protocolo de Resolución de Direcciones (ARP, Address Resolution Protocol) y

protección de envenenamiento (suplantación de identidad) por Descubrimiento

de Vecinos (ND, Neighbors Discovery).

• Protección del Protocolo de Configuración Dinámica de Anfitriones (DHCP,

Dynamic Host Configuration Protocol).


• Lista de Control de Acceso (ACL, Access Control List) para el filtrado de tráfico.

• Modo troncal a capacidades de VM.

• Monitoreo de tráfico de red.

• Capacidades de LAN aisladas (privadas) que permiten a los administradores

segregar el tráfico en varias VLAN y establecer comunidades de inquilinos

aisladas.

• Los administradores pueden crear un conmutador virtual Hyper-V cuando

instalan por primera vez un hipervisor Hyper-V en Windows Server o Windows

Server 2016. Se pueden crear conmutadores virtuales adicionales utilizando

Hyper-V Manager, Windows PowerShell o Cloud Manager.[51]

Conmutador Virtual Externo.

Este tipo de conmutador está vinculado a las tarjetas de red físicas ubicadas en el

anfitrión. Como puede imaginar, proporcionan máquinas virtuales ubicadas en estos

conmutadores con acceso a la red física a la que está conectado el anfitrión de

Hyper-V. El conmutador externo también puede compartir el tráfico de

administración y el tráfico de la máquina virtual en el mismo conmutador y esta es

una de las opciones que se pueden configurar al crear el conmutador externo.

Conmutador Virtual Interno.

Este conmutador no está vinculado a una tarjeta de red física, por lo que solo

permite el tráfico entre máquinas virtuales y el propio anfitrión. Sin embargo, una

nueva adición a la funcionalidad del conmutador interno en 2016 es la adición del

conmutador interno de reenvío de Traducción de Direcciones de Red (NAT, Network

Address Translation) que permite la conectividad externa a través de NAT desde el

anfitrión de Hyper-V.

Conmutador Virtual Privado.

Este tipo de conmutador solo se utiliza para que las máquinas virtuales se

comuniquen entre sí. Este tipo de conmutador puede ser útil para ciertos tipos

específicos de tráfico, como la red de clústeres, si solo se usa un anfitrión, ya que

no se puede utilizar entre anfitriones.[52]


2.3.3 Conmutadores virtuales en Linux.

En Linux, específicamente en Mininet, que es la herramienta más usada a la hora

de simular redes usando esta plataforma, se usa por defecto el OVS realizando su

previa instalación antes de poder usarlo. Cabe destacar que se usa esta

configuración porque además de ser la más usada en el mercado internacional, es

una de la que más estabilidad y seguridad ofrece, así como la compatibilidad con

gran cantidad de características que nos facilitan grandemente el trabajo a la hora

de realizar una simulación. Y, a diferencia de las otras plataformas que usan

configuraciones internas, en este caso se usa un controlador externo para llevar a

cabo dichas simulaciones, que, a su vez, aumenta aún más las posibilidades de

implementación y provee muchas ventajas que los demás no poseen.

En el Anexo 5 se puede apreciar detalladamente cómo llevar a cabo la instalación

de OVS en la herramienta Mininet en el entorno Linux.


Luego de que se llevara a cabo una revisión de los diferentes estándares existentes,

se puede concluir que el OVS es el estándar más utilizado a nivel mundial, por todas

las ventajas, facilidades de aplicación y características con las que es compatible.

No obstante, muchas plataformas de virtualización optan por crear una

configuración para usar sus conmutadores virtuales propios, por un problema de

optimización de los propios recursos y de compatibilidad a la hora de llevar a cabo

la virtualización.

Cabe destacar que estas configuraciones propias funcionan igual de bien que si se

usara OVS, siempre manteniendo el estándar básico a la hora de crear un

conmutador virtual.

CAPÍTULO 3. HERRAMIENTAS Y ESCENARIOS PARA EVALUAR EL FUNCIONAMIENTO DE CONMUTADORES VIRTUALES 54

CAPÍTULO 3. HERRAMIENTAS Y ESCENARIOS PARA EVALUAR

EL FUNCIONAMIENTO DE CONMUTADORES

VIRTUALES.

En el presente capítulo se van a ilustrar las diferentes opciones existentes en el

mercado para poder crear e implementar un conmutador virtual, dependiendo

siempre e la plataforma de virtualización que se escoja y a las necesidades propias

de la institución que va a adoptar esta tecnología.

3.1 Creación de un conmutador virtual en VMWare.

De forma predeterminada, hay un conmutador virtual en un anfitrión ESXi, con dos

grupos de puertos: Red de Máquinas Virtuales y Red de Gestión. Se va a crear un

nuevo interruptor virtual.

Añadiendo un conmutador virtual estándar (Figura 3.1).

Conectarse al anfitrión ESXi con vSphere Web Client y hacer lo siguiente:

• Vaya a Redes> Conmutadores virtuales.

• Haga clic en Agregar interruptor virtual estándar.

• Establezca el nombre de conmutador virtual ("conmutador virtual2s", en nuestro

caso) y otras opciones según sea necesario. Luego haga clic en el botón

Agregar.


Figura 3.1: Creando un conmutador virtual estándar.[32]

Nota: Si se desea que las tramas gigantes estén habilitadas para reducir la

fragmentación de paquetes, puede establecer un valor de Unidad de transmisión

máxima (MTU) de 9,000 bytes.

Añadiendo un enlace ascendente (Figura 3.2).

Se recomienda agregar un enlace ascendente para garantizar la redundancia del

enlace ascendente haciendo lo siguiente:

• Vaya a Redes> su nombre de conmutador virtual> Acciones> Agregar enlace

ascendente.

• Seleccione dos NICs. También puede configurar otras opciones aquí, como el

descubrimiento de enlaces, la seguridad, la formación de equipos NIC y la

configuración del tráfico.


• Haga clic en el botón Guardar para finalizar.

Figura 3.2: Agregando un enlace ascendente para garantizar redundancia

Puede editar la configuración de conmutador virtual en cualquier momento haciendo

clic en Editar configuración después de seleccionar su conmutador virtual en

Redes> Interruptores virtuales (Figura 3.3).[32]


Figura 3.3: Ejemplo de una topología de conmutador virtual.[32]

3.2 Creación de un conmutador virtual en Hyper-V.

No existe una configuración previa de conmutador virtual durante la instalación de

Hyper-V. Si intenta crear una VM justo después del proceso de instalación, no podrá

conectarla a una red. Para configurar un entorno de red, deberá seleccionar

Administrador del Conmutador Virtual (Virtual Conmutador Manager) en el panel

derecho del Administrador Hyper-V (Hyper-V Manager). (Figura 3.4)

El Administrador del Conmutador Virtual ayuda a configurar conmutador virtual y las

Configuraciones de redes globales, que simplemente le permiten cambiar el rango

de dirección MAC predeterminado si hay algún motivo para hacerlo

Nota: El cambio del rango MAC no afectará a un conmutador virtual existente.

La creación del conmutador virtual es tan fácil como se muestra a continuación.

(Figura 3.5)


Figura 3.4: Abriendo la herramienta Administrador de Conmutador Virtual.[52]

Figura 3.5: Asistente para la creación de un conmutador virtual externo.[52]


Creación de un conmutador virtual externo.

Para crear un conmutador virtual externo, un asistente de creación le permitirá

ajustar algunas configuraciones. (Figura 3.6)

Figura 3.6: Propiedades del conmutador virtual externo.

• Puede seleccionar un NIC físico apropiado si tiene algunos de ellos para un

conmutador virtual externo.

• La configuración “permitir que el sistema operativo de gestión comparta este

adaptador de red” está activada de manera predeterminada. Al deshabilitar esta

configuración se dejará al sistema operativo del hipervisor sin conectividad de

red. Tenga cuidado al crear un conmutador virtual de manera remota porque

anulará por completo una conexión con un anfitrión remoto.


• SR-IOV (Virtualización de E/S de raíz única) le permite preparar dicha

configuración que puede aumentar la capacidad de la red al desviar un

conmutador virtual y redireccionar el tráfico directamente a la VM. La descripción

general de la habilitación de SR-IOV la puede encontrar aquí. Existen algunos

requisitos para tener en cuenta, tales como la compatibilidad con BIOS, el

soporte de SLAT de su CP y una tarjeta de red de interconexión rápida de

componentes periféricos (PCIe) de SR-IOV en su sistema. Asegúrese de saber

lo que está haciendo con anticipación.

NOTA: No se podrá habilitar SR-IOV en un conmutador virtual existente.

• VLAN ID: Esta configuración habilita la Red de área local (LAN) virtual (VLAN)

para el sistema operativo de administración. Lo mismo sucede con el entorno

físico; permite separar el tráfico del hipervisor proporcionando dominios de

transmisión separados dentro de la misma red.[53]

Una vez que hace clic en el botón Aplicar (Apply), prepárese para perder la

conectividad física por un momento mientras Hyper-V debe apagar el NIC físico,

configurar el conmutador virtual y encender ambos. (Figura 3.7)

Figura 3.7: Aplicando cambios a la red.


3.3 Creación de un conmutador virtual en Linux.

A la hora de demostrar la creación de un conmutador virtual en el entorno Linux,

nos vamos a enfocar en la herramienta Mininet, que es la que vamos a usar para

llevar a cabo la simulación de nuestra red.

Mininet es una ventana de comandos donde, por medio de estos, se podrán crear

distintas topologías de red y especificar los parámetros de los elementos que se

encuentran dentro de ella. (Figura 3.8)

Figura 3.8: Inicialización de Mininet.[54]

Al iniciar Mininet, mediante los comandos mostrados, la topología por defecto que

este va a crear consta de un conmutador, un controlador (local) y dos anfitriones.

(Figura 3.9).


Figura 3.9: Topología minimal, la inicial creada por Mininet.[54]

La instrucción “sudo mn” puede venir sola o acompañada de diferentes parámetros,

entre estos algunos de ayuda, para limpiar y reiniciar el emulador y otros para

ejecutar topologías de distintos tipos. Las diferentes topologías existentes son:

• Simple: Se lanzará un conmutador conectado a N anfitriones, los cuales

debemos definir. (Figura 3.10) (Figura 3.11).

Figura 3.10: Comando para crear una topología simple.[55]

Figura 3.11: Ejemplo de topología simple, en este caso con 4 anfitriones.[55]


• Linear: Se trata de una topología en la que cada conmutador se conecta con

otro de forma linear, y cada conmutador tiene un anfitrión conecto. (Figura 3.12)

(Figura 3.13).

Figura 3.12: Comando para crear una topología linear.[55]

Figura 3.13: Ejemplo de topología linear.[55]

• Árbol (Tree): Se creará una topología en árbol con profundidad N y anchura M.

(Figura 3.14) (Figura 3.15).

Figura 3.14: Comando para crear una topología tipo árbol.[55]


Figura 3.15: Ejemplo de topología árbol, con profundidad 3 y anchura 2.[55]

• Personalizada (Custom): Será necesario para este tipo de topologías crear un

archivo en Python con su descripción. Las topologías de este tipo se quedarán

guardadas en /Mininet/custom con extensión .py (Figura 3.16).[55]

Figura 3.16: Ejemplo de topología custom.[55]



Después de analizar las distintas formas que existen para crear un conmutador

virtual se puede concluir que, primeramente, la creación de un conmutador virtual

estándar no presenta muchas complicaciones, ya que en cada plataforma viene

predefinida su configuración y programación interna para que puedan ser

implementados en una red. Asimismo, si se quisiera agregar alguna configuración

adicional o crear otro tipo de conmutador (conmutador distribuido, interno o externo

dependiendo de la plataforma donde lo llevemos a cabo), tampoco resultaría muy

engorroso, ya que las propias interfaces gráficas de cada plataforma son bastante

descriptivas y nos ayudan mucho a la hora de agregar estas nuevas

configuraciones.

Por lo que, para implementar un conmutador virtual, se puede escoger cualquiera

de las plataformas descritas (VMWare, Microsoft Hyper-V o Linux), pues todas

ofrecen una gran estabilidad y fiabilidad con respecto a la hora de llevar a cabo la

virtualización de conmutadores, para ser implementados en cualquier tipo de red

que se desee, pero tiene su mayor aplicabilidad en redes empresariales que van a

ser las más grandes y, por tanto, las más beneficiadas.

CONCLUSIONES Y RECOMENDACIONES 66

CONCLUSIONES Y RECOMENDACIONES

Conclusiones

Al culminar el presente trabajo se puede concluir lo siguiente:

1. La virtualización de conmutadores es una tecnología de gran impacto que

revoluciona el sector de las telecomunicaciones. Llevar a cabo una

implementación adecuada de la misma trae importantes ventajas como la

reducción de los Gastos de Capital y de los Gastos de Operación,

específicamente la disminución del consumo energético y del espacio en los

centros de datos, y una rápida introducción de servicios en el mercado.

2. Al llevar a cabo la implementación de esta tecnología, es necesario conocer y

dominar todos los estándares aprobados a nivel mundial y hacer una correcta

planificación de los recursos físicos necesarios para que pueda explotarse al

máximo todas sus funcionalidades sin sufrir afectaciones en la calidad del

servicio prestado.

3. Las propuestas realizadas para la virtualización de conmutadores son

soluciones robustas, completas y con gran penetración y acoplamiento en

empresas de todo el mundo, por lo que todas se consideran buenas opciones

para llevar a cabo el despliegue, en un futuro, en nuestro propio Centro de Datos.

Por lo expresado anteriormente se considera resuelto el problema de esta

investigación y cumplido el objetivo del presente trabajo de diploma.

CONCLUSIONES Y RECOMENDACIONES 67

Recomendaciones

Una vez concluido este trabajo de diploma y con el objetivo de darle continuidad a

la investigación de este tema en cuestión, se recomienda:

• Dar seguimiento al tema de la implementación de la virtualización de

conmutadores en las empresas debido a que es una tecnología en constante

desarrollo y tendrá un gran impacto en nuestra red.

• Realizar la implementación de esta tecnología en nuestra propia red, utilizando

la versión más reciente de Linux, que es una de las mejores opciones por su

estabilidad y fiabilidad, cubriendo las necesidades del centro de datos.

• Llevar a cabo un análisis detallado de los principales proveedores de funciones

de redes virtuales, así como las características y ventajas que ofrece cada uno

de ellos para poder seleccionar la más estable y aplicable a nuestra red.

ANEXOS 68

REFERENCIAS BIBLIOGRÁFICAS

[1] UIT-T, ITU-T Y.3011. 2012, p. 28.

[2] «¿Qué es NFV y cuáles son sus costes, rendimiento y beneficios de escala? |

Movilidad | NetworkWorld», 05-feb-2019. [En línea]. Disponible en:

https://www.networkworld.es/movilidad/que-es-nfv-y-cuales-son-sus-costes-

rendimiento-y-beneficios-de-escala. [Accedido: 05-feb-2019].

[3] UIT-T, ITU-T Y.3012, vol. 11.1002/1000/12166. 2014, p. 16.

[4] «NFV Service Chaining Challenges - IEEE Software Defined Networks», 07-

feb-2019. [En línea]. Disponible en: https://sdn.ieee.org/newsletter/september-

2016/nfv-service-chaining-challenges. [Accedido: 07-feb-2019].

[5] «What is a Virtual Switch (vSwitch)? - Definition from Techopedia», 05-feb-

2019. [En línea]. Disponible en:

https://www.techopedia.com/definition/27140/virtual-switch-vswitch. [Accedido:

05-feb-2019].

[6] «What is virtual switch? - Definition from WhatIs.com», 05-feb-2019. [En línea].

Disponible en:

https://searchservervirtualization.techtarget.com/definition/virtual-switch.

[Accedido: 05-feb-2019].

[7] «What’s Network Functions Virtualization (NFV)? - SDxCentral», 05-feb-2019.

[En línea]. Disponible en: https://linkedcode.win/nfv/definitions/whats-network-

functions-virtualization-

nfv/?__cpo=aHR0cHM6Ly93d3cuc2R4Y2VudHJhbC5jb20. [Accedido: 05-feb-

2019].

[8] Margaret Chiosi, Don Clarke, Peter Willis, Andy Reid, James Feger, Michael

Bugenhagen, Waqar Khan, Michael Fargano, NFV White Paper. 2012, p. 16.

[9] B. Mohamed, Handbook of Research on Redesigning the Future of Internet

Architectures. IGI Global, 2015.

ANEXOS 69

[10] «ETSI GS NFV 002 V1.1.1 (2013-10) - Network Functions Virtualisation (NFV);

Architectural Framework | Joinup». [En línea]. Disponible en:

https://joinup.ec.europa.eu/solution/etsi-gs-nfv-002-v111-2013-10-network-

functions-virtualisation-nfv-architectural-framework. [Accedido: 10-jun-2019].


Terminology for Main Concepts in NFV | Joinup». [En línea]. Disponible en:


functions-virtualisation-nfv-terminology-main-concepts-nfv. [Accedido: 10-jun-

2019].


Virtualisation Requirements | Joinup». [En línea]. Disponible en:


functions-virtualisation-nfv-virtualisation-requirements. [Accedido: 10-jun-

2019].

[13] «Releases for ETSI GS NFV-PER 002 V1.1.1 (2013-10) - Network Functions

Virtualisation (NFV); Proof of Concepts; Framework solution | Joinup». [En

línea]. Disponible en: https://joinup.ec.europa.eu/solution/etsi-gs-nfv-002-v111-

2013-10-network-functions-virtualisation-nfv-proof-concepts-

framework/releases. [Accedido: 10-jun-2019].

[14] «NFV Testing - IEEE Software Defined Networks», 07-feb-2019. [En línea].

Disponible en: https://sdn.ieee.org/newsletter/november-2016/nfv-testing.

[Accedido: 07-feb-2019].

[15] «Virtual network functions, not network functions virtualization, belong in

enterprise», 05-feb-2019. [En línea]. Disponible en:

https://searchnetworking.techtarget.com/tip/Virtual-network-functions-not-

network-functions-virtualization-belong-in-enterprise. [Accedido: 05-feb-2019].

[16] Ing. Guillermo Manuel Dorantes Alonso, «Caracterización de las redes NFV»,

presentado en XVII SIMPOSIO DE INGENIERÍA ELÉCTRICA (SIE-2017),

Universidad Central “Marta Abreu” de Las Villas, 2017, p. 20.

ANEXOS 70

[17] Conzultek, «Conozca los tipos de virtualización y sus funciones», 05-feb-2019.

[En línea]. Disponible en: https://blog.conzultek.com/conoce-los-tipos-de-

virtualizacion-y-sus-funciones. [Accedido: 05-feb-2019].

[18] «Los principales tipos de virtualización». [En línea]. Disponible en:

https://blog.apser.es/2015/12/17/los-principales-tipos-de-

virtualizacion?hs_amp=true. [Accedido: 10-may-2019].

[19] «7 Tipos de virtualización para cloud computing», El blog de Kyocera:

soluciones para digitalizar tu negocio, 14-jul-2017. .

[20] «Tipos de virtualización», Evaluando Software, 27-oct-2015. .

[21] «Virtualización: definición y enfoques - 1&1 IONOS». [En línea]. Disponible en:

https://www.ionos.mx/digitalguide/servidores/configuracion/virtualizacion/.

[Accedido: 08-may-2019].

[22] Unknown, «Laboratorio TIC: Hypervisores... ¿Que es un Hypervisor?»,

Laboratorio TIC. .

[23] B. O. dice, «¿Qué son los Hipervisores?» .

[24] L. Olmo, «Qué son y cómo funcionan los contenedores virtuales (infografía)»,

TICbeat, 13-sep-2016. [En línea]. Disponible en:

https://www.ticbeat.com/tecnologias/que-son-y-como-funcionan-los-

contenedores-virtuales-infografia/. [Accedido: 10-may-2019].

[25] «¿Qué son los contenedores? Kubernetes, Mesos, Docker...»,

OpenWebinars.net, 24-oct-2016. [En línea]. Disponible en:

https://openwebinars.net/kubernetes-mesos-docker-que-son-los-

contenedores/. [Accedido: 10-may-2019].

[26] «¿Qué es Virtualización basada en contenedores (virtualización a nivel de

sistema operativo)? - Definición en WhatIs.com»,

SearchDataCenter en Español. [En línea]. Disponible en:

https://searchdatacenter.techtarget.com/es/definicion/virtualizacion-basada-

en-contenedores-virtualizacion-a-nivel-de-sistema-operativo. [Accedido: 10-

may-2019].

ANEXOS 71

[27] «¿Qué es un hipervisor? | M2M | NetworkWorld». [En línea]. Disponible en:

https://www.networkworld.es/m2m/que-es-un-hipervisor. [Accedido: 08-may-

2019].

[28] M. Torchiano y M. Morisio, «Overlooked aspects of COTS-based

development», IEEE Softw., vol. 21, n.o 2, pp. 88-93, mar. 2004.

[29] M. Morisio y M. Torchiano, «Definition and Classification of COTS: A Proposal»,

en COTS-Based Software Systems, 2002, pp. 165-175.

[30] «Virtualization benefits: Making the switch to a virtual environment», JAXenter,

26-dic-2018. .

[31] «Standard Virtual Switch Architecture». .

[32] «What is a VMware vSwitch? Learn More in This Post», Official NAKIVO Blog,

17-jul-2018. [En línea]. Disponible en: https://www.nakivo.com/blog/what-is-

vmware-vswitch/. [Accedido: 13-may-2019].

[33] «Open vSwitch», 12-mar-2019. [En línea]. Disponible en:

https://www.openvswitch.org/. [Accedido: 11-mar-2019].

[34] «Globenet International». [En línea]. Disponible en:

https://www.globenetcorp.com/blog/switch-virtualization/. [Accedido: 13-may-

2019].

[35] «Investigación en la AGETIC: El switch virtual libre y el protocolo OpenFlow /

Blog AGETIC». .

[36] «3.1.2.4 VLAN nativas y etiquetado de 802.1Q». [En línea]. Disponible en:

https://static-course-

assets.s3.amazonaws.com/RSE50ES/module3/3.1.2.4/3.1.2.4.html.

[Accedido: 10-jun-2019].

[37] «IEEE 802.1AX-2008 - IEEE Standard for Local and metropolitan area

networks--Link Aggregation». [En línea]. Disponible en:

https://standards.ieee.org/standard/802_1AX-2008.html. [Accedido: 15-may-

2019].

ANEXOS 72

[38] «IEEE 802.1D-1998 - IEEE Standard for Local Area Network MAC (Media

Access Control) Bridges». [En línea]. Disponible en:

https://standards.ieee.org/standard/802_1D-1998.html. [Accedido: 10-jun-

2019].

[39] C. Wang, «OpenvSwitch vs OpenFlow: What Are They, What’s Their

Relationship?», Fiber Transceiver Solution, 14-ago-2018. .

[40] «Open vSwitch: Un ejemplo práctico | News about building Cloud-ready

Infrastructures». [En línea]. Disponible en: http://www.cloudadmins.org/open-

vswitch-un-ejemplo-practico/. [Accedido: 10-may-2019].

[41] N. McKeown et al., «OpenFlow: Enabling Innovation in Campus Networks»,

SIGCOMM Comput Commun Rev, vol. 38, n.o 2, pp. 69–74, mar. 2008.

[42] A. Zhu, «What Is OpenFlow Switch and How Does it Work?», Fiber Optic

Cabling Solutions, 27-jul-2018. .

[43] «Software Defined Networking (SDN) - OpenFlow and OVSDB connection»,

HowtoForge. [En línea]. Disponible en:

https://www.howtoforge.com/tutorial/software-defined-networking-sdn-

openflow-and-ovsdb-connection/. [Accedido: 06-may-2019].

[44] M. Oswalt, «Introduction to Open vSwitch», Keeping It Classless, 07-oct-2013.

[En línea]. Disponible en: https://keepingitclassless.net/2013/10/introduction-to-

open-vswitch/. [Accedido: 06-may-2019].

[45] «What is OVSDB (Open vSwitch Database Management Protocol)? - Definition

from WhatIs.com», SearchNetworking. [En línea]. Disponible en:

https://searchnetworking.techtarget.com/definition/OVSDB-Open-vSwitch-

Database-Management-Protocol. [Accedido: 06-may-2019].

[46] «What is Open vSwitch Database or OVSDB? - Definition», SDxCentral. [En

línea]. Disponible en: https://www.sdxcentral.com/open-

source/definitions/what-is-ovsdb/. [Accedido: 06-may-2019].

ANEXOS 73

[47] «Cisco UCS Virtualized Networking Simplified», 17-oct-2011. [En línea].

Disponible en: https://community.cisco.com/t5/data-center-documents/cisco-

ucs-virtualized-networking-simplified/ta-p/3118573. [Accedido: 10-jun-2019].

[48] «All About Virtual Standard Switch (vSS) in VMWare – Dtechinspiration.com».

.

[49] A. Lambeth y S. Zhou, «Distributed virtual switch for virtualized computer

systems», US8195774B2, 05-jun-2012.

[50] shortpatti, «Hyper-V Virtual Switch». [En línea]. Disponible en:

https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v-virtual-

switch/hyper-v-virtual-switch. [Accedido: 10-jun-2019].

[51] R. Oistacher, «An Introduction to Hyper V Virtual Switch». [En línea]. Disponible

en: https://blog.5nine.com/introduction-hyper-v-virtual-switch. [Accedido: 03-

jun-2019].

[52] «Virtual Switches in Hyper-V: Short Guide», Official NAKIVO Blog, 21-feb-2017.

[En línea]. Disponible en: https://www.nakivo.com/blog/hyper-v-networking-

virtual-switches/. [Accedido: 02-jun-2019].

[53] scooley, «Introduction to Hyper-V on Windows 10». [En línea]. Disponible en:

https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/about/.

[Accedido: 06-may-2019].

[54] «Mininet: An Instant Virtual Network on your Laptop (or other PC) - Mininet».

[En línea]. Disponible en: http://mininet.org/. [Accedido: 10-may-2019].

[55] «Mininet: a versatile tool for emulation and prototyping of Software Defined

Networking». [En línea]. Disponible en:

http://www.scielo.org.co/scielo.php?script=sci_arttext&pid=S1909-

83672015000100009. [Accedido: 10-may-2019].

ANEXOS 74

ANEXOS

Anexo 1 SYMKLOUD.

Altamente escalable y preparado para SDN/NFV. Infraestructura COTS para

radiodifusión. SYMKLOUD es un concepto único de plataforma diseñada para

emitir contenidos a la nube/TI y NFV/SDN.

• 18 microprocesadores Quad-Core Intel i7

• 256GB de Memoria DDR Dual-Channel

Para aplicaciones con cargas de procesos muy elevadas:

• Envío y transcodificación de Vídeo/Contenido

• Big Data/IoT

• Móvil/Telecomunicaciones

• Servicios en la nube

• Hasta 180 transmisiones de vídeo HD 1080p en directo.

• 10 transcodificadores de VoD (Video on Demand) HD fuera de línea en tiempo

real por archivo.

ANEXOS 75

• Dos transmisiones de vídeo 4K HEVC @60p en directo.

Anexo 2 TCS-025-01924-001.

Equipo de prueba automática en las industrias aeroespacial, de defensa y

automotriz. Control de manufactura en los mercados médico y semiconductor.

Número de producto: TCS-025-01924-001.

Marca: Comark.

Familia: Montaje en Rack 3U.

Características:

• Placa base industrial de larga duración.

• Configuración estándar que proporciona un ciclo de vida de más de 5 años.

• Bahías de unidad de disco duro extraíbles.

ANEXOS 76

• E / S estándar y complemento en la tarjeta probada y compatibilidad verificada.

• Configurado a sus requerimientos exactos.

Placa base: TCS-001-01915-001 factor de forma ATX.

CPU: Socket LGA1155, 3ra. o 2º. Generación Intel® Core ™ i7 / i5 / i3, procesadores

Celeron.

Chipset: Intel Q77.

Memoria: 2 x DDR3, 8GB, PC3-10600, 1333MHZ, 240 PIN.

Sistema operativo: MICROSOFT WIN 7 PRO 64-bit instalado.

Gráficos: Gráficos integrados Intel HD.

Ethernet: 1 x Intel® 82579V / LM PHY para AMT 8.0

1 x Intel® 82583V PCI Express Gigabit Ethernet

Soporte de arranque desde LAN (PXE)

2 x RJ45 con LEDs.

Puertos de E / S: 1 x Combo para PS2 KB / MS

1 x DisplayPort

1 x HDMI con doble pila USB 2.0 (negro)

1 x VGA

2 x RJ45 con conectores de doble pila USB 3.0 (azul) y de doble pila USB 2.0

(negro).

ANEXOS 77

Puertos USB: 3.0: 4 puertos (2 x USB3.0 en la E / S de borde, 2 x encabezado

interno)

2.0: 8 puertos (4 x USB2.0 en el borde de E / S, 4 x encabezado interno)

COM: 2 x pila DB9 para COM1 y COM2.

Almacenamiento: 1 x TB, SATA3, 7200 RPM, 64MB CACHE, 3.5 "HDD.

Almacenamiento opcional: 2 x 180Gbyte SATA3.

Unidades extraíbles: 1 x RACK MÓVIL, DISCO DURO DE 2.5 ?, DISCO DUAL,

SATA, SOPORTE, INTERRUPTOR EN CALIENTE, BLOQUEO DE TECLAS.

Unidad óptica: 24X SATA DVD +/- RW Unidad de doble capa – Negro.

Dimensiones: Tamaño (W x H x D): 19.0 "(W) X 17" (L) X 5.25 "(H)

Chasis: Montaje en rack 4U.

Compartimientos del chasis: Externo 1 x 5.25 ", 2 x 3.5", Puerta del

compartimiento de la unidad con cerradura, Interno 2 x 3.5 ".

Puertos del chasis: 2x USB frontal.

Entrada de alimentación: Rango completo 90 ~ 265 VCA (RMS), máx. 12 A (RMS)

a 115 VCA, 6 A (RMS) a 230 VCA, frecuencia de 47 a 63 Hz.

Fuente de alimentación: Fuente de alimentación única de 400 vatios.

Temperatura de funcionamiento: 0ºC ~ 50ºC Temperatura de almacenamiento: -

20ºC ~ 70ºC Humedad: 5% ~ 95%, sin condensación.

ANEXOS 78

Anexo 3 TCS-025-01941-001.

Familia: Montaje en rack 4U.

Número de producto: TCS-001-01941-001

Marca: Comark

Placa base: TCS-001-01896-001 tamaño completo PICMG 1.3.

CPU: Intel Core i7-2600 8M Cache 3.4 Ghz.

Memoria: 2 x 2 Gbyte DDR3 1333 Mhz 240-Pin SIN ECR SDRAM Memoria, doble

canal, soporta hasta 8GB.

Sistema operativo: MICROSOFT WIN 7 PRO 32-bit instalado.

ANEXOS 79

Gráficos: HD integrado en Intel Q77, VGA analógica, DB15. Puerto DVI-D / HDMI /

Display en la cabecera de la placa.

Ethernet: 1 x GLAN, Intel 82579LM, 1 X GLAN Intel 82574I PCI Express, RJ45 en

la placa de E / S.

Puertos de E / S: SATA HDD 6 puertos

4 x SATA 3.0

2 x SATA 2.0

Soporta RAID 0,1,5,10.

Puertos USB: 4 x puertos USB 3.0 (2 en la placa de E / S, 2x encabezado)

4 puertos USB 2.0 incluidos con el sistema: 2 puertos de chasis delanteros, 2 placas

de ranura posterior.

COM: 3 x RS-232, 1 x RS232 / 422/485 Cabecera interna.

Almacenamiento: 2 x 500 Gbytes SATA3 7200 RPM, 16MB CACHE

Discos duros de 3.5 ", uno configurado como unidad del sistema, uno como unidad

de datos.

Unidades extraíbles: 2 discos duros SATA extraíbles, capacidad de intercambio

en caliente, aluminio, grado Mil.


Bahías de unidad: 2 discos duros extraíbles SATA, capacidad de intercambio en

caliente, aluminio, grado Mil.

Placa posterior: TCS-008-01584-001 (PICMG 1.3, 14 SLOT, 7 X PCI, 1 X PICMG

1.3, 5 X PCIex4, 1 x PCIex16).

ANEXOS 80

Dimensiones: Tamaño (ancho x alto x ancho): 19.0 "(ancho) x 19.75" (largo) x 7.0

"(alto) 37 libras.

Chasis: TCS-002-01552-001 Montaje en bastidor de 4U.


compartimiento de la unidad con cerradura, Interno 2 x 3.5 ".


Entrada de alimentación: Rango completo 90 ~ 265 VCA (RMS), máx. 12 A (RMS)

a 115 VCA, 6 A (RMS) a 230 VCA, frecuencia de 47 a 63 Hz.

Fuente de alimentación: Fuente de alimentación conmutada ATX12V de 600

vatios, eficiencia mínima del 82%, corrección activa del factor de potencia (PFC),

cumple con EN61000-3-2.


20ºC ~ 70ºC Humedad de funcionamiento: 10% ~ 90%, sin condensación Humedad

de almacenamiento: 10% ~ 90%, sin condensación.

ANEXOS 81

Anexo 4 TCS-025-01955-001.

Familia: Montaje en Rack 4U.

Número de producto: TCS-025-01955-001.

Marca: Comark.

Placa base: TCS-001-01943-001.

CPU: Intel Core i7-2600 8MB Cache 3.4 Ghz, LGA1155 - 4ta generación

incorporada.

Chipset: Intel Q77.

Memoria: 2 x 2 Gbyte DDR3 1600 Mhz 240-Pin SDCAM SIN ECC Memoria, doble

canal.

Sistema operativo: Microsoft Windows 7 Pro 64-bit.

ANEXOS 82

Gráficos: Gráficos integrados Intel HD.

Ethernet: NA.

Puertos de E / S: 2 x SATA-600 y 4 x SATA-300, con RAID 0/1/5/10.

Puertos USB: 10 x USB 2.0, 4 x USB 3.0.

COM: 1 x RS-232 (COM 2)

1 x RS-232/422/425 (COM 1).

Almacenamiento: 2 x 500 Gbytes SATA3 7200 RPM, 16MB CACHE, 3.5 "HDD.


Placa posterior: TCS-008-01588-001.

Tamaño (ancho x alto x ancho): 19.0 "(ancho) x 19.75" (largo) x 7.0 "(alto) 37 libras

Chasis: TCS-002-01552-001 Montaje en bastidor de 4U.


compartimiento de la unidad con cerradura, Interno 2 x 3.5.


Consumo de energía: Rango completo 90 ~ 265 VCA (RMS), máx. 12 A (RMS) a

115 VCA, 6 A (RMS) a 230 VCA, frecuencia de 47 a 63 Hz.

Fuente de alimentación: Fuente de alimentación conmutada ATX12V de 600

vatios, eficiencia mínima del 82%, corrección activa del factor de potencia (PFC),

cumple con EN61000-3-2.


20ºC ~ 70ºC Humedad: 10% ~ 90%, sin condensación.

ANEXOS 83

Anexo 5 Comandos para la instalación del OVS.

Primer método:

Primeramente, se instalan las dependencias:

Ahora se procede a instalar el OVS desde los propios repositorios para Linux:

Se configura la base de datos:

Segundo método:

O, en este caso se descarga desde la fuente, se descomprime y se accede a la

carpeta donde está ubicado el archivo:

Ahora se procede a instalar OVS:

ANEXOS 84

Ahora, al igual que en el método anterior, se procede a configurar la base de datos:

Para iniciar el servicio:

Se crea una interfaz puente para permitir la comunicación:

Se incorpora dicho puente a un puerto ethernet:

Y, por último, se configura la interfaz el puente:

Análisis de la virtualización de conmutadores virtuales en ...

Documents

Transcript of Análisis de la virtualización de conmutadores virtuales en ...