como obter scp via snmp para trabalhar com roteadores Cisco?

10

Eu tenho uma configuração de laboratório onde estou tentando usar o SCP via SNMP para um roteador Cisco. Encontrei alguma documentação on-line, como: http://ccie20728.wordpress.com/2008/05/05/20/get-the-cisco- configuration-over-snmp /

Aqui está minha configuração de alto nível. No roteador:

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 o roteador atue como servidor SCP, é necessário ativar com o cmd acima. Em um servidor ubuntu, tenho o openSSH instalado / executando e executando este 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

Em seguida, para verificar qual é o status, eu faço um snmpget e / ou snmpwalk atravé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

quando executo isso, obtenho o número inteiro (2), o que significa que está em execução, e depois o número inteiro (4), o que significa que falhou.

Depois, verifico o motivo da falha:

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

e recebo o número inteiro (2), que significa "nome do arquivo inválido".

Então, eu tentei permutações diferentes de um nome de arquivo para ".6.111 string" acima, incluindo diferentes extensões de arquivo, com e sem hífens, o mesmo nome de arquivo de configuração dos cmds, até mesmo o nome absoluto especificado do caminho, mas nenhum parece funcionar.

Tentei depurar o sshdarquivo com vários níveis de log e não obtive saída do arquivo syslog salvo / armazenado.

Alguém conseguiu fazer isso funcionar?

user1609
fonte
aqui estão duas outras ligações que eu usei para documentação: tools.cisco.com/Support/SNMP/do/... e cisco.com/en/US/tech/tk648/tk362/...
user1609
Para descartar problemas no servidor SCP, ele está funcionando se você executar a cópia manualmente do seu roteador? Eu me lembro de algum servidor TFTP que não nos permitiu criar novos arquivos enquanto escrevia nele, então primeiro tivemos que criar um arquivo vazio no lado do servidor e depois executar a cópia com o arquivo de destino apontando para o nome do arquivo vazio
Daniel Yuste Aroca
sim, eu tentei isso muito manualmente do roteador para o servidor via scp e funcionou bem. Consegui copiar o arquivo manualmente para o servidor, mesmo sem antes criar um arquivo vazio.
user1609
Alguma resposta o ajudou? Nesse caso, você deve aceitar a resposta para que a pergunta não apareça para sempre, procurando uma resposta. Como alternativa, você pode fornecer e aceitar sua própria resposta.
Ron Maupin

Respostas:

6

Eu apenas tentei isso no meu 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 a execução do config (4) para a rede (1), trocando-os, você pode alterar a direção (da rede para a execução).

Executando acima do script, meu diretório pessoal terá o arquivo 'filename', que contém o meu 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 ~]% 

Além do que @daniel também menciona, seu '14' ou 'rowstatus' está errado, você usa 1 'ativo', enquanto você deve usar 4 'createAndGo'.

ytti
fonte
tentei novamente alterando "14" para o número inteiro 4 e ainda recebendo erro no pacote, Razão: valor inconsistente. Eu até limpei o snmpset com "6", como você sempre fez. a propósito, você conseguiu fazê-lo funcionar com a configuração acima?
user1609
Sim. Acima funciona muito bem no meu 881G rodando 15.1 (2) T5. Eu adicionei a saída do script. Se eu tenho esse índice / id (9) suspenso, recebo a mesma reclamação de 'valor inconsistente', leva muito tempo para que você possa destruí-lo. Você pode testar com um novo índice / ID para ter certeza.
ytti
tentei com índice / ID diferente, ainda não está acontecendo. Vou tentar um dispositivo diferente. talvez este dispositivo específico não seja realmente suportado. O fato é que, mesmo na matriz Cisco mib e software, isso mostra que esses MIBs são suportados pelo IOS atual no qual estou testando.
user1609
Já é bem antigo o MIB, como talvez 5 a 10 anos. Então provavelmente não é isso. De IOS CLI faz este trabalho: 'copy running-config scp: // usuário: senha @ servidor / filename'
ytti
sim, fazer uma cópia scp manual do roteador para o servidor funciona bem. Posso até criar um agendador kron ou script EEM para fazer isso e funciona bem ao fazer o scp do roteador para o servidor. só não via SNMP ...
user1609
4

De acordo com o Cisco SNMP Object Navigator, o valor 4 não é suportado em 1.3.6.1.4.1.9.9.96.1.1.1.1.3. Em vez disso, o valor 2 significa a 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

Provavelmente é por isso que você está recebendo o erro badFileName.

EDITAR:

Na verdade, parece que há contradição entre o SNMP Object Navigator e a MIB Definition , como tipo para ccCopySourceFileTypee ccCopyDestFileTypeé ConfigFileTypee de acordo com a definição MIB:

ConfigFileType ::= TEXTUAL-CONVENTION

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

E isso parece confirmado pela resposta de ytti

Daniel Yuste Aroca
fonte
sim, eu vi isso no mib também, mas mesmo que eu mude para um número inteiro 2, recebo um erro dizendo: *** snmpset -c <str> -v 2c <ip> 1.3.6.1.4.1.9.9 .96.1.1.1.1.3.111 i 2 Erro no pacote. Motivo: wrongValue (O valor definido é ilegal ou não é suportado de alguma forma) Objeto com falha: iso.3.6.1.4.1.9.9.96.1.1.1.1.3.111 *** Tentei diferentes permutações disso também com .3 e. 4 onde talvez o número inteiro fosse diferente em ambos os casos. Estou tentando copiar do roteador para o servidor, que, pelo que entendi, é executado-cfg no arquivo de rede.
user1609
Eu acho que a contradição pode ser porque existem duas gerações de cópia mibs. O original era muito mais simples / estúpido e fazia apenas tftp, não me lembro, mas talvez naquela época 1 fosse de inicialização e 2 em execução.
ytti
este é um bom ponto. parece que as alterações foram feitas com atualizações de código.
user1609
o mib "write-net" foi depreciado (por várias razões) em favor do mib "config-copy", que ainda é a maneira atual de fazer isso.
Ricky feixe
3

Já postei isso antes: http://checkforbees.com/router-backup/

Acho que seu problema é com os vários snmpsets. Você precisa começar criando a entrada para fazer isso. [14.xxx = 5 (createAndWait)] Em seguida, você pode configurar a entrada conforme necessário antes de definir o rowStatus como "1" (ativo).

[Nota: meus scripts têm décadas e, portanto, estão 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

Estou fazendo um loop ... 10.111 (estado) enquanto está "rodando". Eu suspeito que você nunca excluiu sua entrada "111". Caso contrário, essas são as seqüências exatas de snmpsets contra um 2960S com o servidor ssh de uma caixa Linux. (como meu prompt sugere, uma caixa debian.)

Ricky Beam
fonte
Eu tentei de acordo com a sua sugestão, ainda não funcionou :-(. Eu recebo a mesma falha e o motivo da falha. Gostaria de saber se isso deve ter algum bug, em seguida, para este código IOS específico. 12.2 (33) SCF4
user1609
Que dispositivo você está utilizando?
Ricky feixe
vindo a fazer o meu teste em um cisco ubr10k CMTS, também tentou com um cisco 3725 (código 12.4T), obtendo o mesmo resultado
user1609
badFilenametambém pode significar uma falha de login ssh, mas recebo um noConfig(5)por isso. (que é oposto do que ele deve dizer)
Ricky feixe
Recebo um badFileName(2)de 12.4T. (o 2960S é 15.x)
Ricky Beam