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í.

Cómo tomar el control de su infraestructura de red. Capitulo dos. Limpieza y documentación

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
  • ha sido implementado en su empresa proceso de gestión y control de cambios para la red
  • 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.

Por elementos físicos entendemos

  • equipo activo
  • interfaces/puertos de equipos activos

Bajo lógica -

  • dispositivos lógicos (N7K VDC, Palo Alto VSYS, ...)
  • VRF
  • Wealans
  • subinterfaces
  • túneles
  • zona
  • ...

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.

Fuente: habr.com

Añadir un comentario