¿Cómo documentar una red?

No estoy seguro de cómo hacer esta pregunta, ya que no estoy en el campo. Digamos que eres un administrador de red y dejas tu trabajo. ¿Cómo sabe el chico nuevo por dónde empezar?

Depende del tamaño de la red, el número de usuarios, el número de nodos (computadoras, servidores, impresoras, etc.) y el tamaño de su personal de TI, entre otras cosas.

También depende de tu objetivo. ¿Está documentando la red con fines de capacitación y mantenimiento, seguro / prevención de pérdidas, etc.?

Personalmente, documento mis redes de tal manera que sé que puedo derivar cualquier información faltante basada en lo que está documentado. Desde una posición práctica, hay un punto de rendimientos decrecientes cuando su documentación se vuelve demasiado granular.

Una buena regla general que uso es que debe haber documentación en una ubicación conocida que sea lo suficientemente exhaustiva como para que si me atropella un autobús esta noche, otro administrador pueda mantener la red central en funcionamiento mientras completa las piezas que faltan próximos días / semanas.

Aquí hay una descripción general de lo que creo que es más importante sobre una de mis redes. Para el registro, esta es una tienda solo para Windows con aproximadamente 100 usuarios y 5 oficinas.

• Credenciales de administrador para todos los servidores. Obviamente, esto debe mantenerse seguro.
• Direcciones IP y nombres NetBIOS para cualquier nodo en la red con una dirección IP estática, incluidos servidores, estaciones de trabajo, impresoras, firewalls, enrutadores, conmutadores, etc.
• Información básica del hardware del servidor, como etiquetas de servicio o equivalente, capacidad total del disco, RAM total, etc.
• Funciones principales de cada servidor, como controlador de dominio, servidor de archivos, servidor de impresión, servidor de terminal, etc.
• Ubicación de cintas / unidades de respaldo.
• Información sobre los números de cuenta y las credenciales para servicios como proveedores de voz y datos de oficinas remotas.
• DNS externo para sitios web y enrutamiento.

Si hubiera algo extraño acerca de una configuración o flujo de trabajo que no fuera obvio de inmediato para un nuevo administrador, también escribiría un breve "breve" al respecto.

Creo que es mejor incorporar todo lo siguiente:

• Prosa: una descripción general en forma de párrafo, que ayuda con el panorama general inicial y también puede describir la evolución en el tiempo
• Tablas: listas tabulares, ya sea con dirección, con entorno o con máquina (preferiblemente todas las anteriores)
• Diagramas: definitivamente necesitan diagramas con múltiples niveles de detalle. En cualquier red de tamaño decente, es simplemente imposible capturarlo todo en una sola página y hacerlo fácilmente digerible. Desea un diagrama a nivel global, con dispositivos de infraestructura (enrutadores, conmutadores, puntos finales de túnel, etc.), y otros varios para los recursos informáticos de cada uno de esos enrutadores o puntos finales.

Notas adicionales sobre diagramas ... La distribución geográfica es una forma fácil de segmentar, pero también necesita vistas lógicas basadas en la función de instalación. Además, etiquete como loco, haciendo uso completo de tipos de letra y colores.

La forma más efectiva y completa de comenzar este proceso es construirlo desde un escenario de recuperación de desastres, por ejemplo, el edificio se incendió y todo lo que tenemos son las copias de seguridad externas. ¿Qué necesitaremos comprar primero y cómo será necesario configurarlo?

Kyle ya dio grandes detalles, pero creo que el enfoque de DR me ayuda a tomar las cosas de una en una.

La respuesta de Kyle es un gran consejo. Sin embargo, como mínimo, probablemente podría salirse con la suya:

• Servidores (incluye nombres de host, IP y roles)
• Hardware de red (conmutadores, enrutadores, firewalls)
• Archivos de contraseñas maestras (contraseñas de dominio, contraseñas de administrador)
• Un documento aproximado que describe las políticas de red y cualquier configuración extraña (incluya aquí valores atípicos como máquinas que no forman parte del dominio o dominios)

Donde trabajo: enfrentamos el mismo problema cuando comencé aquí. A medida que aumenta el número de servidores y servicios, encuentra más y más documentación desactualizada, y con eso viene la actitud inevitable de que el personal no confíe en la documentación, al menos la documentación técnica sobre nombres de servidores, grupos de servidores, redes, etc.

Comenzamos a desarrollar un proyecto de código abierto llamado hotwire para abordar esto ...

• Sistema de inventario (servidores, redes, etc.)
• Construcciones de servidor: RHEL Kickstart, SuSE AutoYaST, (TODO: Debian Preseed, Solaris Jumpstart)

Al combinar el sistema de inventario con el sistema de compilación, nos aseguramos de que lo que está en la base de datos sea consistente con lo que hay en nuestros centros de datos, porque ahora tenemos que ingresar los datos en el inventario primero para poder construir los servidores .

Luego se instala un programa cliente (funcwire) en todos los servidores (como parte del proceso de compilación) que luego vigila dinámicamente el hardware del servidor según lo informado por python-dmidecode y lo que hay en el inventario, por lo que si algo cambia, los administradores Lo sabremos de inmediato.

Luego hemos integrado nuestro sistema wiki para que cada servidor, rack, proyecto, modelo de hardware, etc. en enlaces hotwire directamente a la página wiki correspondiente.

Por lo tanto, hemos "documentado" nuestros servidores / red / etc. utilizando hotwire + a wiki (aquí utilizamos confluencia, pero cualquier wiki decente servirá). (Sin embargo, tenga en cuenta que una vez que los servidores están construidos, hotwire no los modifica de ninguna manera, la administración continua se realiza a través de cfengine).

Utilizo MikroTik Dude para mapear las cosas automáticamente, esta es una aplicación increíble teniendo en cuenta que es gratis. También puede monitorear el estado actual. Página web de tipo

En general, tiene algunos niveles diferentes de detalles similares a las abstracciones en la documentación de diseño de software. También documenta las prácticas / procedimientos / configuración generales del dispositivo. Contraseñas administrativas según corresponda.

En una situación ideal, casi todo lo que pueda necesitar la próxima persona es fácilmente accesible y documentado entre sus guías y documentos de procedimientos + diagramas de diseño de red.

Los lineamientos y los documentos de procedimiento deberían, en mi opinión, estar centralizados donde sea que estén todos los documentos de TI, y los diagramas de red pueden tener su propia estructura de carpetas para múltiples ubicaciones.

En el caso de muchos sitios satelitales, como un Walmart / Targer / Home Depot, tendría un documento genérico para todas las sucursales, y luego algunos documentos detallados de corporaciones completas de las interconexiones de la oficina principal y luego podría sumergirse en los documentos LAN de la oficina.

Enfoque que documenta una red como un desarrollador se acerca al desarrollo de un sistema ...

• Tenga en cuenta los requisitos: esto se ha señalado anteriormente, pero considere que la OMS consultará el documento y para QUÉ PROPÓSITO. Los auditores buscarán y leerán diferentes artefactos que un SysAdmin de igual.

• Mantenimiento de documentos: muchas personas han mencionado el valor de los diagramas y mapas, y como pensador visual estoy totalmente de acuerdo. PERO esas cosas pueden ser invalidadas con un solo acto de agregar / eliminar un host. Piense en el "nivel correcto" de doc-o, uno que su grupo pueda mantener.

• Feche todo e incluya notas sobre POR QUÉ configuró la red como lo hizo. Muchas, muchas personas se olvidan de incluir una fecha, pero la FECHA proporciona un puntero a la historia de la red. Es invaluable para la resolución de problemas y mitiga la obsolescencia inherente de la mayoría de los diagramas de red.

• Descargue la documentación en "procesos": muchas veces los procedimientos de construcción / implementación sólidos y bien diseñados terminan simplificando la "documentación de la red" porque los detalles de la configuración y el nombre de la máquina se describen mejor en los procedimientos.

Conclusión clave: enfoque de la documentación como un 'sistema'; debe proporcionar valor desde el día 1 y conlleva una responsabilidad inherente de mantenerlo.

En nuestro sitio, utilizamos varios sistemas para documentar nuestras propias redes y las de nuestros clientes. Probamos y fallamos con muchas técnicas / herramientas que no escalaron, pero ahora estamos bastante preparados con lo siguiente:

• DokuWiki para consejos, descripciones detalladas de configuraciones y
• Tablas (Patchport / MAC / IP / Nombre de host / Rol / Búsqueda de administrador para todos los dispositivos, Redes / VLAN / VPN, Descripción del hardware, etc.)
• RSS para difundir cambios de páginas wiki
• Visio (la mejor compañía que M $ compró ...) para dibujar diagramas de todo
• KeePass para contraseñas, incluidos inicios de sesión para sistemas de tickets de proveedores
• RackTables para documentar dónde están ubicados y parcheados los dispositivos
• Sistema de tickets, accesible para clientes
• WhatsUp Gold y otras herramientas para monitorear e informar
• Listas de correo para mantener a las personas actualizadas

Si se trata con muchas redes IP, phpIP podría ser una solución IPAM adecuada.

Para obtener más tutoriales sobre cómo / qué documentar, hay networkdocumentation.com .

Para algunos buenos ejemplos, vea ratemynetworkdiagram.com . Por ejemplo, este es bastante bueno , y este es increíble ;).

Kyle Noland y otros carteles han cubierto mucho sobre cómo documentar. Estamos trabajando en la creación de un software estándar basado en la web (alojado internamente por usted) que facilite a los administradores de redes y sistemas documentar su red.

Tenemos los siguientes aspectos cubiertos en el software a partir de este escrito (abril de 2012):

• Documentación del centro de datos.
• Detalles del dispositivo (incluidos los detalles de HW / OS)
• Gestión de direcciones IP
• Mapeo de dependencia de aplicaciones
• Relaciones de dispositivos: desde edificios hasta virtuales / blades.

Puede leer más aquí y agradeceríamos sus comentarios.

Por lo general, no está documentado, pero si está siendo amable, generalmente lo hace en un programa como Visio o un equivalente de código abierto. La información más importante es qué equipo está conectado a qué y las contraseñas de cualquier consola de administración. El resto generalmente se puede adivinar.

En mi carrera anterior como Gerente de TI, mi carpeta de documentación incluía un diagrama de Visio de todos los dispositivos, una lista de las asignaciones de rango de direcciones IP, todas las claves de producto para Windows / Office / Acrobat, instrucciones sobre lo que debe instalarse en los nuevos computadoras con instrucciones paso a paso cómo, completar el inventario de hardware hasta el nivel de componentes y, por último, pero no menos importante, la lista de números de teléfono de emergencia: soporte técnico de ISP, soporte técnico del fabricante del enrutador, etc.

Como se mencionó, depende de varios factores ...

Mi objetivo era tener suficiente documentación para poder (al menos conceptualmente) entregarlo a un compañero de trabajo y decir "nos vemos en 3 semanas", y saber que todos los detalles importantes estaban allí.

• Contraseñas para todos los servidores y dispositivos (conmutadores, impresoras, etc.)
• Contraseñas para cualquier sitio que requiera registro: ISP, registro de nombre de dominio, garantías de hardware, autoridades de certificación, etc.
• Mapa de direcciones IP utilizadas: internas, externas, dmz, bloques de DHCP, etc.
• Detalles de cada servidor: material estándar como número de serie, cantidad de disco, ram, etc., pero también mantuvimos un registro de todo lo que se hizo en la caja, comenzando con las notas de configuración (o / sy la instalación de la aplicación), luego ll configuración y cambios posteriores.

Nunca logré hacerlo por completo, pero mi objetivo era documentar todos los procesos de rutina principales: cómo se configuraron los servidores, cómo y qué se monitoreó, la configuración y eliminación de cuentas, copias de seguridad, etc.

Sugeriré http://opennetadmin.com . Hace muchas de las cosas que la gente ha sugerido en otros comentarios.

Mapear y documentar su red puede ser una buena manera de transferir la información necesaria. MS Visio es una herramienta de diagrama, pero es estática y debe dedicar mucho tiempo a ello. Encontré que NetBrain es una herramienta de diagrama de red ideal para hacer esto. Puede documentar la red al instante y la documentación se puede exportar a Visio o Word. Puedo personalizar los contenidos que quiero mientras documente mi red. Los contenidos personalizados incluyen: 

1. Contenido relacionado con el inventario, como el número de serie, la versión del sistema operativo, etc.
2. Contenidos relacionados con el diseño, como enrutamiento dinámico, QoS, filtrado de tráfico 
3. Contenidos relacionados con la ruta de tráfico ... 
4. Contenido relacionado con el archivo de configuración 
5. Diagrama

Puede intentar documentar su red en el sitio web.

Utilizo herramientas como Microsoft Visio o WhatsUp Gold para mapear la topología de la red si eso ayuda.

MS Visio es una buena manera de documentar una red, pero no es una solución gratuita. Gliffy es un buen producto si buscas mantener tus costos bajos.

Los diagramas de red típicos muestran cómo fluye la información a través de sus dispositivos (y generalmente a Internet). Por lo tanto, debe tener información en su diagrama sobre dónde están ubicadas sus computadoras, impresoras, WAP, teléfonos IP (si corresponde), conmutadores y enrutadores y cómo están conectados. Las direcciones IP también se pueden incluir con el nombre de su dispositivo. Esto es útil si desea echar un vistazo a su diagrama para obtener información sobre la marcha.

NodeSystems es exactamente eso: una herramienta de documentación de red. Como un efecto secundario agradable, creará un diagrama interactivo para usted.

Consulte la demostración en línea: http://www.nodesystems.org/demo/