Sometimes there are network switches in a state that they still pass traffic, still respond to ping, but don’t allow a login (either remotely or locally on the console). This is often a low memory problem.

I encountered this recently where a VLAN change was required to a port, but it was not possible to schedule downtime to reboot the switch (which would then allow a login to the CLI to update the VLAN). Fortunately, SNMP still appeared to be functional.

Cisco

In this case, a Cisco 2960-48TT switch.

$ snmpwalk -v 2c -c RO-COMMUNITY SWITCH ifDescr
…
IF-MIB::ifDescr.10011 = STRING: FastEthernet0/11
IF-MIB::ifDescr.10012 = STRING: FastEthernet0/12
IF-MIB::ifDescr.10013 = STRING: FastEthernet0/13

To change the access VLAN on FastEthernet0/12 from VLAN 10 to VLAN 20:

$ snmpget -v 2c -c RO-COMMUNITY SWITCH 1.3.6.1.4.1.9.9.68.1.2.2.1.2.10012
SNMPv2-SMI::enterprises.9.9.68.1.2.2.1.2.10012 = INTEGER: 10
$ snmpset -v 2c -c RW-COMMUNITY SWITCH 1.3.6.1.4.1.9.9.68.1.2.2.1.2.10012 integer 20
SNMPv2-SMI::enterprises.9.9.68.1.2.2.1.2.10012 = INTEGER: 20
$ snmpget -v 2c -c RO-COMMUNITY SWITCH 1.3.6.1.4.1.9.9.68.1.2.2.1.2.10012
SNMPv2-SMI::enterprises.9.9.68.1.2.2.1.2.10012 = INTEGER: 20

(cf. https://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/45080-vlans.html#t500)

Then to give these changes permanence (i.e. copy running-config startup-config), where X is a random indexing value (in this case, 99):

Set ccCopySourceFileType
snmpset -v 2c -c RW-COMMUNITY SWITCH 1.3.6.1.4.1.9.9.96.1.1.1.1.3.X integer 4
SNMPv2-SMI::enterprises.9.9.96.1.1.1.1.3.99 = INTEGER: 4

Set ccCopyDestFileType
snmpset -v 2c -c RW-COMMUNITY SWITCH 1.3.6.1.4.1.9.9.96.1.1.1.1.4.X integer 3
SNMPv2-SMI::enterprises.9.9.96.1.1.1.1.4.99 = INTEGER: 3

Possible values for ccCopySourceFileType and ccCopyDestFileType are:
1 – networkFile (file on another network device)
2 – iosFile (file on flash)
3 – startupConfig
4 – runningConfig
5 – terminal (file dumped to the console window)

Set ccCopyEntryRowStatus
snmpset -v 2c -c RW-COMMUNITY SWITCH 1.3.6.1.4.1.9.9.96.1.1.1.1.14.X integer 1
SNMPv2-SMI::enterprises.9.9.96.1.1.1.1.14.99 = INTEGER: 1

It’s possible to then monitor the state of the copy as follows:

Get ccCopyState
snmpget -v 2c -c RO-COMMUNITY SWITCH 1.3.6.1.4.1.9.9.96.1.1.1.1.10.99
SNMPv2-SMI::enterprises.9.9.96.1.1.1.1.10.99 = INTEGER: 3

Possible return values for ccCopyState are:
1 – waiting
2 – running
3 – successful (entry no longer write protected)
4 – failure (entry no longer write protected)

If the copy fails, you can check ccCopyFailCause (1.3.6.1.4.1.9.9.96.1.1.1.1.13.X) which will return values as follows:
1 – unknown
2 – badFileName
3 – timeout
4 – noMem
5 – noConfig (possibly source non-existent)

(cf. http://www.notarus.net/networking/cisco_snmp_config.html#wrmem and ftp://ftp.cisco.com/pub/mibs/v2/CISCO-CONFIG-COPY-MIB.my)

Aruba

There are probably similar ways to do this on the Aruba switches (in this case 2930F) – and this probably merits further investigation, but for now the following two OIDs may be of use:

1.3.6.1.2.1.17.7.1.4.3.1.1 – a table of VLANs configured on the switch (dot1qVlanStaticName)
1.3.6.1.2.1.17.7.1.4.5.1.1 – a table of ports showing the access VLAN configured on each port (dot1qPvid)