The one where we experiment with SNMP and port VLANs …
August 30, 2019
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
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 ccCopySourceFileTypesnmpset -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 ccCopyDestFileTypesnmpset -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 ccCopyEntryRowStatussnmpset -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 ccCopyStatesnmpget -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)