Is it possible to prioritize all types of traffic?

itdaddyitdaddy Senior MemberMember Posts: 2,089 ■■■■□□□□□□
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?

Comments

  • jason_lundejason_lunde Member Posts: 567
    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.
  • TurgonTurgon Banned Posts: 6,308 ■■■■■■■■■□
    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.
  • peanutnogginpeanutnoggin Member Posts: 1,096 ■■■□□□□□□□
    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
    We cannot have a superior democracy with an inferior education system!

    -Mayor Cory Booker
  • stuh84stuh84 Member Posts: 503
    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.
    Work In Progress: CCIE R&S Written

    CCIE Progress - Hours reading - 15, hours labbing - 1
  • peanutnogginpeanutnoggin Member Posts: 1,096 ■■■□□□□□□□
    Thanks for the clarification Stuh!!

    -Peanut
    We cannot have a superior democracy with an inferior education system!

    -Mayor Cory Booker
  • burbankmarcburbankmarc Member Posts: 460
    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
  • rakemrakem Member Posts: 800
    The standard is 4 classes... sometimes 6. Getting more granular just makes it a management nightmare imo
    CCIE# 38186
    showroute.net
  • itdaddyitdaddy Senior Member Member Posts: 2,089 ■■■■□□□□□□
    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...icon_thumright.gif
Sign In or Register to comment.