come ottenere scp tramite snmp per lavorare con i router Cisco?


10

Ho una configurazione di laboratorio in cui sto cercando di utilizzare SCP tramite SNMP su un router Cisco. Ho trovato una documentazione online come: http://ccie20728.wordpress.com/2008/05/20/get-the-cisco- configurazione-over-snmp /

Ecco la mia configurazione di alto livello. Sul router:

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

Per far funzionare il router come server SCP, è necessario abilitarlo con cmd sopra. Su un server Ubuntu, ho openSSH installato / in esecuzione e facendo questo 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

Quindi per verificare quale sia lo stato, eseguo uno snmpget e / o uno snmpwalk tramite:

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

quando eseguo questo, ottengo l'intero (2), il che significa che è in esecuzione, quindi va all'intero (4), il che significa che non è riuscito.

Quindi controllo il motivo dell'errore:

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

e ottengo il numero intero (2), che significa "nome file non valido".

Quindi ho provato diverse permutazioni di un nome di file per ".6.111 stringa" sopra, incluse diverse estensioni di file, con e senza i trattini, lo stesso nome di file che esegue config cmds, persino specificato il nome del file del percorso assoluto ma nessuno sembra funzionare.

Ho provato a eseguire il debug sshdcon vari livelli di registrazione e senza ottenere output dal file syslog salvato / memorizzato.

Qualcuno è stato in grado di farlo funzionare?


ecco altri due link che ho usato per la documentazione: tools.cisco.com/Support/SNMP/do/… e cisco.com/en/US/tech/tk648/tk362/…
user1609

Per eliminare i problemi sul server SCP, funziona se si esegue la copia manualmente dal router? Mi sembra di ricordare alcuni server TFTP che non ci hanno permesso di creare nuovi file durante la scrittura su di esso, quindi prima abbiamo dovuto creare un file vuoto sul lato server e quindi eseguire la copia con il file di destinazione che punta al nome del file vuoto
Daniel Yuste Aroca,

sì, l'ho provato troppo manualmente dal router al server tramite scp e ha funzionato bene. Sono stato in grado di copiare manualmente il file sul server anche senza creare prima un file vuoto.
user1609

Qualche risposta ti è stata d'aiuto? in tal caso, dovresti accettare la risposta in modo che la domanda non continui a comparire per sempre, cercando una risposta. In alternativa, potresti fornire e accettare la tua risposta.
Ron Maupin

Risposte:


6

Ho appena provato questo sul mio 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 ~]% 

Quali copie eseguono config (4) sulla rete (1), scambiandole è possibile cambiare la direzione (dalla rete alla corsa).

Eseguendo lo script sopra la mia directory home avrà il file 'nomefile', che contiene il mio 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 ~]% 

Oltre a ciò che @daniel menziona anche che il tuo '14' o 'rowstatus' è sbagliato, usi 1 'attivo', mentre dovresti usare 4 'createAndGo'.


ho appena provato di nuovo cambiando "14" in numero intero 4 e ancora ottenendo Errore nel pacchetto, Motivo: valore incoerente. Ho anche cancellato lo snmpset con "6" come ogni volta. a proposito, sei riuscito a farlo funzionare con la tua configurazione sopra?
user1609

Sì. Sopra funziona bene sul mio 881G con 15.1 (2) T5. Ho aggiunto l'output dello script. Se ho quell'indice / id (9) in sospeso, ricevo la stessa lamentela "valore incoerente", ci vuole molto tempo prima che tu possa distruggerlo. Per sicurezza, potresti provare con un nuovo indice / ID.
ytti,

provato con indice / ID diverso, ma non si sta ancora verificando. Proverò un altro dispositivo. forse questo dispositivo specifico non è effettivamente supportato. il fatto è che, anche nella matrice cisco mib e software, mostra che questi MIB sono supportati per l'attuale IOS su cui sto testando.
user1609

Ormai è piuttosto vecchio MIB, forse 5 <10 anni. Quindi probabilmente non quello. Dalla IOS CLI fa questo lavoro: 'copia running-config scp: // username: password @ server / nomefile'
ytti

sì, fare una copia scp manuale dal router al server funziona bene. Posso persino creare uno scheduler kron o uno script EEM per farlo e funziona bene facendo scp dal router al server. semplicemente non tramite snmp ...
user1609

4

Secondo Cisco SNMP Object Navigator, il valore 4 non è supportato per 1.3.6.1.4.1.9.9.96.1.1.1.1.3. Invece, valore 2 indica running-config:

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

Probabilmente è per questo che stai ricevendo l'errore badFileName.

MODIFICARE:

In realtà sembra che ci sia contraddizione tra SNMP Object Navigator e la definizione MIB , come tipo per ccCopySourceFileTypeed ccCopyDestFileTypeè ConfigFileTypee secondo la definizione MIB:

ConfigFileType ::= TEXTUAL-CONVENTION

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

E questo sembra supportato dalla risposta di ytti


sì, l'ho visto anche nel mib, ma anche se lo cambio in un numero intero di 2, ricevo un errore che dice: *** snmpset -c <str> -v 2c <ip> 1.3.6.1.4.1.9.9 .96.1.1.1.1.3.111 i 2 Errore nel pacchetto. Motivo: wrongValue (il valore impostato è illegale o non supportato in qualche modo) Oggetto non riuscito: iso.3.6.1.4.1.9.9.96.1.1.1.1.3.111 *** Ho provato anche diverse permutazioni di questo con .3 e. 4 dove forse l'intero era diverso in entrambi i casi. Sto cercando di copiare dal router al server, che a quanto ho capito, è run-cfg al file di rete.
user1609

Penso che la contraddizione potrebbe essere dovuta al fatto che esistono due generazioni di pennini da copia. L'originale era molto più semplice / più scemo e ha appena funzionato, non ricordo, ma forse in quell'era 1 era l'avvio e 2 in esecuzione.
ytti,

è un buon punto. quindi sembra che le modifiche siano state apportate con aggiornamenti del codice.
user1609

il mib "write-net" è stato ammortizzato (per numerosi motivi) a favore del mib "config-copy", che è ancora il modo attuale di farlo.
Ricky Beam,

3

L'ho già pubblicato prima: http://checkforbees.com/router-backup/

Penso che il tuo problema sia con le snmpset multiple. Devi iniziare creando la voce per farlo. [14.xxx = 5 (createAndWait)] Quindi è possibile impostare la voce come necessario prima di impostare rowStatus su "1" (attivo).

[Nota: i miei script sono vecchi di decenni, quindi sono sintonizzati per 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

Sto ripetendo ciclicamente ... 10.111 (stato) mentre è "in esecuzione". Ho il sospetto che tu non abbia mai cancellato la tua voce "111". Quelli sono altrimenti la sequenza esatta di snmpsets contro un 2960S con il server ssh di un box linux. (come suggerisce il mio prompt, una casella debian.)


Ho provato secondo il tuo suggerimento, ancora non ha funzionato :-(. Ottengo lo stesso errore e lo stesso motivo di errore. Mi chiedo se questo debba essere un bug quindi per questo specifico codice IOS. 12.2 (33) SCF4
user1609

Quale dispositivo stai usando?
Ricky Beam,

sto facendo i miei test su un cisco ubr10k CMTS, ho anche provato con un cisco 3725 (codice 12.4T), ottenendo lo stesso risultato
user1609

badFilenamepotrebbe anche significare un errore di accesso ssh, ma ottengo un noConfig(5)per quello. (che è l'opposto di quello che dovrebbe dire)
Ricky Beam,

Ottengo una badFileName(2)da 12.4T. (2960S è 15.x)
Ricky Beam,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.