Juniper EX 4200

Juniper-Ex-WHoy he dedicado gran parte del día a una presentación en las oficinas de Juniper Networks en Alcobendas sobre los EX 4200, unos switches multicapa con un concepto de virtualización muy interesante.

El tema de la virtualización en switches personalmente me resulta muy interesante y estoy convencido que se trata del presente y del futuro de este tipo de arquitecturas, parece que el Spanning Tree tiene los días contados y todo gracias a la virtualización.

El EX4200 es un equipo que nos se entiende funcionando sólo, pero sí se entiende este equipo funcionando con otros equipos de la misma familia, la gracia reside en que estos equipos son capaces de funcionar como si se tratase de un equipo único, de forma que pueden comportarse como si fueran parte de un mismo chasis, pero siendo equipos independientes.

El backplane lo podemos emular con unos cables, que forman un bus de 32 Gbps full duplex, podemos poner 2, es decir, 64 Gbps full duplex de conexión entre ellos y podemos conectarlos de tal manera que podemos cerrar el anillo proporcionando una redundancia muy interesante.

Entre todos los equipos que formen el “virtual switch” resultante tendremos uno que asuma la tarea de master y otro que asuma la tarea de slave, el resto se comportarán como tarjetas de línea, aunque todos los equipos podrían comportarse como master o slave, este parametro es totalmente configurable.

A primera vista parece que estamos ante un equipo stackable, hasta que nos damos cuenta que no es únicamente el tráfico de control el que pasa por el bus posterior, sino que también pasa el tráfico de datos, además, podemos extender el backplane con los cables propietarios que tiene o utilizando puertos de 10Gbps, aunque en la versión 9.3 de Junos está previsto que también pueda usarse puertos Gigabit con SFP lo cual permitirá que sean puertos eléctricos u ópticos.

Por supuesto la gestión de los equipos que forman el “virtual swtich” es única, tanto entrando por telnet como por consola y podemos utilizar hasta 10 equipos en el virtual switch.

Además tenemos que tener en cuenta que Juniper se “ha tirado el rollo” y en la licencia básica incluye tanto OSPF como RIP (BGP no), con lo cual con la licencia básica tendremos un equipo virtualizable con capacidades de capa 3, que no está nada mal.

¿Donde poner estos equipos?, pues en el core yo no lo podría, aunque Juniper da esa opción, pero sí que es interesante como switches de acceso con uplinks de 10Gbps, algo que puede ser muy interesante en racks con Blades, pero no en racks con servidores normales ya que el coste por puerto se dispararía.

Y como todos los equipos de virtualización de capa 2 tiene la opción de utilizar un LAG (Link Aggregation Group, algo parecido al Etherchannel de Cisco) para unir equipos con varios uplinks sin tener que utilizar el mismo EX4200, es decir, proporcionando una redundancia en capa 2 que elimina la posibilidad de bucle y por tanto elimina la necesidad de utilizar Spanning Tree.

Pegas, pues la verdad es que también tiene, el hash que utiliza para el LAG no es configurable, y se realiza un hash basado en L2, L3 y L4, así que si tenemos un “elefante” que genera mucho tráfico del mismo tipo generará un balanceo poco óptimo, otro problema que tiene es la limitación de 64 LAG, una cantidad bastante baja teniendo en cuenta que podemos agregar hasta 480 puertos gigabit al virtual switch, esto hace que desde mi punto de vista no sea un equipo aconsejado para determinados tipos de tráfico muy concretos, aunque sí para otros usos.

Este es el primer equipo de “bajo coste” que permite virtualización y se coloca en un hueco en el mercado que no tienen los 6500 VSS de Cisco.

El equipo me ha gustado aunque encuentro que el número de LAG puede ser un problema para poner el equipo incluso en un nivel de distribución, aunque no así en acceso, pero como ya he dicho, el equipo creo que es el ideal para acompañar blades o sistemas de requieran un ancho de banda muy elevado, más de 2Gbps de uplink.

Para equipos de Core tendremos que esperar a los nuevos 8000 que saldrán en unos meses.

Más información en la web de Juniper

7 pensamientos en “Juniper EX 4200

  1. Cisco está preparando el contra ataque ya que lo máxima que tiene ahora en cuanto a stack es para tareas de control como ya se dijo.

    Juniper ha entrado muy fuerte en L3 y haber como le irá ahora en switching.

    Referente al post corregirte un par de temas:

    Un Etherchannel o un LAG no elimina la necesidad de utilizar SPT, si por ejemplo tienes un Core de routers y switch en maya con HSRP ya que estarías saturando un enlace como tuvieras mucho tráfico. Si utilizases GLBP puede ser que no hiciese falta SPT.

  2. @Galtu en este entorno no es necesario utilizar HSRP o VRRP ni nada parecido porque los dos switches virtualizados se compartarían como uno y tendríamos un interfaz al que se puede acceder desde los dos switches, en este entorno sería tontería usar además dos routers.

    Y tampoco sería necesrio GLBP siempre y cuando podamos agregar enlaces en el servidor por la misma razón

  3. Mi comentario va en función a que comentas que SPT tiene los días contados. Desde mi punto de vista aun queda SPT para rato (a los que le pese, jeje).

    Yo no me refería en mi post a únicamente el escenario que presentabas sino a cualquier escenario de backbone y distribución.

  4. Saludos,
    El mundodigital seguirá vivo por los blogs y porque pinchan másque los post-its.
    Me gustaría crear un blog en mifutura web. Y lo haré.

  5. Pingback: Transparent Interconnection of Lots of Links (TRILL) – Ethernet Multipath | eduangi.com

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>