I was having some trouble getting SNMPv3 up and working on PRTG and Solarwinds. It was a straight forward config but something wasn’t working. The following steps will show how to configure SNMPv3 on Ruckus ZD, and pull info from it on PRTG. Why SNMPv3? it offers a lot of more features such as encryption and user authentication. Definition:
SNMP Version 3 (SNMPv3) adds security and remote configuration capabilities to the previous versions. The SNMPv3 architecture introduces the User-based Security Model (USM) for message security and the View-based Access Control Model (VACM) for access control. The architecture supports the concurrent use of different security, access control, and message processing models. More specifically: Security
First we will configure the ZD
Enable the SNMPv3 agent, and create your user/pass/hash/encryption.
For some reason you have to have a R/W user in the ZD. This does not seem to be a requirement of v3.
Next lets configure PRTG, and find out where I made my mistake.
So everything is pretty straight forward, but I was putting admin in for my context name as well. This was breaking the connection.
The context name is a collection of management information accessible by an SNMP entity. A context is identified by the snmpEngineID value of the entity hosting the management information (also called a contextEngineID) and a context name that identifies the specific context (also called a contextName).
Ruckus does an amazing job finding traffic to be QoS’d, and using a suite of tools to make sure that traffic is delivered as quickly and reliably as possible. They do this with what they call Smartcast. Smart cast is a group of features:
•Traffic queuing on a per client basis (voice, video, best-effort, background)
All of these features work together, but in this post I will just modify the settings for ToS markings and manually classify my traffic.
In wireless QoS there are 4 global hardware queues to place traffic into – voice, video, data and background packets. What happens if one of the wireless clients is sending very slow or having problems it can cause a problem called “Head of line blocking” and will slow everything down from being processed accordingly. Ruckus has helped this by adding 4 software queues for each client! This helps relieve a problem with a misbehaving client and helps get delay sensitive traffic where it needs go. Ruckus also implements Heuristic based classification. This means the look at how the packets are being sent, the gaps and spaces between and classify if its voice/video by preset parameters. But what if you want to know for sure that your data is being put in the right queues — that’s where the below info comes in.
I was working with a client the other day and over some of their private wan links they were having Video issues through Lync. Voice was perfect and the Voice DSCP value was being honored throughout the path. Video was a different story, they were having slight video issues. I know there are many reasons it could be having problems, interference, network issues..etc. I am focusing on wireless QoS though.
We were marking our VOIP/Video packets with DSCP values ef and af41 respectively. Ruckus looks at the ToS value instead of DSCP. I logged into the ZD through CLI and could see what was manually being added to the software queues. See below:
From here you can see the ToS classifications in Hex, and the Heuristics used to detect voice/video/data. I wanted to make 100% sure that my video was in the video queue. So I changed from DSCP af41 Decimal 34 to hex 0x88. To add this I just checked to see what the video was already marked for, and added 0x88 (My DSCP value).
As you can see after adding the 0x88 value to the queue all classifications show up. You could also modify your Heuristic interval from here as well.
Ruckus has lots of documentation on all their greatness and features including some great youtube videos.