Entradas populares

Mostrando entradas con la etiqueta evolución del switching. Mostrar todas las entradas
Mostrando entradas con la etiqueta evolución del switching. Mostrar todas las entradas

miércoles, 23 de abril de 2014

Google's Pluto Switch: SDN previo a Arista

Google es mucho más que unos locos que hicieron un buscador minimalista. Esto a estas alturas creo
que lo tiene claro todo el mundo. Creadores del mejor GPS navegador para coche que ha habido, creador de un nuevo sistema de indexación que en España llega a un 90% de utilización, google street view, google apps....es inacabable la lista de aplicaciones maduras que han llegado y las han desbancado desde la primera versión de producto. Pues en uno de esos ejercicios de creatividad y de punto de vista multidisciplinar, han creado su propia plataforma de switching con
inteligencia distribuída, fuera del hierro. Sí, una verdadera SDN con hardware que han comprado aquí y allá(broadcom como muchos otros para las ASICs).
http://www.wired.com/wiredenterprise/2013/03/big-switch-indigo-switch_light/
En este sentido os recomiendo mirar las webs de pica8.com o http://cumulusnetworks.com que son soluciones parecidas.  Según Wired este proyecto es la chispa que enciende el proyecto que hoy en día conocemos como Arista.
Hth,
Robclav


miércoles, 16 de abril de 2014

SDN: En la "Arista" de la Ola

Tengo que entonar el mea culpa respecto a Arista. Yo como muchos de los partners tradicionales de networking hemos estado anclados a la solidez y la solución de caja negra que eran los switches/routers. Se nos ha abierto una nueva forma de entender el networking, pasando el control a centros de toma de decisión
en equipos externos de orquestración o aplicaciones creadas ex-profeso.
https://gregness.wordpress.com/2008/10/24/recession-induced-network-innovation/
Cambiar de pronto tu forma de entender las redes es cambiar la medida de los proyectos, los conocimientos necesarios para abordarlos, la forma de realizar troubleshooting e incluso el interlocutor a quien le explicas el proyecto.
Hemos discutido habitualmente si era mejor JUNOS que IOS, por que IOS ha evolucionado a NX-OS o
IOS-Xr, pero cual es el motivo de fondo?
En mi caso parte del diagnostico era correcto, respecto a la disponibilidad en todo momento de la IOS y operación 24/7 pero no supe relacionar la importancia de la virtualización con las redes.
Los creadores de Arista Networks(Creadores de los cores de Catalyst), si que hicieron esa lectura y se adelantaron al futuro. Estos equipos permiten desde hace unos años, lo mismo que empieza a anunciar Cisco con los Nexus 9000 y la arquitectura orientada a aplicaciones: Cisco ACI.
Hth,
Robclav

lunes, 11 de marzo de 2013

Software Defined Networks: Recuerda este nombre

La virtualización o abstracción de la parte hardware es consustancial a la informática. Desde los primeros ordenadores, se buscó la independencia de la arquitectura y organización hardware de los modelos de Von Neumann y Harvard. Y este proceso sigue su camino en forma de virtualización de escritorios, aplicaciones, servidores, almacenamiento, balanceadores, firewalls y todo aquello que está por encima de capa 3. 
http://enterprise.alcatel-lucent.com/?dept=Editorials&page=2013GartnerDataCenterMQ

¿Cómo acaba la película? Con la parte de switching y routing desnaturalizada en forma de silicio de conmutación anodino. En todo esto, los servicios ofrecidos en la nube han empujado con fuerza, la necesidad de sistemas de provisión que no solo levantasen máquinas virtuales, más cpus o memoria, sino también mayor número de puertos físicos, seguridad y QoS asociado a diferentes flujos.


Lo curioso de todo es que ya existen frameworks como NOX y plataformas para SDN de Cloud como Meridian que dan forma al concepto. Y fabricantes de multilayer switches que tienen separada la parte de dataplane y controlplane, y que mediante una controladora se toman las decisiones. Es el caso de Xsigo que ha sido comprada por Oracle. 


Por otra parte, la SDN además de separar la capa de "data plane" de la parte de toma de decisiones, comporta otro salto evolutivo muy importante, que apoya los pasos hacia las reglas reputacionales. Se trata de automatizar las acciones de provisión y remediación en función del comportamiento del tráfico extraído con OpenFlow. Esto es trasladar a la parte de transporte, el comportamiento de profiler/auditor del NAC.
Mi opinión es que de la misma forma que ya no se programa en ensamblador, y se utiliza un lenguaje de alto nivel, en networking, ya no se programará en CLI, sinó en un lenguaje de alto nivel de redes. 
Este post es mi resumen  de una serie de artículos de la revista de Communications IEEE de Febrero 2013. Así que si supongo que en la web, también podéis encontrar mas info, respecto a las empresas que trabajan con SDN habían muchas en el MWC
como Tellabs.  
Hth,
Robclav



sábado, 9 de febrero de 2013

El gancho de los Nexus

Según algunos analistas, las claves de de los Nexus son tres pilares de Nexus son los Virtual Port Channel, Fabric Ethernet, y los Fabric Extenders. Y como es evidente todo esto va asociado a la unión del almacenamiento a la virtualización,  pero que le ha ido muy bien a los defensores de las redes planas ¿Pero entonces quien parece que son los grandes perdedores? MPLS y la extensión de nivel 3 para sustituir el Spanning tree.

 Evidentemente esto que estuvo promulgando Cisco como la gran solución(En los últimos networkers que ahora se llama Cisco Live), al supuesto problema de crecimiento de la redes grandes (que era un problema de diseño solo de Europa), presuponía un entendimiento de la importancia de las comunicaciones en el negocio. Pero los clientes, muchas veces tienen gente formada en sistemas, desarrollo o incluso simplemente en gestión, por lo que buscan simplemente redes "plug and play".
Este concepto de las comunicaciones es de fácil identificaciones, con redes planas, redes grandes y multiservicio. En ese caso, es imposible promover una evolución hacia un nivel tres dinámico.

El otro gran problema que hizo fracasar esta tendencia fue el elevado coste de hardware de switching, y que muchas aplicaciones están diseñadas para buscar recursos en la propia lan.

Lo que estoy deseando ver, es como funciona los mecanismos antibucles basados de nuevo en el algoritmo de Dikstra. Si, si como suena, funciona igual que la parte de chasis virtual de los Juniper.
Hth,
Robclav

lunes, 27 de febrero de 2012

Término FABRIC y elección de producto: Switching Evolution (3)

La gran familia de fabricantes de switches parece que no se ponen de acuerdo, en como abordar conjuntamente la vuelta al Fabric. Por cierto este termino se acuña a las redes tipo full mesh en ethernet. El termino surgió de una simplificación publicitaria de esta interconexión donde se dibujo como una matriz NxN. La representación gráfica de una matriz grande NxN, se parece a un tejido, y por el recuerdo de las FABRICas textiles, se acuño el termino FABRIC, a este tipo de interconexión.


 Volviendo al PROBLEMA de elección de un producto, explicar que en este caso la tecnología es lo suficientemente nueva para que todos defiendan sus intereses en la arena IEEE.  Esto hace determinante la elección de producto porque no son compatibles entre ellos, y cada uno tiene su nomenclatura y gama de producto.  Como ejemplo de esto, serían:Cisco’s FabricPath(Nexus 7k), Brocade’s VCS,HP/HUAWEI flex fabric y IRF(como el cisco vss), Juniper QFabric (QFXseries)y Arista.
En esta elección algunos puntos a tener en cuenta serían:

  1. Alineados con el estándard: Cisco, Brocade,  y Arista.
  2. Fabric Switching con equipos pequeños: Juniper, Arista, HP y Huawei.
  3. Integración de SPT en extremo: CISCO, Brocade y Arista.
  4. Mejor rendimiento: Juniper, Brocade.
  5. Menor complejidad de configuración hardware: Juniper y Arista.
  6. Mas extendidos en EEUU: Cisco, Juniper y Brocade.
  7. Duales SPT/TRILL, BROCADE
Conclusión de la elección: No es una decisión más, en función del tamaño de la red actual y futura, de la tecnología de virtualización, de la heterogeniedad de fabricantes presentes y del presupuesto del bolsillo, variará la mejor elección de fabricante.
Este post, tiene tres partes que saldrán cada lunes. 
Si te ha parecido interesante o te ha gustado, visita alguno de los patrocinadores que tengo en forma de anuncios.
Robclav

lunes, 20 de febrero de 2012

Switching Multipath: Switching Evolution (2)

Y todo esto de la muerte de Spanning-tree, ¿supone una evolución del switching?
Sí, el hecho de tener múltiples caminos de nivel 2 y nivel 3 activos permite optimizar mucho los recursos por una parte.
 Pero por otra parte, introduce tecnologías antiguas de sobra conocidas a nivel de operadora como puede ser encapsulado de trunks 802.1q mediante metroethernet o QinQ, redes de transporte multitenancy, o provisión en caliente de las políticas granulares de los puertos incluso en función de máquina virtual. 
http://blog.ioshints.info/2011/11/data-center-fabric-architectures-almost.html
Así que todos los fabricantes conocen la importancia de disponer de soluciones verticales que tengan en cuenta la funcionalidad mágica de "mover" en caliente los servidores entre diferentes sistemas. Este avance popularizado por la gente de VMWARE, no se puede hacer frente tan solo con un estándar "in jure" como TRILL pero con competidores propietarios "di facto".  
Parte de esta suite, serían: 802.1aq (SPB) Shortest Path Bridging, 802.1Qbg (EVB) , 802.1bh (Port extenders), VxLAN. 
Estos últimos se centran en la provisión en caliente de los puertos de acceso de los servidores.. Y lo que es más importante, ¿qué pasa cuando pasamos por interconexiones de nivel 3?Formas de solucionar los problemas de red de VMWARE VMOTION

Este post, tiene tres partes que saldrán cada lunes. 
Si te ha parecido interesante o te ha gustado, visita alguno de los patrocinadores que tengo en forma de anuncios.
Robclav

lunes, 13 de febrero de 2012

Killing Spanning-tree: Switching Evolution (1)

Spanning-tree ha muerto y nosotros lo hemos matado. Esto es lo que puede afirmar los impulsores de TRILL y el fabric switching. Este nuevo protocolo de sus siglas en inglés, Transparent Interconnect of Lots of Links. Es un estándar de IEEE RFC 6325 7/2011, similar a MLAG pero que incorpora una nueva arquitectura a medio camino entre bridging y routing. 
Independiente de la capa de routing, trabaja a capa 2 mediante el protocolo basado en el protocolo de "estado de enlace" IS-IS, es compatible con IPV4 e IPV6 y deja relegado Spanning-tree en los extremos de acceso de los equipos.


El objetivo para implementar esta arquitectura nueva conocida como Fabric Switching, es bajar el funcionamiento de los protocolos de routing dinámicos a capa 2. Permitiendo tener activos TODOS los enlaces a la vez, a diferencia de lo que pasa actualmente, que tienes un camino activo y el resto bloqueados.


Es el camino inverso que se realizo con MPLS, con el que se pretende acelerar el enrutado de paquetes "enrutando vlans" simplificando el concepto, pero no exactamente(Con esta analogía me excomulgan de todos los foros de MPLS). Vamos, se pretende poder descargar a los procesadores de los routers de la tarea principal.


Imagen mental: Se crea un bridge gigante,donde es conectar todo con todo y nos olvidamos de los temas de SPT. Vuelta al hub!!!!!


Target de este tipo de solución, CAMPUS o gran empresa. Revisa, la siguiente presentación que resume la filosofía de los principales fabricantes:
ultimate-guide-to-the-flat-data-centre-network/ 


Este post, tiene tres partes que saldrán cada lunes. 
Si te ha parecido interesante o te ha gustado, visita alguno de los patrocinadores que tengo en forma de anuncios.
Robclav







miércoles, 30 de noviembre de 2011

¿Un Porche por comarcales es un CPD con switches obsoletos? Conociendo Arista Networks

Esto es lo que muchos de nuestros clientes tienen en su CPD, Superservidores en una red terriblemente obsoleta y por lo tanto lenta. Es algo así como comprarse un Porche para intentar correr por un campo de patatas. Lo malo es no plantearse que el campo de patatas es el problema de no alcanzar la velocidad deseada.


Por ejemplo, el caso más sangrante sería los clientes que apuestan por CISCO Catalyst cosa que ni Cisco hace, ya que a nivel de arquitectura no los ha evolucionado. Es más, reconociendo su debilidad en este campo y el gran peso en la facturación 41% del switching, introdujo a los Nexus como fuga hacia delante.


Llegados a este punto, comentar que los Nexus son los equipos pensados para almacenamiento SAN, reconvertidos a networking genérico con un sistema operativo modular. El problema de IOS, lo he comentado previamente no es nuevo. Lo único que me sorprende es que un cliente siga comprando tecnología de hace 15 años cuando en todo el resto, no acepta algo con más de dos años.


Ahora las buenas noticias, los desarrolladores de Catalyst, si han evolucionado los mismos. Y estos equipos se llaman Arista Networks. Son los Ferrari de nuestros CPD con precios de turismos. En otras palabras, son los equipos con MENOR LATENCIA del mercado, SIN SOBRESUBSCRIPCIÓN y  además con un sistema operativo (EOS) modular que permite integrar todas la herramientas necesarias para tener todas las variables controladas.
El otro día, estuve en un evento donde explicaban algunos productos rompedores del mercado, y entre ellos estaban los Arista. 
Simplemente viendo la gente que tiene por detrás, el tipo de producto que sacaron en su momento(Catalyst era una empresa externa a CISCO) ya te puedes hacer una idea de lo que es capaz una promachine con enlaces giga, ten giga y 40 gigaEthernet con la mayor densidad de puertos, que soporta TODOS los puertos transmitiendo.
Ya para finalizar, comentar que estos equipos fueron diseñados a nivel de hard para soportar nativamente IPv6 y virtualización de servidores. Siendo los primeros en tener la integración con la VMWARE.


MANTRA a repetir, no montaré cluster super exigentes sobre infraestructura de transporte obsoleta, y me miraré  http://www.aristanetworks.com.




hth,
RobClav