Physical Broadcast Traffic Attack

Introducción

En esta entrada voy a explicar una incidencia que tuvimos ayer y que provoco una caída en toda regla de la infraestructura de red de la empresa, cuando digo de la empresa, no es de una sede, sino de más de una, en este caso de 3 de 4 que tenemos.

No voy a explicar, nada innovador, aunque el nombre pueda hacer pensar en eso, pero si algo muy estúpido que dejo durante casi un ahora la infraestructura de red y la telefonía fuera de servicio y media hora más funcionando a medias tintas, provocando, como es de suponer, ciertas perdidas económicas en la empresa y horas de trabajo de más sin remunerara de ciertos empleados para recuperar ese tiempo de improductividad.

Arquitectura de interconexión entre sedes

La empresa tiene la siguiente arquitectura de red de interconexión entre sedes:

• 4 sedes intercomunicadas entre ellas a través un backbone ofrecido por un ISP.
• 3 de las sedes están interconectadas en un topología en estrella a través de un canal de fibra óptica. Madrid como nodo central y Barcelona y Bilbao como nodos periféricos.
• Los canales de fibra se interpretan como una conexión directa, es decir que el ISP solo enlaza el tráfico de un extremo al otro, corriendo de parte de la empresa la manera como gestionar el trafico por dicho canal.
• Las sedes también se encuentra interconectadas por una infraestructura paralela, proporcionada por un router DSL en cada sede; en este caso la infraestructura de red del ISP es quien enruta a el trafico a la sede correspondiente.
• La cuarta sede que no está conectada con el canal de fibra óptica, Málaga, solo está enlazada a través del router DSL con el resto de las sedes.
• Distinto rango de red local en cada una de las 4 sedes.

Os dejo un esquema para su mejor compresión.

Esquema de la arquitectura de la interconexión de red entre sedes

Problemas de fondo

Uno de los problemas que detecte hace un mes y medio aproximadamente, snifando la red para analizar otras tareas que no vienen a cuento en este post, y que nunca había verificado antes porque cuando yo empecé a currar aquí la infraestructura de red de interconexión de sedes por fibra óptica ya existía y lo dí por supuesto después de la información que me habían facilitado mis compañeros que estuvieron en el momento de su instalación, es que el broadcast de cada una de las redes interconectadas llega al resto.

El problema que esto provoca es evidente, una inundación de las redes con paquetes que no sirven para nada, no obstante el día a día no provoca grandes estragos. Solo decir que este problema está en la lista de resolución de problemas, pero la prioridad que tiene es baja, ya que las directrices que nos llegan, sin tener ni voz ni voto, nos indican que estos asuntos no tienen relevancia en el negocio, así que mejor nos dediquemos ha hacer las otras que si las tienen.

El "ataque"

Bueno llegado a este punto voy a explicar en que consistió el "ataque", entre comillas ya que no fue intencionado.

El problema vino de un usuario que había venido con su portátil y se había sentado en uno de los lugares donde tenemos un switch de 5 bocas, de esos que no superan los 40 €, ya que es la manera que usamos para ampliar una única boca disponible de un despacho sin la necesidad de tirar nuevo cableado; no obstante esto solo lo tenemos en puntos muy localizados, ya que la oficina de Barcelona, por lo general, los accesos físicos a red están bien distribuidos y cableados. Cuando el usuario abandono su lugar la oficina, se le ocurrió conectar el extremo del cable conectado a su equipo a una de las bocas libres del switch de 5 bocas, creando un bucle físico y directo.

A partir de aquí ya nos podemos imaginar que sucedió, la red empezó a inundarse con los paquetes de broadcast que llegaban a una de esas bocas, ya que entre ellas se iban realimentando.

Las consecuencias

Las consecuencias del "ataque" fueron las siguientes:

• Denegación de servicios en todo los aparatos conectados en la red de Barcelona. Cuando digo todos, son todos; los switches colapsados con tanto broadcast, a raíz de esto las comunicaciones entre las máquinas (usuarios y servidores) se les denegaba los distintos servicios no de manera total pero si parcialmente, que igualmente impedía trabajar, además el router DSL también estaba colapsado, incluso lo manifestaba con parpadeos de luces inhabituales y para completar el DOS, la centralita telefónica también denegaba su servicio, no funcionaba ni las llamadas internas ni externas, es decir como si se hubiese apagado, esto se debe a que la centralita tiene un interfaz de red ethernet para poder ser administrada y parece que un su fabricación y diseño no se tiene encuentra como una parte no importante de su servicio, es decir que no es capaz de tirar al suelo el servicio ethernet y dejar intacto el servicio de telefonía frente aun problema de este tipo.
• Debido a la configuración que hay actualmente de interconexión entre sedes, comentado en el apartado anterior, "Problemas de fondo", todo el broadcast llegó a las otras dos sedes, Madrid y Bilbao, produciendo un efecto similar, solo salvando se las centralitas, porque estas no tienen el servicio de administración vía ethernet.

Bien, todo esto fue una gran putada, nos volvimos locos viendo que pasaba y haciendo hipótesis de lo que podía estar sucediendo, viendo si lo que podía fallar era un swith, cual de ellos, si el problema podía venir por parte de la infraestructura de red del ISP, etc.

Finalmente después de varias pruebas, todo parecía que era un switch de Barcelona, uno de conexión de máquinas de usuarios, o eso o algún equipo que estaba enviando paquetes de broadcast o corruptos; así que mientras pasaba las conexiones de ese switch al switch de backup  iba monitoreando la red para ver si las nuevas bocas que iba pinchando provocaban alteraciones, hasta que finalmente, como la Ley de Murphy indica, fue una de las últimas bocas que pinché y al ir visitar la localización de esa boca fue cuando me comenta uno de los usuarios que habían al lado del "atacante", "Cuando se ha ido ha conectado su cable ahí".

Conclusiones

Parece que hackearnos la red, aunque solo sea por un intervalo de tiempo aproximadamente una hora, es bastante más fácil que conectar un proyecto a un portátil, así que para la próxima vez que pueda suceder algo así, ya tenemos algo bastante fácil que mirar, antes de empezar a desmontar parte del rack de comunicaciones.

Por cierto, tener un rack bien organizado con switch de backup y una buena adecuación y organización del cableado del rack me ayudó a trabajar más ágil y eficazmente.

Hasta la próxima enfermos.

Dejando la improvisación para cuando sea necesario (2/2)

################# Conjunto de entradas ###################
# Dejando la improvisación para cuando sea necesario (1/2)
# Dejando la improvisación para cuando sea necesario (2/2)
########################################################

Entrando en acción

Bueno después de planificar y organizar la acción que se quiere llevar a cabo, esta claro que hay que ejecutarla, sino lo anterior no sirve de nada, ya que hasta este punto no hay ninguno objetivo completado.

La previa

Así que empecé creando las plantillas comentadas en el post anterior y luego, entre yo y el becario, pasamos a rellenarlas. Mientras tanto le iba en mi cabeza iba diseñando la arquitectura lógica de la red y a ratos la iba plasmando en el diagrama.

Cuando ya tuve una primera versión del diagrama del diseño de la arquitectura lógica de la red busqué un rato para comentarlo con el becario, con el objetivo que se sintiera más implicado y motivado (dos aspectos que para mí son muy importantes si quieres que los currantes trabajen bien y eficazmente), supiera que es lo que vamos ha hacer y también que valorase esa opción y las otras que yo le había dado vueltas y las cuales le comenté, ya que dos cerebros piensas más que uno de solo. 

Después de esto él comentó sus puntos de vista y discutió mis argumentos y finalmente acabamos haciendo pequeñas modificaciones sobre mi propuesta inicial por tal de que la red fuese lo más óptima posible (contando solo con los recursos que teníamos) aunque eso implicase un punto crítico, básicamente porque la topología era en estrella; pero era la mejor opción para descartar que la red fuese un cuello de botella cuando te llamen los usuarios para decirte "que todo les va muy lento", una música que escuchamos muchas veces, y  como yo no he sido quien ha montado todo el tinglado y la documentación es inexistente ,si  no optimizo la red cuando he puedo hacerlo, no hay manera de cargarse incógnitas de esta ecuación tan odiada, y  para solucionar el punto crítico, el switch central, se puede solucionar teniendo un switch de backup que nunca viene mal tenerlo.

También elaboré la el diagrama de diseño de la distribución de la energía eléctrica, partiendo de la premisa que no había presupuesto para comprar nuevos UPSs, así que me toco distribuir los distintos dispositivos entre los UPSs existentes garantizando que todo pudiese aguantar el máximo de tiempo posible encendido frente a una caída de tensión y así tener claro a que toma íbamos a conectar cada uno de los dispositivos.

Para terminar con todo esto anoté el orden, de arriba a bajo, con el que iba poner cada uno de los elementos de dentro del rack (centralita, switches, routers, patch panels, etc.) y así completaba como iba se iba materializar todo y no tener que estar improvisando en medio de cables y con la presión  que algo no terminase de funcionar al siguiente día laboral.

El juicio final

Llego el gran día y yo y el becario, estábamos ahí delante del rack y dispuestos a desmontarlo, así que  empezamos a desconectar todo el rack de comunicaciones para posteriormente reorgarnizar los patch panels y todos los dispositivos de red (switches, routers, etc.) y conectar todo como se había planificado.

Sobre ese día no hay mucho más que contar, porque lo único que tuvimos que hacer es seguir las instrucciones que había elaborado y tanto yo como el becario fuimos completando nuestras tareas sin ninguna complicación.

Conclusiones

Es esencial dedicar 5 minutos a valorar si merece la pena o no dedicar un tiempo a planificar las tareas con cierta envergadura que tienes que acometer.

Pensando con antelación y planificando las tareas, por muy chorra que pueda parecer, como en un principio podía parecer la organización de un rack de comunicaciones, te garantizas en un % muy elevado que su ejecución se lleve a cabo sin complicaciones y te da una elevada garantía de cumplir satisfactoriamente con todos los objetivos y a la vez cumplirlos con una calidad más que aceptable.

Para terminar os dejo el antes y el después del rack, ya que aprovechamos y cambiamos el cableado que había hasta el momento por uno de mayor calidad y de adecuada longitud, algo que también fue posible, en parte, a la nueva distribución de los elementos, dejando un rack donde meter la zarpa ya no supone un engorro.

El antes

Y el después

Hasta la próxima enfermos.

Dejando la improvisación para cuando sea necesario (1/2)

################# Conjunto de entradas ###################
# Dejando la improvisación para cuando sea necesario (1/2)
# Dejando la improvisación para cuando sea necesario (2/2)
########################################################

En este post voy a explicar una de las experiencias que he vivido y la cual yo he tenido la posibilidad de "liderar"; si entre " porque no se trata de ninguna gran proeza ni tampoco de ninguna obra maestra pero creo que en ella se refleja claramente que si las cosas se planifican con antelación tienen muchas más probabilidad de que se completen con éxito; y ya sabemos que la planificación no es un plato fuerte de lo "Made in Spain", algo que quiero dejar claro que es un punto de vista personal y al cual he llegado después de estar viviendo lo continuamente tanto en mi vida profesional como personal.

La tarea

• Descripción: Organizar el rack de comunicaciones de la oficina de Barcelona de la empresa para la cual trabajo.
• Objetivos:
1. Mantener la conexión en las rosetas que hasta el momento estaban conectadas.
2. Mantener las mismas extensiones telefónicas de los usuarios.
3. Flexibilizar la escalabilidad física, con los medios actualmente disponibles.
4. Optimizar la red con los medios que  actualmente disponibles.
• Requerimientos implícitos:
1. No influir en el trabajo del día a día de la empresa.
2. No se pueden realizar obras (poner canaletas, poner nuevas rosetas).

El plan

Para llevar a cabo la tarea y cumplir con los requerimientos implícitos realicé lo siguiente:

Analizando el entorno

Basándome en los requerimientos me centré en determinar que es lo que tenía que pensar y organizar para llevar a cabo la labor.

1. Realizar el trabajo fuera de horas laborales, por lo que se aprovechó un día por la tarde fuera de horario laboral.
2. Registrar las rosetas conectadas a la centralita por tal de mantener la mismas extensiones en el caso que haga falta desconectar los cables de los patch panels.
3. Para cumplir con los objetivos 3 y 4 y respetar el requerimiento 2 se tiene que pensar en cambiar la organización física de los switches y como los conectábamos entre ellos.

Detallando las subtareas

1. Registrar las rosetas con conexión y en el caso de las telefónicas anotar en que boca de la centralita van conectadas.
2. Determinar  la distribución física de los switches y los patch panels.
3. Determinar la conexión entre los switches.
4. Distribuir las conexiones de corriente de todos los dispositivos del rack (no se invierte en nuevos UPSs hay que utilizar los que hay).
5. Planificar la desconexión de ciertos servidores con la oficina central (Madrid).
6. Determinar día de realización de la tarea.

Planificando las subtareas

A excepción de la subtarea 6 que es ejecutar la tarea en el mundo físico, consideré que el resto de tareas se tenían que hacer durante los días anteriores, claro está que pare ello mi empresa  no me iba a permitir dejar de atender lo del día a día (incidencias, soporte usuarios, más soporte usuarios, más soporte usuarios, ...).

En esta ocasión tenía una ayuda; estoy hablando de un becario que se acaba de incorporar y el cual me podía ser útil, si lograba transmitirle y explicarle lo que teníamos que hacer, como nos íbamos a organizar y concretamente que iba a hacer él, teniendo en cuenta que no tenía tiempo suficiente, debido a que marqué como día de ejecución el cuarto día después de su incorporación, para ponerle al día al completo sobre la infraestructura tecnológica de la oficina, por lo tanto las tareas en las que podía ayudarme tenían que ser sencillas,

Así que los 3 días antes, de la ejecución y dedicando más horas de las que me pagan ya que el día a día da poco margen para cosas que no son del día a día, me dedique a:

• Crear una plantilla para registrar las conexiones de la centralita, con el objetivo adicional de que se incorporasen a la documentación interna del departamento de TI, en beneficio de la empresa.
• Crear una plantilla para registrar las conexiones de cada una de las bocas de los switches. No es necesario saber concretamente en que boca va conectada cada roseta, ya que hasta hora habían sido conectadas todas a la brava y en el caso de las rosetas donde se conectan las máquinas de los usuarios no es importante.
  Lo realmente importante de esta platilla era registrar las bocas que se utilizan para conectar los switches entre ellos y las que se utilizan para conectar dispositivos relevantes de la arquitectura de red, como son los servidores, routers, impresoras, etc.
• Elaborar un diagrama lógico de la interconexión de los dispositivos relevantes, vamos lo que para mí es diagrama  de la arquitectura lógica de la red,  con el objetivo de plasmar en un diagrama el punto anterior sin entrar en el detalle del número de boca, más bien saber a que switch está conectado cada uno de los dispositivos relevantes y como se conectan los switches entre ellos y de que manera es decir si utilizan un trunk o no.
• Elaborar diagrama de conexión de los dispositivos de dentro del rack (switces, centralita, routers y firewalls) a la toma de corriente, pensando en los UPSs que teníamos y como distribuir estas conexiones entre ellos para soportar las pequeñas bajadas o caídas de tensión y con el objetivo de que también pasé a ser una documentación interna de TI y ser útil para el futuro.
• Para el desarrollo de la subtarea 5, anotar y explicar al becario que switch se iba a mantener conectado hasta el último momento y que es lo que iba a tener conectado.

En el próximo post de esta serie explicaré como lo llevamos a cabo y que conclusiones he sacado de esta experiencia.


Hasta la próxima enfermos.

Jugando con los Switches: Port trunking (3/3)

conjuntoEntradas() {

  Jugando con los Switches: Port trunking (1/3)

  Jugando con los Switches: Port trunking (2/3)

  Jugando con los Switches: Port trunking (3/3)

}

HP Network Configuration Utility
Esta es una herramienta de HP que viene instalada con algunos servidores Proliant y que permite configurar y gestionar grupos de tolerancia a fallos sobres las interfaces de red instaladas y disponibles en el servidor; en resumen, que nos permite crear trunks si el servidor dispone de varias interfaces de red.

No voy a detallar el proceso de instalación, ya que es bastante sencillo además de que si compramos un servidor HP Proliant con varias interfaces de red y con SO incluido ya viene instalado de serie.

En mi caso lo estoy utilizando con uno de los servidores que tenemos, el único que tiene dos interfaces de red, para crear un trunk de conexión servidor-switch y lo que voy a explicar se basa en uso justamente sobre dos interfaces, fácilmente extrapolable a las N interfaces que queramos que formen el trunk.

Después de instalarlo dentro de "conexiones de red" de Windows, veremos que nos aparecen a parte de las dos interfaces de red, una más; está nueva interfaz, es una interfaz lógica que lo que hace es agrupar las otras dos interfaces.

Ventana de listado de interfaces de red del servidor

Si accedemos a las propiedades de una de las interfaces físicas, es decir una de las que actúa como miembro del trunk, vemos que tiene todas las opciones deshabilitadas a excepción de a excepción del elemento "HP Network Configuration Utility", el cual es el que se encarga de indicar que la interfaz pertenece al trunk. Dentro de estas interfaces no podemos configurar nada como haríamos dentro de una interfaz corriente, es decir su IP o DHCP, etc., estas configuraciones las realizamos sobre la interfaz lógica que agrupa las NIC dentro del trunk como habremos hecho ya muchas veces sobre cualquier interfaz de red convencional.

Ventana de propiedades interfaz de red física

Una vez realizado la configuración de la red y habiendo conectado los cables con el switch correspondiente, ya podemos entrar en la ventana de configuración de la herramienta; para entrar lo hacemos a través de los típicos accesos directos del menú de Inicio, a través del icono de la aplicación activo al lado del reloj (si lo tenemos activado) o en directamente haciendo clic en el botón de propiedades una vez seleccionado el elemento "HP Network Configuration Utility" de una de las interfaces físicas.

Ventana principal de "HP Network Management Utility"

En la pantalla de la utilidad, seleccionamos una de las interfaces que forman parte del grupo y hacemos clic en el botón de propiedades para ver lo siguiente:

• En la pestaña "Teaming Controls" podemos escoger el modo en que va operar el trunk y el método de transmisión del balanceo de carga. La configuración de estos dos parámetros dependerá de las necesidades de nuestro trunk y de las capacidades y configuraciones soportadas por switch que se conecta al otro extremo. En mi caso lo dejo en modo automático, el recomendado, por lo que ya la negociaran solitos el servidor y el switch.
  
  
  
  Pestaña "Teaming Controls" del "HP Network Configuration Utility"
• La otra pestaña que me aparecido importante mencionar es la "Information", porque es la que me resume el modo de operación del trunk y como están operando las distintas interfaces que lo forman.
  
  Como podéis ver en la siguiente imagen, en esta ventana se observa que las dos interfaces del servidor que forman el trunk utilizan la una única dirección MAC, y lo mismo sucede con las del switch; también vemos que las dos interfaces envían y reciben por lo que el resultado del trunk es un conexión de justamente la suma de la capacidad de las dos interfaces y por último, observo que el modo en el que opera el trunk, el cual ha sido auto negociado, es el 802.3ad dinámico.
  
  
  
  
  Pestaña "Information" del "HP Network Configuration Utility"

Conclusiones

Como podemos ver he podido crear trunks entre dispositivos de distintos fabricantes; esto ha sido posible porque los dispositivos implementan el standard IEEE 802.3ad.

También he podido observar que gracias a la especificación del LACP incluida dentro del standard 802.3ad es posible conectar dispositivos entre sí y si dicha característica está activada, los dispositivos auto negocian entre ellos creando automáticamente los trunks; este caso lo he observado en dos situaciones:

• En el switch HP al acceder a la configuración de miembros trunks (Trunks --> Membership), se puede observar que para los puertos a los que se ha activado el LACP no se pueden incluir como miembros de ninguno de los 12 trunks que ofrece; esto se debe porque en esta página de configuración, es donde se crean trunks estáticos, y debido a que se ha activado el tipo dinámico (LACP) los trunks son creados automáticamente (siempre que el dispositivo del otro extremo implemente el LACP, en mi caso el HP conecta con el 3Com).
  
  
  
  
  

  Pantalla de configuración de trunks estáticos del HP ProCurve 1800 24G
  

  
  
• Lo mismo me ha sucedido al conectar las dos interfaces del servidor HP al switch 3Com, después de haber configurado los puertos del 3Com que iban a formar el trunk (dinámico) con éste.
  El resultado ha sido demostrado al observar la pestaña "Information" de la aplicación "HP Network Management Utility" del servidor HP, donde se indica que el modo usado es el 802.3ad dinámico.

En el caso del switch D-Link, no he podido crear el trunk dinámico, lo he tenido que dejar en estático, ya que este modelo no implementa el LACP. LACP (Link Aggregation Control Protocol) es un protocolo de capa 2 que permite gestionar trunks de manera automática mediante el envío de tramas específicas para este fin; por lo tanto aunque se active la característica LACP en uno de los dispositivos, si el dispositivos del otro lado no lo soporta o tiene dicha característica desactivada, no servirá de nada ya que se enviarán tramas que serán descartadas por el dispositivo que no lo implementa ya que no las reconocerá.

Creo que será importante valorar los modelos de switches que queramos adquirir si queremos explotar esta característica además de valorar si nos va a ser útil o no que los trunks puedan ser dinámicos, importante si queremos tener una gestión más automatizada y además tener una mejor gestión automática de tolerancia a fallos ya que LACP desactiva un puerto cuando detecta que hay un fallo de conexión permanente (fallo de alguno de los elementos del medio físico), en cambio con un trunk estático, no se produce la desactivación, ya que no se detecta, provocando que se continúe enviando tramas de datos, aunque posteriormente se detecten los errores en los protocolos de capa 2 y se proceda con el reenvío, hasta conseguirlo, claramente será posible si finalmente se reenvía por alguno de los puertos cuyo funcionamiento es el adecuado.

Hasta la próxima enfermos.

Jugando con los Switches: Port trunking (2/3)

conjuntoEntradas() {

  Jugando con los Switches: Port trunking (1/3)

  Jugando con los Switches: Port trunking (2/3)

  Jugando con los Switches: Port trunking (3/3)

}

Creando los Trunks

Ahora que ya he explicado un poco de que va todo esto, ya puedo pasar a explicar como se crean los trunks.

Lo primero que hacemos es crear el trunk en cada uno de los dispositivos unidos por el trunk; menciono dispositivos porque el trunk puede crearse entre switches o entre switches y dispositivos terminales como sería un servidor. Esto es importante tenerlo presente porque sino todo esto no va a funcionar, ya que entonces estaríamos, en el caso de interconectar dos switches, creando bucles en la red los cuales serían anulados por el propio STP.

Por otra parte, cada fabricante de switches distribuye la interfaz de administración a su propio criterio, por eso en función del fabricante y modelo del switch, la parte de la interfaz de administración para crear los trunks puede variar, no obstante los pasos de manera genérica son:

1. Accedemos a la interfaz web de administración del switch.
2. Accedemos al apartado de configuración del Port Trunking.
3. Seleccionamos los puertos que interconectan con el otro dispositivo y con el cual vamos a crear el trunk.
4. Guardamos los cambios.

También tenemos que tener en cuenta que en función del fabricante y el modelo que tengamos (dando por supuesto que soporta la creación de trunks) podremos crear más o menos grupos de trunks y cada trunk estará limitado a un máximo de número de puertos.

D-Link DGS-1248T

Accedemos a la interfaz web, nos validamos (para los que puedan llegar a pensar en ..., si he cambiado el usuario y contraseña de acceso que viene por defecto) y accedemos a la configuración de trunks(menú de la parte izquierda "configuration --> Trunks")

Una vez allí damos un nombre a cada trunk (yo le asigno un nombre que me recuerde que conecta el trunk para que cuando tenga varios sepa que conecta cada uno)y marcamos en los checkbox a que trunk pertenece cada puerto, en el caso que pertenezca a alguno.

Pantalla de configuración de trunks del D-Link DGS-1248T

HP ProCurve 1800 24G

Una vez que ya hemos accedido a la interfaz web de administración del switch, nos posicionamos dentro de la sección "Trunks", que encontramos en el menú de la parte izquierda, y dentro de esta, en la subseción "LACP Setup", lo hacemos así y no definiendo manualmente en la opción "Membership" porque en este caso vamos a crear trunks dinámicos no estáticos, estos dos conceptos los aclararemos más adelante.

Marcamos los checkbox de los puertos que queremos activar el LCAP.

Pantalla de activación del LACP sobre puertos del HP ProCurve 1800 24G

3Com 2924-SFP Plus

Accedemos al switch como hemos hecho con los dos anteriores y después accedemos a la administración de los trunks en la ruta "Port --> Link Aggregation" pestaña "create", del menú de opciones de la parte izquierda.

La interfaz es algo distinta de los otros dos, en ella creamos cada trunk, seleccionando los puertos del esquema gráfico que representa el frontal del switch, asignamos un número de identificación para el trunk (sería el homologo al nombre del trunk que el D-Link nos permite introducir), e indicamos que si queremos que el trunk sea estático (Static) o dinámico (LACP) y finalmente le damos al botón "Apply".

Pantalla de configuración de trunks del 3Com 2924-SFP

En esta misma pantalla de creación, nos aparece en la parte inferior un cuadro resumen con todos los trunks creados, sus puertos asociados y el tipo, estático o dinámico. Además en el esquema de puertos del frontal del switch nos aparece el número de cada puerto, a excepción de los puertos que forman parte del algún trunk, en ese caso aparece el número de identificación del trunk (lo que en la interfaz se específica como "Group ID").

Hasta la próxima enfermos

Jugando con los Switches: Port trunking (1/3)

conjuntoEntradas() {

  Jugando con los Switches: Port trunking (1/3)

  Jugando con los Switches: Port trunking (2/3)

  Jugando con los Switches: Port trunking (3/3)

}

Un poco de historia
Ahora, que ya hace unas semanas atrás, que en la empresa hemos podido conseguir en su totalidad, en el caso de la delegación donde yo estoy, unos switches más adecuados para

1. El tamaño de la red de la delegación.
2. Uso que le damos a la red.

He podido empezar a jugar con ellos y poner en marcha funcionalidades que ofrece que nos van a permitir mejorar el rendimiento de interconexiones entre ellos mismos y servidores de ficheros con gran número de peticiones, siempre que estos últimos estén preparados para ello.

Inroducción
En esta entrada voy a tratar (aprovechando que que todos los switches que tenemos actualmente en la delegación implementan la funcionalidad) de lo que se llama link aggregation, dentro del cual se incluyen otros términos muy relacionados, y como nó, podéis encontrar en la propia definición de link aggregation de nuestra amada Wikipedia, que al menos a mí me ha sido bastante útil para ver de que se trata, además de poder saltar a otra información relacionado con el tema que también puede ser de interés, por lo tanto básicamente voy a decir básicamente de que se trata y no a extenderme mucho más ya que no es el objetivo de este post.

Link aggregation nos permite utilizar varios puertos de conexión (por ejemplo puertos ethernet) como si se tratara de uno solo, permitiendo de esta manera aumentar los límites de capacidad asociados a un solo puerto; resumiendo usamos varios puertos físicamente distintos pero lógicamente funcionan como uno de solo.

Beneficios
Creo conveniente enumerar os beneficios de la utilización de link aggregation ya que es el eje principal de haber experimentado la funcionalidad y posteriormente ponerla en práctica y ahora escribir la experiencia sobre este post.

En fin los beneficios son:

1. Aumentar el rendimiento máximo que nos ofrece un solo puerto físico utilizando varios de ellos pero funcionando como un solo puerto lógico.
2. Balanceo de carga entre los distintos puertos.
3. Redundancia, para asegurarnos el mantenimiento de la conexión en caso de fallo de alguno de los puertos.

Aunque los beneficios parecen muy claros surgen ciertas limitaciones sobre alguno de estos, en ellas nos encontramos:

• La redundancia se ve limitada por el estado actual del estándar el cual no define la manara de que los puertos físicos agregados vayan interconectados a distintos dispositivos, es decir que si uno de ellos conecta con un dispositivo, por ejemplo de un switch A a otro B, el resto tienen que ir conectados por a los mismos por lo que la redundancia queda limitada a fallos únicamente en puertos y/o cableado de interconexión de un puerto, por lo tanto si uno de los dispositivos decide abandonarnos, la redundancia no nos va a salvar el culo.
  Aunque el estándar no define este asunto, ciertos fabricantes (ya sabemos que estos siempre suelen ir por delante de los estándares, bueno es lo que les toca para mantener una buena línea de negocio) ya han creado protocolos cerrados que permiten que los puertos agregados vayan conectados entre distintos dispositivos (siempre que todos sean de su firma) y de esta manera garantizar una redundancia real. Esto mismo sucede cuando varios switches están interconectados por diferentes caminos, algo que el STP controla, solo dejando habilitado el de menor coste, pero que en el caso que falle habilita el siguiente con menor coste para garantizar la conexión; pero en el caso de link aggregation no se deshabilitan sino que se utilizan para aumentar la tasa de transferencia.
• El balanceo de carga se ve afectado por el mismo concepto que la redundancia, provocando que el balanceo solo se produzca entre puertos y cables, pero si lo que está saturado es uno de los dispositivos no se puede balancear nada.

Por otra parte aunque no encuentro que sea una limitación hay que tener en cuenta que todos los puertos agregados sobre un grupo tienen que tener las mimas capacidades de velocidad de transmisión, es decir que si uno es gigabit el resto tendrán que también ser lo; no obstante esto no limita a que los distintos puertos tengan distinto tipo de conexión física (ethernet, fibra, etc).

Hasta la próxima enfermos.