I've looked online and through the user guide but can't find if there is a way to change the QOS sustained download and uplink values on an SU without using radius? I thought I read some where that those values could be altered via an snmp set but now I'm thinking it was for a different radio manufacture because I can't find any details on it. Even if the values can be changed via telnet or ssh I'd be able to make that work. Thanks for your help.
There are a few ways to change an SM's QoS settings without using RADIUS...
- Change via the web management under Configuration on the QoS tab
- Change via cnMaestro
- Change via WirelessManager
- Change via SNMP
Do you know where I can find the documentation to change via snmp? That would be my best solution but I didn't find that info in the User Guide under 14.1.
The authoritative resource for snmp documentation is the MIB itself (matching the software version of course)...
Object ID: 184.108.40.206.220.127.116.11.18.104.22.168
Sustained downlink bandwidth cap.
Object ID: 22.214.171.124.126.96.36.199.188.8.131.52
Burst downlink bandwidth cap.
Object ID: 184.108.40.206.220.127.116.11.18.104.22.168
Maximum burst downlink rate.
Object ID: 22.214.171.124.126.96.36.199.188.8.131.52
Sustained uplink bandwidth cap.
Object ID: 184.108.40.206.220.127.116.11.18.104.22.168
Burst uplink bandwidth cap.
Object ID: 22.214.171.124.126.96.36.199.188.8.131.52
Maximum burst uplink rate.
Thanks that helps me out a lot. I am able to pull the data correctly, now I just need to figure out why snmpset is not working on these radios.
Also in case anyone comes across this post doing a forum search - .184.108.40.206.220.127.116.11.18.104.22.168.0 is the OID for getting the license speed of the radio. Tested on 14.2.1.
Assuming you have the first snmp community string designated read/write instead of read-only, under linux at least the following should work (it does for me):
snmpset -v 2c -c privcomm 10.16.14.22 22.214.171.124.126.96.36.199.188.8.131.52.0 i 2000
(assuming r/w community is "privcomm") on success returns:
Two possible stumbling blocks - if you've been using snmpwalk instead of snmpread, you may not be including the trailing .0, and if you've not used snmpset much it's easy to forget or mis-enter the datatype flag, i for integer in this case.
You hit it right on the head. I was missing the trailing .0 at the end. Once I figured that out its been working great.