design - Administrar Cisco programáticamente; Telnet vs SNMP?
network-programming (9)
Hace poco me contactó un ingeniero de red y compañero de trabajo que desea descargar sus deberes menores de administrador de red a un técnico de soporte de nivel junior. La ubicación específica que necesita la 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. Me gustaría proporcionar inicialmente una funcionalidad que podría modificar las listas de control de acceso, las asignaciones de VLAN del puerto y las limitaciones de ancho de banda por VLAN ... agregando más a la lista como se considera valiosa.
Mi pensamiento inicial fue emular una sesión de telnet con el dispositivo de red; utilizando la familiaridad de mi ingeniero de red con la interacción línea de comando / IOS. Se necesitaría un tiempo mínimo para aprender las convenciones de Cisco IOS, yo mismo.
Aunque mientras busca soluciones, parece que la mayoría de la gente prefiere 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?
He encontrado que SNMP es un dolor para la gerencia. Si solo necesitas tomar un poco de datos, es genial; si necesita cambiar las cosas o usarlas en gran medida puede consumir mucho tiempo. En mi caso, me siento cómodo con la CLI, por lo que un enfoque de Telnet funciona bien. He escrito algunas secuencias de comandos de Python para realizar tareas administrativas en varias piezas de la red utilizando Telnetlib
Nota: antes de reinventar la rueda escribiendo otro sistema de provisión de servicios / sistema de gestión de red, intente buscar los existentes. Conozco bastantes soluciones comerciales de diversos grados de flexibilidad / funcionalidad, pero estoy seguro de que hay muchas de código abierto.
SNMP no está mal pero es posible que no pueda hacer todo lo que necesita hacer. Dependiendo de la biblioteca que use y cómo oculta los detalles de la interacción con SNMP puede que le cueste encontrar las partes correctas de la MIB para cambiar e incluso saber qué o cómo cambiarlas para hacer lo que desee.
Una razón para no usar SNMP es que puede hacer toda la configuración que necesita usando la API IOS XR XML . Podría ser mucho más fácil agrupar los comandos que desea enviar a los dispositivos utilizando eso que interactuar con SNMP.
SNMP tiene un golpe de CPU bastante significativo en los dispositivos en cuestión en comparación con telnet; Yo recomendaría telnet siempre que sea posible. (Como se indicó en una respuesta anterior, la API XML de IOS XR sería agradable, pero hasta donde yo sé, IOS XR solo se implementa en enrutadores de grado de operador de gama alta).
En términos de sistemas de gestión de configuración existentes, dos jugadores comerciales son HP Opsware y EMC Voyence. Ambos probablemente hagan lo que necesiten. No conozco muchas soluciones de código abierto que sean compatibles con la implementación de cambios. ( RANCID , por ejemplo, solo hace la monitorización de la configuración, no preestablece e implementa cambios de configuración).
Si va a rodar su propia solución, una cosa que recomendaría es sentarse con su administrador de red y crear un modelo de implementación de mejores prácticas para el servicio que proporciona (por ejemplo, ACL estandarizada, cola QoS y nombres de VLAN; entradas en ACL que tienen la misma función para diferentes clientes, etc.). Asegúrese de que todas las configuraciones implementadas existentes cumplan con esta BP antes de comenzar su diseño, esto hará que el problema sea mucho más manejable. La mejor de las suertes.
No usaría SNMP, sino que miraría un pequeño lenguaje llamado ''esperar''. Es un procesador de espera / respuesta muy agradable para estos enrutadores.
SNMP es ideal para obtener información de un dispositivo de Cisco, pero no es muy útil para controlar el dispositivo. (aunque técnicamente, puede enviar una nueva configuración a un dispositivo Cisco IOS usando 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 de Cisco IOS XR XML. Es importante tener en cuenta que IOS XR XML API solo está disponible en dispositivos que ejecutan IOS XR. IOS XR solo se usa en algunos de los dispositivos de clase portadora de gama alta de Cisco, por lo que para el 99% de todos los enrutadores y conmutadores Cisco, la API IOS XR XML no es una opción.
Otras posibilidades son SSH o HTTP (muchos enrutadores Cisco, switches, AP, etc. tienen una interfaz web opcional). Pero recomendaría contra cualquiera de esos. Que yo sepa, la interfaz web no es muy uniforme en todos los dispositivos, y una cantidad bastante sorprendente de dispositivos Cisco no son compatibles con SSH, o al menos no lo admiten en la licencia base.
Telnet es realmente el único camino a seguir, a menos que solo esté apuntando 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.
Cisco ha incluido opciones de menú para aplicaciones de helpdesk. Básicamente, usted telnet a la caja y presenta un buen menú limpio (presione 1, 2, 3). Para 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 firewalls a través de telnet o SNMP, ssh es el único camino a seguir. El motivo es que ssh cifra su carga útil y no expone las credenciales de administración privilegiadas a una posible intercepción.
Si por alguna razón no puede usar ssh directamente, considere conectar un servidor de consola serie habilitado para ssh al puerto de la consola del firewall y configurarlo de esa manera.
He hecho una cantidad razonable de programación de SNMP en el mundo real con los switches de 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: Cisco Switch Upload a través de Net-SNMP y Python . Debo revelar que fui el coautor del libro al que se hace referencia en el enlace.
El kilometraje de cada persona puede variar, pero personalmente no me gusta usarlo, y prefiero usar SNMP porque en realidad fue diseñado para ser un "Protocolo simple de administración de red". En un apuro, espero que esté bien, pero no sería mi primera opción. Una de las razones por las que algunas compañías esperan es que un desarrollador se acostumbre a esperar. No necesariamente superaría SNMP solo porque hay un ejemplo de alguien que automatiza telnet o ssh. Pruébalo primero.
Puede haber algunas cosas realmente horribles que ocurran con la expectativa, que pueden no ser obvias también. Debido a que espere esperar la entrada, en las condiciones adecuadas, habrá problemas muy sutiles que son difíciles de depurar. Esto no significa que un desarrollador con mucha experiencia no pueda desarrollar código confiable con la expectativa, pero también es algo a tener en cuenta.
Una de las otras cosas que quizás desee ver es un ejemplo de uso del módulo de multiprocesamiento para escribir código SNMP no bloqueante. Debido a que esta es mi primera publicación en , no puedo publicar más de un enlace, pero si 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 una gran cantidad de documentación y hacer prueba y error. En el caso de Cisco, la documentación es bastante buena.