949 Words. Plan about 4 minute(s) to read this.
Although there’s some overlap from the previous blog post that covered MQC, this remaining portion of this OECG chapter discusses how to configure the router for class-based marking, matching a CoS (layer 2 ethernet QoS) to an DSCP value, using NBAR, and closes with a mention of policers and policy-maps.
Configuring Class-Based Marking
- “ip cef” is required.
- MQC class maps drive the packet classification logic.
- Packets matching a particular class will be marked by a policy map. The policy map uses class-maps to determine what packets to mark in a particular way.
- “service-policy in” will apply a policy-map to packets flowing into interface. “service-policy out” will apply a policy-map to packets flowing out of an interface.
- Policy-maps are processed in order. The first class match that a packet makes drives the QoS markings. Subsequent matches are ignored.
- You can perform multiple “set” commands on a class match to set say, both CoS and DSCP.
- If a given packet doesn’t match any of the class-maps, the packet will implictly match a special class known as “class-default”.
- If you don’t have a set command associated with a defined class, then that traffic won’t be marked.
- A number of IOS commands are notable in this context.
- “set [ip] precedence <value>” will mark IPP for IPv4 and IPv6 if the “ip” keyword is left out. If “ip” is included, just IPv4 packets will be marked.
- “set [ip] dscp <value>” will mark DSCP, same notes as above for the “ip” keyword.
- “set cos <value> will mark ethernet frame Class of Service.
- “set qos-group <group-id>” marks the group identifier for the QoS group. [Note – I hope to know later in the chapter what this means. I didn’t see “QoS groups” mentioned anywhere else.]
- “set atm-clp” sets the ATM CLP bit. But you knew that. :-)
- “set fr-de” sets the frame-relay discard eligible bit. And I bet you know that, too.
- “show policy-map <name>” lists all the information about a particular policy map.
- “show policy-map interface-spec [input|output] [class <name>] lists stats about how a policy-map is behaving on a specific inteface.
- “ip nbar protocol-discovery” enables NBAR on interface. [Side note. On a whim, I jacked a 2621XM router with 12.4.12 advanced security IOS into a monitor port on a 2950 that carries the traffic for my home network. I have web servers, database servers, audio servers, e-mail servers, and no life. So, no traffic flowing through the router, but it was getting sent a copy of everything going to/from my public firewall hanging off of the 2950 switch. I flipped on NBAR, hoping to the router would start classifying all the traffic the 2950 was sending its way. No joy. The 2621XM doesn’t even register the traffic on the ethernet counters. I’d have to assume since the traffic isn’t really going to the router (wrong MAC), that the router ignores it. Bummer. I can’t stick the router into the middle of my little production network here, at least not right now, so The Great NBAR Experiment will have to wait.]
- Note that you don’t need “ip nbar protocol-discovery” on 12.2T/12.3 releases, since using a service policy with “match protocol” was enough to imply to the router that NBAR would be used.
- NBAR’s capabilities can be upgraded with Package Description Language Modules, or PDLMs. Check my Links page to see where to download them. Download the PDLM, copy it to flash, then use “ip nbar pdlm <name>” so that NBAR will use the new PDLM.
Class-Based Marking Design
- In general, mark packets as close to the point of entry to the network as possible.
- Keep in mind that you may not want to trust every DSCP or CoS that shows up on the wire. A sysadmin might ratchet all their server’s packets up to EF, for instance. So be smart about when the classification happens. You’re the network guy – keep control of your network.
- The RFCs recommend a number of markings.
- Voice – CoS=5 – IPP=5 = DSCP=EF
- Video payload – CoS=4 – IPP=4 = DSCP=AF41
- Voice/video signalling – CoS=3 – IPP=3 = DSCP=CS3
- Mission-critical data – CoS=3 – IPP=3 = DSCP=AF31/AF32/AF33
- Transactional data – CoS=2 – IPP=2 = DSCP=AF21/AF22/AF23
- Bulk data – CoS=1 – IPP=1 = DSCP=AF11/AF12/AF13
- Best effort – CoS=0 – IPP=0 = DSCP=BE
- Scavenger (less than best effort) – CoS=0 – IPP=0 = DSCP=2,4,6
- Cisco recommends tht you don’t use more than 4 or 5 classes for data traffic. If you use more than that, it’s hard to tell the difference between the classes. Along the same lines, there’s no point in giving too many data classes high-priority services. If the pipe’s too small, it’s too small. Classifying all that traffic as high-priority isn’t going to make a river flow through a straw.
- QoS can be used to police traffic rates. Traffic that has a defined rate and burst size are said to have a traffic contract. If the rate and/or burst size is too high, then the traffic has exceeded the contract; otherwise the traffic conforms to the contract. QoS policies can pass traffic that conforms and drop traffic that exceeds the contract. More sophisticated policies can re-mark a packet, marking down its priority. This means that the packet is more likely to get dropped downstream. We’ll talk more about this in probably a week or 2 when I get into OECG chapter 16. This is all referred to as “class-based policing”.
- You can make routing decisions based on a number of things using PB/policy-based routing. We know this. Using policy routing, you can also set precedence. This is presented as an alternative to class-based marking.
Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks