Pregunta

Hace poco, un ingeniero de redes, un compañero de trabajo, me contactó y me gustaría descargar sus tareas menores de administrador de redes a un técnico de asistencia técnica de nivel inferior. La ubicación específica que necesita administración actúa como un ISP para los inquilinos en su propiedad de un solo sitio, por lo que se realizan muchos pequeños ajustes a diario.

Estoy pensando que sería útil escribirle una aplicación winform para administrar los 32 dispositivos de Cisco, en el sitio. Inicialmente, me gustaría proporcionar una funcionalidad que pueda modificar las listas de control de acceso, las asignaciones de VLAN de puerto y las limitaciones de ancho de banda por VLAN ... agregando más a la lista como se considera valioso.

Mi idea inicial fue emular una sesión de telnet con el dispositivo de red; utilizando la familiaridad de mi ingeniero de redes con la interacción línea de comandos / IOS. Se necesitaría un tiempo mínimo para aprender las convenciones de Cisco IOS, yo mismo.

Aunque al buscar soluciones, parece que la mayoría de las personas prefieren SNMP. Eso, o sus circunstancias específicas, los empujaron en la dirección de SNMP.

Quería saber si he pasado por alto un beneficio obvio de SNMP. ¿Debo usar SNMP? ¿Por qué o por qué no?

¿Fue útil?

Solución

SNMP es excelente para obtener información de un dispositivo Cisco, pero no es muy útil para controlar el dispositivo. (aunque técnicamente, puede insertar una nueva configuración en un dispositivo Cisco IOS utilizando una combinación de SNMP y TFTP. Pero enviar una configuración completamente nueva es un instrumento bastante contundente para controlar su enrutador o conmutador).

Uno de los otros comentaristas mencionó la API XML Cisco IOS XR. Es importante tener en cuenta que la API XML IOS XR solo está disponible en dispositivos que ejecutan IOS XR. IOS XR solo se usa en algunos de los dispositivos de clase de operador de gama alta de Cisco, por lo que para el 99% de todos los enrutadores y conmutadores de Cisco, la API XML IOS XR no es una opción.

Otras posibilidades son SSH o HTTP (muchos enrutadores, conmutadores, AP, etc. de Cisco tienen una interfaz web opcional). Pero recomendaría contra cualquiera de esos. Que yo sepa, la interfaz web no es muy consistente en todos los dispositivos, y un número bastante sorprendente de dispositivos Cisco no admite SSH, o al menos no lo admite en la licencia base.

Telnet es realmente el único camino a seguir, a menos que solo se dirija a una pequeña gama de modelos de dispositivos. Para ofrecerle algo con lo que comparar, el software de administración de red CiscoWorks de Cisco utiliza Telnet para conectarse a dispositivos administrados.

Otros consejos

No usaría SNMP, en lugar de eso, vería un pequeño lenguaje llamado "esperar". es un procesador de expectativa / respuesta muy bueno para estos enrutadores.

He realizado una cantidad razonable de programación SNMP en el mundo real con conmutadores Cisco y encuentro que Python en la parte superior de Net-SNMP es bastante razonable. Aquí hay un ejemplo, a través de Google books, de cargar una nueva configuración de Cisco a través de Net-SNMP y Python: Carga del switch Cisco a través de Net-SNMP y Python . Debería revelar que fui coautor del libro al que se hace referencia en el enlace.

El kilometraje de todos puede variar, pero personalmente no me gusta usar expect , y prefiero usar SNMP porque en realidad fue diseñado para ser un "Protocolo simple de administración de red". En un apuro, esperar está bien, pero no sería mi primera opción. Una de las razones por las que algunas compañías usan el sistema de esperar es que un desarrollador simplemente se acostumbra a usar el sistema de esperar. No necesariamente evitaría pasar por alto SNMP solo porque hay un ejemplo de alguien que automatiza telnet o ssh. Pruébelo usted mismo primero.

Puede haber algunas cosas realmente horribles que suceden con esperar, que también pueden no ser obvias. Debido a que esperar espera por entrada, bajo las condiciones correctas habrá problemas muy sutiles que son difíciles de depurar. Esto no significa que un desarrollador con mucha experiencia no pueda desarrollar un código confiable con la expectativa, pero también es algo a tener en cuenta.

Una de las otras cosas que es posible que desee ver es un ejemplo del uso del módulo de multiprocesamiento para escribir código SNMP sin bloqueo. Debido a que esta es mi primera publicación en stackoverflow, no puedo publicar más de un enlace, pero si lo buscas en Google puedes encontrarlo u otro sobre el uso de IPython y Net-SNMP.

Una cosa a tener en cuenta al escribir código SNMP es que implica leer mucha documentación y hacer pruebas y errores. Sin embargo, en el caso de Cisco, la documentación es bastante buena.

SNMP no es malo, pero es posible que no pueda hacer todo lo que necesita hacer. Dependiendo de la biblioteca que utilice y de cómo oculta los detalles de la interacción con SNMP, es posible que le resulte difícil encontrar las partes correctas de la MIB para cambiar e incluso saber qué o cómo cambiarlas para hacer lo que desea.

Una razón para no usar SNMP es que puede hacer toda la configuración que necesite usando API XML IOS XR . Podría ser mucho más fácil agrupar los comandos que desea enviar a los dispositivos que usan que interactuar con SNMP.

He encontrado que SNMP es un problema para la administración. Si solo necesitas un poco de información, es genial; Si necesita cambiar las cosas o usarlas si es muy difícil, puede llevar mucho tiempo. En mi caso, me siento cómodo con el CLI, por lo que un enfoque de Telnet funciona bien. He escrito algunos scripts de Python para realizar tareas administrativas en varios equipos de red usando Telnetlib

SNMP tiene un gran impacto de CPU en los dispositivos en cuestión en comparación con telnet; Recomendaría telnet siempre que sea posible. (Como se indicó en una respuesta anterior, la API XML IOS XR sería buena, pero que yo sepa, IOS XR solo se implementa en enrutadores de nivel de operador de gama alta).

En términos de los sistemas de administración de configuración existentes, dos actores comerciales son HP Opsware y EMC Voyence. Ambos probablemente harán lo que necesites. No tengo conocimiento de muchas soluciones de código abierto que realmente admiten la implementación de cambios. ( RANCID , por ejemplo, solo realiza la supervisión de la configuración, no la preparación previa y la implementación de los cambios de configuración).

Si va a implementar su propia solución, una cosa que recomendaría es sentarse con el administrador de su red y proponer un modelo de implementación de mejores prácticas para el servicio que brinda (por ejemplo, ACL estandarizada, cola de QoS y VLAN) nombres; entradas similares en ACL que tienen la misma función para diferentes clientes, etc.). Asegúrese de que toda la configuración implementada existente cumpla con esta BP antes de comenzar su diseño, hará que el problema sea mucho más manejable. La mejor de las suertes.

Sidenote: antes de reinventar la rueda escribiendo otro sistema de aprovisionamiento de servicios / sistema de gestión de red, intente buscar los existentes. Conozco muchas soluciones comerciales de diversos grados de flexibilidad / funcionalidad, pero estoy seguro de que hay muchas de código abierto.

Cisco ha incluido opciones de menú para aplicaciones de servicio de asistencia. Básicamente, hace telnet a la caja y presenta un menú limpio y agradable (presione 1, 2, 3). Para obtener más información, consulte este enlace:

http: / /www.cisco.com/en/US/docs/ios/12_2/configfun/command/reference/frf001.html#wp1050026

Otro voto para esperar.

Además, no desea permitir la configuración de sus cortafuegos a través de telnet o SNMP; ssh es el único camino a seguir. La razón es que ssh cifra su carga útil y no expondrá las credenciales de administración privilegiadas a una posible intercepción.

Si, por algún motivo, no puede usar ssh directamente, considere la posibilidad de conectar un servidor de consola serie habilitado para ssh al puerto de la consola del cortafuegos y configurarlo de esa manera.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top