Arquitectura de balanceo de carga dinámico para la lógica de conmutación EtherChannel

PONTIFICIA UNIVERSIDAD JAVERIANA

Arquitectura de balanceo de carga dinámico

para la lógica de conmutación EtherChannel

Jaime Alejandro Carlos Navarro

Pontificia Universidad Javeriana

Facultad de Ingeniería

Bogotá, Colombia

Arquitectura de balanceo de carga dinámico

para la lógica de conmutación EtherChannel

Jaime Alejandro Carlos Navarro

Tesis en modalidad Profundización presentada como requisito parcial para optar por el título de:

Magister en Ingeniería Electrónica con énfasis en Telecomunicaciones

Director:

Ing. LUIS CARLOS TRUJILLO ARBOLEDA, M.Sc.

Línea de Investigación:

Redes y Sistemas de Telecomunicaciones

Pontificia Universidad Javeriana

Facultad de Ingeniería

Bogotá, Colombia

NOTA DE ACEPTACIÓN

______________________________________________________

______________________________________________________

______________________________________________________

_____________________________________________

Director del proyecto

________________________________________

Jurado

________________________________________

Jurado

Resumen

El uso eficiente de la infraestructura de conmutación es un aspecto crítico en los objetivos de administración de red de las empresas que proveen servicios de comunicación masivos y de transporte de datos. Ciertamente las necesidades crecientes de ancho de banda están conduciendo el desarrollo y estandarización de nuevas tecnologías LAN y WAN del tipo Ethernet. Sin embargo, los entes de estandarización como IEEE reconocen que la tendencia del mercado siempre conducirá a mayores anchos de banda; y en cierto grado a aumentar la penetración de tecnologías existentes como 40Gigabit Ethernet y disminuir los costos actuales de despliegue 100Gigabit Ethernet. Cisco ha desarrollado una tecnología llamada EtherChannel cuyo objetivo es asistir a los usuarios en el crecimiento de la infraestructura de conmutación Ethernet de acuerdo a necesidades puntuales optimizando las inversiones relacionadas con el proceso (capex de infraestructura). Las implementaciones basadas en EtherChannel posibilitan una mejor explotación de la infraestructura existente agregando hasta ocho enlaces Ethernet del tipo FastEthernet, Gigabit Ethernet o 10Gigabit Ethernet en un canal lógico con un ancho de banda potencial de hasta 160Gbps full dúplex. El método de asignación de carga de esta tecnología se conoce como Hashing de Bits el cual localiza tráfico en los enlaces que hacen parte del canal agregado de acuerdo a un análisis de patrones binarios de la cabecera de los paquetes, sin tener en cuenta la ocupación en esos medios, aspecto que localiza a este método en el grupo de algoritmos de asignación de carga estáticos. La dependencia del desempeño del método en mención con los patrones de tráfico, naturaleza de las aplicaciones y nuevas tendencias en los servicios de red conlleva a una utilización desbalanceada del canal lógico por parte del método. Este trabajo aborda la consideración de un método de asignación de carga dinámico para la utilización de múltiples enlaces de comunicaciones en el marco de la tecnología EtherChannel, por medio del diseño y propuesta de una arquitectura de conmutación orientada a mejorar la utilización global del grupo de interfaces agregadas, la medición del desempeño, así como la detección temprana y reacción proactiva ante condiciones de tráfico en ráfaga de manera que pueda optimizarse el nivel de utilización del canal lógico y se extienda la vida útil de la infraestructura. Los resultados de este trabajo pretenden ser un soporte para futuras investigaciones orientadas a optimización de los métodos considerados, simulación con infraestructura Ethernet e implementaciones en plataformas hardware.

Abstract

The efficient deployment of the switching network infrastructure is a critical fact in the network management objectives of the enterprises that provide massive customers and data transport communication services. Indeed, the bandwidth growing needs are driving the development and standardization of the LAN/WAN Ethernet technologies. However, standardization bodies like IEEE recognize that market trends will ever drive towards more bandwidth; and, in some degree, to increase the existing network technologies penetration like 40Gigabit Ethernet, and to reduce the current 100Gigabit Ethernet unfolding costs. Cisco has developed a network technology called EtherChannel whose objective is to assist customers in the Ethernet switching infrastructure growing according to specific needs optimizing the investments related to the mentioned process (infrastructure capex). EtherChannel-based deployments make possible a better use of the existing infrastructure bundling up to 8 Ethernet links FastEthernet, Gigabit Ethernet or 10Gigabit Ethernet in a logical link with a potential bandwitdh up to full duplex 160Gbps. The EtherChannel´s load allocation method is known as Bits Hashing which allocates traffic into the links that are part of the aggregate channel according to a bit pattern analysis of the packet´s headers without take into account the links utilization, fact that locates this method into static load allocation algorithms group. The Bits Hashing method dependency with traffic patterns, applications nature and new network services trends leads to an unbalanced utilization to the logical channel. This work tackles the consideration of a dynamic load allocation method for the utilization of multiple communication links framed under EtherChannel technology, by means of the design and proposal of a switching architecture oriented to getting better the global utilization of the bundled links group, performance measurement as well as early detection and proactive reaction to burst traffic conditions so that logical channel utilization level can be optimized and it could be possible to extend the network infrastructure life cycle. The work results expect to be a technical support for future researches oriented to optimization of the methods taken into account, Ethernet infrastructure simulation, and hardware platforms deployments.

CONTENIDO

Resumen ... I

Abstract ... II CONTENIDO ... III LISTA DE FIGURAS ... VI

LISTA DE TABLAS ... XII LISTA DE TÉRMINOS Y ABREVIATURAS ... XIII

INTRODUCCIÓN ... 1

Descripción del Problema - Justificación ... 3

Objetivo General ... 7

Objetivos Específicos (Alcance) ... 7

Limitantes y Exclusiones (Alcance) ... 8

Organización del Documento ... 8

1.MARCO TEÓRICO ... 9

1.1 TECNOLOGÍA DE CONMUTACIÓN ETHERCHANNEL ... 9

1.2 CONCEPTOS SOBRE SIMULACIÓN ...11

1.2.1 MODELADO DE RED E INTRODUCCIÓN A LA SIMULACIÓN ...11

1.2.2 CLASIFICACIÓN DE LOS SIMULADORES ...13

1.3 INTRODUCCIÓN AL SIMULADOR OPNET ...14

1.3.1 SUITE DE APLICACIONES OPNET ...14

1.3.2 OPNET MODELER ...15

2.ESPECIFICACIONES ... 18

2.1 PRESENTACIÓN DE ARQUITECTURA PROPUESTA ...18

2.2 ESPECIFICACIÓN OPERATIVA DE LA ARQUITECTURA ...19

2.3 ESPECIFICACIÓN MODULAR DE LA ARQUITECTURA ...20

2.3.1 Módulo SWFabric_Processor...20

2.3.2 Módulo StatisticsPoller ...21

2.3.4 Módulo SM_Reqs_Queue ...23

2.3.5 Módulo EtherChannel_HA_Algorithm ...24

2.3.6 Módulo WeightsLoad_Settings ...25

2.3.7 Módulos Collector ...26

2.3.8 Conjunto de Módulos SM_Ctrl_Switch _– RoundRobin Scheduler _– RoundRobin Deficit .28 3.DESARROLLOS ... 32

3.1 IMPLEMENTACIÓN DE NODO DE CONMUTACIÓN EN OPNET MODELER ...32

3.2 VALIDACIÓN DEL MODELO DE NODO EN OPNET ...34

3.2.1 Módulo LeastLoad_Analysis ...35

3.2.2 Módulo SM_Reqs_Queue ...38

3.2.3 Módulo EtherChannel_HA_Algorithm ...38

3.2.4 Módulo SWFabric_Processor...41

3.2.5 Módulo StatisticsPoller ...42

3.2.6 Módulo WeightsLoad_Settings ...42

3.2.7 Módulos SM_Ctrl_Switch – RoundRobin Scheduler – RoundRobin Deficit ...42

3.2.8 Módulos Collector ...44

3.2.9 Estadísticas programadas ...45

4.ANALISIS DE RESULTADOS ... 46

4.1 PLAN DE SIMULACIONES DEL PROYECTO ...46

4.1.1 Modelo de Tráfico de Entrada ...46

4.1.2 Definición de Estadísticas y Parametrización del Modelo de Red ...47

4.2 EJECUCIÓN DE PLAN DE SIMULACIONES _– ANÁLISIS DE RESULTADOS ...49

4.2.1 Análisis de resultados Simulación No. 1 (Método Hashing de Bits > src-ip) ...49

4.2.2 Análisis de resultados Simulación No. 1 (Método Hashing de Bits > dst-ip) ...50

4.2.3 Análisis de resultados Simulación No. 1 (Método Hashing de Bits > src-dst-ip) ...51

4.2.4 Análisis de resultados Simulación No. 2 ...53

4.2.5 Análisis de resultados Simulación No. 3 ...56

4.2.6 Análisis de resultados Simulación No. 4 ...59

5.CONCLUSIONES ... 66

6.BIBLIOGRAFÍA ... 71

7.ANEXOS... 72

Anexo A: PROCESO DE VALIDACIÓN DEL MÓDULO “SM_REQS_QUEUE” ...72

Anexo B: PROCESO DE VALIDACIÓN DEL MÓDULO “SWFABRIC_PROCESSOR” ...75

Anexo C: PROCESO DE VALIDACIÓN DEL MÓDULO “STATISTICSPOLLER” ...77

Anexo D: PROCESO DE VALIDACIÓN DEL MÓDULO “WEIGHTSLOAD_SETTINGS” ...79

Anexo E: PROCESO DE VALIDACIÓN DE MÓDULOS “SM_CTRL_SWITCH”-“ROUNDROBIN SCHEDULER”-“CONJUNTO ROUNDROBIN DEFICIT” ...83

LISTA DE FIGURAS

LISTA DE FIGURAS

Figura 1. Proyecciones de demanda de ancho de banda del IEEE 802.3 HSSG: ... 1

Figura 2. Comportamiento Diario Interfaz Gi0/15 THDPCB (Cisco3400) – THDPolo1 (Cisco7600): .... 4

Figura 3. Comportamiento Diario Interfaz Gi0/13 THDPCB (Cisco3400) – THDPolo1 (Cisco7600): .... 4

Figura 4. Comportamiento Diario PortChannel Po1 THDPCB (Cisco3400) - THDPolo1 (Cisco7600): .. 4

Figura 5. Delta Tráfico Inbound – Outbound interfaces participantes EtherChannel THDPCB (Cisco3400) – THDPolo1 (Cisco7600): ... 4

Figura 6. Comportamiento en una base horaria Interfaz EtherChannel Po3 THBGoliat (Cisco7606) – THBSuba2 (Cisco6500): ... 5

Figura 7. Comportamiento en una base diaria Interfaz EtherChannel Po3 THBGoliat (Cisco7606) – THBSuba2 (Cisco6500): ... 5

Figura 8. Comportamiento en una base semanal Interfaz EtherChannel Po3 THBGoliat (Cisco7606) – THBSuba2 (Cisco6500): ... 5

Figura 9. Ambiente de simulación para el modelado de comportamiento y desempeño de los diferentes algoritmos de balanceo de carga: ... 6

Figura 10. Canal lógico EtherChannel entre dos plataformas de conmutación Cisco: ... 9

Figura 11. Diagrama de Flujo de la Simulación basada en Tiempo:... 13

Figura 12. Diagrama de Flujo de la Simulación basada en Eventos Discretos: ... 14

Figura 13. Editor de Proyectos de OPNET Modeler: ... 16

Figura 14. Editor de Nodos de OPNET Modeler: ... 16

Figura 15. Editor de Procesos de OPNET Modeler: ... 16

Figura 16. Diagrama de bloques de arquitectura modificada del nodo de conmutación propuesto con especificación de señales unidireccionales y señalización de control: ... 18

Figura 17. Arquitectura propuesta operando en Modo Normal: ... 19

Figura 18. Arquitectura propuesta operando en Modo Recuperación: ... 20

Figura 19. Las operaciones de gestión de tráfico inbound son controladas por un multiplexor estadístico de salida y una cola atendida a una tasa específica, lo cual propone un modelo de módulo “SwitchFabric_Processor” conmutando tráfico outbound exclusivamente: ... 20

Figura 20. Topología estrella entre los módulos “Collector” y el módulo “StatisticsPoller”: ... 21

Figura 21. Señalización considerada en el modelo de nodo de la arquitectura propuesta: ... 24

Figura 22. Ilustración de la operación del conjunto “RRD Algorithm”. La subcola q_7 controla el inicio y finalización del recorrido de las subcolas durante el modo Recuperación: ... 28

Figura 23. Diagrama de bloques del módulo “SM_Ctrl_Switch”: ... 28

Figura 24. Modelo de nodo diseñado en OPNET Modeler para la arquitectura propuesta del nodo de conmutación: ... 32

Figura 26. Modelo de red de subred 0 con 8 estaciones de trabajo que generan tráfico TCP/IP: ... 33

Figura 27. Modelo de red de subred 1 con 8 estaciones de trabajo que generan tráfico TCP/IP: ... 33

Figura 28. Exposición de parametrización de generadores de entidades TCP/IP en el modelo de red OPNET: ... 34

Figura 29. Parametrización de la operación del nodo EtherChannelADV_X en el modelo de red OPNET: ... 34

Figura 30. Modelo de Proceso OPNET del módulo “LeastLoad Analysis”: ... 35

Figura 31. Modelo de Nodo para validación del módulo “LeastLoad Analysis”: ... 35

Figura 32. Flujo de mensajes y señalización esperada para la operación del módulo “LeastLoad Analysis”: ... 35

Figura 33. Señalización involucrada en la operación del módulo “LeastLoad Analysis”: ... 35

Figura 34. Contenido de los vectores de prueba que consolidan los valores promedio de tráfico para el grupo de ocho interfaces: ... 36

Figura 35. Flujo de paquetes de prueba durante la simulación controlada: ... 36

Figura 36. Contenido del paquete ID 91: ... 36

Figura 37. Contenido del paquete ID 90: ... 36

Figura 38. Paquete ID 92 resultado de la operación del módulo “LeastLoad Analysis”: ... 36

Figura 39. Contenido del paquete ID 92: ... 36

Figura 40. Flujo de paquetes de prueba durante la simulación controlada: ... 37

Figura 41. Contenido del paquete ID 64: ... 37

Figura 42. Contenido del paquete ID 63: ... 37

Figura 43. Paquete ID 65 resultado de la operación del módulo “LeastLoad Analysis”: ... 37

Figura 44. Contenido del paquete ID 65: ... 37

Figura 45. Modelo de Proceso OPNET del módulo “SM_Reqs_Queue”: ... 38

Figura 46. Modelo de Proceso OPNET del algoritmo Hashing de Bits de EtherChannel: ... 38

Figura 47. Modelo de Red para validación del modelado del algoritmo de asignación de carga de EtherChannel: ... 39

Figura 48. Modelo de Nodo en el cual fue aislado el módulo “EtherChannel_HA_Algorithm” objeto de validación: ... 39

Figura 49. Direcciones IP origen y destino asignadas al generador de tráfico para fines de construcción de las entidades IP: ... 39

Figura 50. Parametrización del módulo “EtherChannel_HA_Algorithm”: ... 39

Figura 51. Flujo de paquetes hacia el módulo “EtherChannel_HA_Algorithm” durante validación: ... 40

Figura 52. Mensajes de simulación para el paquete ID 5 que confirman direcciones IP y el contenido del campo “ici_id” con el índice de la interfaz: ... 40

Figura 53. Parametrización del módulo “EtherChannel_HA_Algorithm”: ... 40

Figura 54. Flujo de paquetes hacia el módulo “EtherChannel_HA_Algorithm” durante validación: ... 40

LISTA DE FIGURAS

Figura 56. Parametrización del módulo “EtherChannel_HA_Algorithm”: ... 41

Figura 57. Mensajes de simulación que confirman direcciones IP para un paquete procesado y el campo “ici_id” con el índice de lainterfaz “5”: ... 41

Figura 58. Modelo de Proceso OPNET para el módulo “SWFabric_Processor”:... 41

Figura 59. Modelo de Proceso OPNET para el módulo “StatisticsPoller”: ... 42

Figura 60. Modelo de Proceso OPNET para el módulo “WeightsLoad_Settings”: ... 42

Figura 61. Modelo de Proceso OPNET para el módulo “SM_Ctrl_Switch”: ... 42

Figura 62. Modelo de nodo de conmutación donde se destaca el conjunto modular que implementa el algoritmo RRD (“SM_Ctrl_Switch” –“RoundRobin_Scheduler” –“Conjunto RoundRobin_Deficit”): . 43 Figura 63. Modelo de Proceso OPNET para el módulo de subcola q_0 – q_6: ... 44

Figura 64. Modelo de Proceso OPNET para el módulo de subcola q_7: ... 44

Figura 65. Modelo de Proceso OPNET para el módulo “Collector”: ... 44

Figura 66. Estadística “Estado de Sistema”: ... 45

Figura 67. Estadística “Retardo de Procesamiento Nodal”: ... 45

Figura 68. Plan de Simulaciones del Proyecto: ... 48

Análisis de resultados Simulación No. 1 (Método Hashing de Bits > src-ip) Figura 69. Ocupación Outbound promedio de enlaces de salida: ... 49

Figura 70. Frecuencias para observaciones de tráfico saliente: ... 49

Figura 71. Ocupación Inbound promedio de enlaces de salida: ... 49

Figura 72. Frecuencias de observaciones de tráfico entrante: ... 49

Figura 73. Retardo de Procesamiento Nodal: ... 50

Figura 74. CDF Retardo de Procesamiento Nodal: ... 50

Análisis de resultados Simulación No. 1 (Método Hashing de Bits > dst-ip) Figura 75. Ocupación Outbound promedio de enlaces de salida: ... 50

Figura 76. Frecuencias para observaciones de tráfico saliente: ... 50

Figura 77. Ocupación Inbound promedio de enlaces de salida: ... 51

Figura 78. Frecuencias de observaciones de tráfico entrante: ... 51

Análisis de resultados Simulación No. 1 (Método Hashing de Bits > src-dst-ip) Figura 79. Ocupación Inbound promedio de enlaces de salida: ... 51

Figura 80. Frecuencias de observaciones de tráfico entrante: ... 51

Figura 81. Ocupación Outbound promedio de enlaces de salida: ... 52

Figura 82. Frecuencias de observaciones de tráfico saliente:... 52

Figura 83. Retardo de Procesamiento Nodal: ... 52

Análisis de resultados Simulación No. 2

Figura 85. Ocupación Outbound promedio de enlaces de salida (Alpha 25%): ... 53

Figura 86. Estadística – Estado de Sistema (Alpha 25%): ... 53

Figura 87. Frecuencias de observaciones de tráfico saliente (Alpha 25%): ... 53

Figura 88. Ocupación Inbound promedio de enlaces de salida (Alpha 25%):………..54

Figura 89. Diagrama de Frecuencias de observaciones de tráfico Inbound (Alpha 25%): ... 54

Figura 90. Retardo de Procesamiento Nodal (Alpha 25%): ... 54

Figura 91. CDF Retardo de Procesamiento Nodal (Alpha 25%): ... 54

Figura 92. Ocupación Outbound promedio de enlaces de salida antes de modificación (Alpha 25%):... 55

Figura 93. Ocupación Outbound promedio de enlaces de salida después de modificación (Alpha 25%): 55 Figura 94. Diagrama de Frecuencias de observaciones de tráfico saliente post modificación (Alpha 25%): ... 55

Figura 95. Estadística – Estado de Sistema (Alpha 25%): ... 55

Figura 96. Ocupación Inbound promedio de enlaces de salida antes de modificación (Alpha 25%): ... 55

Figura 97. Ocupación Inbound promedio de enlaces de salida después de modificación (Alpha 25%): ... 55

Figura 98. Diagrama de Frecuencias de observaciones de tráfico entrante (Alpha 25%): ... 56

Figura 99. Comparación entre CDFs Retardo de Procesamiento Nodal antes (azul) y después (rojo) de modificación propuesta (Alpha 25% - Escala X logarítmica): ... 56

Análisis de resultados Simulación No. 3 Figura 100. Ocupación Outbound promedio de enlaces de salida antes de modificación (Alpha 15%):... 56

Figura 101. Ocupación Outbound promedio de enlaces de salida post modificación (Alpha 15%): ... 56

Figura 102. Diagrama de Frecuencias de observaciones de tráfico Outbound (Alpha 15%): ... 57

Figura 103. Diagrama de frecuencias de observaciones de tráfico Outbound post modificación (Alpha 15%): ... 57

Figura 104. Ocupación Inbound promedio de enlaces de salida antes de modificación (Alpha 15%): ... 57

Figura 105. Ocupación Inbound promedio de enlaces de salida después de modificación (Alpha 15%): . 57 Figura 106. Diagrama de Frecuencias de observaciones de tráfico entrante pre modificación (Alpha 15%): ... 57

Figura 107. Diagrama de Frecuencias de observaciones de tráfico entrante post modificación (Alpha 15%): ... 57

Figura 108. Est. Estado de Sistema (pre modificación) (Alpha 15%): ... 58

Figura 109. Est. Estado de Sistema (post modificación) (Alpha 15%): ... 58

Figura 110. Retardo de Procesamiento Nodal pre modificación (Alpha 15%): ... 58

LISTA DE FIGURAS

Figura 112. Ocupación Outbound promedio de enlaces de salida antes de modificación (Alpha 5%):... 59 Figura 113. Ocupación Outbound promedio de enlaces de salida después de modificación (Alpha 5%): 59 Figura 114. Diagrama de Frecuencias de observaciones de ocupación Outbound antes de modificación (Alpha 5%): ... 59 Figura 115. Diagrama de Frecuencias de observaciones de ocupación Outbound después de modif. (Alpha 5%): ... 59 Figura 116. Diagrama de Frecuencias de observaciones de ocupación Inbound pre modificación (Alpha 5%): ... 59 Figura 117. Diagrama de Frecuencias de observaciones de ocupación Inbound post modificación (Alpha 5%): ... 59 Figura 118. Retardo de Procesamiento Nodal pre modificación (Alpha 5%): ... 59 Figura 119. Comparación entre CDFs Retardo de Procesamiento Nodal pre (azul) _– post (verde) modificación (Alpha 5%): ... 59 Figura 120. Estadística _– Estado de Sistema (pre modificación): ... 60 Figura 121. Estadística – Estado de Sistema (post modificación): ... 60

Análisis de resultados Simulación No. 4 (con perturbaciones)

Figura 136. Estadística Estado de Sistema Escenario con Perturbaciones antes de modificación (Alpha 15%): ... 63 Figura 137. CDF Retardo de Procesamiento Nodal (Alpha 15%): ... 63 Figura 138. Estadística Estado de Sistema Escenario con Perturbaciones antes de modificación (Alpha 5%): ... 63 Figura 139. CDF Retardo de Procesamiento Nodal (Alpha 5%): ... 63

Análisis de resultados Simulación No. 5

LISTA DE TABLAS

LISTA DE TABLAS

LISTA DE TÉRMINOS Y ABREVIATURAS

LISTA DE TÉRMINOS Y ABREVIATURAS

Término/Abrev. Descripción

IDC International Data Corporation (Empresa líder en proyección, análisis e investigación de mercados especializada en tecnologías de consumo, información y de telecomunicaciones).

IEEE Institute of Electrical and Electronics Engineers (Instituto de Ingenieros Eléctricos y Electricistas).

HSSG IEEE 802.3 Higher Speed Study Group (Grupo de Estudio de Mayor Velocidad 802.3 del IEEE).

Network Core Núcleo de Red (Permite enlazar diferentes servicios como Internet, redes privadas, redes LAN o telefonía, entre otros).

Streaming (Método de transmisión y reproducción de archivos de audio y video por lotes).

P2P Network Redes Punto a Punto (Son redes de computadoras en la que todos o algunos aspectos funcionan sin clientes ni servidores fijos, sino una serie de nodos que se comportan como iguales entre sí).

QoS Quality of Service (Calidad de Servicio).

Capex Capital Expenditures (Gastos Capitales).

FastEthernet (Tecnología de red LAN basada en IEEE 802.3 con velocidad 100Mbps).

GigabitEthernet (Tecnología de red LAN basada en IEEE 802.3 con velocidad 1Gbps).

10Gigabit Ethernet (Tecnología de red LAN basada en IEEE 802.3 con velocidad 10Gbps).

LAN Local Area Network (Red de Área Local).

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

EtherChannel (Tecnología propietaria Cisco para agregar enlaces físicos IEEE 802.3 en canales lógicos).

HP-UX (HP-UX es la versión de Unix desarrollada y mantenida por Hewlett-Packard desde 1983, ejecutable típicamente sobre procesadores HP PA RISC y, en sus últimas versiones, Intel Itanium (arquitectura Intel de 64 bits)).

Hashing de Bits (Método de asignación de carga estático soportado en la tecnología EtherChannel).

Throughput Rendimiento (Se llama throughput al volumen de trabajo o de información que fluye a través de un sistema).

SNMP Simple Network Management Protocol (Protocolo de Gestión de Red Simple).

NetFlow (Protocolo de gestión de red propietario Cisco).

IP Internet Protocol (Protocolo Internet).

Overhead Carga (Se refiere, en el campo de las telecomunicaciones, al tiempo de procesamiento requerido por el código o su implementación para chequeo de errores y control de transmisiones de información).

DMZ Demilitarized Zone (Zonas Desmilitarizadas).

Proxy Proxy (En una red informática, es un programa o dispositivo que realiza una acción en representación de otro).

Firewall Cortafuego (Es una parte de un sistema o una red que está diseñada para bloquear servicios de red y accesos no autorizados).

UDP User Datagram Protocol (Protocolo de Datagramas de Usuario).

TCP Transport Control Protocol (Protocolo de Control de Transporte).

RTP/RTCP Real Time Transport Protocol / Real Time Transport Control Protocol (Protocolo de Transporte en Tiempo Real / Protocolo de Control de Transporte en Tiempo Real).

Jitter Fluctuación (Variación indeseada y abrupta de la propiedad de una señal).

Packet Loss Pérdida de Paquetes.

Round Robin Round Robin (Método de Asignación de Carga).

Weighted Round R. Round Robin Ponderado (Método de Asignación de Carga).

Random Aleatorio (Método de Asignación de Carga).

Least Connection Menor Conexión (Método de Asignación de Carga).

Least Load Menor Carga (Método de Asignación de Carga)

PagP Port aggregation Protocol (Protocolo de Agregación de Puertos).

LACP Link Aggregation Control Protocol (Protocolo de Control de Agregación de Enlaces, definido en el estándar IEEE 802.3ad).

OPNET OPtimized NETwork Engineering Tools (Herramientas de Ingeniería de Red Optimizadas).

DES Discrete Event Simulation (Simulación de Eventos Discretos).

INTRODUCCIÓN

La demanda de ancho de banda continúa creciendo a nivel mundial. Independientemente de la aceptación de las proyecciones de Cisco o de otras compañías consultoras como IDC, la realidad es que el tráfico está creciendo y deberían adecuarse las redes de acceso y de interconexión con altas velocidades y capacidad. En general, la mejora en el desempeño de una infraestructura Ethernet puede darse con el incremento de sus capacidades en ancho de banda. El nivel de adecuación de la infraestructura no es un aspecto claro pero lo que parece ser evidente es que cuando este aspecto corresponde al incremento de las velocidades Ethernet, la conclusión es que los operadores parecen demandar más velocidades sin considerar el factor de costos de despliegue y mantenimiento, aun cuando claman rápidamente por la estandarización [1]. Para 2007, año del nacimiento del IEEE 802.3 HSSG, hubo intenso debate acerca de la necesidad de enfocar los esfuerzos en el desarrollo de dos velocidades Ethernet para satisfacer necesidades futuras [2]. Finalmente fue acordado que el tráfico de core y de las aplicaciones de computación estaban creciendo a ratas distintas. Así, se observó que, en promedio, el ancho de banda asociado con el networking de core

estaba doblando sus requerimientos cada 18 meses; mientras que la capacidad en ancho de banda asociada con servidores de alto volumen x86 y aplicaciones de computación estaba doblándose cada 24 meses [3]. En la Figura 1 se presentan esas observaciones que condujeron al desarrollo de las tecnologías 40 Gigabit Ethernet y 100 Gigabit Ethernet por parte del IEEE 802.3ba Task Force. Sin embargo, estas proyecciones también llevaron al HSSG a trabajar en el desarrollo de la siguiente velocidad de Ethernet requerida una vez el estándar 100 Gigabit Ethernet fuera terminado. De acuerdo con [2], esta necesidad es corroborada en las proyecciones de la Figura 1, con Ethernet 400Gbps requerida para 2013 (Estado del Arte de esta tecnología) y 1Tbps para 2015.

Figura 1. Proyecciones de demanda de ancho de banda del IEEE 802.3 HSSG. Tomado de IEEE 802.3 Industry Connections Ethernet Bandwidth Assessment.

potencialmente limitaría su penetración en el mercado. Así las cosas, según [1] para 2013 los principales esfuerzos no van dirigidos hacia 400Gbps o 1Tbps; más a hacer de 100Gbps una solución económicamente atractiva.

De acuerdo con [2], es proyectado que para 2015 habrá cerca de 15 billones de dispositivos de red fijos y móviles, así como conexiones máquina a máquina. La tendencia a ofrecer más y mejores prestaciones en ancho de banda de acceso y la disponibilidad de dispositivos de usuario de banda ancha propone un escenario en el cual los usuarios estarán constantemente consumiendo ancho de banda posiblemente en múltiples dispositivos simultáneamente. A su vez, cada uno de estos dispositivos soporta múltiples aplicaciones con tráficos importantes y requerimientos de calidad de servicio especiales. Hoy, las aplicaciones multimedia e intranet con necesidades incrementales de ancho de banda conducen la demanda de más y más recurso, mientras que las aplicaciones de misión crítica requieren diseños de red que ofrezcan alta disponibilidad. Así, la demanda de recursos de red por parte de aplicaciones de redes sociales, streaming de audio y video en tiempo real y contenido almacenado, así como de intercambio de archivos P2P, crece a ratas superiores al incremento de disponibilidad de recursos en el core. Tales aplicaciones son en cierto grado dependientes de la calidad de servicio, de manera que la administración de QoS se convierte con su consideración en una mejor solución a la intervención de la infraestructura de muchas redes a nivel mundial [4]. En lugar de considerar ítems en capex asociados al incremento de ancho de banda en el core de la red, la administración de red debe contemplar cuidadosamente los aspectos de QoS necesarios de manera que la gestión de tráfico se vuelva más robusta y la clave de la calidad de servicio de red [5]. Por otra parte, las empresas que han venido enfrentando este desafío con empleos incrementales de Ethernet conmutado en el escritorio, están buscando soluciones de mayor ancho de banda para el core que las capacidades ofrecidas por la tecnología FastEthernet o Gigabit Ethernet. Las soluciones implementadas hoy necesitan proteger las inversiones existentes, mientras provean una trayectoria de migración estable hacia anchos de banda 10Gigabit Ethernet y posteriores [6].

Acerca de la tecnología de conmutación LAN Ethernet, cuya especificación reside en el estándar IEEE 802.3, permite la utilización de enlaces con anchos de banda 10Mbps (Ethernet), 100Mbps (FastEthernet), 1Gbps, 10Gbps, 40Gbps y 100Gbps para soportar diferentes requerimientos de conectividad [7]. En lo referente a sus estrategias de escalamiento de ancho de banda, Cisco ha ampliado el alcance del estándar en sus plataformas y ofrece un método propietario para escalar el ancho de banda Ethernet entre equipos de conmutación por medio del uso simultáneo de múltiples enlaces sin necesidad de recurrir a la actualización tecnológica asociada al cambio de interfaces de velocidad superior [7]. Este método es conocido como EtherChannel, el cual posibilita un ancho de banda agregado, la compartición de carga de tráfico entre los enlaces del canal, así como redundancia en el evento que uno o más enlaces físicos fallen. Hoy, esta tecnología puede ser usada para interconectar muchos conmutadores LAN, enrutadores, servidores y clientes de otros fabricantes por medio de cableado UTP o fibras monomodo o multimodo [8]. A título de ejemplo, Hewlett Packard soporta actualmente la característica Fast EtherChannel en su línea de conmutadores HP1600 y HP8000. Es su vez soportada en múltiples plataformas de sistema operativo y productos LAN, incluyendo HP-UX versión 11.0 y posteriores, y un número selecto de NICs FastEthernet HP9000 [6].

en detalle en el capítulo Marco Teórico). Si el crecimiento de ancho de banda conduce a una utilización del enlace EtherChannel cuyo valor de nuevo empieza a superar los umbrales de decisión, la administración de red puede ya con seguridad tomar la decisión de migrar hacia la siguiente versión de Ethernet (1Gbps Ethernet – 2Gbps de ancho de banda full dúplex). En conclusión, esta tecnología conduce a un manejo estable y proyectado del capex requerido para infraestructura de interconexión interna y externa.

Esta tecnología utiliza un método de asignación de carga a los medios participantes del canal EtherChannel denominado Hashing de Bits el cual verifica ciertos bits en las diferentes cabeceras de los paquetes que están buscando asignación en el grupo de enlaces de salida. Respecto a la clasificación de este método, la asignación de paquetes en el canal lógico no contempla la valoración de la ocupación de los medios, recurriendo entonces exclusivamente a la información de los paquetes para arbitrar la asignación, lo que localiza al Hashing de Bits entre los algoritmos de balanceo de carga estáticos. Así, el algoritmo de EtherChannel no está en capacidad de capturar información de tráfico sobre las interfaces participantes del método y a partir de su ocupación generar proactiva y reactivamente acciones sobre su configuración para balancear las cargas de tráfico.

Por estas razones esta tesis de grado se concentra en el diseño y evaluación de una arquitectura de conmutación para la tecnología EtherChannel con capacidad de asignación dinámica de carga de manera que pueda ofrecer un mejor escenario de utilización de los enlaces participantes del método, una gestión de las condiciones de tráfico, así como una base teórico-experimental para futuros trabajos relacionados con optimización de la arquitectura y evaluación en ambientes en producción.

Descripción del Problema - Justificación

Algunos aspectos operativos de la tecnología EtherChannel impiden aseverar que necesariamente el canal lógico agregado cuenta con un ancho de banda igual a la suma del ancho de banda full dúplex de sus enlaces físicos. A título de ejemplo, el máximo throughput de una conexión EtherChannel de ocho enlaces FastEthernet es 1600Mbps, situación que propone que todos los enlaces constitutivos puedan llegar a cargarse a capacidad total y ser utilizados de forma equitativa por la lógica de conmutación EtherChannel con independencia de la naturaleza del tráfico cursado por el canal lógico. Sin embargo, cada enlace integrante del canal solo transportará las tramas que sean puestas en él por la lógica EtherChannel la cual, de hecho, toma las decisiones de selección de enlaces para envío de tramas basada en un algoritmo de asignación de carga que soporta Hashing de Bits. Este algoritmo, parametrizable por usuario1_{, asimila bits}

pertenecientes a la información origen o destino de los paquetes, o bits resultantes de una combinación matemática de la información origen-destino. Respecto a los patrones binarios insumo del método en mención, son posibles las situaciones en las cuales resulten algunos enlaces favorecidos mayoritariamente por la asignación de carga dada la dependencia a la información de cabeceras del tráfico, lo cual indica que esos enlaces transportarán cargas no consistentes con respecto a otras interfaces. En este escenario, es posible encontrar interfaces participantes del canal lógico con factores de ocupación cercanos al 90% mientras otras interfaces están operando al 50% o menos, siendo las primeras las que conducen a no ofrecer garantías en calidad de servicio, acciones manuales sobre la configuración del método para aliviar las cargas de las interfaces en mención y a inversiones en capex de infraestructura para ampliación del ancho de banda del canal asociado. Los aspectos relacionados con medición y retroalimentación no hacen parte del alcance de la arquitectura EtherChannel y conllevan a sistemas adicionales de gestión para medición y evaluación que ofrezcan información de distribución de carga a los operadores de red quienes deciden el mantenimiento de la configuración actual del método o el cambio de la estrategia. Cisco soporta exclusivamente intervenciones manuales a la configuración EtherChannel del tipo operador, que normalmente generan disrupciones de servicio. Las mediciones de tráfico ofrecidas sobre interfaces

1_{Ver Tabla 1. La parametrización del algoritmo de balanceo de carga es una característica dependiente de la plataforma de}

individuales y el canal lógico EtherChannel responden al acumulado de cada 300 segundos sin mayor detalle de la distribución; e información de hecho solo disponible por medio de protocolos tales como SNMP y NetFlow para utilización en diversos sistemas de gestión de red.

Para aclarar estos aspectos, se realiza una evaluación de la medición diaria de tráfico sobre un canal EtherChannel de dos enlaces que ofrece transporte interno entre dos equipos localizados en diferentes ubicaciones de la red Ethernet de Claro Colombia, con las siguientes especificaciones:

 Análisis de BW Agregado y Físico, estacionalidad sobre un tráfico interno EtherChannel (Diario) :  Enlace: THDPCB(Cisco3400) – THDPolo1(Cisco7600)

 Método Hashing Algorithm: source-destination ip

 Portchannel: 2 GigEth 1Gbps → Throughput: 4Gbps.  Portchannel enrutado IP.

Figura 2. Comportamiento Diario Interfaz Gi0/15 THDPCB (Cisco3400)

– THDPolo1 (Cisco7600). Figura 3. Comportamiento Diario Interfaz Gi0/13 THDPCB (Cisco3400) – THDPolo1 (Cisco7600).

Figura 4. Comportamiento Diario PortChannel Po1 THDPCB (Cisco3400) – THDPolo1 (Cisco7600).

A partir de los datos que respaldan las gráficas de tráfico de las dos interfaces participantes del canal (Figura 2 – Figura 3), se obtienen las diferencias para el tráfico entrante y saliente entre las dos interfaces con los resultados presentados en la Figura 5., calculadas para Gi0/15 con respecto a Gi0/13. Dada la naturaleza del tráfico y operación del método de balanceo de EtherChannel, hay situaciones con Gi0/13 más cargado que Gi0/15 y viceversa y de ahí las diferencias negativas en ancho de banda. Para el tráfico entrante llegan a registrarse picos de 70Mbps de diferencia que pueden responder a ráfaga y comportamiento de corto término, lo cual solo es especulación ya que se insiste en el hecho que son deltas de 5 minutos acumulativos sin información alguna acerca de la distribución de tráfico sobre ese periodo.

Figura 5. Delta Tráfico Inbound–Outbound interfaces participantes EtherChannel THDPCB (Cisco3400) – THDPolo1 (Cisco7600). -8,00E+07 -6,00E+07 -4,00E+07 -2,00E+07 0,00E+00 2,00E+07 4,00E+07 6,00E+07 17 :4 0 19 :2 5 21 :1 0 22 :5 5 00 :4 0 02 :25 04 :1 0 05 :5 5 07 :4 0 09 :2 5 11 :1 0 12 :5 5 14 :40 16 :2

En el Anexo G (en medio digital), se encuentra la Figura 5 con mayor detalle (Figura G.1).

Adicionalmente se efectúa un análisis del ancho de banda agregado y estacionalidad sobre el tráfico EtherChannel (Horario – Diario – Semanal) para la salida internacional (Figura 6, Figura 7 y Figura 8).

 Enlace: THBGoliat(Cisco7606) - THBSuba2(Cisco6500)  Método Hashing Algorithm: source-destination ip

 Portchannel: 4 GigEth 1Gbps → Throughput: 8Gbps  Portchannel enrutado IP.

Figura 6. Comportamiento en una base horaria Interfaz EtherChannel Po3 THBGoliat (Cisco7606) - THBSuba2 (Cisco6500).

Figura 7. Comportamiento en una base diaria Interfaz EtherChannel Po3 THBGoliat (Cisco7606) - THBSuba2 (Cisco6500).

Figura 8. Comportamiento en una base semanal Interfaz EtherChannel Po3 THBGoliat (Cisco7606) - THBSuba2 (Cisco6500).

El análisis anterior refuerza el concepto que la distribución resultante en las interfaces es aleatoria, dada la naturaleza de los flujos de tráfico (comportamiento de usuario y operación de las aplicaciones) y el hecho que el algoritmo de asignación de carga de EtherChannel procesa ciertos bits de las cabeceras de los paquetes. Así, es claro que, dada la invariabilidad en la información de cabeceras, flujos cursados entre dos hosts siempre utilizarán las mismas interfaces entre el canal EtherChannel. Dos conversaciones distintas pueden llegar a utilizar interfaces participantes EtherChannel diferentes. Sin embargo, de acuerdo al comportamiento de usuario y naturaleza de las aplicaciones, los volúmenes de tráfico en esas interfaces físicas pueden ser totalmente diferentes, razón por la cual en esta tecnología se argumenta la disponibilidad de múltiples esquemas de análisis de información en los paquetes, vía configuración del método. Se supone que la infraestructura EtherChannel funciona y tiene validez cuando un host trata de comunicarse con diferentes hosts o servicios, dando oportunidad a índices de interfaces EtherChannel diferentes. Son variados los esquemas de análisis de información origen destino que adecúan la operación del algoritmo de balanceo y asignación de carga EtherChannel, dependientes de la plataforma de enrutamiento o conmutación. De aquí se desprende que la lógica de conmutación de EtherChannel puede disponer de métodos de relación de información complejos con data de capas superiores lo que a su vez aumenta el overhead del proceso. Sin embargo, la información que menos overhead agrega al algoritmo es la asociada a la cabecera de capa 2 pero ambientes en los cuales se presentan DMZs , proxies y firewalls

así como servicios de alto ancho de banda al interior y exterior de las compañías mantienen invariable el direccionamiento capa 2, cargando preferiblemente algunos enlaces con respecto a otros.

interfaces únicas aislándolos de la influencia del algoritmo de balanceo de carga. Sin embargo, muchosmétodos asociados con esas aplicaciones contemplan ya el uso de buffers antes de reproducción, RTP/RTCP, números de secuencia, interpolación e Interleaving, etc. que ayudan a conciliar extremo a extremo situaciones en las cuales la multitrayectoria punto a punto inducida en capa 2 pueda desorganizar la información del flujo o inducir jitter, retardo excesivo y packet loss.

A partir de las apreciaciones anteriores, resulta factible y paso lógico la consideración de las prestaciones de los algoritmos de balanceo de carga dinámicos en la lógica de conmutación de EtherChannel. El hecho que haya tal nivel de dependencia actual entre la asignación de carga estática de la conmutación EtherChannel, y las características variables del tráfico, comportamiento de usuario, así como con las tendencias de servicio, conducen a un bajo nivel de adaptabilidad de la infraestructura de conmutación, limitando su capacidad y escalabilidad en términos de utilización óptima de recursos e inversiones en infraestructura, respectivamente.

La consideración de un método dinámico de asignación y balanceo de carga de tráfico implica la definición de una variable sobre la carga de los recursos que retroalimente el método de conmutación e influencie la asignación de tráfico en las interfaces. Esta variable es de facto la ocupación de los enlaces físicos participantes del método en mención. Respecto a las mediciones de tráfico en una base por enlace actualmente suministradas vía SNMP o NetFlow en plataformas Cisco, primero no son adecuadas para ser consideradas como efectivas desde el punto de vista de retroalimentación para un método de balanceo dinámico ya que son acumulados de bytes de entrada y bytes de salida en un periodo de 300 segundos; por ende cualquier entidad de gestión o administración necesita procesar sendas mediciones como ancho de banda full dúplex y obtener la medición para un segundo (con la consecuente disposición de una medida de bps full dúplex). Aun así, no es válida esta aproximación ya que propone una distribución de tráfico uniforme en el periodo de medición descrito. En adición, acumular mediciones en 300 segundos genera una absorción de las variaciones de tráfico en el corto término y suprime cualquier posibilidad de considerar la medición descrita en un ambiente de reacción rápida de cara a contrarrestar la congestión. En segundo lugar, hay una asociación inmediata de esas mediciones a su uso en herramientas de gestión propietarias que permiten a los clientes de la solución de conmutación evaluar la utilización de la infraestructura así como la toma de decisiones inmediatas y proyectadas sobre las configuraciones más acordes sobre la operación de la plataforma de conmutación.

Con aplicación mayoritaria en ambientes de clusters de servicios, los algoritmos de asignación de carga dinámicos pueden alcanzar un buen balanceo de carga en clusters de servidores con recursos heterogéneos dada la consideración de la carga de los servidores y servicios suministrados, pero hace a los algoritmos tipificados en esta categoría complejos, e incrementa el tráfico de administración entre los servidores y el balanceador [9]. Sobre el particular, el desempeño del algoritmo directamente determina el desempeño del sistema de balanceo de carga; así el algoritmo de balanceo es la clave del sistema de balanceo de carga. En [9] se exploran las cualidades y funcionalidad, así como una simulación de desempeño vía OPNET, de los distintos métodos de balanceo de carga entre los cuales están Round Robin, Weighted Round Robin,

Random, Weighted Random, Least Connection y Least Load.

Figura 9. Ambiente de simulación para el modelado de comportamiento y desempeño de los diferentes algoritmos de balanceo de carga. Tomado de Simulation and Performance Analysis of Load Balancing Algorithms Using OPNET, School of Computer, Communication

Según la referencia, el algoritmo de balanceo Least Load es aplicado con la conclusión que la utilización entre las CPUs de los servidores del cluster es la más cercana y consistente; su efecto aparece de manera temprana puesto que toma en cuenta el tamaño relativo de la tarea actual en cada servidor, similar a tener en cuenta la carga del servidor. En adición, el efecto balanceador positivo del algoritmo de balanceoRound Robin aparece después de algunos ciclos de rotación mientras que el balanceador utilizando Least Load

comienza a hacer el balanceo de carga efectivo tan pronto como el cluster de servidores recibe requerimientos. En conclusión, la consideración de métodos de balanceo de carga dinámicos basados en

Least Load conduce a un mejor desempeño y a una reacción más rápida del algoritmo a las variaciones de carga. Ciertamente considerar un balanceador de carga para EtherChannel basado en el enlace menos cargado (Least Load) desvincula la operación del balanceador de las condiciones de tráfico, la infraestructura subyacente y tendencias en los servicios; reacciona rápidamente a cambios en el tráfico, conduce a utilización óptima de los medios de comunicación, generando ahorros importantes en capex asociados a infraestructura.

De acuerdo a los aspectos cubiertos en parágrafos anteriores, queda patente que son varios los aspectos aún por evaluar y optimizar de esta tecnología. Actualizaciones a la lógica de asignación de carga de EtherChannel podrían posibilitar beneficios directos a los proveedores de servicio que cuentan con infraestructura de conmutación agregada de este tipo, por el manejo óptimo de capex, la automatización de la gestión de situaciones de tráfico excesivo con la mejora en calidad de servicio para los clientes que cursan sus flujos por esta infraestructura.

Objetivo General

Diseñar y evaluar una arquitectura dinámica de asignación y balanceo de carga para la lógica de conmutación de la tecnología EtherChannel, basada en el análisis estadístico del factor de ocupación de los enlaces participantes del canal lógico y en la consideración de algoritmos de selección de enlaces diferentes al Hashing de Bits.

Objetivos Específicos (Alcance)

 Simular un entorno de red basado en el modelado y verificación de desempeño del método de balanceo de carga estático de hashing de bits soportado en EtherChannel, en la herramienta de simulación OPNET Modeler 14.5.

 Identificar y desarrollar una arquitectura de balanceo de carga sobre enlaces físicos basada en la filosofía dinámica Least Load (Menor Carga) que permita influenciar la decisión de balanceo sobre enlaces EtherChannel de forma autónoma y consistente.

 Simular un entorno de red basado en el modelado y verificación de desempeño de la arquitectura de balanceo de carga dinámica propuesta, en la herramienta de simulación OPNET Modeler 14.5.

 Verificar el desempeño del método de balanceo de carga y de la arquitectura propuesta en general frente a variaciones discretas de α como parámetro de la medición de tendencia central de ocupación de enlaces físicos EtherChannel y probar la validez de la Media de Rango InterCuartil.

Limitantes y Exclusiones (Alcance)

 El alcance del proyecto de grado no contempla implementaciones en hardware o evaluación de resultados en plataformas de conmutación o enrutamiento.

 No se consideran aspectos relacionados con la evaluación, por medio de simulación, del impacto generado por la influencia de los protocolos de negociación de enlaces agregados EtherChannel (PagP, LACP).

 El tipo de interfaz agregada sobre la cual se realizarán los análisis iniciales y los similares bajo la nueva arquitectura de balanceo de carga es conmutada troncal.

 La simulación de modelos en OPNET solo corresponde a la lógica en transmisión. La recepción se mantiene con la lógica de conmutación ya implementada.

 La simulación de la implementación del método de balanceo de carga EtherChannel de laboratorio así como el diseño, simulación y verificación de la arquitectura de balanceo de carga propuesta se realizarán para un ambiente lógico de 8 canales físicos entre nodos de conmutación.

 No se discriminarán flujos ni sesiones TCP/UDP específicas. En ese orden de ideas, este proyecto solo se enfoca hacia la optimización del performance de la infraestructura de conmutación EtherChannel en lo referente a eficiencia en la asignación de carga de los enlaces participantes de interfaces agregadas, y a la automatización y proactividad del esquema de conmutación y balanceo de carga frente a situaciones de corto término y persistente de tráfico cursando EtherChannels.

Organización del Documento

Este documento de tesis de maestría está organizado en capítulos, los cuales presentan la temática investigada así como los resultados obtenidos y el análisis pertinente:

 En el capítulo 1 se abordan las definiciones y aspectos importantes de la tecnología EtherChannel así como los conceptos relevantes relacionados con los modelos de simulación existentes y el modelo de simulación soportado en la herramienta OPNET Modeler.

 En el capítulo 2 se presenta la arquitectura propuesta de conmutación, una especificación funcional detallada de su diseño modular y demás consideraciones técnicas tenidas en cuenta en su desarrollo.

 En el capítulo 3 se exploran los detalles técnicos relacionados con el modelado de la arquitectura propuesta en la herramienta de simulación OPNET Modeler, el desarrollo y resultados de su fase de validación, así como el diseño del escenario de simulación de red.

 En el capítulo 4 se efectúa una descripción de los objetivos y resultados esperados del Plan de Simulaciones del proyecto y se realiza una revisión exhaustiva, con su respectivo análisis, de los resultados obtenidos de la ejecución de los escenarios que hacen parte del Plan de Simulaciones en mención, con respecto a los objetivos propuestos para este proyecto de grado.

 En el capítulo 5 se presentan las conclusiones sobre el desarrollo de esta tesis de maestría, las recomendaciones para quienes deseen continuar con investigaciones sobre las temáticas tratadas, así como los trabajos futuros y las contribuciones de este trabajo de investigación.

 En el capítulo 6 encontrarán las fuentes consultadas que soportan todas las etapas del proyecto.

1.

MARCO TEÓRICO

1.1

TECNOLOGÍA DE CONMUTACIÓN ETHERCHANNEL

Con mención en el capítulo Introducción, EtherChannel es una tecnología propietaria del fabricante Cisco por medio de la cual se amplía el alcance del estándar IEEE 802.3, en lo referente a escalamiento de ancho de banda, en sus plataformas de conmutación por medio de la agregación lógica de múltiples enlaces Ethernet ya existentes en la infraestructura de los usuarios, sin necesidad de recurrir a la actualización tecnológica asociada al cambio de interfaces de velocidad superior [7]. Este método actualmente posibilita un ancho de banda agregado entre switches y routers, así como con equipos de otros fabricantes y servidores; la compartición de carga de tráfico entre los enlaces del canal lógico, y un esquema de redundancia en el evento que uno o más enlaces físicos fallen (implicando desplazamiento de cargas hacia enlaces adyacentes, tiempos de conmutación no superiores a pocos milisegundos y con transparencia al usuario). En general, equipos que soporten esta funcionalidad están en capacidad de utilizar simultáneamente desde dos hasta ocho enlaces Ethernet de características y configuraciones similares.

Figura 10. Canal lógico EtherChannel entre dos plataformas de conmutación Cisco. Tomado de Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches Document ID: 12023.

Con respecto al estándar Ethernet, el ancho de banda de una interfaz según la especificación IEEE 802.3 no corresponde al ancho de banda full dúplex. Así, una interfaz de 100Mbps cuenta con un ancho de banda full dúplex de 200Mbps. Con EtherChannel, de dos a ocho enlaces físicos de ya sea FastEthernet (FE), GigabitEthernet (GE), o 10-Gigabit Ethernet (10GE) pueden ser “empaquetados” en un enlace lógico de Fast EtherChannel (FEC), Gigabit EtherChannel (GEC), o 10-Gigabit EtherChannel (10GEC), respectivamente [7]. Cuatro enlaces FastEthernet conforman el estándar industrial Fast EtherChannel para proveer balanceo de carga de tráfico con hasta 800Mbps de ancho de banda full dúplex utilizable. La tecnología EtherChannel provee una capacidad en ancho de banda de hasta 1600Mbps FEC, 16Gbps GEC, 160Gbps 10GEC en los casos de utilización de 8 enlaces, límite de acuerdo a la especificación. Todos los enlaces físicos que hacen parte del método utilizan los mismos mecanismos estándar IEEE 802.3 para autonegociación full dúplex y autosensado, son asociados y vistos como un todo extremo a extremo, en lo que respecta a ancho de banda y al comportamiento del canal lógico como una interfaz conmutada o enrutada.

previa a la activación del canal EtherChannel. Por último, es posible una configuración estática extremo a extremo en capa 2 del canal en la cual no hay intercambio protocolario alguno.

Esta tecnología no está en capacidad de identificar flujos de tráfico para tratamiento diferenciado y asignación a enlaces únicos dentro del canal lógico. Algunos trabajos sugieren la modificación de la metodología de EtherChannel y la orientación hacia la identificación de tráfico y flujos en tiempo real y no tiempo real para ofrecer un manejo adecuado y diferenciado en la asignación de anchos de banda con la intención de solucionar el problema de retardo de red causado por congestión [5].

Como fue mencionado en el capítulo Introducción, cada enlace integrante del canal solo transportará las tramas que sean puestas en él por la lógica EtherChannel la cual toma las decisiones de asignación de carga basada en un algoritmo denominado Hashing de Bits. Este algoritmo asimila patrones binarios pertenecientes a la información origen o destino de los paquetes, o resultantes de una combinación matemática de la información origen-destino. Dentro de la información en mención están las direcciones MAC (que inmediatamente relacionan la tecnología EtherChannel con la utilización exclusiva de enlaces basados en IEEE 802.3), direcciones IP, así como números de puerto TCP/UDP. La utilización de solo direcciones origen o destino implica, de acuerdo al número de enlaces participantes, el procesamiento de un número proporcional de bits de bajo orden de una dirección a manera de índice de la interfaz de salida a seleccionar [7]. Como ejemplo, si el algoritmo utiliza la dirección IP destino (dst-ip) en los paquetes, el canal lógico cuenta con dos interfaces físicas y un paquete a procesar tiene una dirección destino IPv4 192.168.15.15, el algoritmo solo necesita un bit (de más bajo orden) de la dirección como índice de la interfaz física a seleccionar. El cuarto octeto <15> corresponde al código binario 00001111 y el último bit (1) indica la selección del enlace “1”. En adición, cuatro interfaces requieren el análisis de 2 bits (00-01-10-11) y ocho interfaces requieren el análisis de 3 bits (000-001-010-011-100-101-110-111).Si la configuración del algoritmo Hashing de Bits implica la utilización de información origen y destino simultáneamente, el hardware EtherChannel desempeña una XOR lógica entre posiciones de bits similares de la información origen destino en mención, cuyo resultado corresponde al índice de la interfaz de salida a seleccionar. Así, a título de ejemplo, un canal EtherChannel de 4 enlaces físicos con una función de hashing procesando información origen y destino (configuración src-dst-ip) procesará en una base por paquete una XOR lógica entre los dos bits de más bajo orden en las dos direcciones capa 3. Bits 10 XOR Bits 11 = 01 con lo cual se selecciona el enlace “1” para enviar ese paquete.

Plataforma de Conmutación

Direcciones usadas por operación XOR

Algoritmo basado en dirs

fuente?

Algoritmo basado en dirs

destino?

Algoritmo basado en dirs fuente / destino?

Algoritmo configurable o fijo?

6500/6000 Dirs Capa 2/3, puertos

Capa 4, data MPLS Si Si Si Configurable

5500/5000 Únicamente dirs. Capa 2 — — Si No modificable

4500/4000 Dirs Capa 2/3, o info.

Capa 4. Si Si Si Configurable

2900XL / 3500XL Únicamente dirs. Capa 2 Si Si — Configurable

3750/3560 Únicamente dirs Capa 2/3 Si Si Si Configurable

2950/2955/3550 Únicamente dirs. Capa 2 Si Si — Configurable

1900/2820 Estas plataformas usan un método especial de balanceo. Por favor ver info detallada de Catalyst

1900/2820.

8500 Únicamente dirs. Capa 3 — — Si No modificable

La Tabla 1 presenta una relación del fabricante Cisco en la cual se detalla en una base por plataforma la información de direccionamiento por capas que puede utilizarse como insumo por el algoritmo de Hashing de Bits del método EtherChannel, la capacidad para utilizar información origen destino simultáneamente y la condición fija o configurable del método de hashing.

En general, la cantidad de información procesada en una base por paquete depende de 1. la plataforma, y 2. el número de interfaces físicas participantes del método. Respecto a la dependencia de la plataforma, la Tabla 1 muestra que no todos los equipos soportan las mismas capacidades de algoritmo (análisis de información proveniente de capas superiores y generación de complejas configuraciones del algoritmo son factores que dependen de la plataforma) e incluso algunas plataformas tienen configuración fija. En el caso de la plataforma Cisco Catalyst 6500/6000 Series corriendo el sistema operativo CatOS, puede configurarse un canal EtherChannel de 2 hasta 8 interfaces físicas (3, 5, 7 interfaces agregadas son instalaciones válidas); pero para todas esas configuraciones siempre se requieren 3 bits de información insumo para el algoritmo. 3 bits producen índices de interfaz del 0 (000) al 7 (111); así que hay enlaces que pueden ser indexados con más de un índice. El balanceo de carga “Equitativo” por índice aparece en la configuración de 2 (4 índices por interfaz), 4 (2 índices por interfaz), y 8 enlaces físicos (1 índice por interfaz). La siguiente tabla muestra la situación inequitativa para EtherChannels de 3, 5, 6 y 7 interfaces.

Número de puertos en el EtherChannel Balanceo de Carga

8 1:1:1:1:1:1:1:1

7 2:1:1:1:1:1:1

6 2:2:1:1:1:1

5 2:2:2:1:1

4 2:2:2:2

3 3:3:2

2 4:4

Tabla 2. Asignación inequitativa de índices a enlaces dentro de configuraciones EtherChannel de 3, 5, 6, 7 enlaces. Tomada de Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches Document ID: 12023

1.2

CONCEPTOS SOBRE SIMULACIÓN

1.2.1 MODELADO DE RED E INTRODUCCIÓN A LA SIMULACIÓN

Un sistema es un conjunto de elementos que interactúan entre sí para lograr un objetivo específico. Se define Simulación como una técnica que imita el comportamiento de un sistema del mundo real conforme evoluciona en el tiempo. Por lo tanto, se podrá analizar y observar sus características, sin necesidad de acudir al sistema real [11]. En particular, hay varios métodos factibles para investigar los protocolos de red y el desempeño de red [10]:

modelado y pérdida de precisión aumentan con la complejidad del protocolo o sistema de networking a evaluar.

 Simulación (basada en tiempo o en eventos discretos), que provee una manera efectiva de modelar el comportamiento de un sistema calculando las interacciones entre sus módulos componentes.  Simulación Híbrida, que considera las prestaciones del análisis matemático y la simulación

explícita de forma simultánea, parcialmente modelando en simulación discreta para precisión; y parcialmente con análisis matemático para reducir la carga computacional y acelerar el proceso de simulación.

 Test-bed Emulation, que normalmente involucra la implementación hardware a baja escala de los protocolos, algoritmos y sistemas objeto de los procesos de análisis. Se considera la mejor manera de estimar la factibilidad de los protocolos y sistemas y para determinar qué tan eficaz y robusto es su comportamiento frente a situaciones reales. Sus desventajas están relacionadas con la consideración de aspectos derivados de la implementación física totalmente irrelevantes con la expectativa funcional del sistema, los costos del prototipado y el ámbito limitado para evaluar interacciones y comportamientos a mayor escala.

Así, un proceso de simulación involucra el diseño, parametrización y observación del comportamiento de un modelo del sistema real a evaluar, que es una representación de ese sistema con cierto grado de aproximación a sus características. Como objetivos de la simulación se tiene la definición de estímulos de entrada al modelo en mención, así como una serie de variables objeto de análisis, y la observación en si misma del comportamiento del modelo a lo largo del tiempo, los que permiten catalogar el proceso global como una ejecución de la simulación. Esa observación está supeditada a los valores de las variables que se usan para ajustar la operación del modelo y su objeto responde a la obtención y análisis de ciertos parámetros que especifican el comportamiento del sistema. Así, estas apreciaciones permiten la definición de dos conceptos relevantes a la simulación [11]:

 Modelo de Simulación, que se refiere al conjunto de hipótesis acerca del funcionamiento del sistema expresado como relaciones matemáticas y/o lógicas entre los elementos del sistema.

 Proceso de Simulación, que se refiere a la ejecución del Modelo de Simulación a través del tiempo de un ordenador para generar las representaciones del comportamiento del sistema.

Es importante tener en cuenta que los resultados de la simulación deben ser analizados para verificar su precisión con respecto a la expectativa funcional del sistema, de manera que tanto el modelo como los estímulos puedan ser ajustados y así lograr un balance entre el nivel de detalle del modelo y la expectativa sobre la simulación.

Se dice que el Estado del Sistema corresponde al conjunto de variables necesarias para describir el comportamiento y estatus de un sistema en determinado instante de tiempo. Dada la naturaleza de las herramientas computacionales que soportan ambientes de simulación, este estado es discreto; se compone por las variables de entrada y salida, últimas que son objeto de estudio en el marco del análisis del sistema. Dentro de las variables de entrada se encuentran [11]:

 Las Condiciones Iniciales, que son valores que expresan el estado de sistema al principio de la simulación.

 Datos Determinísticos, que son valores conocidos que son necesarios para realizar los cálculos que producen las salidas.

 Datos Probabilísticos, cuyos valores son inciertos pero necesarios para obtener las salidas del sistema. La certeza sobre estos valores se deriva del análisis de sus distribuciones de probabilidad. De acuerdo con [11], se tienen las siguientes clasificaciones para los diferentes escenarios y modelos de simulación:

 Modelo de Simulación Estática: La representación de un sistema en cierto instante de tiempo.  Modelo de Simulación Dinámica: La representación de un sistema cuando evoluciona el tiempo.  Modelo de Simulación Determinista: La representación de un sistema que no contiene

 Modelo de Simulación Aleatoria: La representación de un sistema que contendrá variables aleatorias.

 Modelo de Simulación Continua: La representación de un sistema donde su comportamiento cambia de forma continua en el tiempo.

 Modelo de Simulación Discreta: La representación de un sistema donde su comportamiento cambia únicamente en instantes de tiempo concretos, eventos.

1.2.2 CLASIFICACIÓN DE LOS SIMULADORES

De acuerdo con [10], los simuladores de red pueden ser clasificados como Simuladores basados en Tiempo de Reloj y Simuladores de Eventos Discretos. En la simulación basada en tiempo de reloj, la simulación progresa a través de una progresión iterativa de ranuras de tiempo, mientras que en la simulación de eventos discretos la simulación progresa con la ejecución del siguiente evento programado.

1.2.2.1

MODELO DE SIMULACIÓN BASADO EN TIEMPO

Las ranuras de tiempo en la simulación basada en tiempo de reloj corresponden a espacios de tiempo de reloj real. En este modelo de simulación los eventos dentro de la ranura de tiempo iterada son ejecutados mientras la simulación progresa. El tiempo de simulación corresponde al tiempo usado en correr el modelo. Puesto que un conjunto de ranuras de tiempo (con los eventos asignados por ranura) pueden ser iteradas en un escenario de múltiples corridas, el tiempo de simulación y el tiempo transcurrido en una corrida de la simulación son conceptos distintos. Un aspecto importante de este modelo es que el simulador iterará todas las ranuras de tiempo de una corrida de la simulación sin considerar si hay eventos asignados a una ranura de tiempo particular, por lo cual presenta un bajo desempeño si no hay eventos asignados en muchas ranuras de tiempo consecutivas, que deben ser ejecutadas para completar la ejecución de la simulación.

La siguiente ilustración presenta el diagrama de flujo del modelo de simulación basado en tiempo.

Figura 11. Diagrama de Flujo de la Simulación basada en Tiempo.

1.2.2.2

MODELO DE SIMULACIÓN BASADO EN EVENTOS DISCRETOS (DES)