Cisco QoS vs Packeteer/Exinda abilities

[willemvwyk]

Hello

I was told that we need to put a Packeteer on our network in order to achieve smoother packet flow performance.

Essentially what this means is the following. If I have a Cisco router and a customer with 32Mb bandwidth is exceeding their limit, Cisco can be configured to either burst by using more than the allocated 32Mbs or if no b/width availability it will just drop the packet.

The Packeteer (so I was told) has the ability to "reshape" the packets if the 32Mbps b/width is fully utilized, thus causing traffic to have a smoother flow than the Cisco router.

From my understanding, surely QoS can achieve the same as the packeteer? I do not believe sticking a packeteer on a backbone is a good idea, but I need more technical info regarding this to say why I say so.

Please can you assist and advise what can be done on a router to achieve the same end result?

TIA

wvw

[Joseph W. Doherty]

Cisco router are unable to provide many of the capabilties of appliances like Packeteer's, nor the nice detailed and pretty reports and graphs, but in the real world, Cisco router QoS capabilites are very often "good enough", especially if you manage both sides of a WAN link.

The Cisco feature you described, is a rate limiter or policier, and often is the Civil War surgery version of QoS. Cisco routers can often also shape traffic, and with CBWFQ (class based weighted fair queueing), can pretty well manage traffic when there's congestion, at least outbound.

Packeteer type appliances can often much better manage inbound traffic, but if you also manage the far side's outbound, you may not need to manage inbound.

Cisco routers often now support an AutoQoS feature, but, IMO, can fall short of effective QoS in your specific network. Good chance, a product like Packeteer works better out-of-the-box without needing to fully understand QoS and how to configure it or continue to support it.

To summarize, Cisco router QoS support usually "good enough" if you understand QoS and are willing to configure and support it and you manage the network end-to-end.

Products like Packeteer's do usually offer features beyond Cisco's QoS, although may not be needed, and can ease implementation and support.

[willemvwyk]

Hi Joseph

Thank you for the reply.

One concern I raised was that the Packeteer might cause a bottle neck on the backbone as we are planning to run 1Gb links.

Am I correct by saying that? We would rather have the more "robust" Cisco protocols running at better performance speeds than trying to have a "smooth" packet flow with a huge bottleneck.

[Joseph W. Doherty · Accepted solution]

Not an expert on the Packeteer product line, but very likely they have different product models that are rated for different bandwidth loads. (I.e. much like a 2801, vs. 2851, or 3800, or 7200, etc.) Keeping that in mind, I would certainly agree you would want to insure the device to be used can handle your bandwidth otherwise it could become a bottleneck.

Since you mention gig and backbones, Cisco's higher performing multilayer switches often lose QoS features to provide high speed. (Not always true with some high bandwidth WAN cards that can be placed into the 6500/7600 series.) This often isn't an issue when there's lots of bandwidth on a LAN, but can be critical on a WAN. However, often at the connection to the WAN you can use a more featured, and slower, software router.

Likewise, if you were going to use a Packeteer type product, you might see the most benefit for WAN links of reduced bandwidth. This means you might be able to use a less powerful model if it was placed into a WAN distribution block rather than the main backbone.

Within a LAN, bandwidth can often be "cheaply" added to minimize the need for manipulation of the traffic. For instance, perhaps a gig link can be effectivly doubled by adding another gig link Etherchanneled or as a routed link.