comment faire pour que scp via snmp fonctionne avec les routeurs cisco?


10

J'ai une configuration de laboratoire où j'essaie d'utiliser SCP via SNMP sur un routeur Cisco. J'ai trouvé de la documentation en ligne comme: http://ccie20728.wordpress.com/2008/05/20/get-the-cisco- configuration-over-snmp /

Voici ma configuration de haut niveau. Sur le routeur:

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

Afin que le routeur agisse comme serveur SCP, vous devez l'activer avec cmd ci-dessus. Sur un serveur Ubuntu, j'ai openSSH installé / en cours d'exécution et je fais ceci 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

Ensuite, pour vérifier l'état, je fais un snmpget et / ou snmpwalk via:

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

lorsque je lance ceci, j'obtiens l'entier (2), ce qui signifie qu'il fonctionne, puis il passe à l'entier (4), ce qui signifie qu'il a échoué.

Ensuite, je vérifie la raison de l'échec:

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

et j'obtiens l'entier (2), ce qui signifie "mauvais nom de fichier".

J'ai donc essayé différentes permutations d'un nom de fichier pour ".6.111 string" ci-dessus, y compris différentes extensions de fichier, avec et sans hypens, même nom de fichier que l'exécution de cmd de configuration, même nom de fichier de chemin absolu spécifié, mais aucun ne semble fonctionner.

J'ai essayé de déboguer le sshdavec différents niveaux de journalisation et d'obtenir aucune sortie du fichier syslog enregistré / stocké.

Quelqu'un a-t-il pu faire fonctionner cela?


voici deux autres liens que j'ai utilisés pour la documentation: tools.cisco.com/Support/SNMP/do/… et cisco.com/en/US/tech/tk648/tk362/…
user1609

Afin d'éliminer les problèmes sur le serveur SCP, cela fonctionne-t-il si vous exécutez la copie manuellement à partir de votre routeur? Il me semble que je me souviens d'un serveur TFTP qui ne nous permettait pas de créer de nouveaux fichiers pendant l'écriture, donc nous avons d'abord dû créer un fichier vide côté serveur, puis exécuter la copie avec le fichier de destination pointant vers le nom de fichier vide
Daniel Yuste Aroca

oui, j'ai essayé cela trop manuellement du routeur au serveur via scp et cela a bien fonctionné. J'ai pu copier le fichier sur le serveur manuellement même sans créer de fichier vide auparavant.
user1609

Une réponse vous a-t-elle aidé? si c'est le cas, vous devez accepter la réponse afin que la question ne s'affiche pas indéfiniment, à la recherche d'une réponse. Alternativement, vous pouvez fournir et accepter votre propre réponse.
Ron Maupin

Réponses:


6

Je viens d'essayer ceci sur mon 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 ~]% 

Quelle copie exécutant config (4) sur le réseau (1), en les échangeant, vous pouvez changer la direction (du réseau à l'exécution).

En exécutant le script ci-dessus, mon répertoire personnel aura un fichier 'filename', qui contient ma configuration de fonctionnement CPE:

[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 ~]% 

En plus de ce que @daniel mentionne également, votre '14' ou votre 'rowstatus' est faux, vous utilisez 1 'actif', tandis que vous devez utiliser 4 'createAndGo'.


vient de l'essayer à nouveau en changeant "14" en entier 4 et en obtenant toujours Erreur dans le paquet, Raison: valeur incohérente. J'ai même effacé le snmpset avec "6" comme vous l'avez fait à chaque fois. au fait, vous avez pu le faire fonctionner avec votre configuration ci-dessus?
user1609

Oui. Ci-dessus fonctionne très bien sur mon 881G exécutant 15.1 (2) T5. J'ai ajouté la sortie du script. Si j'ai cet index / id (9) suspendu, alors j'obtiens la même plainte de «valeur incohérente», cela prend assez de temps avant que vous puissiez le détruire. Vous pouvez tester avec un nouvel index / ID pour être sûr.
ytti

essayé avec un index / ID différent, ne se produit toujours pas. Je vais essayer un autre appareil. peut-être que ce périphérique spécifique n'est pas réellement pris en charge. Le fait est que, même dans la matrice Cisco MIB et la matrice logicielle, cela montre que ces MIB sont pris en charge pour l'IOS actuel sur lequel je teste.
user1609

C'est assez vieux MIB maintenant, comme peut-être 5 <10 ans. Donc probablement pas ça. À partir de l'IOS CLI, cela fonctionne: `` Copier running-config scp: // username: password @ server / filename ''
ytti

oui, faire une copie manuelle de scp du routeur vers le serveur fonctionne très bien. Je peux même créer un planificateur kron ou un script EEM pour ce faire et fonctionne très bien en faisant scp du routeur au serveur. juste pas via snmp ...
user1609

4

Selon Cisco SNMP Object Navigator, la valeur 4 n'est pas prise en charge pour 1.3.6.1.4.1.9.9.96.1.1.1.1.3. Au lieu de cela, la valeur 2 signifie le 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

C'est probablement pourquoi vous obtenez l'erreur badFileName.

ÉDITER:

Apparemment, il existe une contradiction entre le navigateur d'objets SNMP et la définition MIB , comme type pour ccCopySourceFileTypeet ccCopyDestFileTypeest ConfigFileTypeet selon la définition MIB:

ConfigFileType ::= TEXTUAL-CONVENTION

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

Et cela semble étayé par la réponse de ytti


oui, je l'ai vu aussi dans le mib, mais même si je le change en un entier de 2, j'obtiens une erreur disant: *** snmpset -c <str> -v 2c <ip> 1.3.6.1.4.1.9.9 .96.1.1.1.1.3.111 i 2 Erreur dans le paquet. Raison: falseValue (la valeur définie est illégale ou non prise en charge d'une manière ou d'une autre) Objet ayant échoué: iso.3.6.1.4.1.9.9.96.1.1.1.1.3.111 *** J'ai également essayé différentes permutations de cela avec .3 et. 4 où peut-être l'entier était différent dans les deux cas. Im essayant de copier du routeur au serveur, qui, si je comprends bien, est run-cfg to networkfile.
user1609

Je pense que la contradiction pourrait être due au fait qu'il existe deux générations de mibs de copie. L'original était beaucoup plus simple / stupide et ne faisait que tftp, je ne me souviens pas, mais peut-être qu'à cette époque, 1 était en cours de démarrage et 2 en cours d'exécution.
ytti

c'est un bon point. il semble donc que des modifications aient été apportées aux mises à niveau du code.
user1609

le mib "write-net" a été déprécié (pour de nombreuses raisons) au profit du mib "config-copy", qui est toujours le moyen actuel de le faire.
Ricky Beam

3

J'ai déjà posté ceci: http://checkforbees.com/router-backup/

Je pense que votre problème concerne les multiples snmpset. Vous devez commencer par créer l'entrée pour ce faire. [14.xxx = 5 (createAndWait)] Ensuite, vous pouvez configurer l'entrée si nécessaire avant de définir rowStatus sur "1" (actif).

[Remarque: Mes scripts ont des décennies, ils sont donc réglés pour 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

Je passe en boucle ... 10.111 (état) pendant qu'il "tourne". Je soupçonne que vous n'avez jamais supprimé votre entrée "111". Ce sont autrement votre séquence exacte de snmpsets contre un 2960S avec le serveur ssh d'une boîte Linux. (comme mon invite le suggère, une boîte Debian.)


J'ai essayé selon votre suggestion, mais n'a toujours pas fonctionné :-(. J'obtiens le même échec et la raison de l'échec. Je me demande si cela doit être un bogue alors pour ce code IOS spécifique. 12.2 (33) SCF4
user1609

Quel appareil utilisez-vous?
Ricky Beam

fait mes tests sur un cisco ubr10k CMTS, également essayé avec un cisco 3725 (code 12.4T), obtenant le même résultat
user1609

badFilenamepourrait également signifier un échec de connexion ssh, mais j'obtiens un noConfig(5)pour cela. (ce qui est à l'opposé de ce qu'il devrait dire)
Ricky Beam

Je reçois un badFileName(2)12.4T. (le 2960S est 15.x)
Ricky Beam

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.