In Part 1 we saw we can mark prefixes in CEF with certain attributes that might give us interesting things to play with. In Part 2 we found we could track traffic patterns with the traffic_index tag. We will now turn our attention to the qos-group parameters.
Let’s say we would like four categories of traffic with different QoS.
1 Normal Traffic
2 Super-Duper Important Traffic
3 Scavenger Class
4 I Hate You, Go Away traffic (IHYGO)
Just like the traffic_index classification, we can come up with any breakdown that suits are purposes. Let’s now assume, using secret rites and incantations, that all our prefixes in CEF have already been marked with one of these four qos-groups. We can check this with the show ip cef detail command.
We then apply the following to an interface.
bgp-policy destination ip-qos-map
We are now marking all packets arriving at fa0/0 with the QoS-group based on the IP destination address in the header of the packet. This QoS-group is only locally significant but it will follow the packet to its outbound interface and can be used to write policy.
Note: Although this command starts with “bgp-policy” it is a completely different command from the bgp-policy accounting command. The Cisco documentation merges these two together and is completely confusing. They serve two different purposes and are mutually exclusive.
We can now write a Modular QoS CLI policy (MQC) that takes action on the QoS-group.
class-map match-all NORMAL
match qos-group 1
class-map match-all SUPER
match qos-group 2
class-map match-all SCAVENGER
match qos-group 3
class-map match-all IHYGO
match qos-group 4
priority percent 20
bandwidth percent 5
police rate 8000
The NORMAL class is our “no policy defined” class so we don’t reference it in our policy-map. You could just as well delete the class-map.
We then apply it to fa0/1
service-policy output WAN_LINK_A
We have just produced a policy that will shape and police traffic based on tags in the CEF table. If a qos-group tag in CEF ever changes the QoS dynamically changes on the fly. There are no ACLs to adjust; as soon as the routing table updates with the new information the QoS follows suit.
How is the routing table updated? Well, we generally use a routing protocol to propagate route information throughout an organization. Spoiler: maybe this is where BGP comes in?
You can also use the older Committed Access Rate (CAR) command with qos-group in both the input and output direction.
rate-limit input qos-group 1 2000000 375000 750000 conform-action transmit exceed-action drop
The rate-limit command certainly takes the back seat in popularity to MQC. CAR is clean and concise so it is still found in service provider networks. The QoS-group is applied to the packet before the rate-limit system is hit so the classification will work fine inbound and outbound.
As far as I know you cannot use QoS-group to control the Zone Based Firewall feature or for Policy Based Routing. If someone has found a way to do it, please add a comment!
One limitation to QoS-Group is the tag is only internal to the one router; the policy does not live in the IP header and will not be processed by the next router. In Part 4 we we will see how to overcome this limitation (in a graceful an elegant way, no doubt.)