ProHoster > Blog > administración > Cómo tomar el control de su infraestructura de red. Capitulo dos. Limpieza y documentación
Cómo tomar el control de su infraestructura de red. Capitulo dos. Limpieza y documentación
Este artículo es el segundo de una serie de artículos "Cómo tomar el control de su infraestructura de red". El contenido de todos los artículos del ciclo y los enlaces se pueden encontrar aquí.
Nuestro objetivo en esta etapa es poner orden en la documentación y configuración.
Como resultado de este proceso, debe tener el conjunto de documentos necesarios y la red configurada de acuerdo con ellos.
Ahora no hablaremos sobre la auditoría de seguridad; la tercera parte estará dedicada a esto.
La complejidad de la tarea en esta etapa, por supuesto, varía mucho 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
de acuerdo con este proceso, tiene documentos (incluidos todos los diagramas necesarios) que brindan información completa sobre el estado actual de las cosas
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 proyecto, sin plan, sin coordinación, por ingenieros que no tienen un nivel de calificación suficiente,
con cambios caóticos, indocumentados, con mucha "basura" y soluciones subóptimas
Está claro que su situación está en algún punto intermedio, pero, desafortunadamente, en esta escala, mejor, peor con una alta probabilidad, estará más cerca del peor final.
En este caso, también necesitará la capacidad de leer la mente, porque tendrá que aprender a comprender lo que querían hacer los "diseñadores", restaurar su lógica, terminar lo que no estaba terminado y eliminar la "basura".
Y, por supuesto, deberá corregir sus errores, cambiar (en esta etapa lo menos posible) el diseño y cambiar o volver a crear los esquemas.
Este artículo no pretende ser completo de ninguna manera. Aquí describiré solo los principios generales y me detendré en algunos problemas comunes que deben resolverse.
conjunto de documentos
Comencemos con un ejemplo.
Los siguientes son algunos de los documentos que se crean habitualmente en Cisco Systems durante el diseño.
CR – Requerimientos del cliente, requerimientos del cliente (asignación técnica).
Se crea junto con el cliente y define los requisitos para la red.
HLD – Diseño de alto nivel, diseño de alto nivel basado en requisitos de red (CR). El documento explica y justifica las decisiones arquitectónicas tomadas (topología, protocolos, selección de equipos,…). El HLD no incluye detalles de diseño como las interfaces y las direcciones IP utilizadas. Además, la configuración de hardware específica no se trata aquí. Más bien, este documento pretende explicar los conceptos clave de diseño a la gestión técnica del cliente.
LLD – Low Level Design, diseño de bajo nivel basado en diseño de alto nivel (HLD).
Debe contener todos los detalles necesarios para la implementación del proyecto, como información sobre cómo conectar y configurar el equipo. Esta es una guía completa para la implementación del diseño. Este documento debe proporcionar información suficiente para su implementación incluso por personal no muy calificado.
Algo, por ejemplo, direcciones IP, números AS, esquema de conmutación física (cableado), puede "renderizarse" en documentos separados, como PNI (Plan de Implantación de la Red).
La construcción de la red comienza después de la creación de estos documentos y se lleva a cabo en estricta conformidad con ellos y luego verificada por el cliente (pruebas) para cumplir con el diseño.
Por supuesto, diferentes integradores, diferentes clientes, diferentes países pueden tener diferentes requisitos para la documentación del proyecto. Pero me gustaría evitar formalidades y considerar la cuestión en cuanto al fondo. Esta etapa no se trata de diseñar, sino de poner las cosas en orden, y necesitamos un conjunto de documentos (esquemas, tablas, descripciones...) suficientes para completar nuestras tareas.
Y en mi opinión, existe un cierto mínimo absoluto, sin el cual es imposible controlar efectivamente la red.
Estos son los siguientes documentos:
esquema (registro) de conmutación física (cableado)
diagrama o diagramas de red con información esencial L2/L3
Diagrama de conmutación física
En algunas empresas pequeñas, el trabajo asociado con la instalación de equipos y conmutación física (cableado) es responsabilidad de los ingenieros de redes.
En este caso, el problema se resuelve en parte mediante el siguiente enfoque.
use una descripción en una interfaz para describir lo que está conectado a ella
cerrar administrativamente todos los puertos de equipos de red no conectados
Esto le dará la capacidad, incluso si hay un problema con el enlace (cuando cdp o lldp no funcionan en esta interfaz), para determinar rápidamente qué está conectado a este puerto.
También puede ver fácilmente qué puertos están ocupados y cuáles están libres, lo cual es necesario para planificar conexiones para nuevos equipos de red, servidores o estaciones de trabajo.
Pero está claro que si pierde el acceso al equipo, perderá el acceso a esta información. Además, de esta forma no podrá registrar información tan importante como qué tipo de equipo, con qué consumo de energía, con cuántos puertos, en qué bastidor está, qué paneles de conexión hay y dónde (en qué bastidor/panel de conexión) están conectados. Por lo tanto, la documentación adicional (no solo las descripciones del hardware) sigue siendo muy útil.
La opción ideal es utilizar aplicaciones diseñadas para trabajar con este tipo de información. Pero puedes limitarte a tablas simples (por ejemplo, en Excel) o mostrar información que consideres necesaria en diagramas L1/L2.
¡Importante!
Un ingeniero de redes, por supuesto, puede conocer bastante bien las complejidades y estándares de SCS, tipos de racks, tipos de fuentes de alimentación ininterrumpida, qué es un pasillo frío y caliente, hacer la puesta a tierra correcta, ... igual que en principio puede saber física de partículas elementales o C ++. Pero debemos entender, sin embargo, que todo esto no es su área de conocimiento.
Por lo tanto, es una buena práctica tener departamentos dedicados o personas dedicadas a resolver problemas relacionados con la instalación, conexión, mantenimiento de equipos, así como conmutación física. Por lo general, para los centros de datos, se trata de ingenieros de centros de datos, y para la oficina, el servicio de asistencia técnica.
Si su empresa proporciona dichas divisiones, entonces los problemas de registro de la conmutación física no son su tarea, y puede limitarse a una descripción de la interfaz y el cierre administrativo de los puertos no utilizados.
diagramas de red
No existe un enfoque universal para dibujar diagramas.
Lo que es más importante, los esquemas deben brindar una comprensión de cómo irá el tráfico, a través de qué elementos lógicos y físicos de su red.
Además, si su red no es completamente elemental, estará compuesta por diferentes segmentos.
Por ejemplo
centro de datos
Internet
WAN
acceso remoto
LAN de la oficina
DMZ
...
Sería conveniente tener varios diagramas que brinden una visión general (cómo viaja el tráfico entre todos estos segmentos) y una explicación detallada de cada segmento individual.
Dado que puede haber muchos niveles lógicos en las redes modernas, probablemente sea un buen enfoque (pero no obligatorio) crear diferentes esquemas para diferentes niveles, por ejemplo, en el caso de un enfoque superpuesto, estos esquemas podrían ser:
superposición
Base L1/L2
base L3
Por supuesto, el esquema más importante, sin el cual es imposible comprender la idea de su diseño, es el esquema de enrutamiento.
esquema de enrutamiento
Como mínimo, este diagrama debe reflejar
qué protocolos de enrutamiento se utilizan y dónde
información básica sobre la configuración del protocolo de enrutamiento (área/número AS/ID del enrutador/…)
¿En qué dispositivos se redistribuyen?
donde se lleva a cabo el filtrado y la agregación de rutas
información de ruta predeterminada
Además, el esquema L2 (OSI) suele ser útil.
Esquema L2 (OSI)
Este diagrama puede mostrar la siguiente información:
qué VLAN
qué puertos son puertos troncales
qué puertos se agregan en ether-channel (canal de puerto), canal de puerto virtual
qué protocolos STP se utilizan y en qué dispositivos
Configuración básica de STP: copia de seguridad raíz/raíz, costo de STP, prioridad de puerto
configuraciones adicionales de STP: protección/filtro de BPDU, protección de raíz...
Errores comunes de diseño
Un ejemplo de un mal enfoque para construir una red.
Tomemos un ejemplo simple de construcción de una LAN de oficina simple.
Al tener experiencia en la enseñanza de telecomunicaciones a estudiantes, puedo decir que prácticamente cualquier estudiante a mediados del segundo semestre tiene los conocimientos necesarios (dentro del curso que dicté) para configurar una LAN de oficina simple.
¿Por qué es tan difícil conectar conmutadores entre sí, configurar VLAN, interfaces SVI (en el caso de conmutadores L3) y configurar enrutamiento estático?
Todo funcionará.
Pero al mismo tiempo, las cuestiones relacionadas con
seguridad
reserva
escalado de red
rendimiento
rendimiento
confiabilidad
...
A veces escucho la afirmación de que una LAN de oficina es algo muy simple y generalmente escucho esto de ingenieros (y gerentes) que hacen cualquier cosa menos redes, y lo dicen con tanta confianza que no se sorprenda si la LAN está hecha por personas con poca práctica y conocimiento y está hecha con aproximadamente los mismos errores que describiré justo a continuación.
Errores típicos de diseño de capa L1 (OSI)
Sin embargo, si también es responsable del SCS, entonces uno de los legados más desagradables que puede obtener es un cambio descuidado y no pensado.
También incluiría errores relacionados con los recursos del equipo utilizado, por ejemplo,
ancho de banda insuficiente
TCAM insuficiente en el equipo (o uso ineficiente del mismo)
rendimiento insuficiente (a menudo denominados cortafuegos)
Errores típicos de diseño de capa L2 (OSI)
A menudo, cuando no hay una buena comprensión de cómo funciona STP, qué problemas potenciales trae consigo, los interruptores se conectan aleatoriamente, con configuraciones predeterminadas, sin ajuste STP adicional.
Como resultado, a menudo tenemos lo siguiente
gran diámetro de red STP, que puede provocar tormentas de transmisión
La raíz STP se determinará aleatoriamente (según la dirección mac) y la ruta de tráfico será subóptima
los puertos que se conectan a los hosts no se configurarán como perimetrales (portfast), lo que hará que se vuelva a calcular el STP cuando se enciendan o apaguen las estaciones finales
la red no se segmentará en el nivel L1 / L2, por lo que los problemas con cualquier conmutador (por ejemplo, sobrecarga de energía) conducirán al recálculo de la topología STP y detendrán el tráfico en todas las VLAN en todos los conmutadores (incluso en el segmento crítico desde el punto de vista de la continuidad del servicio)
Ejemplos de errores en el diseño L3 (OSI)
Algunos errores típicos de los networkers principiantes:
uso frecuente (o solo uso) de enrutamiento estático
uso de protocolos de enrutamiento que no son óptimos para un diseño dado
segmentación de red lógica subóptima
uso subóptimo del espacio de direcciones, que no permite la agregación de rutas
falta de rutas de respaldo
sin redundancia para la puerta de enlace predeterminada
enrutamiento asimétrico al reconstruir rutas (puede ser crítico en el caso de NAT/PAT, cortafuegos llenos de estado)
problemas con la MTU
al redireccionar, el tráfico pasa por otras zonas de seguridad o incluso por otros cortafuegos, lo que provoca que este tráfico disminuya
Poca escalabilidad de topología.
Criterios de evaluación de la calidad del diseño
Cuando hablamos de optimidad/no optimidad, debemos entender en términos de qué criterios podemos evaluarla. Aquí, desde mi punto de vista, están los criterios más significativos (pero no todos) (y la decodificación en relación con los protocolos de enrutamiento):
escalabilidad
Por ejemplo, decide agregar otro centro de datos. ¿Qué tan fácil puedes hacerlo?
facilidad de manejo
Qué tan fácil y seguro es realizar cambios operativos, como anunciar una nueva malla o filtrar rutas
disponibilidad
¿Qué porcentaje del tiempo proporciona su sistema el nivel de servicio requerido?
seguridad
¿Qué tan seguros son los datos transmitidos?
precio
Cambios
El principio básico 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 recomendable realizar cambios. Un enfoque razonable es clasificar todos los problemas identificados de acuerdo con dos parámetros:
con qué facilidad se puede solucionar este problema
cuanto riesgo corre
En primer lugar, debe eliminar las cosas que actualmente reducen el nivel de servicio proporcionado por debajo del nivel aceptable, por ejemplo, los problemas que conducen a la pérdida de paquetes. Luego corrija lo que sea más fácil y seguro de arreglar en orden decreciente de gravedad del riesgo (desde problemas de diseño o configuración que representan un mayor riesgo hasta uno menor).
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.