Monthly Archives: December 2014

Routing / switching

QOS-4-QLIMIT_HQUEUE_VALUE_SYNC_ISSUE.. eh what?

Earlier this week I added a class to a already existing policy which was being used for outbound traffic-shaping. Nothing excited you would say? Well, not really. However.. it turned out that when I created the 15th class under the policy a worrying message appeared in the logging of the router:

%QOS-4-QLIMIT_HQUEUE_VALUE_SYNC_ISSUE

The policy did seem to work but this message was not giving me a warm feeling. So as a typical network engineer of the 21th century, I copied the message into Google in the hope to find out what the poor router was trying to tell me. Literately zero results, so that was very promising.

I knew that it had to be something with queues and the size of it (until the adding of this new class, everything was working fine). So I searched for some basic information about hold queues on ISR routers and how to configure them. I stumbled upon some interesting information, but still no satisfying answer on how to calculate which “hold queue size” was appropriated for my situation. So I reached out to TAC and the information they give me was very helpful, so I want to share it with the Internet 🙂

Once you configure class-based queuing on a ISR router, the default interface hold-queue is being changed to 1000 packets. Every class has a default queue-limit of 64, so once you are configuring the 15th class (which is the 16th if you count the default class, which is always there) you should have a hold-queue of 1024 packets (16*64). The hold-queue is 1000 packets so that is the reason why the message is being displayed. So what size should it be? As always it depends, but in consultation with with TAC I configured it to a size of 1984 packets without any problems and with some grow in mind. This was on a 2901 ISR with 50~70Mbit/s traffic placed as a Internet router (so just some basic routing, ACL’s and traffic-shaping). I hope this information can help you!

Wireless

FlexConnect local authentication with WPA2-PSK

It is almost year 2015 and I was expecting that after 15+ years of wireless 802.11 technology, something like a static “password” for getting secure access to the wireless network is not common anymore. And ofcourse, I was wrong. There are still a lot of devices out there which handle a few (very old) EAP methods or don’t understand dot1X at all. That leaves us with the “pre-shared secret” methods and what if we want to use that at a branch office with a crappy connection to the datacenter / HQ?

Cisco’s FlexConnect with “local authentication” to the rescue! The network traffic is being directly bridged to switchport and when the access-point loses the connection to the WLC, clients will be local authenticated. There is a lot of documentation written about the supported EAP methods and how to configure them, but not for a pre-shared key scenario. So I configured it, tested it and it worked like expected. Curious that I’m, I enabled ssh on the access-point and searched for the pre-shared key in the running configuration. It was not there, so where does the access-point stores this information?

I found out that when I changed the pre-shared key on the WLC a file called “lwapp_non_apspecific_reap.cfg” is being updated on the flash of the access-point. I tried to read it and found out that between a lot of “empty” lines and random chars my SSID and profilenames where in that file in clear text, so my guess is that somewhere in those random chars my “encrypted” pre-shared key is being stored 🙂