¿Cómo obtener scp a través de snmp para trabajar con enrutadores Cisco?


10

Tengo una configuración de laboratorio en la que intento usar SCP a través de SNMP en un enrutador Cisco. Encontré documentación en línea como: http://ccie20728.wordpress.com/2008/05/20/get-the-cisco- configuración-sobre-snmp /

Aquí está mi configuración de alto nivel. En el enrutador:

R1(config)# username cisco password cisco
R1(config)# ip domain-name somedomain.com
R1(config)# crypto key generate rsa general-keys modulus 1024
R1(config)# aaa new-model
R1(config)# aaa authentication login cisco local
R1(config)# aaa authorization exec cisco local
R1(config)# ip scp server enable
R1(config)# line vty 0
R1(config)# login authentication cisco
R1(config)# snmp-server community cisco RW

Para que el enrutador actúe como el servidor SCP, debe habilitarlo con el cmd anterior. En un servidor ubuntu, tengo openSSH instalado / ejecutándose y haciendo esto cmds:

snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.2.111 i 4
snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.3.111 i 4
snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.4.111 i 1
snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.5.111 a <svr ip addr>
snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.6.111 s cisco.txt
snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.7.111 s cisco
snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.8.111 s cisco
snmpset -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.14.111 i 1

Luego, para verificar cuál es el estado, hago un snmpget y / o snmpwalk a través de:

snmpwalk -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.10.111

cuando ejecuto esto, obtengo el número entero (2), lo que significa que se está ejecutando, luego va al número entero (4), lo que significa que falló.

Luego verifico el motivo del fracaso:

snmpwalk -c cisco -v 2c <router ip addr> 1.3.6.1.4.1.9.9.96.1.1.1.1.13.111

y obtengo el entero (2), que significa "nombre de archivo incorrecto".

Así que probé diferentes permutaciones de un nombre de archivo para ".6.111 string" arriba, incluidas diferentes extensiones de archivo, con y sin guiones, el mismo nombre de archivo que ejecutando cmds de configuración, incluso el nombre de archivo de ruta absoluta especificado, pero ninguno parece funcionar.

Intenté depurar sshdcon varios niveles de registro y no obtuve ningún resultado del archivo syslog guardado / almacenado.

¿Alguien ha podido hacer que esto funcione?


Aquí hay otros dos enlaces que utilicé para la documentación: tools.cisco.com/Support/SNMP/do/… y cisco.com/en/US/tech/tk648/tk362/…
user1609

Para descartar problemas en el servidor SCP, ¿funciona si ejecuta la copia manualmente desde su enrutador? Parece recordar un servidor TFTP que no nos permitía crear nuevos archivos mientras escribíamos en él, así que primero tuvimos que crear un archivo vacío en el lado del servidor y luego ejecutar la copia con el archivo de destino apuntando al nombre de archivo vacío
Daniel Yuste Aroca

sí, intenté esto también manualmente desde el enrutador al servidor a través de scp y funcionó bien. Pude copiar el archivo en el servidor manualmente incluso sin crear un archivo vacío antes.
user1609

¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.
Ron Maupin

Respuestas:


6

Acabo de probar esto en mi CPE:

[ytti@lintukoto ~]% cat moi2.sh 
#!/bin/sh

snmp="snmpset -v2c -cfoo bu.ip.fi"

$snmp 1.3.6.1.4.1.9.9.96.1.1.1.1.2.9 i 4 \
      1.3.6.1.4.1.9.9.96.1.1.1.1.3.9 i 4 \
      1.3.6.1.4.1.9.9.96.1.1.1.1.4.9 i 1 \
      1.3.6.1.4.1.9.9.96.1.1.1.1.5.9 a 91.198.120.2 \
      1.3.6.1.4.1.9.9.96.1.1.1.1.6.9 s filename \
      1.3.6.1.4.1.9.9.96.1.1.1.1.7.9 s username \
      1.3.6.1.4.1.9.9.96.1.1.1.1.8.9 s password \
      1.3.6.1.4.1.9.9.96.1.1.1.1.14.9 i 4
sleep 10
$snmp 1.3.6.1.4.1.9.9.96.1.1.1.1.14.9 i 6
[ytti@lintukoto ~]% 

Que copia ejecutando config (4) a la red (1), intercambiando estos puede cambiar la dirección (de la red a la ejecución).

Al ejecutar el script anterior, mi directorio de inicio tendrá el archivo 'nombre de archivo', que contiene mi CPE running-config:

[ytti@lintukoto ~]% ls -la filename
ls: cannot access filename: No such file or directory
[2 ytti@lintukoto ~]% ./moi2.sh      
iso.3.6.1.4.1.9.9.96.1.1.1.1.2.9 = INTEGER: 4
iso.3.6.1.4.1.9.9.96.1.1.1.1.3.9 = INTEGER: 4
iso.3.6.1.4.1.9.9.96.1.1.1.1.4.9 = INTEGER: 1
iso.3.6.1.4.1.9.9.96.1.1.1.1.5.9 = IpAddress: 91.198.120.2
iso.3.6.1.4.1.9.9.96.1.1.1.1.6.9 = STRING: "filename"
iso.3.6.1.4.1.9.9.96.1.1.1.1.7.9 = STRING: "username"
iso.3.6.1.4.1.9.9.96.1.1.1.1.8.9 = STRING: "password"
iso.3.6.1.4.1.9.9.96.1.1.1.1.14.9 = INTEGER: 4
iso.3.6.1.4.1.9.9.96.1.1.1.1.14.9 = INTEGER: 6
[ytti@lintukoto ~]% ls -la filename
-rw-r--r-- 1 ytti ytti 16172 Jun 11 00:35 filename
[ytti@lintukoto ~]% 

Además de lo que @daniel menciona también, su '14' o 'rowstatus' está mal, usa 1 'activo', mientras que debe usar 4 'createAndGo'.


solo lo intenté nuevamente cambiando "14" al número entero 4 y aún obteniendo Error en el paquete, Motivo: valor inconsistente. Incluso he borrado el snmpset con "6" como lo hiciste cada vez. por cierto, ¿pudiste hacer que funcione con tu configuración anterior?
user1609

Si. Lo anterior funciona bien en mi 881G con 15.1 (2) T5. Agregué la salida del script. Si tengo ese índice / id (9) colgando, entonces recibo la misma queja de 'valor inconsistente', tomará bastante tiempo antes de que pueda destruirlo. Puede probar con un nuevo índice / ID para estar seguro.
ytti

Lo probé con un índice / ID diferente, todavía no sucede. Voy a probar un dispositivo diferente. tal vez este dispositivo específico no sea realmente compatible. Lo que pasa es que, incluso en la matriz de software y mib de Cisco, muestra que estas MIB son compatibles con el IOS actual en el que estoy probando.
user1609

Es bastante viejo MIB por ahora, como tal vez 5 <10 años. Entonces probablemente no sea eso. Desde IOS CLI hace este trabajo: 'copy running-config scp: // username: password @ server / filename'
ytti

sí, hacer una copia scp manual desde el enrutador al servidor funciona bien. Incluso puedo crear un programador kron o un script EEM para hacer esto y funciona bien haciendo scp desde el enrutador al servidor. simplemente no a través de snmp ...
user1609

4

De acuerdo con Cisco SNMP Object Navigator, el valor 4 no es compatible con 1.3.6.1.4.1.9.9.96.1.1.1.1.3. En cambio, el valor 2 significa la configuración de ejecución:

Object  ccCopySourceFileType
OID     1.3.6.1.4.1.9.9.96.1.1.1.1.3
Type    ConfigFileType
1:startupConfig
2:runningConfig
Permission  read-create

Probablemente por eso está recibiendo el error badFileName.

EDITAR:

En realidad parece que hay contradicción entre SNMP Object Navigator y la definición de MIB , como tipo para ccCopySourceFileTypey ccCopyDestFileTypees ConfigFileTypey según la definición de MIB:

ConfigFileType ::= TEXTUAL-CONVENTION

SYNTAX          INTEGER  {
                        networkFile(1),
                        iosFile(2),
                        startupConfig(3),
                        runningConfig(4),
                        terminal(5),
                        fabricStartupConfig(6) }

Y esto parece respaldado por la respuesta de ytti


sí, también lo vi en el mib, pero incluso si lo cambio a un número entero de 2, aparece un error que dice: *** snmpset -c <str> -v 2c <ip> 1.3.6.1.4.1.9.9 .96.1.1.1.1.3.111 i 2 Error en el paquete. Motivo: Valor incorrecto (el valor establecido es ilegal o no se admite de alguna manera) Objeto fallido: iso.3.6.1.4.1.9.9.96.1.1.1.1.3.111 *** He intentado diferentes permutaciones de esto también con .3 y. 4 donde tal vez el número entero era diferente en cualquier caso. Estoy tratando de copiar del enrutador al servidor, que, según tengo entendido, es run-cfg a networkfile.
user1609

Creo que la contradicción podría deberse a que hay dos generaciones de mibs de copia. El original era mucho más simple / tonto e hizo solo tftp, no recuerdo, pero tal vez en esa era 1 era el inicio y 2 en ejecución.
ytti

ese es un buen punto. Parece que se hicieron cambios con las actualizaciones de código.
user1609

el mib "write-net" se depreció (por numerosas razones) a favor del mib "config-copy", que sigue siendo la forma actual de hacerlo.
Ricky Beam

3

He publicado esto antes: http://checkforbees.com/router-backup/

Creo que su problema es con los múltiples snmpset. Tienes que comenzar creando la entrada para hacer esto. [14.xxx = 5 (createAndWait)] Luego puede configurar la entrada según sea necesario antes de establecer el estado de la fila en "1" (activo).

[Nota: mis scripts tienen décadas de antigüedad, por lo que están ajustados para tftp.]

[root:pts/6{8}]debian1:/tmp/[01:32 AM]:./test.sh
CISCO-CONFIG-COPY-MIB::ccCopyProtocol.111 = INTEGER: scp(4)
CISCO-CONFIG-COPY-MIB::ccCopySourceFileType.111 = INTEGER: runningConfig(4)
CISCO-CONFIG-COPY-MIB::ccCopyDestFileType.111 = INTEGER: networkFile(1)
CISCO-CONFIG-COPY-MIB::ccCopyServerAddress.111 = IpAddress: 192.168.55.25
CISCO-CONFIG-COPY-MIB::ccCopyFileName.111 = STRING: cisco.txt
CISCO-CONFIG-COPY-MIB::ccCopyUserName.111 = STRING: cisco
CISCO-CONFIG-COPY-MIB::ccCopyUserPassword.111 = STRING: cisco
CISCO-CONFIG-COPY-MIB::ccCopyEntryRowStatus.111 = INTEGER: active(1)
..
Status: successful []
CISCO-CONFIG-COPY-MIB::ccCopyEntryRowStatus.111 = INTEGER: destroy(6)
[root:pts/6{8}]debian1:/tmp/[01:32 AM]:ls -l cisco.txt
-rw-r--r-- 1 root root 15790 Jun 12 01:32 cisco.txt

Estoy dando vueltas ... 10.111 (estado) mientras está "ejecutándose". Sospecho que nunca ha eliminado su entrada "111". De lo contrario, son su secuencia exacta de snmpsets contra un 2960S con el servidor ssh de una caja de Linux. (Como sugiere mi mensaje, una caja de Debian).


Intenté según su sugerencia, todavía no funcionó :-(. Obtengo el mismo fallo y la razón del fallo. Me pregunto si esto tiene que ser algún error para este código IOS específico. 12.2 (33) SCF4
user1609

¿Qué dispositivo estás usando?
Ricky Beam

estado haciendo mis pruebas en un CMTS ubr10k de cisco, también probé con un cisco 3725 (código 12.4T), obteniendo el mismo resultado
user1609

badFilenameTambién podría significar un error de inicio de sesión ssh, pero obtengo un noConfig(5)por eso. (que es lo opuesto a lo que debería decir)
Ricky Beam

Recibo una badFileName(2)de 12.4T. (el 2960S es 15.x)
Ricky Beam

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.