El Camino

Como se prometió, aquí está la segunda parte del blog por el autor de la Guia de Estudio CCDE de Cisco Press, Marwan Al-shawi. Disfruten. - Brett Lovins, Community Manager

En la primera parte de este blog se discuten brevemente las similitudes entre “Arte” y “Diseño de redes”. Adicionalmente, se resaltó cómo la Guía de Estudio CCDE les ayudará a ser mejores diseñadores de redes en general, y, particularmente, a prepararles para el Examen Práctico CCDE, de la mano con el enfoque sugerido por mí para leer este libro. Por otro lado, esta segunda parte del blog, se enfocará en un tópico muy importante y crítico - “Cómo pensar como un diseñador de redes”. Para simplificar, usaré un mini escenario que se centra en dos principios de diseño que son primarios, para demostrar “cómo” el pensamiento y enfoque de un diseñador de redes o arquitecto ante cualquier proyecto puede influenciar las decisiones del diseño y los resultados generales. En otras palabras, aun si la tecnología o la opción de diseño seleccionada es técnicamente válida, podría no ser la óptima. ¿A qué se refiere esto exactamente?

En varias contrataciones de consultoría y diseño, he visto muchas redes diseñadas de una manera que, o es muy difícil de administrar, o el equipo de IT sufre limitaciones de escalabilidad cuando tratan de responder a las necesidades de su organización (como abrir nuevos sitios remotos or agregar un nuevo centro de datos). De hecho, cualquier diseño de redes exitoso a largo plazo está determinado en una gran medida por las decisiones que los diseñadores o arquitectos tomen. Por lo tanto, los problemas resaltados anteriormente suceden casi siempre debido al hecho de que diferentes lugares de la red (PINs por su siglas en inglés - Places In Network) están diseñados de manera aislada, o la red está diseñada solamente para satisfacer los requerimientos de hoy en dia (a veces una combinación de ambos). En cualquier caso, muy probablemente, esto conducirá a decisiones de diseño subóptimas. El escenario a continuación explicará esto en más detalle: 

XYZ es un minorista que está expandiendo su presencia rápidamente a través de la región de Norteamérica, y su equipo de TI contrató a un consultor de redes para ayudarles con el rediseño del proyecto de su red internacional. Lo siguiente resume la red actual de XYZ y algunos de los nuevos requerimientos (ver figura 1):

  • 2 Centros de Datos (DCs por sus siglas en inglés - Data Center) con un plan futuro para agregar un 3er centro de datos (DC)
  • MPLS L3VPN habilitado a traves de WAN global
  • Las sedes remotas están conectadas a la WAN global (routers hub) sobre la red separada de otro proveedor (MPLS L3VPN)
  • Tráfico interno de empleados necesita ser separado del tráfico de contratistas (desde todas las sedes remotas y a través de la WAN y los DCs)
  • El consultor de redes/arquitecto/diseñador debe realizar una prueba de concepto (POC por sus siglas en inglés - Proof Of Concept)  de la solución propuesta, utilizando la región 3 de sedes remotas con conectividad de extremo a extremo con el DC primario.

 

Blog-part-2-Figure-1-Edited-Spanish.pngFigura 1


En este escenario, el consultor de redes se concentró, principalmente, en cómo cumplir los requerimientos y realizar una prueba de concepto exitosa usando la Región 3 como piloto para este proyecto. Como se muestra en la Figura 1, la Región 3 tiene 18 sedes remotas (un número relativamente pequeño de sedes remotas). Basado en esto, el consultor de redes decidió hacer uso de una solución sencilla que se basa en el aprovisionamiento de “Túnel GRE + VRF” por grupo de usuarios (Personal interno y contratistas) para cumplir el requerimiento de separación entre ellos de extremo a extremo, tal como se muestra en la Figura 2.

          Blog-part-2-Figure-2-2-Edited-Spanish.pngFigura 2


Técnicamente, cuando se considera esta solución, la red requerirá, al menos, los siguientes números de túneles GRE, que deberán ser creados y administrados:


  • Hub Region 1 : 100 Sedes remotas - 200 Tuneles GRE + 8 Túneles GRE desde el hub a los 2 DCs
  • Hub Region 2 : 80 Sedes remotas - 160 Tuneles GRE + 8 Túneles GRE desde el hub a los 2 DCs
  • Hub Region 3 : 18 Sedes remotas - 36 Tuneles GRE + 8 Túneles GRE desde el hub a los 2 DCs


Total de túneles GRE: ¡~420 Túneles! (Ver Figura 3)


Aunque esta solución es técnicamente válida y la prueba de concepto (POC) será probablemente un éxito, cuando el minorista comience a implementar esta solución a lo largo de sus diferentes regiones, así como también integrarla con su data center secundario, van a enfrentar muchos problemas, incluyendo:


  • Escalabilidad y flexibilidad limitadas (agregar un nuevo sitio remoto o considerar una nueva red virtual/VRF para los sitios remotos, requerirá muchos cambios con mayor complejidad)
  • Dificultad para administrar (aumento de complejidad operacional, tal como: dificultad para solucionar problemas)
  • Falta de resiliencia (incremento en la complejidad del enrutamiento para controlar flujos de tráfico a través de los DCs existentes y futuros, para aplicaciones alojadas en diferentes DCs)


Como resultado, esta solución introduce limitaciones al negocio para lograr sus metas y planes futuros. Sin mencionar la complejidad operacional y solución de problemas, que posiblemente aumentarán el riesgo de tener largas caídas/fallas de servicio cuando haya un problema de red.


Blog-part-2-Figure-3-3-Edited-Spanish.pngFigura 3


Como se resaltó anteriormente, el problema aquí es principalmente que el consultor de redes diseñó la red de manera aislada, enfocándose principalmente en la Región 3 y en el resultado prueba de concepto (POC) usando un DC para probar la exactitud de la solución. Este enfoque no considera los impulsores claves del negocio ni el panorama, para visualizar cómo la red lucirá cuando otras regiones se unan a la misma (Túneles GRE). Además, no se consideró algún plan futuro, por ejemplo, qué tan complejo y resiliente será este diseño cuando el minorista agregue el tercer centro de datos a su red (ver Figura 3).


Para proveer un diseño exitoso que funja como habilitador de negocio, se debe pensar como un diseñador/arquitecto, mirando más allá de los límites o solo los aspectos técnicos de la solución. En otras palabras, para proveer un mejor diseño para este minorista, XYZ, en el ejemplo de arriba se debe observar el panorama y emplear un enfoque integral, en lugar de diseñar de manera aislada. Con un enfoque holístico, simplemente se hace la pregunta: “¿Cómo se integrará esta solución con otras partes de la red? Como el DC primario o el secundario, otras regiones, el núcleo WAN MPLS, etc. El otro principio que debería haber sido empleado por el consultor de redes es “construir hoy pensando en el mañana”. Con este principio, no sólo se considerará con qué debe lidiar la red hoy, sino que también se comenzará a mirar hacia adelante y pensar sobre qué planea hacer el negocio en el futuro y cómo puede impactar el diseño propuesto, tal como agregar nuevas redes virtuales, nuevos DCs, aplicaciones, o fusionarse con otra compañía.


Tomando estos dos simples, pero muy importantes principios en consideración, ustedes serán capaces de tomar mejores decisiones de diseño para respaldar las metas del negocio y los planes futuros, que son impulsados por algo más que solo aspectos técnicos.Tomando en cuenta lo de arriba, una solución optimizada posible para XYZ sería utilizar MPLSoDMVPN (2547oDMVPN). Esta solución ofrecerá lo siguiente (ver Figura 4):


  • Sencillez con alto grado de escalabilidad y flexibilidad (único túnel desde cada sede remota, agregar nuevas sedes remotas o redes virtuales no impactará o cambiará la capa overlay o diseño del núcleo de la red)
  • Resiliencia (Controlar el enrutamiento será más sencillo “Estilo L3VPN”)

 

Blog-part-2-Figure-4-4-Edites-Spanish.png Figura 4


La sencillez operacional acá es un poco discutible, porque, por un lado, esta solución ofrece un diseño de enrutamiento más simplificado y flexible, pero por otro lado, el mismo necesita personas con conocimientos avanzados de redes/experiencia en MPLS, MP-BGP, IGPs, etc.


Habiendo dicho eso, la información dada sigue sin ser suficiente para decidir si utilizar MPLSoDMVPN es la mejor opción para esta organización o no. Por ejemplo, las aplicaciones utilizadas dentro de esta red y sus características, no fueron especificadas, lo cual puede influenciar las decisiones de diseño en un alto grado. Sin embargo, este ejemplo no fue destinado para describir “qué” escoger, sino para ayudarles a aprender “cómo” pensar como un diseñador y tomar mejores decisiones de diseño.


Para resumir, la manera en la que piensen como diseñador/arquitecto de redes cuando aborden un proyecto, guiará sus decisiones de diseño y determinará significativamente que tan exitoso será su diseño. Por lo tanto, la mentalidad y enfoque deben ser diferentes de cuando abordan un proyecto como un ingeniero de implementación (mentalidad CCDE vs. mentalidad CCIE). Pensar como un diseñador siempre abrirá nuevas dimensiones a considerar en su diseño, que eventualmente les ayudará a tomar decisiones de diseño más sabias.


Sobre el autor


Marwan Al-shawi, CCDE No. 20130066, es un Ingeniero de Sistemas con Cisco Systems, Inc. y Autor de Cisco Press, cuyos títulos incluyen los principales libros de diseño de certificación de Cisco, CCDE Study Guide y Designing for Cisco Network Service Architectures (ARCH) Cuarta edición. Marwan tiene una Maestría en Ciencias en redes de la Universidad de Tecnología de Sydney. Le gusta ayudar y evaluar diseños y arquitecturas de redes; por lo tanto, fue seleccionado como Experto en Materia de Diseño (SME), por Cisco Learning Network, Cisco Designated VIP por la Comunidad de Soporte de Cisco (CSC) (foros oficiales de Cisco Systems) en 2012 y por la Subcomunidad de Soluciones y Arquitecturas en 2014. Además, Marwan fue seleccionado como miembro del programa Cisco Champions en 2015 y 2016.


Traductor voluntario del blog en Español: David Peñaloza

Versión original en Inglés: The Road to the CCDE – Part 2 with Marwan Al-shawi


A continuación, algunas maneras adicionales para integrarnos y mantener la conversación: