Is it possible to prioritize all types of traffic?

itdaddy

Hello CCIEs

can you tell me if it is possible to prioritize data in a granular way like you
priorities voice and data and voice having priority over data. This is how
I see our traffic on our network.

Voice 1
Data 2

voice always has priority over data. always.
but data is lumped in one big pile so first come first serve kind of thing.

I have read briefly that it is possible to prioritize Data into something like this:
1 Voice
2 Data
2a 9600 traffic
2b 443 traffic
2c printer traffic
2d 23 traffic
3 Data other like copying files or ftp transfer etc...


something likethat I need data to have some priority

this should be possible? rightor is a nitemware bottlenecking thing?

jason_lunde

It is absolutely possible man. QoS is not something to take lightly though. You have to educate yourself on it b/f you try to implement, or even plan for it. If you really want to look into doing something like this pick up Wendall Odom's Qos book, or the end-to-end book. The MQC will do everything you need to do in a case like this.

Turgon

itdaddy wrote: »

Hello CCIEs

can you tell me if it is possible to prioritize data in a granular way like you
priorities voice and data and voice having priority over data. This is how
I see our traffic on our network.

Voice 1
Data 2

voice always has priority over data. always.
but data is lumped in one big pile so first come first serve kind of thing.

I have read briefly that it is possible to prioritize Data into something like this:
1 Voice
2 Data
2a 9600 traffic
2b 443 traffic
2c printer traffic
2d 23 traffic
3 Data other like copying files or ftp transfer etc...


something likethat I need data to have some priority

this should be possible? rightor is a nitemware bottlenecking thing?

QoS you need to think through. People get hung up on the configuration. It's more important you get hung up on the requirements first, then the the technology options and then the design. You cannot get more than you have to play with. You must decide which traffic is important from a delay and bandwidth perspective and go from there. The mechanisms available on your equipment will offer constraints. You must consider end to end. Classification of traffic is important. They policies. You can police, you can prioritise, you can queue, you can shape and you can use congestion avoidance. I would advise that you are not too granular in your traffic types.

peanutnoggin

As Turgon said, you can use many tools and mechanisms to prioritize your traffic. Don't get so granular on your traffic because it'll be a nightmare trying to sort out requirements. Also, with larger data packets, you can use Link Fragmentation with Interleaving (LFI) to chop up those large data packets and allow your voice packets to "jump ahead". Kevin Wallace provides an excellent basic tutorial on some QoS configurations at his website: 1 Exam a Month and the books mentioned by Jason are also top notch. Pickup one of the QoS books before you try to implement QoS. Just a suggestion...

HTH

-Peanut

stuh84

peanutnoggin wrote: »

As Turgon said, you can use many tools and mechanisms to prioritize your traffic. Don't get so granular on your traffic because it'll be a nightmare trying to sort out requirements. Also, with larger data packets, you can use Link Fragmentation with Interleaving (LFI) to chop up those large data packets and allow your voice packets to "jump ahead". Kevin Wallace provides an excellent basic tutorial on some QoS configurations at his website: 1 Exam a Month and the books mentioned by Jason are also top notch. Pickup one of the QoS books before you try to implement QoS. Just a suggestion...

HTH

-Peanut

Only issue with LFI is its only useful up until a certain link speed/bandwidth (I believe its quoted as 768kbps in the QoS Cert guide, but I'd say about 1.5 meg and up just to be safe), as after a certain point, the time it takes to get a full packet (1500 byte) will be less than the delay that Voice needs a guarantee of. At that point, just throw an LLQ on, and make sure it gets serviced before anything else waiting already.

peanutnoggin

Thanks for the clarification Stuh!!

-Peanut

burbankmarc

Definitely get Odom's QoS book.

Amazon.com: Cisco QOS Exam Certification Guide (IP Telephony Self-Study) (2nd Edition) (0619472201244): Wendell Odom, Michael J. Cavanaugh: Books

That book will teach you almost everything you need to know about QoS. I was disappointed with it's coverage of L2 QoS, but that can be supplemented with Cisco white papers.

Give yourself about 1-2 months of research/study. Once you cover the book and go over the Cisco white papers you should be ready to solve almost any QoS scenario.

Catalyst 3560 Switch Software Configuration Guide, Rel. 12.2(25)SEE - Configuring QoS [Cisco Catalyst 3560 Series Switches] - Cisco Systems
Cisco Catalyst 3750 QoS Configuration Examples [Cisco Catalyst 3750 Series Switches] - Cisco Systems

rakem

The standard is 4 classes... sometimes 6. Getting more granular just makes it a management nightmare imo

itdaddy

wow thanks guys
yeah I just want to priorities some traffic over others like

we have client software that travels across then network. But check this out. I was thinking today things will change big time once I put in
Terminal services and we use the thin client for our workstations,
then the graphics will be traversing network and not so much the same data that use to be. So I need to rethink how that will play out. Because
the only thing traversing the WAN will be graphics for ther terminal server thinclients and not the other old traffice. Which I am pumped about but would like to prioritize:

1 voice
2. data
2a. terminal service traffice
2b all other traffic

is that simple enough for youguys! HAHA

But serious that should be it. we have backups that run across our T2 lines and well they suck the life out of them. but I think above will be perfect. have any of you guys experience a switch in traffic shapping when you have migrated to Terminal services and the thin clients??
gonna be a cool project. And I hear yo loud and clear before I start messing with Qos believe me if I dont have it down in my lab, no go on the production. I do have some consulting engineers I will for sure consult with...