cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Who Me Too'd this topic

Problems with CISCO-CONFIG-COPY MIB and SCP/SFTP over IPv6

oysteingyland
Level 1
Level 1

I'm using the CISCO-CONFIG-COPY MIB to upload startup-config from a switch using SCP.

I'm experiencing the same problems on multiple switches / IOS versions:

WS-C3560CG-8PC-S  running 15.0(2)SE

WS-C3560CG-8PC-S running 12.2(55r)EX11

WS-2960-8-TC-L running 12.2.58.SE1

WS-2960-8-TC-L running 15.0.2.SE

I'm successfully using these OID's to upload startup-config to 192.168.202.90 using SCP as transfer protocol:

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.14.1370 i 5

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.3.1370 i 3

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.4.1370 i 1

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.5.1370 a 192.168.202.90

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.6.1370 s config-dump

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.7.1370 s username

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.8.1370 s  password

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.2.1370 i 4

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.14.1370 i 1

Now, as 1.3.6.1.4.1.9.9.96.1.1.1.1.5 (ccCopyServerAddress) is deprecated, I've replaced

ccCopyServerAddress with 1.3.6.1.4.1.9.9.96.1.1.1.1.15.1370 (ccCopyServerAddressType) and 1.3.6.1.4.1.9.9.96.1.1.1.1.16.1370 (ccCopyServerAddressRev1).

As far as I've understood, this be the correct usage for uploading startup-config from the switch with SCP.

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.14.1370 i 5

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.3.1370 i 3

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.4.1370 i 1

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.6.1370 s config-dump

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.7.1370 s username

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.8.1370 s password

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.2.1370 i 4 

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.15.1370 i 1

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.16.1370 s 192.168.202.90

snmpset -v2c -c <community> <switch> 1.3.6.1.4.1.9.9.96.1.1.1.1.14.1370 i 1

Using the aforementioned OID's, the switch will silently discard the SNMP commands, there is no attempt to initiate a connection with the SCP server whatsoever.

"debug ip scp" prints out these two lines

Dec  5 09:44:33: SSH CLIENT: attempt to create connection failed

Dec  5 09:44:33: SCP: SSH Client connect failed

Now, If I use TFTP as transfer protocol by assigning 1.3.6.1.4.1.9.9.96.1.1.1.1.2 (ConfigCopyProtocol) to 1, it works as expected. If I try to use SFTP,

by assigning ConfigCopyProtocol to 5, the switch will respond with "wrongValue (The set value is illegal or unsupported in some way)".

What I'm really trying to achieve is to use SCP with IPv6, thus must I use ccCopyServerAddressType and

ccCopyServerAddressRev1 instead of ccCopyServerAddress, as the latter OID is a IPv4 type object.

By the way, TFTP/FTP/RCP upload using IPv6 appears to work (atleast I can see a WRQ/SYN-packet to the correct address when I capture the network traffic).

I'll be grateful for any leads or hints.

-Øystein

Who Me Too'd this topic