Hola estimado lector,
¿Cómo estás?
Empecemos por decir que hacer un buen troubleshooting cuando las cosas se ponen feas depende mucho de tu conocimiento y de todas las herramientas que tienes a tu disposición, la diferencia entre un impacto leve y un impacto grave puede ser simplemente la velocidad en la que logras solucionar, en este post de Net4DD [Networking para el día a día] queremos darte una guía de como estructurar tus diagramas de red y explicarte por que son de fundamental importancia para tu día a día.
| Contenido |
| Antecedentes |
| Documentación de red |
| Diagrama físico vs Diagrama lógico |
| Diagramas por Capas |
| Conclusión |
Antecedentes
Seguramente en tu experiencia como soporte para Networking has pasado por la situación de tener que resolver una falla y no tener la menor idea de por dónde empezar, seguramente pides una descripción de los síntomas del problema, equipos envueltos en el escenario, datos relevantes de los servicios afectados y demás. Es posible que obvies algunos de los puntos anteriores, pero podría apostar que en el 99.996% de los casos siempre has preguntado por el diagrama de red. En otro escenario, quizas seas un administrador que conoce a profundidad su red, pero estes en el mar caribe disfrutando de tus vacaciones cuando entra esa llamada del trabajo y todos te preguntan por detalles que pudieron haber quedado correctamente documentados.
Documentación de Red
Sabes que muchos fallos y tiempos altos de resolución de problemas en red se dan por la falta de una óptima documentación, sobre todo unos buenos y bien descriptivos diagramas de red. Si has tenido la oportunidad de conocer muchas redes y diferentes infraestructuras, seguramente te identificas con esta situación: preguntas por la documentación de la red y te entregan diagramas de excesivo alto nivel, seguramente una ppt, con conexiones de líneas sobre fotos de equipos que muchas veces no son los que tienen en operación actualmente, y finalizando con la frase “espera y llamamos a John Doe que se acuerda de cómo están conectados los equipos”. A continuación te voy a dar unos tips muy simples para que este no sea tu caso y puedas generar unos diagramas con los detalles mínimos para representar tu red.
Diagrama físico vs Diagrama lógico
El primer paso en el camino de poder tener una información suficientemente efectiva para el mantenimiento y troubleshooting de la red es tener topologías muy bien documentadas. Es necesario hacer una distinción muy importante, y es entender de fondo que no siempre los diagramas físicos y los diagramas lógicos son 100% equivalentes, por lo cuál posiblemente sea recomendable que tengas por lo menos un diagrama físico y uno o varios lógicos dependiendo de las soluciones críticas que tienes implementadas.
El diagrama físico representa las conexiones físicas entre diferentes equipos y tiene como intención representar puertos físicos, tipos de cables, y todo lo relevante a la parte de interconexión entre diferentes maquinas que componen una solución. Imagina una situación donde en medio de una migración un servicio fue afectado, con un simple diagrama físico podrías tener ese servicio de vueltas en cuestión de cortos minutos, inclusive si no estas en sitio lo que lo hace mas mucho mas relevante. Entre otras cosas, desplegar servicios nuevos donde las instalaciones físicas deben ser ejecutadas por terceros requieren que estos diagramas sean lo suficientemente detallados para garantizar un excelente trabajo.
Por ejemplo en el diagrama a continuación represento una conexión back to back entre dos parejas de switches configurados como MLAG, en este caso por ejemplo puedo usar etiquetas para los diferentes tipos de cables dependiendo de los colores, si te fijas en detalle cada tipo de cable tiene la descripción en su etiqueta, también está descrito el puerto de origen y destino, la intención de este diagrama es detallar la conectividad a nivel fisico al más bajo nivel posible, con el fin de facilitar tareas de mantenimiento, validación de problemas de conexión y demá, sobretodo cuando no estas directamente en sitio y requieres asistencia de manos remotas:
Es posible que requieras incluir más elementos, como servers por ejemplo, obviamente no vas a incluir los 40 servers que tienes en el Datacenter, sin embargo, si hay roles especiales en sus puertos podrías incluir esto dentro del diagrama para alguno, y usarlo como template de conectividad, como se ve en el siguiente ejemplo:
El diagrama lógico busca representar la solución a nivel de servicio de red, o flujo de tráfico, o inclusive funcionalidades dentro de la arquitectura representada. No siempre la relación con el diagrama físico es 1:1, y esto debido a que en ocasiones se puede tener convergencia de varios servicios en un mismo equipo de red, pero representa varias soluciones, por ejemplo, un equipo que concentre tráfico LAN y iSCSI. Esto es al mismo tiempo tráfico front-end (LAN) y back-end (SAN), creo que este ejemplo sencillo nos puede dar una visibilidad de la importancia de este tipo de diagrama. Por ejemplo el diagrama a continuación tiene como fin lograr una representación de una solución que involucra Campus y Datacenter:
Diagramas por capas
En lo que respecta a temas de networking es muy popular tener un esquema de 3 diagramas:
- Diagrama de capa 1: Lo ideal de este diagrama es representar la conectividad a nivel físico, es decir las conexiones entre equipos, posiblemente denotan los puertos a usar y los medios de conexión con etiquetas y demás. Es equivalente al diagrama físico mencionado en la primera parte.
- Diagrama de capa 2: En este caso podemos representar en el diagrama servicios asociados a VLANs específicos, o simplemente representar los conjuntos de VLANs por Servicios sobre las conexiones, por ejemplo usar colores para representar dominios de fallas y su VLAN en diagramas para iSCSI es una práctica común. Acá no nos interesa tanto la parte de conexión y tipos de cables, pero si representar los servicios.
- Diagrama de capa 3: Este no siempre se utiliza, pero en escenarios con routing dinámico o con redistribución, múltiples protocolos, tipos de redes, etc, es bastante útil para saber dónde se demarca un protocolo de routing o un sistema autónomo. Esto nos permite tener mayor visibilidad de cómo funcionará nuestra red a nivel de estos servicios de conectividad entre redes.
Conclusion
Espero que hayas tenido un poco más de visibilidad de lo crítico que es la documentación apropiada como herramienta de troubleshooting básico de la red. Quienes han tenido que enfrentarse a ambientes nuevos donde hay fallas saben que tener un buen diagrama es más efectivo que tener que reconstruir la red desde 0 (cuando no tienes herramientas de gestión) totalmente por CLI utilizando LLDP o CDP.
Ten presente que no es una camisa de fuerza como debes estructurar tus diagramas, sin embargo, ten presente que el nivel de detalle es importante, sobretodo cuando quieres diferenciar una solución en sus componentes físicos y lógicos. Trabájalos pensando en que cualquiera que los vea pueda rápidamente asimilar los características de tu solución.
Como ultimo recuerda ¡un gran administrador no deja nada a la memoria!
Por ultimo, dejanos tus comentarios y no olvides subscribirte a nuestro newsletter con un par de clicks nomas.