Este artículo es el segundo de una serie titulada "Cómo tomar el control de la infraestructura de red". Puede encontrar el contenido de todos los artículos de la serie y los enlaces. .
Nuestra meta en esta etapa es organizar la documentación y la configuración.
Al final de este proceso, debería tener un conjunto completo de documentos y una red configurada de acuerdo con ellos.
En este momento, no vamos a hablar sobre la auditoría de seguridad; esto se abordará en la tercera parte.
La dificultad de la tarea planteada en esta etapa, por supuesto, varía bastante de una empresa a otra.
La situación ideal es cuando
- su red fue creada de acuerdo con el proyecto y tiene un conjunto completo de documentos
- en su empresa se ha implementado para la red
- de acuerdo con este proceso, dispone de documentos (incluidos todos los diagramas necesarios) que proporcionan información completa sobre la situación actual
En este caso, su tarea es bastante simple. Debe estudiar los documentos y revisar todos los cambios que se han realizado.
En el peor de los casos, tendrá
- una red creada sin un proyecto, sin un plan, sin coordinación, por ingenieros que no tienen el nivel de calificación suficiente,
- con cambios caóticos, no documentados, con una gran cantidad de "basura" y soluciones subóptimas
Es evidente que su situación se encuentra en algún lugar intermedio, pero, desafortunadamente, en esta escala de mejor a peor, es muy probable que se sitúe más cerca del extremo peor.
En este caso, se requerirá de usted, entre otras cosas, la habilidad de leer pensamientos, porque tendrá que aprender a entender lo que los "diseñadores" intentaban hacer, reconstruir su lógica, completar lo que no se terminó y eliminar "basura".
Y, por supuesto, necesitará corregir sus errores, modificar (en esta etapa lo más mínimamente posible) el diseño y cambiar o crear de nuevo los esquemas.
Este artículo no pretende ser exhaustivo. Aquí solo describiré principios generales y abordaré algunos problemas comunes que se presentan.
Conjunto de documentos
Comencemos con un ejemplo.
A continuación se presentan algunos documentos que se suelen crear en la empresa Cisco Systems durante el diseño.
CR – Requisitos del cliente, requisitos del cliente (especificación técnica).
Se desarrolla conjuntamente con el cliente y define los requisitos de la red.HLD – Diseño de Alto Nivel, diseño de alto nivel basado en los requisitos de la red (CR). El documento explica y justifica las decisiones arquitectónicas tomadas (topología, protocolos, selección de equipos,…). HLD no contiene detalles del diseño, como las interfaces utilizadas y las direcciones IP. Tampoco se discute la configuración específica del equipo. Este documento está más destinado a explicar al gerencial técnico del cliente los conceptos clave del diseño.
LLD – Diseño de Bajo Nivel, diseño de bajo nivel basado en el alto nivel (HLD).
Debería contener todos los detalles necesarios para la implementación del proyecto, como información sobre cómo conectar y configurar el equipo. Es una guía completa para la implementación del diseño. Este documento debe proporcionar suficiente información para su implementación incluso por personal no muy calificado.Cosas como, por ejemplo, direcciones IP, números AS, esquema de cableado, pueden ser 'externadas' a documentos separados, como NIP (Plan de Implementación de Red).
La construcción de la red comienza después de la creación de estos documentos y se lleva a cabo estrictamente de acuerdo con ellos y luego es verificada por el cliente (pruebas) para su conformidad con el diseño.
Por supuesto, los requisitos de la documentación del proyecto pueden variar entre diferentes integradores, diferentes clientes, en diferentes países. Pero nos gustaría evitar formalismos y considerar la cuestión en esencia. Esta etapa no se trata de diseño, sino de ordenar el proceso y necesitamos un conjunto de documentos (esquemas, tablas, descripciones…) suficiente para cumplir nuestras tareas.
Y en mi opinión, existe un mínimo absoluto sin el cual no es posible controlar la red de manera efectiva.
Estos son los siguientes documentos:
- esquema (registro) de cableado
- esquema o esquemas de la red con información sustancial de L2/L3
Esquema de cableado
En algunas empresas pequeñas, las tareas relacionadas con la instalación de equipos y el cableado están bajo la responsabilidad de los ingenieros de red.
En este caso, la tarea se aborda en parte con el siguiente enfoque.
- utilizar la descripción en la interfaz para detallar lo que está conectado a ella.
- Desactive administrativamente (shutdown) todos los puertos no conectados del equipo de red
Esto le permitirá, incluso en caso de un problema con el enlace (cuando CDP o LLDP no funcionan en esta interfaz), identificar rápidamente lo que está conectado a este puerto.
También podrá ver fácilmente qué puertos están ocupados y cuáles están libres, lo cual es necesario para planificar las conexiones de nuevo equipo de red, servidores o estaciones de trabajo.
Sin embargo, es evidente que si pierde el acceso al equipo, también perderá el acceso a esta información. Además, de esta manera no podrá documentar información tan importante como qué equipo hay, qué potencia consume, cuántos puertos tiene, en qué rack está, qué paneles de parcheo hay y a qué (qué rack/panel de parcheo) están conectados. Por lo tanto, una documentación adicional (no solo descripciones en el equipo) es muy útil.
La opción ideal es utilizar aplicaciones diseñadas para trabajar con este tipo de información. Pero también se puede recurrir a simples tablas (por ejemplo, en Excel) o mostrar la información que considere necesaria en esquemas L1/L2.
¡Importante!
Un ingeniero de red, por supuesto, puede conocer bastante bien los matices y estándares de cableado estructurado, tipos de racks, tipos de fuentes de alimentación ininterrumpida, qué es un pasillo frío y caliente, hacer una correcta conexión a tierra... así como también puede entender la física de partículas elementales o C++. Pero hay que entender que todo esto no es su área de conocimiento.
Por lo tanto, es una buena práctica contar con departamentos o personas dedicadas para resolver tareas relacionadas con la instalación, conexión, mantenimiento del equipo, así como también con la conexión física. Generalmente, para los centros de datos son ingenieros de centro de datos, y para la oficina, el help-desk.
Si se prevén tales departamentos en su empresa, entonces las cuestiones de llevar un registro de la conexión física no son su responsabilidad, y puede limitarse solo a la descripción en la interfaz y la desactivación administrativa de los puertos no utilizados.
Esquemas de red
No hay un enfoque universal para dibujar esquemas.
Lo más importante es que los esquemas deben proporcionar una comprensión de cómo fluirá el tráfico, a través de qué elementos lógicos y físicos de su red.
Por elementos físicos nos referimos a
- equipos activos
- interfaces/puertos de equipos activos
Por lógicos entendemos
- dispositivos lógicos (N7K VDC, Palo Alto VSYS, ...)
- VRF
- VLANs
- subinterfaces
- túneles
- zonas
- …
Además, si su red no es completamente básica, constará de diferentes segmentos.
Por ejemplo,
- centro de datos
- internet
- WAN
- acceso remoto
- LAN de oficina
- DMZ
- …
Es razonable tener varios esquemas que proporcionen tanto una visión general (cómo fluye el tráfico entre todos estos segmentos) como una explicación detallada de cada segmento individual.
Dado que en las redes modernas puede haber muchos niveles lógicos, un enfoque adecuado (aunque no obligatorio) es hacer diferentes esquemas para distintos niveles; por ejemplo, en el caso del enfoque de superposición, esto podría incluir los siguientes esquemas:
- overlay
- L1/L2 underlay
- L3 underlay
Por supuesto, el esquema más importante, sin el cual no se puede entender la idea de su diseño, es el esquema de enrutamiento.
Esquema de enrutamiento
Al menos, en este esquema debe reflejarse
- qué protocolos de enrutamiento se utilizan y dónde
- información básica sobre la configuración del protocolo de enrutamiento (área/número de AS/id del router/…)
- en qué dispositivos se realiza la redistribución
- dónde se realiza la filtración y agregación de rutas
- información sobre la ruta predeterminada
Además, a menudo es útil tener un esquema L2 (OSI).
Esquema L2 (OSI)
En este esquema puede reflejarse la siguiente información:
- qué VLANs
- qué puertos son puertos trunk
- qué puertos están agregados en el ether-channel (canal de puerto), canal de puerto virtual
- qué protocolos STP y en qué dispositivos se utilizan
- configuraciones básicas de STP: root/root backup, costo de STP, prioridad de puerto
- configuraciones adicionales de STP: BPDU guard/filter, root guard…
Errores característicos en el diseño
Ejemplo de un enfoque deficiente para construir una red.
Tomemos un ejemplo simple de construcción de una red local de oficina simple.
Con la experiencia de enseñar telecomunicaciones a estudiantes, puedo decir que prácticamente cualquier estudiante a mediados del segundo semestre posee el conocimiento necesario (dentro del curso que impartí) para configurar una LAN de oficina simple.
¿Qué hay de complicado en conectar switches entre sí, configurar VLAN, interfaces SVI (en caso de switches L3) y escribir enrutamiento estático?
Todo funcionará.
Pero aún quedan preguntas relacionadas con
- la seguridad
- la redundancia
- la escalabilidad de la red
- el rendimiento
- el ancho de banda
- la fiabilidad
- …
A veces escucho la afirmación de que una LAN de oficina es algo muy simple y lo suelo oír de ingenieros (y gerentes) que se dedican a todo menos a redes, y lo dicen con tanta seguridad que no se sorprendan si la LAN es realizada por personas con prácticas y conocimientos insuficientes, cometiendo aproximadamente los errores que describiré un poco más abajo.
Errores característicos de diseño de nivel L1 (OSI)
- Si de todos modos usted es responsable también de la CCSI, uno de los legados más desagradables que puede heredar es una conmutación descuidada y poco reflexionada.
También al tipo L1 incluiría errores relacionados con los recursos del equipo utilizado, por ejemplo,
- ancho de banda insuficiente
- TCAM insuficiente en el equipo (o un uso ineficaz del mismo)
- rendimiento insuficiente (a menudo se refiere a firewalls)
Errores característicos de diseño de nivel L2 (OSI)
A menudo, cuando no hay un buen entendimiento de cómo funciona STP, qué problemas potenciales acarrea, los switches se conectan de manera caótica, con configuraciones predeterminadas, sin ajuste adicional de STP.
Como resultado, a menudo tenemos lo siguiente
- un gran diámetro STP de la red, lo que puede llevar a tormentas de broadcast
- el root de STP se determinará al azar (en función de la dirección MAC) y la ruta del tráfico será subóptima
- los puertos conectados a hosts no se configurarán como edge (portfast), lo que llevará a recalcular STP al encender/apagar estaciones finales
- la red no estará segmentada a nivel L1/L2, lo que provocará que cualquier problema con un switch (por ejemplo, sobrecarga de energía) lleve al recalculo de la topología STP y a la detención del tráfico en todas las VLAN de todos los switches (incluyendo el segmento crítico en términos de continuidad del servicio)
Ejemplos de errores en el diseño L3 (OSI)
Algunos errores característicos de los nuevos en redes:
- uso frecuente (o uso únicamente) de enrutamiento estático
- uso de protocolos de enrutamiento no óptimos para este diseño
- segmentación lógica no óptima de la red
- uso no óptimo del espacio de direcciones, lo que impide la agregación de rutas
- falta de rutas de respaldo
- falta de respaldo para el gateway por defecto
- enrutamiento asimétrico durante la reconfiguración de rutas (puede ser crítico en el caso de NAT/PAT, firewalls con estado)
- problemas de MTU
- durante la reconfiguración de rutas, el tráfico pasa por otras zonas de seguridad o incluso por otros firewalls, lo que resulta en que este tráfico sea descartado
- mala escalabilidad de la topología
Criterios de evaluación de la calidad del diseño
Cuando hablamos de óptimo/no óptimo, debemos entender en función de qué criterios podemos evaluar esto. Desde mi perspectiva, los criterios más relevantes (pero no todos) son los siguientes (y la interpretación aplicada a los protocolos de enrutamiento):
- escalabilidad (scalability)
Por ejemplo, si decide agregar otro centro de datos. ¿Qué tan fácilmente puede hacerlo? - facilidad de gestión (managability)
Qué tan fácil y seguro es realizar cambios operativos, como el anuncio de una nueva red o la filtración de rutas - disponibilidad (availability)
qué porcentaje del tiempo su sistema proporciona el nivel de servicio requerido - seguridad (security)
qué tan protegidos están los datos transmitidos - precio
Cambios
El principio fundamental en esta etapa se puede expresar con la fórmula «no hacer daño».
Por lo tanto, incluso si no está completamente de acuerdo con el diseño y la implementación elegida (configuración), no siempre es prudente realizar cambios. Un enfoque razonable es clasificar todos los problemas identificados según dos parámetros:
- qué tan fácil es resolver este problema
- qué tan grande es el riesgo que conlleva
Primero, es necesario abordar lo que actualmente reduce el nivel de servicio proporcionado por debajo de lo aceptable, por ejemplo, problemas que conducen a la pérdida de paquetes. Luego, resuelva lo que sea más fácil y seguro corregir en orden de reducir la gravedad del riesgo (desde problemas en el diseño o configuración que conllevan altos riesgos hacia menores).
El perfeccionismo en esta etapa puede ser perjudicial. Lleve el diseño a un estado satisfactorio y sincronice la configuración de la red de acuerdo con él.
Fuente: habr.com
