I wrote this post during Cisco Live and said “I’ll just give it a once-over tonight and publish it.”  That was something like 6 weeks ago now. What a loser I am.

---

Yes, really. QoS has actually gotten some attention this year. After how many years of living in the dark and being feared by junior and senior engineers alike, we’re seeing some really cool technologies coming out for it.

This is a study note post, so please don’t take this as written.  I’m not the authority on the subject, so please correct me if needed.

Back in the day, somebody decided that we all needed to have a Type of Service (ToS) field in the header of IP packets.  Only God knows what this spawn of Satan wanted to do with it, but we’re stuck with it on the CCIE R&S exams.

Certain divisions of the company tend to shoot themselves in the foot by kicking off large file transfers during business hours, so I had a thought that maybe we could use time-based ACLs to do some QoSing for those guys. I fired up GNS3 with a 3600 running 12.4(25b) with some virtual PCs on it’s Ethernet interfaces.

time-range BUSINESSHOURS
 periodic daily 8:00 to 17:00
!
ip access-list extended PINGS
 permit icmp any any time-range BUSINESSHOURS
!
class-map match-all PINGS
 match access-group name PINGS
!
policy-map PM-F0/0-OUT
 class PINGS

First, I set the router’s time to outside of the time range and sent some pings over.

I’m still working on the ONT test and doing labs, so I marked up a lab for me to work.  I’m using the same setup as I did last time.  The two routers are 3640s running 12.4(25b).

Part of the lab was to identify HTTP traffic coming into F0/0 and mark it as CS3.  That’s pretty easy, right?  Of course, the lab I made up was a little more complicated, but the point comes clear with a simpler example.

I’m still studying for the ONT test, so I did some labs tonight.  One of them was to demonstrate the qos pre-classify command for tunnel interfaces.  When you have a packet sent over a GRE tunnel, the ToS field gets copied to the GRE packet, but there’s no way to see the original packet’s higher-level headers on the way out the interface.  This can be a problem if your service policy needs to see protocol, port, IPs, etc.  The fix for that is to enable qos pre-classify on the tunnel interface and cyrpto map; doing so will provide a copy of the original packet to the physical interface to classify the packet thoroughly.

Here are some more notes from my studies.  Of course, no one cares about them but me, but it’s my blog.  I’m sure someone will find it useful.  Please help to correct dumbass mistakes.

• Congestion

  • Speed mismatch - traffic leaves a lower-bandwidth interface than the one it came in on
  • Aggregation problem - lots of links with one egress of equal bandwidth
  • Confluence problem - a bunch of traffic needs to egress out of the same interface

• Queuing

Here’s another set of notes from my ONT studies.  I’m sure someone will find it useful.  Please help to correct dumbass mistakes.

• Classification is done with traffic desriptors

  • Ingress interface
  • CoS value on ISL or 802.1P frames
  • Source/destination IP address
  • IP Precedence or DSCP value
  • MPLS EXP
  • Application type

• Layer 3 QoS

  • Type of Service (ToS) is 8-bit field.
  • First 3 bits of ToS are the IP precedence.
  • First 6 bits of ToS are the DSCP value.
  • Last 2 bits of ToS are explicit congestion notification (ECN).

• Layer 2 QoS

I’ll try to keep it a little shorter this time.

Major issues for converged enterprise networks

• Available bandwidth: competition among applications
  • Fixes
    • Increase bandwidth: More power!
    • Properly queue based on classification and marking: QoS
    • Compress: cRTP, TCP header compression, etc.
• Delay: Lead time to get a packet to the destination
  • Types of delay
    • Processing delay: routing, switch delay
    • Queuing delay: how long a frame stays in an output queue
    • Serialization delay:  how long to put the frame on the wire
    • Propagation delay: the time to cross the physical medium
• Jitter (delay variation): Variation is the delay
  • Different delays mean different arrival times
  • De-jitter buffers save up packets to reduce jitter (like the old CD writers)
  • Fixes
    • More bandwidth
    • Prioritize sensitive data and forward first
    • Remark (reclassify) packets based on sensitivity
    • Enable L2 payload compression: make sure compression delay isn’t worse than the jitter
    • Use header compression
• Packet loss: Packets are lost in the network somewhere
  • Fixes
    • More bandwidth
    • Increase buffers space: more room for the queue on the interface
    • Provide guaranteed bandwidth: Queuing and QoS
    • Congestion avoidance
      • Random Early Detection (RED) and weighted RED (WRED) drop packets before the queue is full
      • Selective dropping is better than FIFO or LIFO dropping

QoS History

We just talked about tagging traffic and policing traffic, but we haven’t talked about prioritizing traffic. Tagging just sets a value in the header. Policing sets a “bandwidth ceiling” that can’t be crossed. Prioritization guarantees a certain amount of bandwidth for a flow/app/etc. no matter what’s going on.

Prioritization offers you a certain amount of bandwidth; it doesn’t carve it out and hand it over. If you’re using less than the priority value, you only get as much as you need and the rest of the reserved bandwidth goes into the pot for everyone to use. As priority traffic grows, though, you’re given as much as you need up to the configured value. When you go over that, your extra traffic just goes into the best-effort queue with everything else (Note: Don’t go over the limit with VOIP traffic. Echoes and artifacts suck). For example, if you give your VOIP traffic 70% of the bandwidth of an interface but are only using 40%, the other 30% can be used by the other apps on the line. If you’re using 80%, that 10% over is competing with everything else for bandwidth.

We covered QoS tagging the other day, but that just marks packets. I think you’re old enough now that we should actually do some policing. Policing is where you restrict the amount of bandwidth that a flow or set of flows can use. For example, say you have a site that serves webpages to the rest of the network. HTTP is the primary function, but the SysAdmins also have to maintain the boxes via SSH, right? To make sure that their SSH sessions don’t squash the bandwidth that your HTTP servers need, you can police the SSH sessions by giving the a bandwidth ceiling that they can’t cross.

I’ve been trying to get some experience on Cisco VOIP, and, as you probably know, Quality of Service (QoS) is quite important in that realm. Since VOIP is very time-sensitive, you have to be sure your gear delivers the voice packets first. A packet in an HTTP transaction can wait another 200ms without any problems. A voice packet with another 200ms on it means static and digital artifact on the line. Not good. There are lots of things you can do in the world of QoS, but I’ll talk about tagging this time (I may get to some of the other topics later, though).