| Follow me on:

AutoQos error while generating commands

December 2nd, 2010 | 1 Comment

First of all, the post isn’t about explaining QoS. Configuring AutoQos on Cisco switches should be very easy. At least, that is what all the Cisco documentation tells you. I always thought that the statements about configuration AutoQos were true, but a few days ago I would disagree.

I was configuring multiple switches, Cisco Catalyst 2960-24PC-L switches to be more precise. The switches are configured with a default template, which is generated according the needs of the customer. I uploaded the most recent software into the switches, which is 12.2(55)SE. The customer is going to use an Avaya IP telephony environment, so I tried to apply the appropriate AutoQos command to an interface. After applying the command, I received the following error:

AutoQoS Error while generating commands on Gi0/2

The switches didn’t have any QoS configuration before applying the command. Searching multiple forums didn’t gave me a valid solution. I did my own research and found an incompatibility with the configuration mode exclusion command, like shown below:

configuration mode exclusive auto expire 500 lock-show config-wait 5 retry-wait 5

I removed the configuration mode exclusion command and the AutoQos commands can be implemented without errors. I tried to find why it isn’t possible to apply the AutoQos commands while the configuration mode exclusive command is enabled.

I guess the problem is that the configuration mode exclusive commands prevents other users or the auto-generation of commands to be executed. When applying the AutoQos commands, the commands are executed by the router / switch and not by the user who locked the cli.

PacketShaper Traffic Discovery and Citrix Session Reliability

April 16th, 2010 | No Comments

While troubleshooting some performance issues with Citrix sessions between headquarters and sub locations, I decided to take a closer look at the PacketShaper. The PacketShaper is positioned at the headquarter and does outbound shaping to the sub locations. The PacketShaper is using older software (7.2x), which isn’t necessarily a problem.

I deleted the class for a specific location, created the class again and enabled traffic discovery for that class to check which protocols are used by the sub location.

Traffic Discovery: The PacketWise process of observing and creating traffic classes for all packets as they pass through the unit. This process compiles a list of the protocols and applications in use on a network, creating a traffic tree.

Traffic Discovery is working perfectly, because I see different protocols popping up under the sub locations class under which Citrix. In the past PacketShaper had the opportunity to discover the Published Applications or priority bit tagging used with Citrix. This gave you the opportunity to configure shaping parameters per published application.

Nowadays a lot of Citrix customers use Session Reliability. A major drawback of Session Reliability, in conjunction with a PacketShaper, is the encryption of the data stream. The encryption of the data stream prevents the PacketShaper from discovering the published applications or the priority bit tagging.

I first checked if this problem is solved by the latest software release (8.5 at the time of writing), but it isn’t. BlueCoat acknowledges the problem and describes it in this article. The article contains a link to another article about Manage Citrix Performance, which can be useful when using Citrix without Session Reliability.

Disabling Session Reliability isn’t an option for my troubleshooting, so I guess I have to find another way to troubleshoot the performance issues.

CB-WFQ Bandwidth Allocation

January 13th, 2010 | No Comments

When configuring Quality of Service with CB-WFQ I am always puzzling to get the correct classes. When configuring CB-WFQ it is important to remember that the router does not allow the class queues to consume more than 75% of the total interface bandwidth. The remaining 25% are used for the default class as well as all non-IP packets, like routing protocols.

A quick example shows the problem. I have a router with a 10 Mbps Ethernet interface. I will add a service-policy to this interface and create a priority queue for voice traffic of 8 Mbps.

First I created the class-map and the policy-map:

class-map match-all VOIP
match ip dscp ef
!
policy-map policy-cbwfq
class VOIP
priority 8192

Next I try to apply the policy-map to the interface, but I receive an error-message like shown below:

Router(config)#int fa 0/0
Router(config-if)#service-policy output policy-cbwfq
I/f FastEthernet0/0 class VOIP requested bandwidth 8192 (kbps), available only 7500 (kbps)

The error message clearly tells me that I can use only 75% of the bandwidth for class queues. The router automatically adds a fair-queue configuration to the interface as a fallback.

fair-queue 64 256 256

You can increase the amount of bandwidth for reservation of class queues with the command max-reserved bandwidth. This gives you the opportunity to increase the reserved bandwidth to 90%.

Router(config-if)#no fair-queue
Router(config-if)#max-reserved-bandwidth 90
Router(config-if)#service-policy output policy-cbwfq

The service-policy is now accepted by the router.

Router#sh policy-map interface fa0/0 output
FastEthernet0/0

Service-policy output: policy-cbwfq

Class-map: VOIP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 8192 (kbps) Burst 204800 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0

Class-map: class-default (match-any)
23 packets, 2252 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

A useful with more information (difference between bandwidth percent and bandwidth remaining percent) can be found here.

Campus QoS Design Add-On

June 26th, 2008 | No Comments

Yesterday I attended the QoS Design session and blogged on the subject. After posting the blog on the internet I received an e-mail about a statement in the blog. I placed the following statement on the blog:

“Remember e-mail is NOT mission-critical.”

In the e-mail I received the following comment on this statement.

“What he forgot to mention, and which  is the most important aspect, and the most disruptive part of QoS, is the politics around prioritization of applications.  Everyone’s application is Priority 1, even if it is only e-mail.”

This is indeed correct. Everybody will try to convince you that their applications are the most critical for the application. The process of marking and classification involves a lot of politics.

Purely speaking as a network engineer and in the most circumstances, applications like voice and video conferencing are mission-critical and need more priority in comparison with e-mail and normal web browsing.

Thanks for bringing this up. Hope it is more clear now….

Campus QoS Design

June 25th, 2008 | No Comments

What can somebody tell me about QoS after I passed the Cisco QoS (642-642) exam just one hour ago ?!?!?! ;-). A lot as I noticed from the session.

When designing QoS SLA’s are very important. What are the required latency, jitter and data loss for the different applications, which traffic is really mission-critical and which traffic isn’t?? Remember e-mail is NOT mission-critical.

Voice traffic shouldn’t have more 150ms one-way latency. A call, which traffics the network, will have different kind of latencies, like CODEC, Queuing, Serialization, Propagation and Network Latency.

When designing QoS, classification and marking is the first step taken as closely to the edge as possible. After classifying and marking packets with the correct CoS (Class of Service) and DSCP (Differentiated Services Code Point), you have to configure all uplinks between switches/routers to trust these CoS and DSCP markings.

Policing is one way for congestion management. ISP use policing on customer links. Policing, in an ISP perspective, just drops all traffic about a defined rate (exceeding traffic). With policing you have also the option of marking traffic with different CoS or DSCP values, when exceeding the defined maximum rate. In times of congestion this newly marked packets can be dropped, but when the network isn’t congested, these packets are just allowed through.

Shaping is comparable to policing, but is less aggressive in dropping packets. In cases where packets that exceed a defined maximum rate might be discarded, the sending device may choose just to slow down its sending rate, so that the packets aren’t discarded.

Defining the trust boundary between trusted and untrusted devices is also very important when design QoS implementations. Normally a PC isn’t a trusted devices, so all marking from a PC on packets shouldn’t be trusted. A IP phone normally is a trusted device, so CoS markings from an IP phone should be trusted. QoS can be port-based (default) or VLAN-based. To configure VLAN-based QoS, use the command mls qos vlan-based.

There are a lot more best-practices and considerations when designing and implementing QoS in a network, but this is to much to write down in this blog post. I find QoS very interesting, so if you have any questions about QoS, don’t hesitate to contact me.